Is there a particular reason you never read my message sent directly above yours? I know this was four years ago and likely no longer relevant to you. But dang. My message explains how to get it working and it was very hard to miss. Are you not even willing to try it?
high on tantor
Creator of
Recent community posts
I tried it on KDE neon recently which is a linux distro nearly identical to Kubuntu and it worked with both a Wayland and an X11 session. The only difference between the two distros is KDE neon is strictly based on Ubuntu LTS releases and it has newer KDE software releases than Kubuntu does. I'm not sure why you are having issues. KDE neon also doesn't use snap packages by default even though Kubuntu does, but that should be unrelated to the problem as well.
What Linux distro (and release) are you using? Only Ubuntu is supported, last time I updated it was strictly Ubuntu 22.04 LTS that was required for building app images, then the resulting app image could then work on almost any modern distro. I may need to update this to make it work on Ubuntu 24.04 LTS since GameMaker has moved on a bit with the most recent Ubuntu support.
Yes, I fixed this bug a while ago by switching to MinGW to compile the DLL instead of Visual Studio on Windows. Digging deeper more recently and the real reason it crashed was because I was missing a needed mutex for the multi-threading, which, when I have that, it works when compiled with Visual Studio also. Call ProcIdKill(procId) on the process ID associated with Stockfish Chess and it will be forced closed. Handling that to happen when the game crashes in particular, I'm not sure if that is possible in GameMaker. I think GameMaker added support for exceptions, is that what you'd use? I'm not sure if that would work, but it's worth trying. Keep in mind process ID's are reused by the system. It can be dangerous to call ProcIdKill(procId) because it can easily kill the wrong process, so use with caution. I recommend checking the completion status first to see if Stockfish Chess is still running.
Everything you need to know about this is in the demo project, including documentation as previously pointed out in this topic.
These two events in particular are useful for what you need:
Key Press - R Event:
input = GetString("Enter a command to execute from the shell below:", "ENTER COMMAND LINE HERE");
pid = ProcessExecuteAsync(input);
Step Event:
if (pid != 0 && CompletionStatusFromExecutedProcess(pid)) {
output = ExecutedProcessReadFromStandardOutput(pid);
if (string_replace_all(string_replace_all(output, "\n", ""), "\r", "") != "") {
ShowMessage("Process Output:\n\n" + output);
}
FreeExecutedProcessStandardOutput(pid);
FreeExecutedProcessStandardInput(pid);
pid = 0;
}
Details on Above Code:
The return value of ProcessExecuteAsync() is a Process ID, an ID representing the command run, which can be passed to other functions such as CompletionStatusFromExecutedProcess() and ExecutedProcessReadFromStandardOutput(). If ProcessExecuteAsync() returned zero, the function failed. To check if the function both succeeded and the command completed execution, see if the return value of ProcessExecuteAsync() does not equal zero, and also pass the return value of ProcessExecuteAsync() to CompletionStatusFromExecutedProcess(), while checking if CompletionStatusFromExecutedProcess() returned true to verify the process completed execution, like the above code does.
You can pass the return value of ProcessExecuteAsync() to ExecutedProcessReadFromStandardOutput() get the Standard Output and Standard Error strings of your python script (both those strings will be combined into one unless you redirect one of them to a file or null device).
Whenever running ProcessExecuteAsync() or ProcessExecute(), never forget to free memory when the process has completed execution. This can be done by passing the return value of those functions to FreeExecutedProcessStandardOutput() and FreeExecutedProcessStandardInput().
The command argument of ProcessExecuteAsync() and ProcessExecute() treats spaces as separate command line arguments, unless the spaces have quotes around them. Since the command argument has quotes around it already, because it is a string, you will need to use quotes within quotes and apply character escaping on the inner quotes, so the command will recognize the spaces properly and so it won't treat the spaces as separate command line arguments, (for example, working_directory and other paths may contain spaces in them).
Also, ProcessExecute() automatically will wait for the python script to complete its execution before returning to the main game loop. Maybe it would be simpler to use that instead of ProcessExecuteAsync() and having to manually check for completion with Process ID != zero && CompletionStatusFromExecutedProcess() == true.
Lastly:
Please contact me on Discord for quicker help, as we can chat on there in real-time and I'm far more active over there. My discord handle is: samuelvenable
Hi,
which extension does this apply to?
Thanks
Edit:
Sorry, I misread this topic, it appears this is a request for me to write a new extension. I'll look into it, currently busy with other things for the next couple days. The only way that I know of to prevent hanging is to process the screenshot capture in a secondary thread, but the resulting image might look glitchy because of the runner not being able to hold still for the image capture.
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.
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. macOS is not able to do that due to platform lockdown. Apple prevents macOS application windows owned by different processes from interacting with each other in this particular way, with no workaround.
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 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.
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.
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. My discord is "samuelvenable" - 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...



