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

Question - Code Game bug only on YYC?

IGameArt

Member
So I have this game, it works perfectly when I compile to VM, but I have some issues when it comes to compiling it with the YYC module for windows.

The main problem is that several enemies will just randomly disappear in the middle of a dog fight. The thing that these enemies all have in common is that they are controlled by different instances of the same controller object. The only time they are supposed to clear themselves from the game is either when they're destroyed in combat or they've finished their path and left the screen.

Essentially my question is this, how do I debug this if it only happens on the YYC module?
 
L

Lonewolff

Guest
How's your coding habits?

YYC can be temperamental if you don't end your lines in a semi-colon.
 

IGameArt

Member
I'd say my habits are pretty good. As far as I'm aware every line of code ends in a semicolon. I added a check to see if enemies were being destroyed before going off screen or their health reaching zero, and it didn't trigger when they disappeared. Leading me to believe maybe they are some how being transmuted off screen.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Essentially my question is this, how do I debug this if it only happens on the YYC module?
Try running the game using the VM, but call gml_release_mode(), which sets the VM to work (more-or-less) like the YYC. ALso, what I tend to do is add a million show_debug_message() calls into the suspicious code and then revise the console output to see what is happening every step of the game. :)
 
L

Lonewolff

Guest
I didn't even know that was a thing. I'm definitely going to give that a try tonight. Thanks!
Neither did I. I went straight to the manual after @Nocturne pointed it out and saw that it has apparently been around for a while.

So does this suppress all errors? Like if there was an un-initialised variable being used or something? Obviously this would cause weird and wonderful bugs *cough* features if there were errors in code. But interesting to see that you can suppress errors and force a continue, if I understand rightly.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
No this won't suppress errors as such... what it will do is make the VM act more like the YYC, and as such some errors may be "masked" as other errors, and general compilation will become more sensitive to syntax issues and toher things. Note it doesn't make the VM behave EXACTLY like the YYC, but it is a good way to approximate it for debugging.
 

immortalx

Member
Also this entry from the manual might be helpful:
It is also worth noting that when using the YoYo Compiler targets, all expressions and functions are evaluated from left to right, while on all other target platforms they are evaluated from right to left
 

ph101

Member
I also think you should look closely at the code that makes objects disappear and perhaps use show_debug_message to find if and when the "disappear" conditions are being met, and how they are disappearing/being destroyed to get to the bottom of what conditions are behaving differently. I do think the way numbers are rounded is very slightly different in YYC so that is a possiblity. It sounds like you can see what is awry to a certain extent - perhaps something in the way they detect path complete behaves differently? Can you use debug messages to confirm that? Let us know if you find something like that, would be useful. I once saw a path behave differently in YYC recently and I havent figured it out if it was YYC related or just a previously unknown bug in my code. And of course, clear the cache after changing any varaibles between compiles.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Number rounding has been the cause of almost 100% of the bugs I've encountered when using yyc
Ooooooh! Good call! That's one that used to get me all the time too...

Hypothetically, if number rounding is causing issues, what should I do to circumvent that?
Okay, so, when you do something like

Code:
if val == other_val
you are checking to see if something is EXACTLY equal to another. However, most GMS values are floats, and so "val" can actually be "val.0000000000001". Now, the VM isn't quite so precise when calculating values, but the YYC is, and so oftentimes a check that might work on the VM will fail on the YYC. For an actual example think of the image speed fo a sprite. You could have something like this:

Code:
if image_index == image_number - 1
{
// do something
}
Now on the VM, with an image speed of 1, this will probably work fine. But on the YYC, it probably won't because of floating point rounding errors that accumulate over time, even with simple things like adding 1 + 1 (the answer might be 1.9999999999999997 and not 2 as you'd expect!). So you need to adapt the code a little and start to check for greater/less than, like this:

Code:
if image_index >= image_number - 1
{
// do something
}
Generally, stay away from doing == comparisons unless you are SURE that the values being checked are ints/bools. :)

Have a read at this page, as it helped me greatly way back when I first came across this issue: https://floating-point-gui.de/
 

IGameArt

Member
so what if I want to check if two values are essentially the same, should I filter them both first using round(number)?
 

IGameArt

Member
I just learned about mat_set_epsilon from our buddy Yal. I'm going to experiment with that and with flooring I think. See what happens :p
 
Last edited:
I recently ran in to this issue as well. While running in VM, my comparison of a float number that incremented over time was being compared against an integer, and this worked fine. When my value was
Code:
6.01 > 6
all the way up to
Code:
6.99 > 6
, these comparisons would return `true`.

But in YYC, those comparisons would both return `false`. It only started returning true after the number got past 7. I fixed it by changing the `>` to `>=` and that did the trick.

I'll be looking into this documentation in more detail so I know to watch out for this next time: https://docs.yoyogames.com/source/dadiospice/002_reference/maths/real valued functions/index.html
 
Top