Hey, I updated the extension and it now works on macOS! I'm not sure what made the difference to be honest. I made some technical changes on how it is used and it no longer has the problem you mentioned. Please test it and let me know if it works on your end. Turns out I was way too quick to blame YoYoGames for this... Originally, I was trying to fix an issue that someone reported of it not working on Linux. When I fixed it on Linux, by some weird chance, it happened to fix the macOS bug as well. As usual, I recommend seeing what's different in the demo project; it is slightly different now.
Samuel Venable
Creator of
Recent community posts
For people reading this, Marcio Ramos reached out to me on Discord and I helped him get this working. For a demo that works on Windows and Linux that you can test drive yourself, download my "GameLauncher.zip" GameMaker extension from the collection downloads page. There is no macOS example however because of platform specifics which only work on Windows and Linux, code which allows the game window to be modal/transient for the launcher window aka stay on top.
Mac is not able to do that due to platform lockdown. Apple prevents application windows owned by different processes from interacting with each other. I could technically implement the macOS version differently, where the game stays on top of all normal windows in the desktop, and not just the launcher, but that is not the expected behavior of this type of window interaction. Let me know in a new topic if you want a macOS version regardless of this limitation and I'll add it.
Edit:
For people reading the OP, the function execute_shell_simple() is provided by a different extension (Execute Shell Simple) by a different author (Yellow Afterlife). That function as far as I know at the time of writing this does not return a process ID and is not compatible with my xProcess extension at all. I apologize if the OP confuses anyone. I think the author of this topic just wrote a typo and that's why it says what it does. Use Execute Shell Simple by Yellow Afterlife if my extension is too advanced for you.
Note: Execute Shell Simple by Yellow Afterlife is Windows-only.
I think I might have fixed the crash you were experiencing with xProcess and chess engines. Here's a test project I sampled which used to crash but no longer does: shogi_demo.yyz. At least for me, anyway. Import the version of the xProcess extension from the YYZ into your chess game project and see if that fixes it. (While deleting the old version of xProcess in your project). Here's to hoping you haven't deleted your game project file. The crash happened because the DLL was compiled with Visual Studio. Compiling with MinGW/GCC instead fixed it. Really stupid solution, but at least it works now. Since STIGMA uses MinGW/GCC as its compiler on Windows, that explains why it didn't crash.
I apologize if my former message sounded cranky. I'm not upset with you or anyone, just slightly annoyed I'm going to have to update all my assets from scratch again, which isn't anyone's fault, (maybe YoYo's), but definitely not yours. But before I do that, I'm going to attempt to report this bug to YoYoGames in hopes they fix it on their end. I'll link to the bug after it has been made in an edit to this comment. Edit: Here's the bug report.
If it doesn't import correctly, that is a bug with GameMaker. It is not my responsibility to clean up after YoYoGames' messes. I would report this bug to the correct people (YoYoGames and not me) on GitHub - New Issue · YoYoGames/GameMaker-Bugs (github.com) If they refuse to be responsible and fix what they broke, let me know and I'll see what I can do, if anything. However, if their asset importer is completely broken and they don't fix it, there is nothing I can do. (I could technically try to recreate the projects and yymps files from scratch in the IDE version you mentioned, and see if that fixes it, but that will break the extensions from being able to work in older versions, which I'd like to avoid doing). TL;DR if YoYoGames fixes this on their end, it should work in both older and future versions of GameMaker.
Since several people have requested it, I decided for a limited time to make my WebMPlayer available for GameMaker Studio 2.2.x. Note the version of GameMaker Studio the project was made in is specifically GameMaker Sudio 2.2.3.436, and it may not be compatible with all 2.2.x versions of GameMaker Sudio, most notibly versions that are older than 2.2.3.436 or ones that are new enough that they fully transitioned to a 64-bit Runtime on Windows. Get it here. (Hotsted on Discord).
After further investigation, I have absolutely no idea how to produce a workaround to this problem. Please share your input on this bug report I submitted on GitHub and hopefully YoYoGames will take it more seriously: https://github.com/YoYoGames/GameMaker-Bugs/issues/6799
Generally, code like this doesn't simply stop working abruptly on its own. At least not under these particular circumstances. My guess is it has nothing to do with my code but rather internal changes to GameMaker's macOS runner which doesn't play well with my extension's pre-existing code. Meaning, I didn't break anything, but YoYoGames did. This is something I need to make accommodations for quite a bit over the years, because they constantly break how my code interacts with theirs, forcing me to either file a bug report, (and hope they fix it), or be left with having to attempt a workaround to the problems they created, on my end, even though it isn't my responsibility to fix what they break.
That said, thanks for bringing this to my attention. I'll see what I can do to get this resolved.
it really sounds like this has nothing to do with my extensions but rather you have tried one of them which has the filesystem sandbox turned off, in which case you are used to working with that turned on.
also, you can use game_save_id instead of working_directory; it is guaranteed to give you the path you want.
I just completed writing documentation just now for the GameMaker version of the library:
https://github.com/time-killer-games/libxprocess/blob/main/README.md
Please contact me on discord if you have more questions or need one-on-one assistance.
My discord handle is: samuelvenable
for starters, most basic usage is covered here:
http://gamemaker.info/en/manual#execute_program
execute_program(prog,arg,wait) Executes program prog with arguments arg. wait indicates whether to wait for finishing.
execute_shell(prog,arg) Executes the program (or file) in the shell.
Note in order to open a file with execute_shell you will need to specify as a first command line parameter in the prog argument the desired executable to open the file with passed in the arg argument. arg can contain multiple arguments, and they are space separated, so if you want to use a file path, flag, or paremeter with spaces in it, enclose it within single or double quotes (within the initial quotes representing it as a string).
execute_shell(@'cmd', @'"' + working_directory + @'batch_file.bat"');
or if you need the wait argument to make the call synchronous, use execute_program() instead, like so:
execute_program(@'cmd', @'"' + working_directory + @'batch_file.bat"', true);
if the prog argument in execute_shell or execute_program is command prompt (cmd.exe, cmd, or the absolute path to it, even) it will automatically have /c passed to it so the hidden command prompt window automatically closes when the batch_file.bat is done its execution.
I have documentation for (most) of the C++ library this extension is based on, however the C++ function implementations are rather different from the GameMaker implementation, function names, arguments, and usage are slightly different, but should help point you in the right direction:
https://github.com/time-killer-games/xproc/blob/main/README.md
It's on my to-do list to write documentation for the GameMaker-specific implementation. I've been requested this a lot so i will try to make it a priority soon.
For readers of this topic, I was able to narrow down the issue further, and it turns out that this is not a bug with the extension/demo itself, but rather a bug with GameMaker. I just tried the extension in a different game engine, a GameMaker clone called STIGMA, I maintain, (my fork of ENIGMA), and it doesn't crash on any platform, not even on Windows. Since both STIGMA and GameMaker rely on identical code for the xProcess extension, this is how we know it is a bug with GameMaker and not my extension. You can download the EXE made with STIGMA yourself if you would like to see for yourself what I am talking about:
https://github.com/time-killer-games/ENIGMA-StockfishChess-Demo/releases/downloa... You will notice if you leave the EXE running for a long time (it has the depth set to 1,000) it won't ever crash. I am going to report this bug to YoYoGames, but it is so specific to my extension and doesn't really effect any other projects, I doubt they will fix it, so no one should hold their breath or be the least bit hopeful about this. Previous download link includes a Windows EXE, macOS APP. Linux ELF, and not to mention there is also the GM81 project file which may be edited and compiled with STIGMA. STIGMA can be downloaded here: https://samuel-venable.itch.io/stigma-development-environment
For readers of this topic who aren't aware, I am talking with Byte GameMaker Magazin on Discord and behind the scenes I have been able to reproduce the bug he mentioned, though it is confirmed to be a Windows-only bug. Meaning it will not crash on macOS or Linux for anyone, making the extension/demo still valid/useful way more than it would be if it crashed on all platforms, (which it doesn't). Most people use Windows in the marketshare though, so this bug is considered crucial and I am making it a priority to fix it. I might get help from the boost process lead developer when he is less busy, if I am unable to figure this one out by myself.
My discord is "samuelvenable". Try downloading the project again and see if the new version of the extension fixes it. I added a new function which allows you to limit the buffer length to a specific number of characters, (including the null byte at the end). For example:
SetBufferLimitForStandardOutput(2048);
...will limit the buffer to 2,048 of the most recent characters.
Does the crash only happen with fairy-stockfish? Or does it happen with the default stockfish app which comes with the extension? It is my understanding the demo doesn't come with fairy-stockfish in specific, so it wasn't intended for that. Another user on discord already reported this to me with fairy-stockfish, and they ended up using a different chess engine entirely as their workaround to solve this issue. Unfortunately, this demo was made for a client and they seemed happy with it, but I can't comment much on the stability of it because while I did write the demo I don't actually know much about stockfish or command line chess engines as a whole, so I'm not the person to be much a help here. The demo was meant to show what can be done from the command line with various apps, and stockfish was just the command line app chosen for the demo, and mileage will vary across command line apps.
Also, I can't remember who pinged me on discord about stockfish, and I have way too many messages to dig through of support tickets to really go about finding who they were much less what chess engine they settled on; maybe if they read this topic they could comment and help you out.
I apologize for the inconvenience. I was never able to figure out the root cause of the crash and I've already spent as much time on trying to figure that one out as I would like.
One thing to make note of with any command line app you try to read standard output from is the buffer might overflow, which causes crashes. This happens when the string returned and sent to standard output is too large for the app to hold it in memory, and so it will close abruptly (crash) in such case. The extension used to store standard output in a string, called xProcess, does not truncate the string at all if it gets too big, though I doubt buffer overflow is the reason you get the crash you are facing. This note is more of a "so you know" for general rule of thumb in case you, (or anyone else for that matter), uses my xProcess extension for anything besides stockfish.
Hey, this is the author of stigma-dev. if you don't want to join my discord server, is there some other way I could contact you I could give you links to documentation and other useful information? This comments section really isn't the place for it--feel free to email me at samuelvenable@hotmail.com and delete this comment if you want. :) Sorry for the inconvenience!
P.S. My previous comment here came across a little rude and I deleted it as soon as I noticed that--I get a little grumpy sometimes and I apologize.
This assumes you have built this with non-i386 runner versions of GMS 2.x and not with 1.4. But if you want to appease the users who aren't Linux savvy enough to do this on their own, this is how you may convert the Linux app to an AppImage so it will run on any modern Linux distribution without any installation required. Let me know if you want or need i386, armv7, or aarch64 support - my discord is "Samuel Venable#5465" - tutorial here - https://forum.yoyogames.com/index.php?threads/gmappimager-tutorial-gm-games-that...
That's apple's way of forcing devs to pay for their Apple Developer Program, and they convince us to do it by blatantly lying to users who try to download software that isn't codesigned. I'm not joking. Apple is a deceitful turd of a company. Do as instructed here and it will run: https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-at...