PROJECT: Playtest

[Martin Gühmann]

Well we could increase the save file version again, and if the save game version doesn't match the save file version of that release a /reloadslic should be forced instead of loading the slic from the savegame, unfortunatly this means that we have to increase the save file version everytime we add such an member. And actual I don't like this part of the idea.

-Martin

[Solver]

A good summary, Martin .

[Fromafar]

Originally posted by Martin Gühmann
Well we could increase the save file version again, and if the save game version doesn't match the save file version of that release a /reloadslic should be forced instead of loading the slic from the savegame, unfortunatly this means that we have to increase the save file version everytime we add such an member.

Let's address the 2 separate problems separately:

If you want to store and reload the values of the members, changing the save file version is the only proper solution. But I don't think this is necessary for the current members. These seem to behave more like accessor functions than variables, so you don't need to store the values at all.
So, this could be solved by introducing some new functions: e.g. something like AddButDontSaveMember to register such a new member, and GetNumberOfMembersNotCountingDontSaveMembers in the file load/save handling to have only the original members in the file, but still have the new members accessible to the Slic coders.

The other problem is more difficult. You really don't want to do a /reloadslic, because this will reset the values of all Slic variables in the game.

[Tamerlin]

Originally posted by Fromafar
If you want to store and reload the values of the members, changing the save file version is the only proper solution. But I don't think this is necessary for the current members. These seem to behave more like accessor functions than variables, so you don't need to store the values at all.
So, this could be solved by introducing some new functions: e.g. something like AddButDontSaveMember to register such a new member, and GetNumberOfMembersNotCountingDontSaveMembers in the file load/save handling to have only the original members in the file, but still have the new members accessible to the Slic coders.

Could someone be kind enough to explain what Martin and you are talking about? I need some explanations for the non-educated.

Sorry to bother you with this kind of questions but I would like to understand.

[J Bytheway]

Originally posted by Tamerlin
Could someone be kind enough to explain what Martin and you are talking about? I need some explanations for the non-educated.

Sorry to bother you with this kind of questions but I would like to understand.

Martin added new things to SLIC, for example a g.numplayers variable (or something like that) to allow for SLIC to get the number of players in the game. This is being saved with the save game, but old save games don't have it so CTP2 gets confused when it loads them.

I think fromafar is suggesting that this really shouldn't be saved with the save game (after all, it can be determined on the fly easily enough), and that would solve the problem.

[Flinx]

Suggestion

The changes which are causing the problems are good for future use.
Could we remove them for now from the regular playtest versions.
We should continue to collect these types of changes and at some future point we can increment the savegame version and include them all.

[Tamerlin]

Originally posted by J Bytheway

Martin added new things to SLIC, for example a g.numplayers variable (or something like that) to allow for SLIC to get the number of players in the game. This is being saved with the save game, but old save games don't have it so CTP2 gets confused when it loads them.

I think fromafar is suggesting that this really shouldn't be saved with the save game (after all, it can be determined on the fly easily enough), and that would solve the problem.

Thank you very much J Bytheway, it is much more clear now.

[Martin Gühmann]

Originally posted by Fromafar
The other problem is more difficult. You really don't want to do a /reloadslic, because this will reset the values of all Slic variables in the game.

If you mean doing it everytime when a game is loaded then you are right, but we have also other problems, whenever we add strings then the string database is invalid and the meassages contain something like "Gdansk" instead of an informative piece of text, in that case strings at least must be reloaded. That could also be addressed by a /slicreload. The other problem is with the database access itsself even if we can generate a save game format that leaves the database access intact after reloading, we have to /reloadslic if a savegame is loaded generated by Activision's original patch, because we have no idea how the designed the database access originally, so I am sure whatever we do in the end it is not the way they did, so that we end with invalid data from such a savegame.

-Martin

[Fromafar]

There are lots of problems indeed. So maybe we should try not to do too much at once. I think we should aim for the following goals:

• Saving and reloading a game with the same version should work without doing any /reloadslic or similar tricks. Right now, this doesn't work, because of the design error in the Slic parser.
• Likewise, starting a new game from a scenario (may involve loading some old Activision .ctg save file) should work without user intervention. Right now, this doesn't work because of the added variables.

Loading a game in progress that has been saved with an older version is more of an option. If we can support this without user interaction, fine. Maybe we could even perform an automatic string table reset when loading a game, because that Gdansk/Noyon thing is very annoying indeed, and there should not be an effect on the game state. IIRC someone mentioned a /resetstrings option, it could be interesting to have a look into that one.

