God-Emperor
Deity
If you want to preserve values across a save/load cycle you need to store them in the savegame file, and the easiest way to do that is to put them in some object's scriptdata value since those get saved. The scriptdata is just a text string, so you can write whatever you want to it. (As per j_mie6's suggestion.)
If you have multiple different things to save you can save each to a different object. Every plot has a scriptdata field, as does every player, every unit, every city, and one for the game object (there may be more things that have it too, I didn't check). Alternatively you can write each of them into a dictionary and use "pickle" to save the dictionary on just one object - this has the advantage of not having data overwrite other data if you are not careful. For limited usage, typically plot related things are saved to the matching plot, unit related things to the unit, city related things to a city, and "other stuff" to the game object. If the stuff to save is a class, list, dictionary or such non-simple thing then you use the "pickle.dumps(x)" function to serialize it - a fancy term for converting it to a text string that is in a known format which it can later convert back to the original data via the "pickle.loads(y)" function. If you have multiple values to save then you can put them into a list and pickle the list and put it into a scriptdata to save it, then to load it you unpickle the scriptdata and extract the items from the resulting list. You can look at the original Final Frontier for examples of using this sort of thing directly or Final Frontier Plus for an example of using BugData.
You'd do this in the onPreSave game event handler. Then you'd retrieve the data in the onLoadGame game event handler.
There are mod components that add methods of doing this relatively transparently, so you do not have to put in the code to do the load and save yourself for everything. SdToolKit has stuff for this (the "sd" might stand for "store data") and I think it lets you store the data on any object. The BUG mod also has stuff for this in BugData.py which only uses the game object to store a dictionary of data, and this is already present if you are using BUG (otherwise adding just this may require some other chunks of BUG and figuring out how to make it work - what to call where).
In the long run, using the method of storing everything in a dictionary on the game object is better since it deals with the "multiple things that would otherwise use the same scriptdata" issue. The key into the dictionary is something relevant to the data being stored (like a mod component name, for example) and the data for that key is likely to be a single value, list of values, or another dictionary. This would be good, for example, for storing data for multiple different mod components, like wonders and special units (although in the units case you can probably store data about the unit on the unit itself without much of an issue, unless you then want to add a mod component that also stores data on units).
If you have multiple different things to save you can save each to a different object. Every plot has a scriptdata field, as does every player, every unit, every city, and one for the game object (there may be more things that have it too, I didn't check). Alternatively you can write each of them into a dictionary and use "pickle" to save the dictionary on just one object - this has the advantage of not having data overwrite other data if you are not careful. For limited usage, typically plot related things are saved to the matching plot, unit related things to the unit, city related things to a city, and "other stuff" to the game object. If the stuff to save is a class, list, dictionary or such non-simple thing then you use the "pickle.dumps(x)" function to serialize it - a fancy term for converting it to a text string that is in a known format which it can later convert back to the original data via the "pickle.loads(y)" function. If you have multiple values to save then you can put them into a list and pickle the list and put it into a scriptdata to save it, then to load it you unpickle the scriptdata and extract the items from the resulting list. You can look at the original Final Frontier for examples of using this sort of thing directly or Final Frontier Plus for an example of using BugData.
You'd do this in the onPreSave game event handler. Then you'd retrieve the data in the onLoadGame game event handler.
There are mod components that add methods of doing this relatively transparently, so you do not have to put in the code to do the load and save yourself for everything. SdToolKit has stuff for this (the "sd" might stand for "store data") and I think it lets you store the data on any object. The BUG mod also has stuff for this in BugData.py which only uses the game object to store a dictionary of data, and this is already present if you are using BUG (otherwise adding just this may require some other chunks of BUG and figuring out how to make it work - what to call where).
In the long run, using the method of storing everything in a dictionary on the game object is better since it deals with the "multiple things that would otherwise use the same scriptdata" issue. The key into the dictionary is something relevant to the data being stored (like a mod component name, for example) and the data for that key is likely to be a single value, list of values, or another dictionary. This would be good, for example, for storing data for multiple different mod components, like wonders and special units (although in the units case you can probably store data about the unit on the unit itself without much of an issue, unless you then want to add a mod component that also stores data on units).