Hello,
during my lunch break I tried to port Another World (RAW - the opensource reimplementation of the engine) to Haiku.
Screenshots:
WARNING: you need original game files (I used the DOS version).
I’ll write a recipe and send a PR tonight or tomorrow (@Begasus you are authorized to kick my ass if I forget any trailing line this time 
)
HELP NEEDED: the recipe is almost ready, but since the game requires additional files (the original game data) to be copied to the installation directory, and since that directory is read-only (/boot/system/apps/AnotherWorld/), I don’t know how to proceed.
Any advice? Thanks a lot.
Other than that, it is ready.
What about?
–datapath=PATH Path to data files (default ‘.’)
@johna Yeah, this is also feasible, but then you have to instruct the user to place the data in another directory.
Don’t get me wrong, this is perfectly fine (at least for me), but for the end user I think that a self-contained solution is better.
Anyway if this is the only solution, I can proceed. I’ll wait for a confirmation 
You can use a wrapper script like it is used here: https://github.com/haikuports/haikuports/blob/master/games-strategy/ja2_stracciatella/additional-files/ja2_stracciatella.sh
Thanks everyone for your suggestions.
@extrowerk solution is my favourite: a launch script is perfect for notify the user any error due to missing game data! Thanks
Also, sorry for these questions, I’m a total noob at packaging software on Haiku 
It’s also possible to provide a script to make a “data” package from the original data files, then install this package locally.
PR is now live: Another World (NEO-RAW): new recipe by Luca1991 · Pull Request #9426 · haikuports/haikuports · GitHub
@humdinger is our script guru, I’ll leave that up to him, left a note on the PR to put the binary “raw” in $binDir or $prefix/bin so users can control the engine from Terminal even without the script.
Hardly… 
I did have a few comments, though.
Hi @luca91
The 32-bit version has a problem:
The bash startup script looks for the application “neo-raw”, in 32 bits it is called “neo-raw-x86”. I have copied and modified the script and it works fine with that executable, but I guess that not everyone looks at the script file or launch some things from Terminal
Maybe creating an alias (end-user) or editing the recipe are good options for the distribution. Or create the verification in script:
runapp=""
FILE=/boot/system/bin/neo-raw
if [ -f "$FILE" ]; then
runapp="/boot/system/bin/neo-raw"
else
runapp="/boot/system/bin/neo-raw-x86"
fi
"$runapp" --datapath=$DATA_PATH --savepath=$SAVE_PATH $@ &
# Something like this i supose
Greetings and thanks for one of my favorite games!
This is actualy just a symlink, the actual binary is located in: “/boot/system/bin/x86/neo-raw”
Then is that an system error?
I have this on the PATH variable: ~> echo $PATH
.:/boot/home/config/non-packaged/bin:/boot/home/config/bin:/boot/system/non-packaged/bin:/bin:/boot/system/apps:/boot/system/preferences
~>
I doesn’t have /boot/system/bin/x86/ added by default, ergo doesn’t start neo-raw because the name of the symlink is neo-raw-x86 … that’s important, right? Because ok, the neo-raw-x86 is a symlink but …Shouldn’t that route be added by default in the system?
What’s the point of having it like this, /bin for symbolic links and /bin/x86 for applications?
My bad, it is maybe better to point to the liked file in this case? As for routing the path, I think it would confuse the system when it can find both the binaries in $PATH? (not a dev here so not that knowlidgable in that area).
I think the PATH is only routed to /bin/x86 in x86 mode, with setarch x86, otherwise, by default, x86_gcc2 binaries are run, unless you are explicit with the -x86.
That is why gcc is gcc2 unless you setarch x86.
Thanks all…
First, thanks for the replies!!
The github user @korli was updated the recipe… replacing $binDir (better option than mine of course! :-D) with $prefix/bin
Now works without problem in x86 (and without external scripts!)
Thanks! Regards!