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