Custom CheckpointRecords

[tracktwo]

Got it working! Custom classes for both Checkpoint and Checkpoint_StrategyGame were required, as was adding the config bit on the variable (it needs to be in two places, since it's an array var... ue explorer should show it as:

const config array< config class<Actor> > ActorClassesToRecord

You also need to explicitly list all the original default property entries, as they get completely ignored when you add any in the .ini file.

 

Currently it supports the strategy layer only, and it also doesn't allow configuration of the ActorClassesToDestroy variables, but I haven't needed those. I've uploaded this as a new mod:

 

http://www.nexusmods.com/xcom/mods/621/?

 

EDIT: I've also updated the save game format page on the wiki.

Edited August 14, 2015 by tracktwo

[wghost81]

Great! BTW, when using tactical saves I noticed that multiple copies of saved objects sometimes persist when you load a save. So we might need ActorClassesToDestroy after all.

[dubiousintent]

Very nice. Added to the "Modding Tools" wiki article under "Custom XCOM Mod Tools".

 

Thanks for updating the "save game format" page as well. I note the "CreateCheckpointRecord" and "ApplyCheckpointRecord" process entries on that page indicate "needs more investigation". Did you explore those processes as well?

 

-Dubious-

[tracktwo]

I don't know exactly how they work, but if I had to guess it'd be that CreateCheckpointRecord is called just before the game saves your object, and ApplyCheckpointRecord called just after it restores it. They look like they'd be used as hooks to be able to take class-specific actions at these times, e.g. using ApplyCheckpointRecord to set some state in your class that's derived from the checkpoint variables. But, I can't really say that's what they do with any kind of authority cause I haven't experimented much with them.

[dubiousintent]

I don't know exactly how they work, but if I had to guess it'd be that CreateCheckpointRecord is called just before the game saves your object, and ApplyCheckpointRecord called just after it restores it. They look like they'd be used as hooks to be able to take class-specific actions at these times, e.g. using ApplyCheckpointRecord to set some state in your class that's derived from the checkpoint variables. But, I can't really say that's what they do with any kind of authority cause I haven't experimented much with them.

Thanks. That's a little clearer, but obviously the "needs more investigation" caveat still applies.

 

-Dubious-