• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Remove those deprecated health variables

Gradius

Member
They're already listed as something not to use, any imported project is likely to need editing anyway, and Studio 2's pricing is now a bit of a barrier for really basic learners that might need them.

It's a constant niggling annoyance to have to avoid naming the health variable for an object something sensible like 'health', ditto for lives. And ideally 'score' being free would be nice too.

There's never been a better time to remove them and make variable naming a teensy bit easier.

Heck, surely now is the time - before people start using Studio 2 for actual full projects - to remove those things that were deprecated throughout Studio's lifespan (i.e. globalvar, especially as this can be somewhat prevented from causing import issues by compatibility scripts).
 

Cpaz

Member
While I agree (Primarily since they've changed dnd there isn't nearly as much of a need for them), they're there for backwards compatibility it might seem insignificant, but I'd wouldn't make any assumptions, especially since pretty much no one in the beta knows how imports work (yet?)*.

Again, I agree to a point, but having backwards compatibility is definitely nice to have. Maybe they can deactivate those variables depending on if it's a dnd or gml project. That actually sounds ideal.

*EDIT: Official post on importing old projects: http://help.yoyogames.com/hc/en-us/articles/231719468-Porting-A-GMS-1-4-Game-To-GameMaker-Studio-2
 

mMcFab

Member
They may be here for backwards compatibility, but if they were removed and someone was desperate to use them as prevously, they could just define them as... ugh... globalvars.
Heck, the golbalvars could be added the same way as the compatibility scripts are.
I personally would be happy to see them go.
 
A

Andy

Guest
What benefit would come from removing them? Unless it would give projects a notable performance boost, why not leave them in?
 

mMcFab

Member
It simply would mean we wouldn't have to avoid using those variable names within our instances anymore. It would be way nicer to give an enemy "health" instead of "HEALTH", "_health", "myHealth" etc.
Basically, it makes it faster/easier to type, and helps readability. No other real benefits, however.
 

FrostyCat

Redemption Seeker
What benefit would come from removing them? Unless it would give projects a notable performance boost, why not leave them in?
I'll tell you what it is: Usability for anyone who isn't a total idiot. Performance shouldn't the sole consideration for adding or removing features.

The built-in health, lives and score variables are in the wrong scope for way too many projects, even novice-friendly ones. I've seen way more novice questions about why their health variables (declared at the instance scope) seem to go global for no apparent reason, than complaints about having to declare variables for health. I've been observing this over a decade, and it hasn't changed.

For the first 1% of the time might help a little, but for the remaining 99% of the time it just doesn't help. It sends mixed messages about scope and makes learning harder more often than easier. It also adds to the compendium of unwritten rules that complicate GML rather than making it easier.

Novices with the potential to succeed and buy GM don't need this done for them, and they definitely don't need this done for them wrong. On the other hand, idiots who complain about having to declare variables give up in a matter of days or weeks, and having it done for them doesn't save them for long enough to move onto buying GM.

This is part of the "excessive accessibility" that I've been repeating over the past decade, and GMS 2 is the time to let them go. If GMS 2 is to achieve its full potential, developers at YoYo need to stop prioritizing idiot-proofing over usability beyond the total novice stage.
 
A

Andy

Guest
I've seen way more novice questions about why their health variables (declared at the instance scope) seem to go global for no apparent reason, than complaints about having to declare variables for health.
I never considered this. I have become accustomed to avoiding words like "health" for local variables, training myself to compensate. But new users would not understand this, and it could confuse them.
 

Gradius

Member
As Michael said, if 'globalvar' stayed (I care much less about that, unless its removal would boost performance for projects not using them), simply converting projects to include a line with 'globalvar health' would fix them.
It just seems silly to have consistant niggling annoyances created by the inclusion of features the manual has said not to even use since, what, GM8?
 

nesrocks

Member
The problem with deprecated functions and variables is that they apparently are not. So if removing them is not in your plans, then there should be a warning telling you that you have just typed in a deprecated function or variable. Otherwise it's telling people that it's ok to use them in their new projects. I mean, it's pretty easy to "accidentaly" type "health" without looking it up previously and you'd go "oh, there's a built-in variable for that, cool" and then your project would be filled with a deprecated var.
 
P

ParodyKnaveBob

Guest
I mean, it's pretty easy to "accidentaly" type "health" without looking it up previously and you'd go "oh, there's a built-in variable for that, cool" and then your project would be filled with a deprecated var.
To be fair, the moment you accidentally find your variable name of choice is already built-in, you should immediately be looking it up, or else the consequences are 100% your fault.

That said, it could be neat for "health" to at least be instance scoped; I don't know if GMS2 has the Other events No More Health and No More Lives, (perhaps soon I'll look over the GMS2 manual despite not being able to use it,) but they're nice to have when actually relevant. Otherwise, agreed, if GMS2 is now calling these things deprecated -- which by the way...

