Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

[Fixed] Issues with 2.3

A topic by Evoleo created Jul 14, 2020 Views: 1,780 Replies: 36
Viewing posts 1 to 9
(2 edits)

I've created a blank project to test the extension and here're the issues I've faced:

After it reloads the files, some things break, including:

  • room_* and some other constants/variables became undefined.  (for example room_width, room_last, room, debug_mode, etc.)
  • += / -= operators are threated as just =

It's possible that there're more issues, I haven't tested that much


I'll pin the project file in 10 mins


Edit: For anyone reading: These issues have been fixed, but for now you don't want to name a script "macros" (if you have one, just rename it to something else and you'll be fine)

(1 edit)

Sorry for the delay, here's the file <snip>

Developer

Fun times!

I have uploaded a new build (1.0.25a) to address these.

Date submitted: 2018-12-05 10:43 - yeah, typical YYG :P

But at least they added this new bug to database too, maybe it will be fixed one day ;)

Developer

To be fair, this was a very exotic bug up until introduction of structs - no one would use an instance instead of a ds_map as a dictionary, and I only ran into it while implementing serialization on a project.

GMLive + HTML5  in 2.3 doesn't work at all, it won't even run the game, just throws this error:

X_GMLive.js?KLPYB=1741178719:36517 Uncaught TypeError: Cannot read property 'gmli_blanks' of undefined
    at gml_Script_haxe_ds_basic_map_i_set (X_GMLive.js?KLPYB=1741178719:36517)
    at Object._g83 (X_GMLive.js?KLPYB=1741178719:53478)
    at gml_Script_gml_type_check_init (X_GMLive.js?KLPYB=1741178719:42586)
    at gml_GlobalScript_GMLive (X_GMLive.js?KLPYB=1741178719:16058)
    at gmlInitGlobal (X_GMLive.js?KLPYB=1741178719:46234)
    at _Ty2 (X_GMLive.js?KLPYB=1741178719:52597)
    at __c3 (X_GMLive.js?KLPYB=1741178719:53650)

 do you maybe know why Vadim?

I imported the 2.3+.yymps file and ran it in a new project, also populated the live_blank_*  variables as specified in the documentation.

Developer

HTML5 in general is very buggy as far as new 2.3 features go, I'm not sure if it's practical to try to workaround these if it may cost me more hours than the rest of 2.3 porting combined.

This was my initial thought, I know the HTML5 is very buggy, no idea if it's worse in 2.3 at the moment but I was willing to take a shot to see if it was at least something small for GMLive to work with it. Thanks though Vadim. 

Developer

I'm sure they'll fix it up by the full release of 2.3, but things will break and un-break often during the beta.

I certainly hope so they will, not looking forward to things breaking, so hopefully 2.3 becomes stable soon.

(-1)

This damn thing is the worst. At least now it partially works, but every time I recompile the game to change something in the Create event, it throws this exact same stupid error:

___________________________________________
############################################################################################
ERROR in
action number 1
of Async Event: HTTP
for object obj_gmlive:

Variable <unknown_object>.set(100500, -2147483648) not set before reading it.
 at gml_Script_gml_program (line 3073) -                             l_mcrMap.set(l_mcrNames[l_i1], l_mcrNodes[l_i1]);
############################################################################################
gml_Script_gml_program (line 3073)
gml_Script_live_update_script_impl (line 10057)
gml_Script_live_async_http_1 (line 8851) -               live_update_script(l_name, l_ident, l_code);
gml_Script_live_async_http (line 8941) -        live_async_http_1(l_map);
gml_Object_obj_gmlive_Other_62 (line 1) - live_async_http();


This is usually fixed by commenting out all "live" definitions, then restarting the server and the game, then uncommenting them again, but sometimes it just randomly persists. This thing pops up literally every time and I just end up wasting more time than I did before

My guess is that this is related to the server updating events it shouldn't update (in the log above it often writes "Reloaded oPlayer:Draw_0" even if I disabled reloading for the event and then threws this error)

Sometimes this occurs when I change something in code (it was 1 time), but mostly after recompiling and/or adding new events to live update


Please fix, this is extremely annoying

I tried seeing the code myself, but as it's artificially generated (correct me if I'm wrong, maybe I misunderstood that article), it appears impossible to manually fix anything

Developer

Please email me a sample project that causes this. From the code this looks impossible - that variable is assigned 60 lines up in the same function and the dictionary does unconditionally get a "set" function.