[Martin Gühmann]

Originally posted by Fromafar
Saving and reloading a game with the same version should work without doing any /reloadslic or similar tricks. Right now, this doesn't work, because of the design error in the Slic parser.

It does work as long as you don't use any run time database access code. However I was able to find a solution.

Originally posted by Fromafar
Likewise, starting a new game from a scenario (may involve loading some old Activision .ctg save file) should work without user intervention. Right now, this doesn't work because of the added variables.

So all scenarios are affected and why can I load the world map successfully?

Originally posted by Fromafar
Loading a game in progress that has been saved with an older version is more of an option. If we can support this without user interaction, fine. Maybe we could even perform an automatic string table reset when loading a game, because that Gdansk/Noyon thing is very annoying indeed, and there should not be an effect on the game state. IIRC someone mentioned a /resetstrings option, it could be interesting to have a look into that one.

Actual it is a must, because noone want to lose his savegames, and those savegames provide us with valuable information about bugs. So tell me how do you want to reload the database support from an patch 1.1 file without reloading slic, the only way to do this is to know how Activision designed the database support, how many SOP_*s did they use, in which order, how they made they sure that at run time even after a reload the necessary information like the database and the member is available.

-Martin

[J Bytheway]

Update 2004-04-30

Since Martin has just fixed one of the above problems with loading, I thought it was time for a new Playtest version.

New version available:

Edit: Removed link. The latest version of the Apolyton Edition can be found here.

Changes:
Added: New SLIC global variables
Fixed: Bug with scenario editor and players who have been removed
Added: New SLIC functions
Changed: Some French and German strings
Improved: Govener AI choice of squares on which to place tile imps
Changed: Error reporting for modulo 0 errors
Fixed: Active defense movement type check
Fixed: Neutral tile imp pillage bug
Fixed: Problem with loading games using SLIC database access

[Flinx]

2004.04.18.CTP2Playtest.rar

[J Bytheway]

Originally posted by Flinx
2004.04.18.CTP2Playtest.rar

Whoops - I copied my last post and updated what the link pointed to, but not what it said . Fixed .

[Tamerlin]

Thank you J Bytheway...

I have done a few tests and I can't load saves from the previous Playtest Build (be them quicksaves or normal saves), I have a CTD at the end of the loading process.

Saves from the current build are loaded adequately though.

[EDIT]Sorry, I have just read Martin's post in the Altered Source files thread. The new feature about saves from previous versions will only apply to the future Playtest Builds.[/EDIT]

[Flinx]

Originally posted by Fromafar
Crashes when loading a file

At the moment, we have 4 different file formats for save files, dependent on the release. Only the first 2 types are correct.

• Playtest releases 2004.02.21 and before generate files that are in the same format as the original (unpatched) Activision release.
  These releases can read files that have been generated with the unpatched Activision release, but can not read files that have been generated with the Activision 1.1 patch.
  Files generated with this release can be loaded with the Activision executables (both patched and unpatched), and with the 2004.03.31 and 2004.04.03 releases.
• Playtest releases 2004.03.31 and 2004.04.03 generate save files that are compatible with the Activision 1.1 patch format.
  This release is able to load both 1.1 patch format files and original unpatched format files.
  Generated files can be loaded with the Activision 1.1 executable, but not with the unpatched executable, nor with playtest releases 2004.02.21 and before.
• Playtest release 2004.04.12 generates incorrect save files - because of the added player.government variable.
  Loading any other than 2004.04.12 format files may cause a crash, and loading files generated with this release may cause a crash when loading with any other release.
• Playtest release 2004.04.18 generates another type of incorrect save files - because of 3 more added variables.
  Loading correct or 2004.04.12 save files may cause a crash, and loading files generated with this release may cause a crash when loading with any other release.

Releases that crash on loading correct save files will also crash when starting a scenario.

For people with the source code: comment out the 4 new AddMember statements in SlicBuiltIn.cpp to reenable loading any correct file format and generation of Activision 1.1 patch format files.

Crashes after loading a file

These occur mostly when pressing the end of turn button, but may also be triggered by other Slic events during the movement phase.

All playtest releases since January 2004 contain a design error that may surface when executing database related Slic functions (such as GrantAdvance) after loading a file.
Using /reloadslic immediately after loading the file will prevent the crash.

Did Martin's fix address any of these situations? The April 3rd playtest seems to still have the most portable savegames, and the ability of future playtest versions to load current savegame files is still up in the air. Or am I wrong?