WARNING: original game data is required to play. You can buy the game on GOG and then extract the ThimbleweedPark.ggpack1 and ThimbleweedPark.ggpack2 files using “innoextract”
I’ll try to create a recipe, but this time it will probably take a lot longer as I had to do some dirty hacks to get it to work, so upstream patches are needed. I’ll try to send PRs to the upstream project (and dependencies) to fix the various build issues. I’ll keep this thread updated.
I’ll try to summarize here the current issues that prevent the creation of an haiku package.
[FIXED] nimbler looks for libSDL.so in the wrong path: this is now fixed thanks to a flag passed to nimbler during building phase (many thanks to the ppl in the haiku irc channel who helped me).
[FIXED LOCALLY] scemino/nglib dependency has a critical bug on haiku: I already fixed it locally, I just need to open a PR upstream.
The game engine uses hardcoded paths (“./”) for both game data and save data: this is the real problem preventing the creation of the package I can’t just put the binary in /apps because then the users can’t copy the required game data there (and of course the save system will be broken too, since this directory is not writable). One possible solution is to patch the code to accept launch params (like --datapaht and --savepath): while this is very easy for the datapath param (I have already wrote the patch locally), it is complex for the savepath param (since multiple parts of code will read/write savegames, multiple patches are needed).
tldr: the remaning issue is the hardcoded paths in the source code for game data and savegame files.
If the paths are relative to the current directory, all you need is to insert a chdir() call somewhere in the main function. Or even do a shell script that will do a cd to the correct directory and then launch the app.
Certainly no need for something crazy like a RAM disk??? Even if you needed a directory with links, you could do that in /tmp, or in the app main directory, actually.
during my lunch break I took a closer look at the issue. I can confirm that if I cd to the dir with game data and then launch the executable everything works correctly. So worst case scenario: I’ll write a launch script that will cd to ~/config/non-packaged/data/thimbleweed_park (or similar) and then start the main executable (located in /bin).
I’ve already sent an email (yersterday night) to the original author of engg2, asking if he is insterested in adding launch arguments to specify the gamedata and savegame paths. Let’s wait for his opinion and then decide what to do. In the meantime I’ll fix the nglib issue.
Hi, lunch break here again, so it is time for some updates
@lelldorin great tutorial, thanks. Sadly I can’t package the two ggpack files as they are copyrighted.
I sent a PR to scemino/nglib (upstream) with a workaround for Haiku.
Once it is (hopefully) merged, I’ll be able to open a PR to haikuports, since all the other issues are already somewhat fixed.
You can create a folder for the files you need and create this folder via a postinstall script. The folder should already be on your system and you can then create a link to this folder in your program directory. The description must then state where the files need to be copied.
The postinstall script is always executed when the package is read, so it should always be available when the user should copy the files.
There is only one further problem with this: the game creates some files (savegames) in its directory. There is no way to know how many of these files will be created (because it depends on how often the user decides to save the game). Do you have any ideas for this? Thanks a lot.
Unfortunately not. Not without patching multiple functions as the code reads/writes the save file from multiple functions.
Anyway I think a startup script is the way to go in this particular case. The problem is that the PR isn’t getting merged and the repository owner doesn’t respond to my emails. I don’t think my patch can be applied at build time since nimbler downloads the required libraries into a subfolder in the home directory.
I can’t just put the binary in /apps because then the users can’t copy the required game data there (and of course the save system will be broken too, since this directory is not writable). One possible solution is to patch the code to accept launch params (like --datapaht and --savepath): while this is very easy for the datapath param (I have already wrote the patch locally), it is complex for the savepath param (since multiple parts of code will read/write savegames, multiple patches are needed).
