Determine source of initial game state

[dertseha]

The game state chunk 0x0FA1 in archive.dat is (almost) entirely 0x00. Try to figure out if all of the initial data for a started game is generated from the game code. It would be weird to have the initial location of the hacker be hardcoded.

Hunches that I have so far:

• Is the remainder info after the archive name ("Starting Game") in 0x0FA0 truly just garbage? May this be the initial seed?
• Is there perhaps a trigger (or spawn) object in the level that the engine looks for?

[dertseha]

I had a quick look:

• archive.dat 0x0FA0 does not have any bytes that resemble the initial tile coordinates
• the initial tile does not contain any hidden objects

The easiest way to determine whether 0x0FA0 plays a role is to erase the extra information with 0x00.

On a side-note, comparing archive.dat and a savegame from right at the start revealed that the save game archives contain 4 more chunks that haven't been considered so far: 0x0000, 0x024E, 0x024F and 0x0F9F !

[dertseha]

Clearing all the extra info in archive.dat 0x0FA0 did not have any (immediately visible) effect. A new game could be started and the hacker was at the usual position.

[dertseha]

Thanks to inkyblackness/construct , at least the first level and hacker position is hardcoded. The first level is 1 and hacker is always put on tile 30:22.

Even the current health seems to be hardcoded, though, the energy level is not. The absolute minimal archive.dat required, created by inkyblackness/construct, starts a new game with full power. The regular archive.dat leaves the hacker with about a third of power.

[dertseha]

As for the power level: This mystery is solved, there is a "level entry trigger" (object index 695, located at tile 31:23) which removes some power.

[dertseha]

The source code proves it: gamewrap.c, create_initial_game_func() has a dedicated comment stating that there's no point in taking in the struct from archive.dat. So, the original engine ignored this resource, and everything else is hardcoded in player.c, init_player().

However, the source port was extended to allow this, and this behaviour has now been documented.

Keeping this issue open, as I haven't come round to detail the MFD fields, which are also set.