• 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.

Legacy GM [close]Is it possible to have any effect on what the engine checks for errors, when building a YYC export?

I have noticed that a GMS 1 project of mine, when trying to export to YYC, gets an error that isn't present when running it as Windows. Basically, a script that isn't even being called by the single instance, in the single running room, throws an error because it's checking an uninitialized variable that at this point has no defined value.

At this point in time it shouldn't matter that it has no value, because I'm not calling it. Nor does the object in the room call it. So why does Gamemaker Studio 1 insist on checking it, and throwing an error?

I understand the need for error checking, but it would seem to my mind, that only checking the room that is currently active would be the obvious starting point, and then working from there to the objects in that room: creation code, and then event code. Looking for scripts called, or other objects being referenced, or timelines called. Anything where there's a link to something else, and it justifies the effort of making sure all of these connections are properly working.

As is, the approach seems like overkill, and is both irritating, and to a layman, feels like it ought to be adding quite a lot of needless expense. Obviously YoYo felt the same, as GMS 2 doesn't replicate this behaviour, and in my experience will ignore the content of unused scripts when making a YYC build.

I'm no expert, but this behaviour seems way off how I'd approach it, and really, really, really unnecessary. Presumably it is actually building a picture of variables defined through various facets of the game, since it is true that this variable is missing. I'm aware that it's missing. It shouldn't matter that it's missing.

I know how to correct the error, but to my mind it shouldn't even be an issue in the first place. Can I somehow turn off this behaviour, or at least direct it to be more efficient?

EDIT:
There are objects present in my project that call this script, and technically if they were to do so, it would crash. But these objects are not in any room, or ever called into existence, so it seems foolish to me, that GMS 1 appears to go by checking the objects in the project, or the script library. Rather than looking at the current room, and seeing what objects are in it, then starting with those objects and working it's way out.

I'm assuming it's parsing probably the scripts library, and just seeing if the variables are defined. Since the "solution" is to define the variable, even if the actual value is non-existent when run as code, it doesn't now throw an error. I don't understand why it feels the need to look through all of them as the default practice, unless that is felt to be less costly than actually parsing all the resources and working out what scripts are actually going to be called.
 
Last edited:
when trying to export to YYC, gets an error that isn't present when running it as Windows.
The YYC compiler uses a much more strict set of rules, in return for efficiency. There's nothing that can be done about this, especially with GMS1.4

There are objects present in my project that call this script, and technically if they were to do so, it would crash. But these objects are not in any room, or ever called into existence, so it seems foolish to me, that GMS 1 appears to go by checking the objects in the project, or the script library. Rather than looking at the current room, and seeing what objects are in it, then starting with those objects and working it's way out.
This is how most compilers work, we're just spoiled with game maker being so relaxed.

You cannot compile code that is invalid, even if that code will never run. A lot of the time, the compiler doesn't know whether code can or cannot run, it only knows that it doesn't make sense if it were to run. So to be safe, it gives the error
 
The YYC compiler uses a much more strict set of rules, in return for efficiency. There's nothing that can be done about this, especially with GMS1.4


This is how most compilers work, we're just spoiled with game maker being so relaxed.

You cannot compile code that is invalid, even if that code will never run. A lot of the time, the compiler doesn't know whether code can or cannot run, it only knows that it doesn't make sense if it were to run. So to be safe, it gives the error
I know nothing about compilers, or non-GML programming. But from observation, I don't see what you say happening with GMS 2.

If I put in a script that is unused, and it refers to a variable not defined in the script, it won't crash in the YYC build.

In terms of code, that wouldn't cause an error: the script could be referring to a permanent variable, so it will be accessible throughout. Maybe it's better form to access held variables by providing them as arguments, but nonetheless: in the code chain it's not an error. To the GMS 1 compiler: it's an error, simply because in that event it can't tie up all the loose ends.

step, or whatever:
GML:
this_variable = true;