Sent! Sorry for the delay(

Developer (1 edit) (+1)

Turns out that this is a GM bug! If you have

self.a_resource_name = value;
var v = self.a_resource_name;

then you get a resource ID back instead of the variable value. If you find-replace "macros" in the GMLive script into something else (or rename the "macros" script), it'll work fine. I'll rename this for the next version since name "macros" is common enough.

Oh, wow! Thanks man, I'd never thought it's related to the "macros" script

Hi again, yellow, now snippets aren't working. I've already sent the example project (it's literally a simplified version of the example code from the GMLive manual)

Fortunately, live_execute_string() is working fine, so I have an alternative for now (even tho you're saying it's far slower)

Developer(+1)

Turns out that this is a bug too...

I can add a workaround for this though.

What a legend!


Also I'm not sure if it's fixable at all (it's probably nested inside the GMS 2.3 nature), but local variables from outer scope don't work inside live_execute_string(). (They don't work properly inside of 2.3 functions scope either), fortunately I've already designed a workaround so it's not that big of an issue.

e.x. function(target) {

live_execute_string("trace(target);")

}

^ doesn't work, unless you add self.target = target before the live call (which may or may not have circumstnces)

Developer(+1)

This goes against how 2.3 works in general - functions don't share local scope.

I can add the ability to pass an optional argument into live_execute_string so that you could pack up all your variables of interest into an array or a struct.

That makes sense, live_execute_string_ext() would be reasonable.

Anyways, now that snippets are fixed, there's no real need for that I guess (why use live_execute_string() over snippets)

I think that this is just a very low priority feature

(1 edit)

I've found some issue in console logs, but I don't know when it exactly happens:

Runtime error: [error] Variable <unknown_object>.i_id(101072, -2147483648) not set before reading it.
 called from vm:field_on_field_set (line 13064)
 called from game:anon_gml_thread_gml_GlobalScript_GMLive_396240_gml_thread_gml_GlobalScript_GMLive (line 11248) -                     var l_ar1 = vm_v2_gml_thread_v2_handlers[l_act.__enumIndex__](l__gthis, l_act);
 called from game:anon_gml_program_gml_GlobalScript_GMLive_120080_gml_program_gml_GlobalScript_GMLive (line 2825) -             l_th.i_exec();
 called from game:live_call (line 10204) -                 var l_th = l_pg.i_call_v(l_scriptName, l_vals, false);
 called from game:obj_event_questionplate_Step_0 (line 3) -     if live_call() return live_result;
 called from obj_event_questionplate:Step_0[L40,c22]

On line 40 in obj_event_questionplate there is:

creator.wait_for = _cutscene;

where "creator" and "_cutscene" are variables with ID of existing objects (_cutscene is just created few lines before).

Developer(+1)

This should be fixed in 1.0.26. If not, email me a sample project - it's a little weird now with mix of instance IDs, structs, and instance references (which are structs, but also not)

as always - fixed :)

Thanks a lot!

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 ?

Yeah, they aren't updating for me either

Developer (1 edit)

live_name can be used to clean up script detection, but this did work as of me publishing the announcement. Perhaps debug_get_callstack output changed again

Yep, live_name solves it.


So I found 2 more bugs (in the interpreter part of the extention rather than the live part)

1) show_message()

and some other stuff doesn't automatically convert real to string (original GM function does)

2) inst.value = other_value

doesn't work


luckily, as a user you can find workarouns (use variable_instance_set() and string() functions), but this still might be a bit annoying and hard to debug (it just silently crashes/doesn't execute code after a complile error)


Here's the example string: 

Developer

I think I'll need a sample project/larger code snippet for this since I'm trying

var v = instance_create_depth(0,0,0,obj_blank);
v.friendly = 1;
show_message(v.friendly);

via live_execute_string and this does not fail no matter the configuration.

(3 edits)

I'm using live snippets


The context:

Card game.

I'm loading all the cards from JSON files. Each card has a bunch of characteristics, including "effect" (which is a string of GML code, containing what the card actually does)

Then, the oCardLoader, when loading a card, assigns it a live snippet, containing the effect string.

live_snippet_create()

is called inside oCardLoader

effect()

is called inside the card struct


With this setup, I'm having these errors. Pretty sure it's not too specific to the project (although I may be wrong)

Developer (1 edit)

I wouldn't be asking for a sample project if it was as easy to reproduce

oSmallSlime Create event:

friendly = 4;

Test code:

var s = live_snippet_create(@'
var slime = instance_create_layer(0, 0, "Instances", oSmallSlime);
show_debug_message(["slime", slime, slime.object_index, object_get_name(slime.object_index)]);
show_debug_message(["friendly", slime.friendly]);
show_message(slime.friendly);
slime.friendly = false;
return slime;
');
if (live_snippet_call(s)) {    var slime = live_result;    show_debug_message(["slime", slime, slime.object_index, object_get_name(slime.object_index)]);    show_debug_message(["friendly", slime.friendly]);
} else show_debug_message(live_result);

Output:

[ "slime",100003,3,"oSmallSlime" ]
[ "friendly",4 ]
[ "slime",100003,3,"oSmallSlime" ]
[ "friendly",0 ]

(unless I fixed this in 1.0.27 without noticing)

(1 edit)

Okay, sorry, maybe I'm missing something.


I'll try it again and send a sample project if the issue is still there

Yep, 1.0.27 magically fixed it. In 1.0.26 I had trouble even reproducing the sample snippet on an empty project

Not sure why, but apparently GMLive really doesn't like methods/functions, defined inside objects.

I had some cursed unreproducible issues on my production projects, then I hopped onto an empty project and faced some weird things there.
Sending the project. I may or may not have spent way too much time on it

Developer
  • The server warns you that you need a live_name in `name = function()`
  • `function name()` in a script/event with live calls causes some issues as the server mistakes it for a global declaration, which proceeds to interact unusually and show a compile error in game's output. I'll see about that.

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

Developer(+1)

This is now fixed in 1.0.29+