features the manual has said not to even use since, what, GM8?
...I don't see GMS1's manual saying anything about deprecating health or lives -- then yeah, calling them obsolete instead and supplying a compatibility script (out of mere generosity) for "globalvar health, lives;" and instructing "replace all your No More * Events with 'if (variable <= 0) {} in the whatever Event" ought to do it, right?

Regards,
Bob
 

11clock

Member
I very hope that globalvar keyword will be removed.
Can I ask what is wrong with globalvar? I use it because I hate typing "global." every time I want to access a global variable. I often forget to include "global." as a result.
 

mMcFab

Member
Can I ask what is wrong with globalvar? I use it because I hate typing "global." every time I want to access a global variable. I often forget to include "global." as a result.
If I remember right, it messes up local/instance scope variables if they happen to share the same name as the globalvar - the global takes precedence (I think). That, and it makes it way harder to track which variables are global and which are not, unless you have a good memory or naming convention (though if your naming convention includes something like "G_variable", then you may as well do what I do - see below).
In order to save time writing global, I usually just make a macro called "g" with global as its value - I can then access stuff with "g.variable" instead. Saves heaps of time.
 

rwkay

GameMaker Staff
GameMaker Dev.
just in case you have not noticed in GMS2 you can just start typing the name of the variable and it knows if it is a global. or a globalvar and will adjust accordingly - should appear in the intellisense and show you explicitly (and insert the correct thing)

Russell
 

11clock

Member
If I remember right, it messes up local/instance scope variables if they happen to share the same name as the globalvar - the global takes precedence (I think). That, and it makes it way harder to track which variables are global and which are not, unless you have a good memory or naming convention (though if your naming convention includes something like "G_variable", then you may as well do what I do - see below).
In order to save time writing global, I usually just make a macro called "g" with global as its value - I can then access stuff with "g.variable" instead. Saves heaps of time.
Wait, constants can be equal to expressions? I should have been told this ages ago!
 

FrostyCat

Redemption Seeker
just in case you have not noticed in GMS2 you can just start typing the name of the variable and it knows if it is a global. or a globalvar and will adjust accordingly - should appear in the intellisense and show you explicitly (and insert the correct thing)

Russell
While that feature is nice, that's not what we asked for or about.

We wanted health, score and lives no longer built-in so that we're free to define them ourselves in the right scope. Especially health.

With "compatibility scripts" in place to help with GMS 1.x migrations, I don't see how a simple globalvar health, score, lives; isn't doable.

Now please answer our request instead of sidestepping it.
 

rwkay

GameMaker Staff
GameMaker Dev.
We have left them in for compatibility reasons, but we are monitoring the situation throughout the Beta period and we may yet remove them before launch

Russell
 

Dmi7ry

Member
We have left them in for compatibility reasons, but we are monitoring the situation throughout the Beta period and we may yet remove them before launch
Maybe an option in preferences which will enable/disable these variables?
 

Dmi7ry

Member
just in case you have not noticed in GMS2 you can just start typing the name of the variable and it knows if it is a global. or a globalvar and will adjust accordingly - should appear in the intellisense and show you explicitly (and insert the correct thing)
It may help only in some cases. Firstly, developer (usually it's newbie) must be attentive and type slow (for see hint, read them and understand). But newbies usually is not very attentive, so even this may won't help.
Also it won't help after copy-paste, when added external script, etc. And then we may get very difficult bugs.
 
A

Andy

Guest
We have left them in for compatibility reasons, but we are monitoring the situation throughout the Beta period and we may yet remove them before launch

Russell
So YoYo is watching me though the IDE, I knew it was spying. How much do you know? :p

With the new IDE features, you could just search for "health" and replace it with "global.health". Someone could fix their project in seconds.
 
Z

zendorf

Guest
We have left them in for compatibility reasons, but we are monitoring the situation throughout the Beta period and we may yet remove them before launch

Russell
Please don't remove it, or at least have an option to keep it i the preferences. I am planning on moving a large project over that I have worked on and off for 3 years. I realise that some people think it is the work of the devil, but I have never had an issue with it, and when I started this project, there was nothing in the documentation that explicitly stated that it was bad usage. I was pleasantly surprised to see it still in GMS2 as I had heard that it would be removed.

In hindsight, I would have used the above poster's suggestion of using g.variable and using a macro(g = global). Not sure if macros were even in the version I started on...
 

FrostyCat

Redemption Seeker
I'd like to see the function names that were deprecated in 8.1 removed from GMS.

The functions can't be called in GMS but the function names are still reserved. If you create an extension to emulate one of the deprecated functions, GMS wont allow the use of the function name - even though the function does not exist in GMS. Very annoying.
Been there, done that.

Are the "internals of GameMaker" any different now? Given how removed 1.x functions now come with "compatibility scripts", perhaps removed 8.1 functions would receive similar treatment.
 
Top