Alterations to Start Scen State and Save Game files

[Ishad Nha]

Here I will be exploring alterations to the contents of the Start Scen state, after the designer has started to play test the scenario. These alterations would be done by hex-editing the save file or by a new program. If you test a design and add a boat to the Start_Scen_State it won't show up in an existing save game.

 

40,986: start of the 30 boat records in one save file, 40,976 in another.

location boat_loc,boat_loc_in_sec,boat_sector;

short which_town;

Boolean exists,property;

 

41,284: start of the horse records. Much the same story.

Save game file shows only the current locations.

 

 

 

[Celtic Minstrel]

Oh, you mean making the alterations in the save file without needing to restart the game, right?

[Niemand]

Quote:

If you test a design and add a boat to the Start_Scen_State it won't show up in an existing save game.

Of course, because the START_SCEN_STATE only runs at the start of the scenario. So, don't add the boat there. Add it from some other script state. As far as I know there's no problem with doing this; Jeff's comment on usage of the call is just misleading, as best I can tell.

[Celtic Minstrel]

Ah, yes, good idea.

 

Here's another idea. Pick one scenario state as the designated "debugging" state, and have it be called every move or something. Then whenever you add something to the init or start state you can duplicate it in the "debug" state, open your game, move one step, and voila! Change made.

 

Then you'd have to remove it from the debug state, of course.

 

 

 

...Or something like that, anyway.

[Niemand]

My solution to things like this is often to put the code directly in somewhere like the LOAD_SCEN_STATE or scenario START_STATE, load the scenario, maybe take one step, save, take the added code back out, and then load again. It sounds like a ot of steps, but it works very naturally when you're in the middle of editing scripts and play-testing anyway.

[Celtic Minstrel]

Ah yes, the LOAD_SCEN_STATE seems like a better place to put stuff like this. I forgot it exists. In that case you wouldn't even need to save and reload: just put the code in, save the script, load the game, take the code out and save the script again.

 

At least, assuming LOAD_SCEN_STATE works as I'd expect.

[Ishad Nha]

I had better test that it actually works in practice for boats and horses. I recall having problems there.

It does work for shops, else the High Level Party Maker would need one town for each possible party experience level.

Edit:

It seems to work as expected. We really need to have a sticky thread on documentation errors and omissions.

 

I will have to see what happens if you radically alter the number of boats and horses when the save file shows the original number.

 

[Ishad Nha]

What it does is mandate the location of all the affected boats and horses, it overrides the save file. Hence a boat will vanish if its location is overridden. It is best only used for boats and horses that need to be altered.

[Celtic Minstrel]

Originally Posted By: Ishad Nha

We really need to have a sticky thread on documentation errors and omissions.

I'd particularly like to know about any errors in the scripting documentation – ie, keywords that are not in the documentation, and incorrect keywords that are.

[Niemand]

There is a category for such things in the bugs thread; likely the overly strict description of the boat and horse calls should be noted, but other than that I don't think there are many details that are wrong or missing in the documentation. (Although there is always the location datatype. )

[Ishad Nha]

Using Load Scen state to alter boats and horses in save games:

The relevant boat or horse entry should be "commented out" in the scenario script as soon as the game is next saved. Else, when the save game is next re-loaded, the boat or horse will be restored to the location specified by Load Scen state, the state always overrides the save file.

 

This is why the documentation only mentions the Start Scen state, it is probably not over-strict.

 

 

 

[Niemand]

No, there are perfectly good ways to use the calls from any state: One should merely write code to ensure that the call is only made once. For development purposes it is perfectly reasonable to put the code in without checks, let it run, then immediately take it out. The documentation is misleading because there are many valid uses for the calls outside of the START_SCEN_STATE, which require nothing more complicated than the SDF checking and setting code that every script is familiar with from writing notes which are only to be displayed once.

[Celtic Minstrel]

Originally Posted By: Niemand

There is a category for such things in the bugs thread; likely the overly strict description of the boat and horse calls should be noted, but other than that I don't think there are many details that are wrong or missing in the documentation.

Well, checking it revealed two constants that I had not accounted for in the TextWrangler CLM. Also if someone could link to the list of constants that is linked to in that thread, it would be nice (and fix it – it's still a link for the old UBB).

[Niemand]

What constants are unaccounted for?

[Celtic Minstrel]

BASE_TRAP_XP and NUM_CHARS were not recognized by the module.

[Ishad Nha]

Once you introduce a boat or horse into Load Scen state, you can then comment it out. I would recommend commenting out rather than deletion, this way you won't forget the details. Once you are satisfied that the scenario is finished, you can remove the comment slashes from the boat/horse entries (or whatever) then transfer the entries to Start Scen state.

[Niemand]

Quote:

BASE_TRAP_XP and NUM_CHARS were not recognized by the module.

Huh, you're right, those de seem to exist but be missing from the documentation.

[Celtic Minstrel]

...It's right there in that bugs post you pointed me to!

[Niemand]

It is at that. . . I should read that more often.

[Kelandon]

For some reason that I don't at all remember, I actually use a boat placement deep into the scenario in Exodus (not at the scenario start). I think it had something to do with not wanting the boat to be in a town until a certain event occurred.

 

There are MANY things like this that are misleadingly documented (or totally undocumented). One of the tricky bits is that undocumented features are not even slightly robust; calling them on a Mac and calling them on Windows may have different effects (usually a crash, on Windows).

 

For instance, calling erase_char on all character numbers from 6 to 119, whether or not all such characters exist in a given town, works perfectly fine in Mac-BoA and erases all the monsters in a town. In Win-BoA, if the monsters don't exist, at least some of the time, it causes an Unhandled Exception.

 

Thus, any use of a call outside its normal function needs to be checked thoroughly, ideally both on Mac and on Windows (or at least on Win-BoA, which is more prone to crashing or malfunctioning) to make sure that it works.

[Celtic Minstrel]

Originally Posted By: Kelandon

I think it had something to do with not wanting the boat to be in a town until a certain event occurred.

Seems like a good reason to me.

[Ishad Nha]

I loaded all the Exodus text files in Crimson Editor and used Search > Find in Files, I found a few examples. Kelandon did it in the Init State of a town script, examples include t10, t27 and t29.

This might be useful in making boats or horses disappear from a town that has been levelled by quickfire.

Edit:

Also town 3 has this feature.