Fixed in new mini-update.

Thank you!

It should highlight after you save the file (Ctrl+S). This is the case for most things in GMEdit.

If it does not highglight after that, try figuring out on what occasions this happens

Oh! That means that I forgot to add a DLL and you don't happen to have Neko VM installed for you to have one already.

Here's that: https://www.dropbox.com/s/02fdcssif22on30/std.ndll?dl=0

if that's all of troubles, I'll update the extension with it in a few

Oh yeah, on extension functions - it's because if GMEdit doesn't index the extension files, it can't do local variable highlighting and syntax extensions in them, but if it does, it auto-detects extension scripts as actual scripts due to #define lines. I've not yet implemented the abiliity to attach metadata to files so that it'd know if to do this or that or not.

Can you pick "Show in directory", Shift+Right-click on an empty spot, pick "Open command prompt" / "Open PowerShell", and open (".\GMRoomPack.exe", Enter) it from there? Should tell you what the error is then.

There's no single definitive way of handling this, 1.4 did highlight them as keywords:

I think it makes more sense this way - while all/noone as of yet remain magic numbers for instance handling operations, self/other/global have been special case structures for a very long time now - trying to do "v = self;" will compile as "v = self.id;", and you can no longer do "v = global;" at all, as it's no instance.

Apparently this would happen only very specifically if it's the first thing in the event as I forgot to reset the regular expression state between checks. Will be fixed in the next build.

Look up the sprite names here, /savesprite them, and add cases for them into skin_sprite template.

Для игры настраивается borderless режим в global game settings; спустя несколько вызовов window_frame_update расширение подвязывает к игре свое окно-рамку, благодаря которому фриз и устраняется

Someone said they'd take a look into that but I've not heard from them as of yet.

The game evidently manages to send data to the server [as the server notices it connecting], and the server is evidently responding to it [as it crashes if it cannot], but the game does not notice the response. Therefore you should check in GMS2 output if it's unhappy about anything or try adding an Async HTTP event and logging json_encode(async_load) to see if there's anything unusual (status codes/timeout) there.

На данный момент документации не существует, лишь проект-пример (GMZ) и примечания к некоторым функциям в авто-завершении. Если есть возможность пожертвовать ~$20 через итч, документация по 26 функциям расширения может быть написана (пример) на русском или английском языке в ближайший выходной.

The server says "ready!" after getting the "greeting" HTTP request from the game. The game continuously sends "greetings" until there's a valid response. So it would seem like it still fails to get a reply. See if the game gets blocked by firewall or needs an explicit permit to do anything about connectivity?

Does this happen on a smaller project and how long does the server take before printing out "ready!"?

"Broken pipe" means that the remote (in this case, GameMaker runner) closed the connection (in this case, an HTTP request) by the time things were going to get written to it, but I cannot think of any reason for this aside of reaching connection timeout (but even then I'm not sure if network_ connection timeout applies to this)

As far as I'm aware, the only thing in GMLive that can cause IDE lag is if your code is constantly throwing up errors and they are piling up in Output tab until they eventually "clog" it due to there being too many lines.

Other than that, neither the extension or the server perform any direct or indirect interactions with IDE - the server checks the requested files for changes and sends them to the game whenever it asks if there's anything new.

If you can get this to happen on a small project, feel free to email me a YYZ, and I'll see if I can reproduce this on my end.

In that case I have no further guesses other than trying to update graphics drivers or running the game windowed.

Is that on Linux? Someone had that issue before and it turned out to be something conflicting with their window manager, but I cannot recall what it was specifically.

Well, not easily.

Marking what code should be live-updated is not live_call's only function - it is also what runs the actual (new) code, subsequently backing out before running the original code if it did. So it cannot "automagically" apply to everything as it cannot have any effect on compilation process to inject that line.

You could add in a live_call to all scripts automatically one or other way (probably find-replace-in-files file-start "^" via any external code editor via regular expression), but there are a few gotchas:

• GMS1 tends to freak out if project files are being changed while also open in it, sometimes to the point of overwriting changes on save/compile or corrupting the file/project entirely. In other words, if using GMS1, make sure that the project isn't open in it while you do large external changes.
• If your project is really big, I expect the thing to not work that well - GMLive's server is watching specified files rather than directories as whole, so having way too many files might add up.

Generally I'd suggest to add live_call as a snippet to GameMaker (there's snippets.txt) for quick insertion and to add it to multiple potential subjects of interest before running the game.

It would usually mean that you had forgotten to run gmlive-server, or that something went wrong with it and it's throwing up errors instead of listening for the game's requests (see server window for errors)

You click "download" and name the file based on what the thing is

• custom characters: name.race.gml
• custom weapons: name.wep.gml
• custom skins: name.skin.gml
• general mods: name.mod.gml

I intend to address this soon - Mac builds were recently changed in GMS2 to produce 64-bit binaries (and use 64-bit extensions as result), but I've not yet managed to get the extension to work with that (primarily due to being overloaded with other tasks as-is). If there's a sense of urgency and you know your way around the basics of compiling with gcc+/g++, send me an email from your purchase address and with your order reference (find it here), and I'll send you the source code + current build files to try things out with.

