Daikatana 1.3 (Linux) crashes when launched from Steam

[Hells Bells]

Since Daikatana was on sale this weekend, I picked it up and began experimenting with the 1.3 patch (specifically the native Linux capability). I installed the game via Proton, then unzipped the Windows 1.3 patch into the folder Steam created, followed by the Linux 1.3 patch, as directed in this guide (https://steamcommunity.com/sharedfiles/filedetails/?id=282094762). If I run the game by clicking the daikatana file in the game folder, the game runs without issue.

Generally what I do with sourceports (ECWolf, GZDoom, Quakespasm, YamagiQ2) is set a launch option in the game’s Steam entry so that the source port launches instead of the Windows version of the game. With Daikatana, this would look like:

/mnt/6173eb9c-38d6-4b95-b26d-6d873df543c0/SteamLibrary/steamapps/common/Daikatana/daikatana %command%

Launching the game in this way will bring me to the main menu, where I can change settings and have those changes persist (though it doesn’t seem to run the auto updater, which is fine since I’m told there’s an update regardless of whether or not there is one). If I attempt to start a new game, however, or load one from if I’d launched via terminal or double click, the game crashes.

I’m attaching the terminal output of this, hopefully a solution can be found!

[Frank Sapone]

The dump isn’t as helpful as I’ve hoped. To be honest, I’ve never ran it via Steam in Linux; I would cd /usr/local/games/daikatana (or something similar). The game does need to be able to find your home folder and have write access to this folder (the console output shows /home/chas/.local/share/./Daikatana/data) to be able to save games and to save your configs, in addition to any custom assets that are downloaded from servers. My guess is how it is executing, the permissions are not able to talk to that directory properly with write access and this is why it is crashing. When you start a new game it generates an autosave.

In any case, if you can do /developer 1+65536 in the console as soon as you start the game this way and send me an additional console log from that it may shed some light. You could probably also try setting CHMOD to allow R/W for everyone for /home/chas/.local/share/./Daikatana/ briefly to verify this is the problem.

Sorry for the delay. I am interested in helping you, but I have been busy!

[Frank Sapone]

Also, I realized that the blank portable.cfg in Daikatana/data is only available on Windows; I need to add that to non-Windows platforms at some point. I’ll try to get around to doing that over the next couple of days as this would help debugging folder permission issues.

[Hells Bells]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Hells Bells]

No worries, life gets in the way sometimes! Only reason I made dual Bitbucket and Steam posts is cause I thought maybe there’d be different people in each place.

65536 is attached. Unfortunately setting the folder to R/W everyone did not solve the problem. Hopefully this will shed more light!

[Frank Sapone]

Unfortunately the verbose output doesn’t tell me much. Is there any files in /home/chas/.local/share/./Daikatana/data/save_x64/current/ ?

Does the game just exit abruptly at “Setting up 1.3 protocol limits”? Does it give a segfault of any kind or does it just simply exit? If it does give a segfault can you give me a memory dump? Can you go to Multiplayer and join a server or even host one?

One thing that is interesting is that it shows “MD5 for daikatana: 00000000000000000000000000000000” so I guess the code for the autoupdater is not able to ready the current working directory properly when launched from steam this way. This is why it keeps telling you updates are available.

[Frank Sapone]

My guess, is that however this steam app is redirecting things is messing up the directory structure in somehow that we don’t have proper handling for in the helper file i/o functions. But without a memory dump it’s hard to tell at this point. I might be able to try and set the game up in a linux VM with Steam installed and see what happens.

[Hells Bells]

Simple exit, unfortunately. Any kind of fault was the first thing I looked for since i thought it would help.

As for the current folder, there’s e1m2a.savz, game.ssv, info.hdr, server.ssv, and shot.jpg (I’ve played the first mission without Steam just to confirm it works if launched in what I’ll call the “traditional” way.

Generally I run games from a separate SSD than the one my OS and Steam itself is installed on. I’m going to try moving the original install of Daikatana to the OS drive and see if that changes anything.

[Hells Bells]

Attempting to join a multiplayer game results in same crash

[Hells Bells]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Frank Sapone]

Interesting. This still doesn’t tell me anything about why it crashes. Did you try moving it to your OS drive? Are you able to start all this through GDB? Maybe when it crashes while running in GDB it will give you more details.

[Hells Bells]

No joy on the OS drive. I gave GBD a shot but I’m not sure it returned anything different.

[Hells Bells]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Frank Sapone]

That does show that its crashing somewhere in steams libraries. Not sure what to say you may just have to run it without steam. I've ran into issues before with dk and strange memory corruption issues from dk launched inside steam but its been years.

With that said, there is some newer betas I have not released where I ran it through ASAN to fix a lot of memory corruption bugs, etc. I could make a compile tomorrow for you to test if you'd like.

[Frank Sapone]

Also I am unfamiliar with unix except to make some compiles for the environment. But sigint is apparently related to ctrl+c handler. There is a console variable to disable ctrl+c shortcut in daikatana. I dont remember it offhand I am not at a computer right now but do /cvarlist ctrl or /cvarlist disconnect. If you can't find it there look in the readme.pdf

[Hells Bells]

Sure, I'd be happy to help. Not the end of the world if it doesn't work I suppose. I've just always felt this was a more elegant way to launch native Linux source ports than adding as non- steam games.

Sent from ProtonMail mobile

[Hells Bells]

I should have mentioned, the Ctrl+C was me copying the terminal logs.

Sent from ProtonMail mobile

[Frank Sapone]

Okay, well the cvar is con_shortcut_instant_disconnect but that only forces a disconnect so I doubt it will change things. What distribution and version are you using? I'll try and make some time to setup it up in vbox and install steam on it.

I am interested in getting it to work properly I cant think of reasons why it wouldn't work.

[Hells Bells]

Pop!_OS 20.04, an Ubuntu variant. Running the 64 bit version as 32 bit has always failed to launch entirely for me.

Sent from ProtonMail mobile

[Frank Sapone]

I had Dekonega run the same test via steam and he also had the crash at the same point. He was able to get a proper backtrace that shows it fails from some libcurl code. It looks like steams library of libcurl is overriding the one for DK 1.3. Not sure if their version has a bug in the version they are using, or what’s the deal but I added some additional sanity checks. During loading of a map the HTTP handles for downloads are cleared. They’re likely NULL from cleanup, but it’s an additional bit I added just in case if a download fails and it’s not reset for whatever reason. I’m pretty sure it is safe to pass NULL to these libcurl functions, but maybe the one steam has doesn’t work this way.

Here is a test build that I believe will fix the issue: http://maraakate.org/DK13/Test_Builds/Daikatana-Linux-2021-03-28-x64-TEST.tar.bz2

Please run this and let me know if it fixes your issue. If it does, set developer to 0 (or developer 1 if you really want to see things). Developer 65536 is verbose messages, and there is currently on going testing for some things ASAN discovered and it may flood the console output on occasion from some things which will be annoying.

[Hells Bells]

And we’re in business!

That worked and messages have been restored to default. Previous Save wasn’t compatible but no matter, I was only up to the Sewer System.

Thank you for your help and sorry I couldn’t get a proper backtrace myself.