Decoding the Savegame

[LLCoolDave]

Well, the main problem with Mission coding right now is the fact that save games are not compatible with your edited code. Big mods are hard or even impossible to make like this, as you have to start from scratch to even just test minor changes.

 

So what we shoul do is decode the save game and figure out how and which thread data is stored, how we add our own threads and if necessary adjust the running threads accordingly *coughoffsetscough*

 

We've been doing some theory over at the #gtamodding IRC channel, but well, we're not experienced and/or skilled enough to get something like this running on our own.

[jonc]

What you want to do is akin to Apple's Fix and Continue and probably a feature Visual Studio will (already? dunno) have. It is a *very hard problem* to adjust the state of running code automatically. Without large edits to the script source code, I doubt such a thing is remotely feasible. But please do prove me wrong.

 

But if you want to try, here's an basic idea I just dreamed up.

When building the SCM the first time, create a data file mapping source code lines to bytes in the SCM.

When building a second time,

- first find what lines of the source have changed with some kind of diff algorithm;

- if the program counter of an executing thread was inside or near a changed region, tell the user it can't be fixed up;

- adjust the program counter forward or backward based on where it is in the source code and the byte locations that changed. (I.e., find the source line that was executing and use its new byte location.)

 

Of course this only works if you didn't mess with variables too much since that could cause various conditions to exist where the variable state is from the old code that the new code no longer handles correctly. And if you use anything more useful than an assembler like MB, just forget it.

[PatrickW]

If the topic wouldn't have been removed in the latest forum-cleanup , I would have given you a pointer to the VC savefile decoding topic.

In that topic we've decoded the global structure of the savefile. We've also identified the portion that saves the states of the running threads. And the format of those blocks for VC is fully documented there.

 

I've been able to restart dead-threads by adding an extra thread-block to the savefile.

 

With al this knowledge it should in theory be possible to patch old savefiles, to run with edited SCM files. There are however immense hurdles to be taken before this is reality:

* variable locations are not preserved by the current SCM-tools, thus also the complete variable map in the savefile needs to be reshuffled.

* It's not always easy to figure out in an automated way how threads between two versions match-up.

 

The savefile decoding topic should become available sometime in the near future again, in a read only archive ( so the staff has promised).

 

This message was not meant to hold you back in your endaviour, but to supply you with the progress we've been made on this issue in the past.

I surely wished that the scenario you propose will one day become reality..