Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MedO]

lateralGM
...which gmksplit uses as a lib

This. You might actually be able to run it from the gmksplitter .jar with the right commandline arguments, but it's probably missing some images or other ressources

[ajf]

lateralGM
...which gmksplit uses as a lib

This. You might actually be able to run it from the gmksplitter .jar with the right commandline arguments, but it's probably missing some images or other ressources

wait, gmksplitter contains the entirety of LateralGM?

[MedO]

lateralGM
...which gmksplit uses as a lib

This. You might actually be able to run it from the gmksplitter .jar with the right commandline arguments, but it's probably missing some images or other ressources

wait, gmksplitter contains the entirety of LateralGM?

Code-wise, yes. Extracting only the important bits is more difficult that you might think, and it would make updating with bugfixes from the main lateralGM project much more work.

Edit: In fact I actually had to apply some changes in LGM so that accessing the model classes and Gm file reader/writer didn't start up part of the UI systems. That was originally done in static initializers, i.e. performed on class load... shudder. Also, some code that gets executed when the resource tree changes tries to inform the UI about it, and runs into a NullPointerException because the UI doesn't exist. I just added a null check, because there was no way I'd be able to untangle that mess without sinking days or weeks into it.

Edit2: Am I derailing this into a general "coding horror" thread here?

[Orpheon]

lateralGM
...which gmksplit uses as a lib

This. You might actually be able to run it from the gmksplitter .jar with the right commandline arguments, but it's probably missing some images or other ressources

wait, gmksplitter contains the entirety of LateralGM?

Code-wise, yes. Extracting only the important bits is more difficult that you might think, and it would make updating with bugfixes from the main lateralGM project much more work.

Edit: In fact I actually had to apply some changes in LGM so that accessing the model classes and Gm file reader/writer didn't start up part of the UI systems. That was originally done in static initializers, i.e. performed on class load... shudder. Also, some code that gets executed when the resource tree changes tries to inform the UI about it, and runs into a NullPointerException because the UI doesn't exist. I just added a null check, because there was no way I'd be able to untangle that mess without sinking days or weeks into it.

Edit2: Am I derailing this into a general "coding horror" thread here?

I think "stupid stuff in GML" and "programmer's nightmares" aren't that far from one-another.


Actually, now I've looked up again what ENIGMA is, and why haven't we tried applying it to gg2? It claims to be completely compatible with GML, can create C++ code and compile it, and also claims to be cross-platform. Is there some problem with extensions or whatnot, or am I missing something?

[Orpheon]

Code: [Select]

instance_destroy = 0;

[Orangestar]

I still find it ridiculous that you can type whole scripts and never touch the ;

I had to fucking recondition myself when I used ROBOTC since I learned on GML.

Which was stupid as fuck to do.

[cspotcode]

My favorite GML WTF moment:
When we realized that any real value x where -0.5 < x < 0.5 will be considered false in an if(), while(), etc.  WAT.

I agree GML is terrible, but let's focus on legitimate flaws.  Some of these complaints are just pointing out differences between GML and C-style languages.  There are tons of languages out there with/without semicolons, with different meanings for the "." operator, etc.

[ajf]

what you just pointed out isn't a flaw, it just floors the value and does != 0

[cspotcode]

Point taken.  I think my frustration at the time was that, even though GML's behavior is predictable once you know what it's doing, it wasn't documented anywhere.

[ajf]

Just like the parser then?

[MedO]

Actually what AJF said is completely wrong. The GML truth check is probably round(x) > 0, not floor(x) != 0. You can abbreviate it to x>=0.5, but I think the former explains the source of this behaviour better: GML just wants to check for x>0, but treats this check as an integer operation, so the value is first rounded.

[Phantom Brave]

If it was floor(), then anything truly <0 would be false and any else truly <1 would be true, rather than the -.5 .5 range here.

[MedO]

It isn't a -0.5...0.5 range though, that's part of my point.

Code: [Select]

if(-10)
    show_message("-10");
   
if(-1)
    show_message("-1");
   
if(-0.5)
    show_message("-0.5");
   
if(0.49999)
    show_message("0.49999");
   
if(0.5)
    show_message("0.5");

Only the last message will be shown.

[ajf]

I think I'll make angl just do != 0 then.

[cspotcode]

It isn't a -0.5...0.5 range though, that's part of my point.

Ok yeah, I remembered it was terrible but I had my details mixed up.

I think I'll make angl just do != 0 then.

You might consider adding a backwards-compatibility toggle that can be enabled on a per-file basis.  So, on the off chance that old code depends on GML's wonky behavior, it can still be made to work in angl.

Or you could implement the old GML behavior by default unless a script author specifies a flag that enables newer, more sensible angl behavior.  I'm basically borrowing the idea behind Javascript's "use strict".