Launcher does nothing on Linux

[SeongGino]

Before this gets closed because not-Windows hear me out: HOTD3 does work normally under Linux with Wine (and dgvoodoo2, going through DXVK), as well as using DemulShooter alongside it to patch things like disabling automatic reloads. Save for requiring valid install location in the registry, it works even on a clean prefix (with Esync/Fsync disabled for the intro video to run smoothly).

However, the Arcade Mod Launcher doesn't seem to do much of anything. No crash, no notable output in Wine logs or Lutris, nothing. And when I searched earlier for similar questions and saw the -v verbose flag switch and tried it, all it output was:

[10:39:55.636929] RunGame() => Process created

Tried this on a clean wineprefix (simulated Windows install), and the prefix with HOTD3's registry entries; tried disabling DXVK; tried setting working directory to the ArcadeMod's directory and the main hod3pc.exe in case that mattered; tried using both my current exe with modified custom 1080p resolution and the original NO-CD-patched executable (judging by an md5 733da4e3cfe24b015e5f795811d481e6 seems to correlate with "Unknown Release no.1"). All the same symptom and (nearly no) log output.

Not sure if something about Wine is tripping up the launcher, or if maybe there's somehow a missing dependency separate from what's required for vanilla HOTD3 or DemulS?

FWIW, I'm using Arch Linux, running through Lutris as a launcher, tried with both Wine-GE and Wine-Staging.

[argonlefou]

Hi,

Thanks for your feedback

So....it's good to know that Wine can make DemulShooter work on linux, as it's also using low-level Win32API to work.

But this launcher is way more low-level and complicated : this mod is that it's creating the hod3pc process (what you can see in the debug file) with specific settings so that it can attach it as debugger, and use very low level Windows debugging API ton control and handle the differents steps of the binary loading process to patch in memory what need to be patch at the right moment.

Then once it is done, the launcher closes itself and the modified game run on it's own.

So it's almost like emulating a Windows debugger, coded on a language that need a lot of layered work from the .NET framewok to interface native old code with modern one....without creeping the OS memory.

Unfortunatelly, and as I don't know at all how WINE is working to make all of this work, there's nothing I can do. And even if my main computer is Debian based, going on WINE debugging for this is not something I can or want to do

[SeongGino]

So I know you closed this issue as not planned, but I thought I'd leave this here:

So it's almost like emulating a Windows debugger, coded on a language that need a lot of layered work from the .NET framewok to interface native old code with modern one....

Ironically enough, this helped immensely. The wine prefixes I was using didn't have .NET installed (or used Mono, more accurately, I guess). But since you brought it up, I tried running the mod on a prefix with .NET 4.7.2/4.8 installed (just a shot in the dark kind of move I guess).

And just like that, it works now.

So I guess in the end, I didn't realize that this mod has a hard(er) dependency on .NET (since none of the readme mentions it, like what I normally see on some unrelated projects that rely on it). But it's on me for not having the dependency in the first place, and assuming it's on the project's side for the failing. Regardless, the technical breakdown you gave was very much appreciated!

I'd probably close as finished, but a bit late for that. Anyways, I'd consider this retroactively finished.

[argonlefou]

Closing the ticket doesn't mean that I won't discuss anymore on the topic ;-)

There's no mention of .NET dependency because usually on Windows, if the targeted framework version is not installed the program will simply not start at all and yell error message

I honestly never though someone would be using it with WINE !

I'm glad to hear you found a workaround !

[SeongGino]

Fair enough!

Though I did check on Windows 10 for something slightly related (an input issue with DemulShooter and Gundam SOZ specifically) it at least prompted installing dotNET 3.5 there. But I've not used Windows in a little over a year at this point, so eh.

And usually Wine does a decent enough job of hinting what dependency is needed or going wrong, but since it (Mono, in this case) wasn't crashing but simply stalling, it was hard to tell what part it was on.

Still, thank you!