itch.io

I can confirm, that 2024.11 & 13 (betas for now) works without issues with this fix: https://itch.io/post/11906426

Also, 2024.13 doesn’t seem to add something breaking even if they would add UI Layers (from what I’ve heard, there’s only 1 new function for now layer_get_flexpanel_node(layername) - to get flexpanel for such layer, no new resource types etc. - it reuses existing code).

Typical for any .exe that antivirus’ servers aren’t yet aware of (based on checksum). Especially when packed, AV loves to raise false alarms.

I don’t have that “Download” button on https://yellowafterlife.itch.io/gamemaker-live/devlog/692926/20242-minifix…

Edit: OK, I see it, it’s on main page ( https://yellowafterlife.itch.io/gamemaker-live ), not in linked Development Log.

I’ve just checked IDE v2023.800.0.402 Beta Runtime v2023.800.0.423 and it seems that GMLive works there again.

This seems to be a bug in runtime, as script_get_name(Script1); also breaks games…

why not breaking 2.3.7? since we have LTS, I would leave:

• 1.4 - no change
• 2.2.3 - no change
• 2.2.5 - no change
• 2.3 - 2022+ –> 2.3 - LTS
• Bleeding edge 2023+

GM 2023.1 introduced singletons:

function foo() constructor {
  static bar = 1;
}

foo(); // initialised at least once so static is set

/// now you can do this anywhere:
foo.bar; // returns 1

However, GMLive (yet) doesn’t support this syntax. There’s however very easy way to bypass this issue. Instead of foo.bar you need to write static_get(foo).bar - as in fact while compiling, GM translates former to latter, which means only latter is used in compiled games.

Have fun playing with new syntax!

in fact there’s nothing wrong with having 20 FPS after reload - GMLive is rather for debugging and shouldn’t be used in compiled game, so it will have no impact on final version of game.

For-loops love to slow down games when using live code. I’m not sure if it’s because of “var”, or just because how live code is executed.

My solution to make it faster is to put code inside for-loop into separate script and live update only that script, not event where for-loop is.

Yes, it even works in 2022.6[00]. It only doesn’t supports time_sources.

yeah, I’ve noticed // @is {xxx} in last version of GMLive, which didn’t worked yet - sad that this won’t work at all, IMHO this will give more errors that it should, so I hope that YYG will change their mind one day.

As GMS Feather is still in it’s early stage and reports lot of false-positive errors with GMLive, I would like to propose adding // Feather disable all comment on top of every GMLive GML script, so we won’t get any notices (as for now there’s 1000+ errors/warnings/notices detected by Feather in GMLive).

https://itch.io/post/5503144

it might crash, if you try to apply it on different version, or applied any change on original files

Since we cannot re-distribute GMLive source code, but fixing for 2022.2 only requires to remove list of outdated GML functions (so that part can be shared), I’ve prepared a .patch file (which can be applied using git, or by copy-pasting without +/- characters in first column) which fixes GMLive for 2022.2 release.

You can get it here:

https://gist.github.com/gnysek/23e3b3c1d082fe7ffe0c6b734617599f

We will need to wait a little longer for a fix, as YellowAfterlife got more important things to do for few next days, cause of some 70yo prick who decided to ruin whole world.

Russell wrote on forums that Tuesday (1st Feb) beta version will have tons of fixes for Feather, so I will wait with reports. Generally IMO best solution would be to mark most of GMLive scripts and variables as ignored, as they don’t need to be exposed (except those that are documented, like live_call() etc.), so that requires YYG to make those features stable enough to start thinking about it (as some things are bugs yet, but are not completed at all).

Seems that /// @ignore is bugged, as it loads even slower… I’ve given up after 30 minutes of no response. Checked on todays IDE (2022.100.0.468)

I’ve added ignore before each functions that started with “vm_gml”, “live”, “gml”, “vm_group”.

Seems that projects with GMLive aren’t running in GMS 2 2022.1.464 because of Feather feature. Of course since Feather is in alpha stage and have bugs even on smallest possible projects, this seems to be Feather issue rather than GMLive and for now there’s no sense in fixing anything on GMLive side, I’m rather writing this post to inform, that if you want to test Feather, and project loading hangs - this might be the cause (probably too many code, or it crashes on some specific syntax). Further betas will for sure solve it.

Edit: as for now, leaving GMS beta version for 10-20 minutes seems to finally load project.

with new intellisense and references finding they probably makes a big rewrite for syntax checking, so new bunch of bugs is incoming! :D

In fact, nullish operator is little broken:

// nullable operator test + ds_map accessor 
show_debug_message(list[| 1] ?? "not found"); // crashes
show_debug_message(map[? "test"] ?? "not found"); // crashes

I’ve reported it during 2.3.7 beta ASAP after this feature was added, but seems that they don’t want to fix it yet…

After so many issues with 2.3.0 it’s nice to see that since GM switched to monthly releases none of them seems to broke GMLive functionality :)