scr_check_this_variable()
scr_check_this_variable:
Code:
if this_variable
{
do whatever
}
That would make it crash, because when checking the script, the compiler doesn't know what 'this_variable' is. But you can see that there is easily a situation where that's incorrect, as the code isn't the problem - it's the context of the compiler looking at the script before the circumstances that call the script.

This same scenario doesn't cause a crash in GMS 2, so I am assuming that they have made significant changes to how the compiler works. At the very least: it simply no longer reacts to undefined variables. At best: it can hopefully ignore evaluating scripts / objects / timelines that aren't used (this is what GMS 2 appears to be doing to me)

As 1 is already gone, and 2 seemingly near to its end as well, these are just curiosities on my part. I certainly have no programming skills to delve deeper into the engine, but if there is anything on the topic, then I might get some pointers to interesting threads.
 
Bit of a late reply from me, sorry!

There is talk of a subscription model for Gamemaker Studio 3, so not only would there be a tech overhaul, but also a massive change to how you pay. How far off Studio 3 is, I don't know, though if I recall correctly it was a YoYo topic where I saw this being discussed. Presumably they wouldn't be talking about it, unless plans to introduce it are fairly near (?)

Maybe a year, or two, and Studio 2 will be 5 or 6 years old, so is put out to pasture. Also: this plan for a subscription model would suggest that financially they need to drop Studio 2, and then release a new product to justify a yearly fee. Well, this topic is moving further away from my original post, I just didn't want to seem rude by not replying :)

Cheers!
 

rIKmAN

Member
Bit of a late reply from me, sorry!

There is talk of a subscription model for Gamemaker Studio 3, so not only would there be a tech overhaul, but also a massive change to how you pay. How far off Studio 3 is, I don't know, though if I recall correctly it was a YoYo topic where I saw this being discussed. Presumably they wouldn't be talking about it, unless plans to introduce it are fairly near (?)

Maybe a year, or two, and Studio 2 will be 5 or 6 years old, so is put out to pasture. Also: this plan for a subscription model would suggest that financially they need to drop Studio 2, and then release a new product to justify a yearly fee. Well, this topic is moving further away from my original post, I just didn't want to seem rude by not replying :)

Cheers!
GMS2 has already moved to a subscription model.

It's highly unlikely it will "put out to pasture" with this model and it'll be continual development and advancement of the existing engine with incremental version numbers.
 
GMS2 has already moved to a subscription model.

It's highly unlikely it will "put out to pasture" with this model and it'll be continual development and advancement of the existing engine with incremental version numbers.
Alright, I got that wrong. It happens :) The subscription model is unappealing, so technically to me, it's dead before I've even started to explore using it.

It's off-topic from what I originally asked, so that's all I will say. Might as well close this, since asking it in the Technical forum would perhaps be better.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
script that isn't even being called by the single instance
Thanks to script_execute and several more obscure ways of per-ID execution, it is hard to be so sure about this in GML, so the compiler picks the safe option of notifying about any variable names that have reads but no writes.

Same goes for the instances - it takes a lot of analysis to figure out whether an instance of object may ever be created or its code executed, so the compiler goes on assumption that if you've put it in your project, you intend to use it.

Additionally, YYC cache in GMS1 can be buggy, so using "Clean" (broom button on the toolbar) can be necessary.
 
Thanks to script_execute and several more obscure ways of per-ID execution, it is hard to be so sure about this in GML, so the compiler picks the safe option of notifying about any variable names that have reads but no writes.

Same goes for the instances - it takes a lot of analysis to figure out whether an instance of object may ever be created or its code executed, so the compiler goes on assumption that if you've put it in your project, you intend to use it.

Additionally, YYC cache in GMS1 can be buggy, so using "Clean" (broom button on the toolbar) can be necessary.
Thanks for that info. Essentially it only looks at the contents of each script / resource, for the purposes of performance? Rather than cross-checking them for accuracy. Presumably GMS 2 does have this performance hit, as I didn't find it had the same issues as GMS 1, and would happily compile the same conditions.
 
Top