Doom64EX support (working directory issue)

[DanilaSpevak]

I tried to add Doom64EX as an engine to make DoomRunner the launcher of all my old Doom, and it's not working correctly. The launcher generates correct command line but the issue is with the working directory. When run from DoomRunner, the Current directory is DoomRunner's, not the one where Doom64ex is located.

So it can't find it's own files. I think that might happen to some other older sourceports as well. Wouldn't it make more sense generally to run engine processes using their location as a working directory?

[Youda008]

Hm, i have never thought about it. Until now all paths in the generated command have been relative to the DoomRunner's directory and there were no issues. But if some engines have problems with it, it makes sense to do it as you say.

---

From: DanilaSpevak notifications@github.com Sent: Sunday, January 3, 2021 9:31:22 AM To: Youda008/DoomRunner DoomRunner@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [Youda008/DoomRunner] Doom64EX support (#31)

I tried to add Doom64EX as an engine to make DoomRunner the launcher of all my old Doom, and it's not working correctly. The launcher generates correct command line but the issue is in the working folder. When run from DoomRunner, the Current directory is DoomRunner's, not the one where Doom64ex is located.

[2021-01-03_13h21_36]https://user-images.githubusercontent.com/42034406/103474589-40725f00-4dc7-11eb-87cc-63d70d130a4b.png

So it can't find it's own files. I think that might happen to some other older sourceports as well. Wouldn't it make more sense generally to run engine processes using their location as a working folder?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Youda008/DoomRunner/issues/31, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE25U35N47BXKFLQYQNPH5TSYATNVANCNFSM4VRWFE3A.

[Berzasperd]

This seems to be related to a similar issue I had with using DoomRunner with Crispy Doom. When launched using DoomRunner, Crispy Doom assumes that it is running in the same directory that the DoomRunner.exe is located in. As a result, it will create its own config files there and read from those, ignoring the ones in crispy-doom.exe's home directory. I haven't figured out which program is causing this issue yet, as it does not seem to affect other source ports, like GZDoom.

Major Edit

Originally, my comment on this issue was a long winded reiteration of DanilaSpavek's issue. All that I need to say at this point is that I can confirm the issue they are referring to. Doom64EX, when ran as a sourceport through DoomRunner, will generate a new config.cfg file in whichever directory DoomRunner.exe is in and not use those files that are located in DOOM64.EXE's directory. This behavior matches that of Crispy Doom, as mentioned above.

As an aside, I have tested running other games through DoomRunner. I have set up a preset for Quake and Hexen 2. The source ports I use for these allow the passing of -basedir or +set basedir to direct the source port to use the files located in the path specified by these arguments. This is something specific to those games / source ports, and so this issue does not appear to have a workaround for the Doom source ports that get confused by being launched in DoomRunner.

[Berzasperd]

Okay, did a little more testing and found some potentially useful details.

Source ports that accept the -config parameter can be told exactly which config file to use during launch, and will not create new ones in DoomRunner.exe's directory. Doom64EX and Chocolate/Crispy Doom support this. The difference is that these source ports use the .cfg file extension, which DoomRunner does not support in its drop down menu.

Workaround: Manually type in -config "filepath/config.cfg" for your preset to use the specified file consistently and not generate new files.

Consequences: If a user launches one source port that creates and reads "config.cfg" and then launches a different source port that also creates and reads the same file name, the second source port may overwrite the first config file or fail due to an error reading that file. This occurs if the user does not type in their own -config parameter. I have not tested this situation, since Doom64EX and Crispy Doom have different names for their config files.

Potential Fix 1: Make DoomRunner tell the source port that it is launching to stay within its own directory rather than using DoomRunner's directory to look for files. The relative file pathing works very well for command line parameters, but lacking those, some source ports seem to be easily confused. I am not sure how viable this fix is. I can't tell if this is a result of DoomRunner, or how Windows interprets programs launching other programs.

Potential Fix 2: Add support for .cfg files in DoomRunner's "Select config (optional)" drop down menu. This would allow users to more easily select the config file in question without having to type it into the additional arguments field. This would be a nice addition, though it will not solve the issue if the user leaves the config file blank. There may still be other unseen issues regarding a source port looking outside of its own directory, but I am not aware of any others at this time.

[Youda008]

Thank you for additional usecases. In that case DoomRunner will be reworked to switch the current dir to the engine's one before launch.

[Youda008]

Alright, this has been fixed. It will be part of next release.