Those aren’t errors, rather notices.

So yes, it’s a bug in latest beta runner, that using “vars” as arguments in functions when creating a struct causes errors.

Also, seems that actually 2.3 causes a random order for scripts (especially on import) no matter what is their order in resource tree, so there’s a high probability that divided version of GMLIVE need to be put in some functions, so only one script will define order in which they are created. But that’s to check after they fix first bug, cause there’s no way to check GMLIVE latest version at all now in latest beta.

You’ve got info about it in docs, but you need to remember, that it in fact will open a security breach in your game, as basically everything can be changed by users if you leave GMLIVE in final game. Also, generally it will cause a lot of FPS drop quickly.

So, while it could be used that way, it’s not optimal and safe in any way.

Yep, we need to wait for next beta which should be soon, and if that still happens, YYG need to solve it then.

I also have problem with GMLiveAPI::live_preinit_funcs() , line 17, var l_m={name:l_name,func:method(undefined, l_scr),used:false}. Error message is: Variable struct.l_scr(100633, -2147483648) not set before reading it..

Changing it to

var m = method(undefined, l_scr);
var l_m={name:l_name,func:m,used:false}

seems to fix the issue (it might be a bug that method()+var can’t be used when creating struct).

For problem with wrong order of script execution, as for now I’ve manually deleted all entries in YYP which were starting on "GMLive and were about scripts, and I’ve manually copied the same order that was in your package.

Edit: seems that these are caused by using runner other than from public beta channel, so it’s worth to wait for next official beta.

I’m getting error when trying to run latest version:

 at gml_GlobalScript_GMLive_program (line 263) - if(live_enabled)mt_gml_program.h_constructor=gml_program;
############################################################################################
gml_GlobalScript_GMLive_program (line 263)

Seems that issue happens cause GMLIVE scripts aren’t executed by order in which they are in resource tree, but by the order they are in Project.yyp, which is… random. So, in fact error messages will also be random, depending on how GM will put those files among YYP. Deleting extension and importing it agan caused totally different order in my case.

https://i.imgur.com/FaVmFc7.png

My advice:

• if there’s a part of code which you not gonna touch in same event, make a separate script for it
• avoid using too many for-loops in live code. Again - if some part is already completed, move it rather to some script (you don’t need to change code in any way, as it will be run in context of event) and keep the smallest amount in code you want to modify.

I’ve got one object which have around 10 nested for-loops inside, and I’m getting 2FPS cause of it, so above solutions helped me a lot.

Damn, I forgot that removing extension doesn’t remove included files, re-uploaded now and double checked (renamed yyz to zip, manually deleted, renamed to yyz again).

Thanks!

Yeah, this solves my problem!

Definitely worth mentioning in help docs then.

Here it is: https://gmclan.org/up23_18_gms_23_GMLIVE_crash.html (with GMLIVE cut, need to be re-added).

To crash, I just need to run it and wait about 60-120 seconds (you can watch memory usage in Task Manager, for me it crashes around 1.5 GB used).

This is how memory usage looks on my side, the moment of crash is easily visible: https://i.imgur.com/PP5RVF6.png

Edit: here is a chart from GM debugger for above example:

I was thinking about some GMLive helper like:

live_link_instance(“my_instance_identifier”, my_instance_identifier); - then after compilation you should have dictionary of names and instances in-game ? User would need to manually enter every instance he wants to read this way.

After some new tests - crashes because of no enough RAM (game uses around 2GB when crashes - with only 5 lines of code).

I’m not sure that it’s possible at all, but I’m often using “named instances” in room editor (giving them custom name instead of inst_XXXXXX with random 8-digit HEX).

However when using them with GMLive, I’m getting:

Runtime error: [error] instance#100083(obj_xxx) (obj_xxx) does not have a variable inst_my_custom_name

Is it possible to add this feature ?

Every time I’m importing this extension, I can see “GMLive - Copy.gml” file under scripts, is this some hidden file in extension, or it’s some GM bug/feature that causes to create this file?

Seems that after last release I also can see “GMLive.gml._” which is empty…

From my experience, as this happens often to me - it seems to happen when there are for-loops with temp variables in code, and you update it several times (but it crashes randomly - sometimes after half minute, sometimes after 10 minutes). As I'm unable to find one easy way to reproduce it, I didn't reported it yet, as I know what to report in fact... this error message doesn't help.

for me, I need live_name in everything that isn't an event, so in every function (even in those which have same name as in resource tree).

Yep, live_name solves it.

Hmm, I've got some issues with live_call() in scripts. Does it work like in 2.2, or something changed?

I'm getting log that script is reloaded on Ctrl+S, but it seems to still run old code... Am I doing something wrong ?