Alberto Salvia Novella

Fixed in Linux: darkmod-linux-packager

I have created this software, in case you wanted to mention it in the website. Before that making the game available in a Linux software center was a major pain. On Arch Linux for example the game was broken for years because nobody really knew how to fix its packaging. But now this software builds in one clic the file system of the game, so a person only needs to provide that as it is inside a package for making the game available to any Linux operating system. Then one single installation serves all users in the system, and the game is updated using the software center itself. This software will handle gracefully and automatically mostly any new release of the game. And it will even be resilient to transient internet disconnections, where by the way the current updater just hangs forever.

Probably using libcurl for downloads will fix this. At least the curl command on Linux handles gracefully disconnections. If there is a disconnection curl simply waits for the connection to come back, and when it does curl just continues downloading from where it left.

I don't mean that. Command line programs can print its content using two different channels. One is stdout (&1), intended for regular messages, and the other is stderr (&2), for errors. If no channel is specified in the code, the program uses stdout by default: echo "Message" echo "Error" >&2 Also when those programs finish they return an integer value (named ${?}) which signals if it has finished properly or not for following commands. Success always has a value of 0, while any other value signals an error. These are standard in every single application you see, and allows properly working between different software. For example, if The Dark Mod followed the standard, another application could check if it crashed and log the error: if [ ${?} -ne 0 ]; then echo "${function}: ${error}" >&2 exit 1 fi I have written an application that allows all users in a system to run The Dark Mod with a single system wide folder. That application right now cannot tell when the program crashes. I'm planning to share the software in the case other people find it useful.

How to reproduce: 1. Delete "tdm_fonts01.pk4" 2. Run the game in a terminal. Result: signal caught: Segmentation fault About to exit with code 0 Also these errors are printed to stdout, where it should be stderr. This is relevant because if the game crashes it cannot properly report that to a parent process. Such parent is needed, for example, for running the game with a single installation for all users on an Unix system.

I'm using a Linux system. You can reproduce the bug like this: 1. Run tdm_update. 2. Disconnect from the Internet. 3. Reconnect to the Internet. Result: The installer permanently hangs. Yes, I meant tdm_update in all cases. Actually what I'm trying to do isn't to install the game, but to package it for Arch Linux. And I realized that I don't even need the installer for that. I could simply download the files from a mirror, and use good Unix utils for that. Easier to code, and more reliable. Sorry for other operating system, but supporting them on my side would require considerably more work. As you cannot compose simple commands for making a new software, but you have to code everything. Plus I don't see them as a viable future. I will share the code when it's finished.

And this isn't about making the installer more robust, but it to work properly to start with. It hangs quite often.

I wouldn't normally recommend changing the programming language of a software, simply because the other language is better. That's very typical, but most of the time a bad move. On the other hand this seems the perfect situation for doing it, as the program is small and the target language much better suited. I'm not trying to convince you of anything, I'm simply speaking my mind.

As side note, just in case the info is useful, the root cause of these problems probably has to do a lot with the language selection for writing the installer. C++ is very capable and performant, but is quite easy to let slip bugs on it and it's slow on developing compared with mostly any other programming language, even if you are not good at it. Simple tools like this doesn't require such performance and tooling, and would greatly benefit from using a simpler compiled language. Go seems a good fit, since it robust against errors and was designed with networking in mind. Its binaries are cross platform compatible, and compiling them is instant.

@freyk @greebo If while the installer is downloading files there's a transient disconnection, either by the client computer or the download mirror, the installer permanently hangs. As result, as other people told me, users believe that the installer simply doesn't work on their systems. Additionally if you are using the installer for building a Linux package, the building process never finishes. The installer should re-connect on connection lost, and timeout with a crash if the connection has been failing for a while. Also it currently returns exit status 1 on success, where it should be 0. Status 1 means failure.