Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


Livecoding for GameMaker: Studio / GameMaker Studio 2 · By YellowAfterlife

Issues when setting live_enabled to 0

A topic by DanBradbury created Dec 04, 2018 Views: 150 Replies: 3
Viewing posts 1 to 4
(1 edit)

Sorry for the vagueness of the question but I very naively bought GMLive right before Ludum Dare and used it throughout development (very happy with the results throughout the process.. tossing `if (live_call()) return live_result;` into many draw events / most scripts. My understanding was that I would do this during dev and then flip the macro back to 0 when I wanted to deploy an .exe (single runtime / zip would have worked for me)

When I flipped the value over and ran my game I started to notice strange bugs that I thought were possibly introduced during a refactor.. upon verifying many times (driving myself crazy) the game logic would only function when `live_enabled =1` and netlog + gmlive-server were running (smoothly and as expected without bugs I was seeing in my exe)

The project is quite large so not sure what the snippet to share would be but I am a noob with GMLive and probably missed something in the docs / abused the tool to try and bust a game out.. tried to rollback to commits a day before and turn the value off and am still running into similar bugs popping up only when live_enabled=0.. the failure of not completing a LD is still a bit raw

Other details:

GM Version: 1.4.999

Windows 10

Code editing done in custom IDE but I feel fairly confident it's not the problem (I built simple replace logic and cant see it failing in my logs).. but possible I corrupted gmx state (although Im sure GM would complain when I open the project)

- GM Studio Compile+Run produce same results as ghetto custom compile that I use in my own IDE


I'd need to see a sample of code that misbehaves - there's a small chance that you somehow wrote code that only works in GMLive's variant of GML (which matches the regular GML in ~99% of cases). If that is the case, removing live-call line from the affected event would trigger the issue all the same.

(1 edit)

I've got a full repo on github with the project.. Ill do the work to figure out exactly what the issue is if it helps? My plan is to wipe all the live stuff out and ensure the game functions as it did when live was running.. Ive got the bug trapped to an exact moment when a script should be executed and isnt in the non live environment.. Will do some more science and update here if it helps with the effort is the repo.. I believe the issue is a terrible looking STEP event inside the o_level1_enemy.. only thing thats bothering me is the entire game ran so smoothly with live and then once it turned off it was a pretty immediate bug.

Can you speak to some of the nuanced differences in the GMLive variant? Obviously quite a bit of magic going on but I'd venture to guess that the magic for scripts/object events has to do some nifty tricks to function correctly (part of me thinks that whatever that magic logic is to live load is actually correcting some bug that I have in my code base.. no idea why but just the "feel" I get during debugging it).. remember that I am a noob to GMLive and pretty much copied-pastad `if (live_call()) return live_result` into everything that I was working on as I went (without thinking about any consequences)


Here's a [gist]( with the output from netlog+gmlive-server.. thinking that i can/will go through each of those files meticulously and find quite a few bugs that were written in the heat of the jam..

GMLive was an incredible experience for a first time during a jam.. im sure ive just covered up a bug but hopefully whatever it is can be helpful to you.. will freeze master as is for the time being / have a SHA if I find what it is and start making changes


On a glance, nothing is off in an obvious way - I think out of the few differences the one that is the most likely to cause mystery issues is the array copy behaviour, but you don't seem to be using it that way