Space Trader: Merchant Marine's for OpenPandora/Pyra and Linux x86-64


Thank you for your response.

I send you a private message with a key.

I have no idea what could be inside pak4.hwp.
pak4.hwp, like all the other pakX.hwp files, are simple zip. pak4.hwp contains 2 vm files:

Code:
Archive:  st/pak4.hwp
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  11-20-2008 15:56   vm/
   605348  11-20-2008 15:55   vm/qagame.qvm
   426748  11-20-2008 15:55   vm/ui.qvm
---------                     -------
  1032096                     3 files
 
I'm confident in my position: The source code that has been made public will never be able to run the version of the qame publicly available.

There are many magic index and switch case in a quaje3 engine game. Comparing the source code and a siassemble of the available game, I can see some range are missing in the source code!
For example, I'm focussing my analysis on the ui part. You can find the list of the values in ui_public.h (which is somewhat mirrored in ui_syscalls.asm where the value are negative minus one) There is a range 200-217 that doesn't appear at all in the code, but do exist in the SpaceTrader.exe and is also used in ui.qvm
also, the entre "100" is not COM_Draw as in the code, but memset...

cg_public.h is also missing the range 501-514 that's a lot of functions. Also no quaranties that the existing index are correct...

So yeah, that code will not build a working binary to run current available data, it's missing many things, it is outdated.
 
Last edited:
I'm confident in my position: The source code that has been made public will never be able to run the version of the qame publicly available.

There are many magic index and switch case in a quaje3 engine game. Comparing the source code and a siassemble of the available game, I can see some range are missing in the source code!
For example, I'm focussing my analysis on the ui part. You can find the list of the values in ui_public.h (which is somewhat mirrored in ui_syscalls.asm where the value are negative minus one) There is a range 200-217 that doesn't appear at all in the code, but do exist in the SpaceTrader.exe and is also used in ui.qvm
also, the entre "100" is not COM_Draw as in the code, but memset...

cg_public.h is also missing the range 501-514 that's a lot of functions. Also no quaranties that the existing index are correct...

So yeah, that code will not build a working binary to run current available data, it's missing many things, it is outdated.


Thank you so much for trying to build Space Trader for OpenPandora/Pyra and Linux x86.

I didn’t expect to read about all these issues with the source code and the .pak files.

Does it mean that versions built from this source code for Windows and Mac also won’t work with the pak files from GOG or Steam?

I ask because I don’t know if the source code for these versions is better than that for the Linux version.


I know there was a shareware version on their website, which I don’t have.

Do you think this file SpaceTrader-1.0.8_linux_en-US.run could be used with the source code for Space Trader 1.1.14?

I speculate here because I don't know who has this file, but maybe there's something about version 1.0.8 in this code.
 
Last edited:
Thank you so much for trying to build Space Trader for OpenPandora/Pyra and Linux x86.

I didn’t expect to read about all these issues with the source code and the .pak files.

Does it mean that versions built from this source code for Windows and Mac also won’t work with the pak files from GOG or Steam?

I ask because I don’t know if the source code for these versions is better than that for the Linux version.


I know there was a shareware version on their website, which I don’t have.

Do you think this file SpaceTrader-1.0.8_linux_en-US.run could be used with the source code for Space Trader 1.1.14?

I speculate here because I don't know who has this file, but maybe there's something about version 1.0.8 in this code.

Yes, Windows & Mac version would do the same. The part of the code that have issue (I mean, that is missing stuffs) is common to all architecture.

About the 1.0.8 version... Maybe? I did also try to "regress" the data version: remove pak4.hwp and pak3.hwp and even pak2.hwp: but it was the same (because the pak files are incremental: each patch adds it's own pakX.hwp file that can contains new version of the same files. I assume the initial version of the game only contains pak0.hwp+pak1.hwp but even with this minimum files, it would not work).
 
If someone could get in contact with the developers...maybe we could ask why and if they still had a compatible dataset for the OpenSource release.
 
The harder way might be to use the already ported ioquake3 source and port the parts we need. Reverse engineering the existing executable is maybe possible for ptitSeb but probably not for the average dev.
 
The harder way might be to use the already ported ioquake3 source and port the parts we need. Reverse engineering the existing executable is maybe possible for ptitSeb but probably not for the average dev.

I started doing that, to see how far I can go... But it's a huge huge task. As I wrote before, the binaries (both GoG and Steam) have been stripped and have no symbol.... So trying to recognise that many functions based on the disassembly is ... heavy stuffs... And I'm not even sure if some of the exisitng ids are correct (like ID 45 was used but was not connected in the source code, but, well I thought initialy that only functions with ID starting around 100 were an issue)...
 
Back
Top