Some help needed re. (New)SaveUtils

[JFD]

This issue is regarding my Piety & Prestige mod. The simple premise is that I have a new yield, Piety, which changes at least every turn. This obviously needs some form of SaveUtils to persist the piety amount through save data. I have a method to do this which works, but there are some hoops through which I've had to jump that I don't understand (and causes a bit of a performance hit).

The main function is this:

function JFD_ChangePiety(playerID, change)
	local player = Players[playerID]
	local hasStateReligion = JFD_HasStateReligion(playerID)
	if not (hasStateReligion) then return end
	
	local currentPiety = JFD_CalculatePietyRate(playerID)
	local currentPietyLevel = JFD_GetPietyLevel(playerID)
	local maxPiety = JFD_GetMaxPietyRate(playerID)
	local newPiety = math.min(maxPiety, currentPiety + change)
	local pietyToSet = newPiety
	if newPiety < 0 then pietyToSet = 0 end
	if pietyToSet == currentPiety then return end
	
	print("piety to set, current piety: " .. pietyToSet, currentPiety)
	local JFD_Piety = "JFD_PietyOf" .. playerID
	print("person", JFD_Piety, player:GetName())
        SetPersistentProperty(JFD_Piety, pietyToSet)	

       player:GetCapitalCity():SetNumRealBuilding(buildingPietyID, pietyToSet)
end

The dummy building serves as a (hopefully) temporary check. The issue I have is that whilst it does seem to change the piety level in the persistent property, it also does not... On turn 1, I might have 1 Piety, so on turn two I should get 2 Piety. This is reflected as expected in the building count and in the print statements, as well as from calling the main function which checks one's current piety in Firetuner, yet nothing else reflects this new value - for instance the Religion Overview UI still reflects 1 Piety instead of 2, and the cost for items which require piety by a percentage value of your current piety reflects this cost as being as if one's current piety were at 1. Turning JFD_ChangePiety into a LuaEvent (and calling it as a LuaEvent) doesn't seem to help, which is confusing because of the following:

function JFD_ChangePiety(playerID, change)
	local player = Players[playerID]
	local hasStateReligion = JFD_HasStateReligion(playerID)
	if not (hasStateReligion) then return end
	
	local currentPiety = JFD_CalculatePietyRate(playerID)
	local currentPietyLevel = JFD_GetPietyLevel(playerID)
	local maxPiety = JFD_GetMaxPietyRate(playerID)
	local newPiety = mathMin(maxPiety, currentPiety + change)
	local pietyToSet = newPiety
	if newPiety < 0 then pietyToSet = 0 end
	if pietyToSet == currentPiety then return end
	
	print("piety to set, current piety: " .. pietyToSet, currentPiety)
	local JFD_Piety = "JFD_PietyOf" .. playerID
	print("person", JFD_Piety, player:GetName())
	-- SetPersistentProperty(JFD_Piety, pietyToSet)
	LuaEvents.JFD_SetPiety(playerID, JFD_Piety, pietyToSet)	
end

function JFD_SetPiety(playerID, name, value)
	SetPersistentProperty(name, value)
	Players[playerID]:GetCapitalCity():SetNumRealBuilding(buildingPietyID, value)
end
LuaEvents.JFD_SetPiety.Add(JFD_SetPiety)

This method seems to fix the issue, except for updating parts of the UI (which having the dummy building resolves). Without JFD_SetPiety as a LuaEvent (and without it being called as a LuaEvent), it won't change the persistent property, basically. Yet JFD_ChangePiety as a LuaEvent directly doesn't seem to work.

So with the above set up everything works, but this seems to execute noticeably slower (a small stutter when called, which'll be because the LuaEvent fires several times when called once, which can be fixed with a check that the new piety is different than the current piety, but I'm not sure if this is normal or not to begin with) and is something that I'd like to understand better. So if anyone can explain away the issues I'm having, or, better yet, to offer the best way to achieve my desired end, I would be utterly appreciative. Especially as this might help me understand why other functions that change persistent properties don't work without a LuaEvent, too, but consequentially have a performance hit (the other yield this mod introduces, Prestige, is possibly going to fire a bit more frequently).

 

[LeeS]

Just a thought. But would creating an lua table to save the data and using TableSaverLoader to persist the table get around some of these issues?


Plus I found from experience that there's a big time difference between running print commands and not running print commands. I overload my lua files with print statements when I'm debugging to get them to actually do what I want, but once I get it all figured out I take the print commands back out except for a couple of "it got loaded" print commands.

 

[JFD]

I'll give TableSaverLoader a shot then, thanks.

I mean, you know, if I can figure it out

Yeah, well, TSL completely eliminates any stuttering or slow-down, so I'll be determined to use that from now on.