Kind of hard to guess from that, but try restarting Steam or attempting to connect again after 15-20 seconds - if Steam takes too long to establish the connection to someone, you'll get a connection timeout, but subsequent attempts should take less time.

You cannot have "true" overloading in a dynamically typed language - the IDE cannot possibly show matching auto-completion because it has no clue what types variables or values are, and having a script do different things based on incoming argument is only fun up until you do so on accident.

#args schema is influenced by JavaScript's default parameters, as that's the safest way of doing this by a margin; both GMS and GMEdit support same syntax in function doc lines.

Apparently the issue with both is that, since it is the frame window that is in focus rather than the game (though it is a child of it and takes input), it is not counted as active and will not take inputs. Not actually sure if there's an easy fix, but if you know anyone experienced with WinAPI and willing to help, you can have them look at the source code.

It is possible that child rooms count as some different resource type or are not where most resources are. I'll need to check

Oh, that's possible - only the other day I had a conversation with someone about how low-level UDP libraries usually do not do URL resolution+caching automatically, and... well, I guess the one I used here doesn't either.

I'll see if this can be addressed later.

Does the same happen if you connect to yourself over localhost / could you get me dumps of the actual packets? It seems like the client is considering the connection to be broken as soon as they get the first packet.

There's this issue with GMLive.gml where if I'm to add new functions to it's script wrappers, it will no longer work with any preceding GM runtime (throwing an error about missing functions on compile).

A workaround for now is to make a script that calls the function in question,

/// @desc scr_collision_rectangle_list(x1,y1,x2,y2, obj, prec, notme, list, ordered)
return collision_rectangle_list(argument0, argument1, argument2, argument3, argument4, argument5, argument6, argument7, argument8);

and link it up at the end of obj_gmlive's Create event like so:

gml_func_add("collision_rectangle_list(x1,y1,x2,y2, obj, prec, notme, list, ordered)", scr_collision_rectangle_list);

It does seem like on the current GM version buffer_[get|set]_surface functions are once again broken on WebGL so it works only with WebGL disabled (Global Game Settings - HTML5 - Graphics)

Not sure if there's a good workaround tbh

I have answered that exactly one comment below yours.

You can do so by adding a counter variable to obj_gmlive and changing obj_gmlive's Async - HTTP event to be like

if (live_async_http_check()) {
    live_async_http();
    if (!live_is_ready && ++retry_counter > 5) instance_destroy();
}

Someone else asked about this before so I'll see about adding a built-in thing later

All available technical details are on the blog.

My extension for interfacing with Steam networking/matchmaking backends in GameMaker is publicly available.
Other engines have their own tools (sometimes built-in, sometimes not).

Patching is engine and version specific. For GameMaker you'd probably be looking at tools made for Undertale as that had grown the largest modding community as far as tinkering with file formats goes.

Actual networking can be done very differently game-to-game (this isn't specific to modding) and engines can be more or less fit for specific kinds of networking - search around for details on what people have been doing for similar games.

Ah, sorry. I didn't pay enough attention to your first message.

1. It'd take an entirely different system to minimize to tray instead.
   If you are able to pay for that (rough estimate is $100..$150 depending on features), that could be implemented into this or a separate extension.
   (if you are wondering, this extension similarly exists only because someone sponsored the development and was fine with it being made publicly available)
2. Conventional (DirectX) fullscreen rolls up on the monitor that it was initialized for, so usually the primary one.
   It's usually possible to move the game window between screens via Win+Shift+Left/Right, but I'm not sure if you could cheat it by pressing those keys via keyboard_key_press.
   If window_set_rect has any effect in fullscreen (or you are fine with borderless fullscreen), I could modify my other extension to return screen XYWH per monitor index.

Someone had this same issue half a year ago and editing the file worked for them, but they did not clarify what else they had an issue with. If you can send me an email from your purchase address, I can email you a version with these three functions removed.

That makes it a little hard to diagnose. Is there anything in the compile form? Does it happen if you import the extension to a blank project?

1. See the example from Window Commands extension, this one has the same-styled functions.
2. Disabling border (see the example attached) would allow you to call window_set_fullscreen as usual.

Please open the console (Ctrl+Shift+I, Console tab) and send the error that pops up there.

Known issues at this time are limited to GMEdit not being able to open GMS1 projects on Mac/Linux because GMS1 used Windows-only backslashes at a few points in formats.

To change max hp, add

maxhealth = 4;

to "create" script. (variables)

To explode on death, add

if (fork()) {
    var _x = x, _y = y;
    wait 1;
    if (!instance_exists(self)) { // we're dead!
        instance_create(_x, _y, Explosion);
    }
    exit;
}

to "step" script. (fork)

If your app is marked as freeware (or was marked at the moment of registering the App ID), you will need to contact Valve for them to enable matchmaking API for your app.