SaveUtils.lua -- Itemized Data Storage Across Mods

[Ryan F. Mercer]

1.) You need to have the "include" line near the top of every file-scope that wants to use the SaveUtils functionality. Without looking at your code, I assume you are correct that it would be included in both your main mod and the modified UnitPanel.

2.) There are two considerations regarding load order.

2a.) As long as SaveUtils is included near the top of each file-scope that uses it, then load order isn't necessarily a problem. SaveUtils itself isn't loaded, but rather embeds global functions into the file-scope, such as save() and load().

2b.) The shared cache is a load order issue and is explained somewhat in the documentation here:

Automatically shares cache and cache-state upon Events.LoadScreenClose().
Call share_SaveUtils() explicitly to share cache and cache-state immediately.
Explicit call necessary when shared data operations performed from global
scope or any point prior to Events.LoadScreenClose().  Avoid explicit call
whenever possible for greater interoperability of concurrent mods.

For maximum performance and to avoid potential desyncronization of data, if you are calling save() or load() prior to Events.LoadScreenClose(), such as within the global-scope of a modded built-in lua file, then you want to call share_SaveUtils() first (after the "include" line). However, doing so will require that ShareData.lua be loaded near the top of InGame.xml.

Perhaps a simpler alternative is to just disable the cache with setCacheState( 0 ), but this results in slower performance.

 

[Pazyryk]

OK, I'll give it a try with and without modifying InGame.xml and see what happens.

I'd like to point out that my situation is generic and not specific. There will be many mods that need to display saved/shared object data, and that (more often than not) means using the load() function from within overwritten UI lua files. Not complaining, of course. Just something you might want to point out in that 20 page document that you are writing for these utilities.

 

[Ryan F. Mercer]

For greatest simplicity while still retaining the majority of performance improvement, I recommend the following.

Include SaveUtils near the top of each file-scope that uses it, do not call share_SaveUtils() explicitly, and do not load ShareData.lua in the InGame.xml. Then for each call to save() and load() that occurs prior to Events.LoadScreenClose(), such as the global-scope of a modded built-in lua file, only disable the cache for those particular calls in the following manner.

load( pTarget, "key", nil, 0 );
save( pTarget, "key", data, nil, 0 );

This way any calls to load() and save() that occur after Events.LoadScreenClose() will still benefit from the shared cache. Given the complexity of the issue, this seems the best compromise.

 

[Ryan F. Mercer]

OK, I'll give it a try with and without modifying InGame.xml and see what happens.

I'd like to point out that my situation is generic and not specific. There will be many mods that need to display saved/shared object data, and that (more often than not) means using the load() function from within overwritten UI lua files. Not complaining, of course. Just something you might want to point out in that 20 page document that you are writing for these utilities.

Ideally, the built-in lua files should be rewritten to perform independent of file load order. Unfortunately, that is not terribly realistic and I fully understand your concern regarding frequency of this distraction. Thus my recommendation above.

Hopefully will document some of this in an easier to read format soon.

 

[Ryan F. Mercer]

Oh and do keep in mind, when I say it results in slower performance, I don't just mean you can run your mod with it and without it and see how fast it runs, rather it is a cumulative issue that grows according to the number of concurrent mods being run at the same time. Basically, the more mods that disable the shared cache, the slower performance will be the more of those mods are run at the same time. By enabling the shared cache, each mod can basically help each other out and thus they execute faster. This gets to be more important late game when there is a lot of units and data flying around.

 

[Pazyryk]

Well, although my load() function is in UnitPanel.lua, it's easy for me to put it behind an "if" statement (protect it so to speak) so that it is only ever called during game play. If I do this, then I don't need to "disable the cache," correct?

 

[Ryan F. Mercer]

Yeah that should work. I assumed it couldn't wait, but if a conditional can be used, then go for it.

 

[alpaca]

Whys, I tested adding your own content add-in points and it works fine

So it's possible to add ShareData as an InGameUIAddin, create a new content type called ShareDataAddin and load those contexts in ShareData when it's ready to receive share commands. This would get rid of having to share data on LoadScreenClose rather than simply writing it into the base script and you could actually induce an ordering in ShareData if you want to. I basically just copied the code from InGame.lua to create my own content point for custom missions (unit actions)

 

[Ryan F. Mercer]

Thanks alpaca. I haven't had any time for modding lately, but when I do, I'll certainly take this into account.

 

[Slowpoke]

I'm having a bit of trouble getting this to work. Admittedly, I'm a newbie to lua, so this may very well be an obvious mistake. Anyways I'm trying the following:

function AllocateFood()
pPlayer = Players[Game.GetActivePlayer()]
for pCity in pPlayer:Cities() do
amt = load(pPlayer, "FoodRoutes") or 2;
pCity:ChangeFood(amt);
end
end

Events.ActivePlayerTurnStart.Add(AllocateFood)

And tuner gives me an error complaining nil is an invalid argument. Does this just happen if load fails to find anything (There's currently nothing saved atm), or am I doing something wrong?

 

[Ryan F. Mercer]

If nothing has been saved, then load(pTarget, "key") returns nil, so your code appears correct. Are you including SaveUtils in the following manner?

include( "SaveUtils" ); MY_MOD_NAME = "???";

 

[Seraphim8400]

i have a problem
the SaveUtils.lua i put it as modname\Common files\SaveUtils.lua
and a file A in another folder at modname\
then A including SaveUtils

WARN_NOT_SHARED = false; include( "SaveUtils" ); MY_MOD_NAME = "...";

It is running well before
but it is a bit of trouble after last update
the log writed:

Runtime Error: [string "My Games\Sid Me..."]:126: attempt to call global 'save' (a nil value)

Runtime Error: [string "My Games\Sid Me..."]:69: attempt to call global 'load' (a nil value)

how to fix it?

 

[Seraphim8400]

oh it is three row

Runtime Error: [string "C:\Users\Seraphim\Documents\My Games\Sid Me..."]:498: attempt to call method 'GetScriptData' (a nil value)

i never use this word
i think this row is form SaveUtils?

 

[MouseyPounds]

oh it is three row

Runtime Error: [string "C:\Users\Seraphim\Documents\My Games\Sid Me..."]:498: attempt to call method 'GetScriptData' (a nil value)

i never use this word
i think this row is form SaveUtils?

This error is because the patch removed the GetScriptData and SetScriptData functions from the game, essentially crippling SaveUtils.

 

[Slowpoke]

Ugh, why would they just remove functions? Can saveutils be fixed?

 

[Seraphim8400]

This error is because the patch removed the GetScriptData and SetScriptData functions from the game, essentially crippling SaveUtils.

then they do not give any Substitute?

 

[MouseyPounds]

If they did supply a substitute for the ScriptData functions, it's not obvious and we haven't found it yet.

 

[Seraphim8400]

So they simply do not want us to save additional data to the game next load?

 

[alpaca]

Well we could substitute it by using the functions from the tutorial to store mod-specific values. These aren't game-specific, though, and would therefore disable sharing of savegames. I hope Firaxis will tell us what's what before the christmas vacation

 

[Ryan F. Mercer]

Indeed. They just spring this on us with no warning, no indication, and no explanation. They just broke something fundamental and have offered nothing in return.

*sigh*...