What version is this on? Doesn’t seem to leak on 1.4.1804 YYC

It’s a tricky problem - if two players are on the same network, they may not necessarily be able to connect to each other - or even recognize each other as being on the same network (as a computer is not aware of its external IP when it’s behind a NAT).

The Steam-based version of the mod offloads this problem onto Valve’s infrastructure instead.

That requires a complete rewrite and investigating how and whether that could be done on Android, so probably not.

The actual problem appears to be that variable_global_get("event_data") doesn’t work again and can be workarounded by adding the following to the end of obj_gmlive’s Create event,

live_variable_add("event_data*", function() {
	return event_data;
})

(note: also applies to other global built-in variables like async_load)

but the rest is unclear - seemingly at random, you either get the actual error message as intended by GMLive,

[live][2021-05-03 17:11:51] Runtime error: [error] Expected an index
 called from o_plr:Other_59[L2,c18]

or the technically-impossible error seen in your post.

Similar to last topic about this, send me a sample project that reproduces the issue.

Please send me a sample project that reproduces this to be sure

You go into the extension’s directory in Explorer and open the file with any text/code editor

Are you using pointer_null or pointer_invalid as your variable value per chance? Someone has recently discovered that these cause issues and I have fixed this for the next version. A workaround is to assign either into a global variable prior so that you are not referencing the values directly.

Regarding the exclamation message, you’ll need to remove that single show_message call from window_frame.gml in the extension’s directory. That is a leftover of me spending a while trying to figure out why the extension wouldn’t work right in GMS2.x

By default, the example demonstrates Window Commands functions and will wait 30 frames before closing the game. You can find a handful of comments in the example object.

Fixed this for the next release - it was caused by indexing code thinking that the text inside the comment is the preceding expression

I did, but so far I was not able to reproduce your crash after stubbing out the missing variables by adding

function GAME_CONTROLS() {}
enum mods {laser_beam}
instance_create_depth(x, y, depth, obj_player_suit);
key_secondary_press = 0;

to Create and creating an obj_player_suit which does

enum player_state { suit }
has_control = 1;
state = player_state.suit;

on Create.

A more specific example might be necessary - it is most likely a specific line of the code, so making a backup of the draw event and removing the code from it until you find the offending bit should help to isolate the problem.

This looks like your room has no visible background, causing the pixels from the last drawn frame to remain.

You can verify this by adding an object with a sprite that moves in a direction in Step event (without any GMLive code there)

When additional players join, the host tells them to connect to each other. Sometimes (usually due to complicated NAT setup) this doesn’t work out.

On Steam, having everyone rejoin the lobby (or, worst case, restart Steam) usually fixes this.

Off-Steam, you can try having people join in a different order, but might have to use one or other VPN software to bypass this problem.

I have outlined the workaround for this in a topic slightly below yours (it’s ultimately a GM issue), but have now uploaded the said quick fix to marketplace and itch.

I looked into it further and honestly, what a trouble - if you look at the old GMEZ, it has two sets of GMLive executables - one in datafiles/ (old version?) and one in datafiles/GMLive/ (right ones), but GMS1 imports the top-level ones instead. And not just that - if you try to re-export the extension afterwards, it somehow grabs those old files even if you deleted them from the project folder. Truly amazing.

I manually removed them from GMEZ (which seems enough to fix this) and reuploaded.

Can you email me a small sample project that triggers this? The issue doesn’t seem to be as easy to replicate.

Can you email me a sample project that triggers this (copying the object to a new project might be enough)? I believe that you are the second person to report this, but the error is seemingly impossible.

You can adjust this behaviour in apollo_core.gml ➜ lua_add_file - change

lua_set_cwd(dir);

to

lua_set_cwd(filename_dir(fp));

or call lua_set_cwd yourself and set the optional chdir argument to false when calling lua_add_file.

Allegedly it’s supposed to be Apollo_x64.dll, though previously people seemed to have issues with x64 DLLs unless replacing the non-suffixed version with the x64 one.

You must have disabled “show gutter” and/or “show line numbers” in Code Editor Settings.

You can also go to %APPDATA%\AceGM\GMEdit\config and check what did you change in aceOptions.json in general

I believe that you are the second person to ask about this, but I cannot think of a way to handle this without rewriting the extension for the third time - at most I can add an option to alphabetically order fields and/or a special field that you can set to an array of keys to control field output order, so something like

{ "a": 1, "c": 3, "b": 2, "$$order$$": ["a", "b", "c"] }

If you can replicate this in an empty project (or trim down a copy of your project to just the needed parts), please email me a sample - I figure that someone else might run into this as well.

Clarify “not working”? Ideally a screenshot/GIF

This seems correct - I must have uploaded debug DLLs or changed something while setting up x64 builds.

Published a pair of DLLs that only rely on KERNEL32.

Ah gee, I’ll need to look into this - must be something having switched from {"name":"<name>","path":"<relative path>"} to just "name", which is not something I can future-proof against. Do you know if it’s a specific feature that causes this? From the error it looks like variable definitions, but this part is shared between GMRoomPack and GMLive’s room reloader, so I’m not sure if I had modified it since the last release.

GMLive.js uses GameMaker’s HTML5 runtime functions directly, meaning that these did not function as intended in GameMaker runtime itself as of ~1.4.1804 (“GMS1”) / 2.2.5 (“GMS2”) accordingly. You can try fiddling with version (try GMS2) / mode (try GL) settings, but if that is of no help - that’s it. Manually trying to fix bugs in obfuscated GameMaker runtime code is way too time-consuming.

Cloud saving in general can cause all kinds of weird things - by premise, it will check whether the save files are in sync when the game opens and will upload them when the game closes, but changing files both with the game closed or while the game is open is undefined behaviour - e.g. Steam might straight up cache small files in the memory for quick access.

As for my doubts of name having anything to do with this (unless it’s on Steam’s end), the character name has no meaning - in fact, your character name can even be different from the file name, which will happen if it contains characters that are not allowed in a file name (like \/<>|"*: on Windows)

You might be doing something wrong - like not replacing the file with a new one. See troubleshooting

Tabs are managed by chrome-tabs. You can modify it or replace it entirely.

There are a few hundred hours worth of changes between the original Spelunky Classic source code and what Spelunky SD is. Perhaps a few dozen less if you take the Humble Bundle version that’s already imported to GM:S.

The game runs fine under WINE/CrossOver, but a native version is currently unlikely - you may thank Apple for their prolonged efforts in quickly deprecating hardware and requiring developers to pay them a yearly fee even if an application is not being distributed through App Store (“notarization”).

Are you using Apollo V2.3? It’s linked statically now (as per post).

You can also try getting logs (run the game with -output out.txt -debugoutput out.txt) from the person.

Music not playing would usually mean that files cannot be found next to NTT executable.

Hello! It should work fine on x86 Windows so long as it’s Windows Vista or newer.

It is possible that your executable gets confiscated by an antivirus program for the duration of scan - try with something simpler like a .txt file first.

Each of the lines formatted like

if (live_enabled) mt_something.h_constructor=something

You can generally global search (Ctrl+Shift+F) for “h_constructor” and remove each line that mentions it

That means that you did not remove the NDLLs (which are for Windows) as the documentation instructs in setup steps

See the topic directly below yours (this bit specifically)

Your line must be something like

array_name[i][k] = val

which looks innocent but is executed as

if <is not set>(array_name) || !is_array(array_name) array_name = [];
var tmp;
if (i >= array_length(array_name) || !is_array(array_name[i])) {
    tmp = [];
    array_name[@i] = tmp;
} else tmp = array_name[i];
tmp[@k] = val;

Changing it to array_name[@i][@k] = val; would fix it. Using legacy [i, k] syntax might also work since I had that hard-coded as an exception from usual rules before.

I intend to rewrite how GMLive handles this but it’s a moderate amount of work since you can similarly do map[?key][ind] = val, list[|i][k] = val, and so on, and it will store the freshly made array in the data structure in each case.

That is most likely a bug/side-effect - although the compiler accepts them, it is not mentioned in the Release Notes, IDE doesn’t know about this, and non-Latin characters cause compilation errors on YYC on ~half of the platforms.

If it does become an officially supported feature, I can add support for it to GMEdit - will mostly need to figure out what is a valid letter now and what isn’t (e.g. µ counts as a valid variable name but ¶ doesn’t).