Eh... it's still not making a whole lot of sense, but here's what I've gathered from it:
Well then, time to try and explain everything, haha.
Code:
t_AW_PlotOwnerFunctionsTable = {}
[COLOR="Red"]tPlayerPlots = t_AW_PlotOwnerFunctionsTable.tPlayerPlots[/COLOR]
include("TableSaverLoader016.lua")
tableRoot = t_AW_PlotOwnerFunctionsTable
tableName = "AW_PlotOwnerFunctions"
include("TSLSerializerV2_AW_PlotOwnerFunctions.lua")
function OnModLoaded()
[COLOR="Red"]local bNewGame = not TableLoad(gT, tableName)[/COLOR]
if bNewGame then
print("New Game")
else print("Loaded from Saved Game")
[COLOR="Red"]gLoadFromSave = 1[/COLOR]
end
[COLOR="Red"]TableSave(gT, TableName)[/COLOR]
end
I've highlighted in red the various areas that will cause problems. The basic order of the hookups looks fine, though, so I'll get that out of the way.
First up, you've defined what I assume will be your global data storage table, called
t_AW_PlotOwnerFunctionsTable which is fine.
However, in the next line, you define a new variable called
tPlayerPlots to what you hope to be a subtable underneath the aforementioned master table. The problem is... when have you defined any such subtable? You haven't defined it at all, much less being a table -- in this case its value is still
nil. You've essentially told Lua to go look for
t_AW_PlotOwnerFunctionsTable.tPlayerPlots, which doesn't exist, and to give that value (nil) to the variable
tPlayerPlots.
This is essentially the same mistake I pointed out earlier; You need to define
t_AW_PlotOwnerFunctionsTable.tPlayerPlots = {} before you can then rig a new reference to this subtable. This tells Lua to make a new, empty table with the index value of "
tPlayerPlots" inside your master table. Only at this point can you start making new references to this, because then Lua will actually find something here (an empty table, which is better than nil.)
After that, the next few lines are fine -- including TSL itself, defining the
tableRoot and
tableName properly, and then including a renamed version of the TSL Serializer client file. At this point, you've gotten TSL save operations working (assuming that invalid subtable reference didn't yet blow anything up.) I should also point out that you should be using V3 of my Serializer, and not V2 -- V2 has a bug with savegame hotkeys, and is now unsupported.
However, the next part is presumably copied from LeeS' code example that I had posted, but there are many areas where you've not altered properly.
First, you need to call
TableLoad(), which is fine because that's what it does -- the problem is
it doesn't load the table you just defined! You just told TSL to load a table called
gT even though your master table is supposed to be
t_AW_PlotOwnerFunctionsTable. However, this is precisely why I advocate using the
tableRoot variable I have everyone define, so replacing it with
TableLoad(tableRoot, tableName) will work -- if at any point your master table changes, simply change the
tableRoot definition, and everything else switches over automatically.
The next bit looks like a boolean from LeeS' code, which you likely don't need in here.
Finally, that
TableSave() operation runs into the same problem as the
TableLoad() -- it's not trying to save your master table, but something called
gT, which in your case is undefined.
After all that, you still need to actually
call OnModLoaded() somewhere in your Lua, or else this function never fires, and your tables are never loaded. The best place to put this would be after your code finishes preparing the table structure, and before the player gains control of the game.
Kind of a bunch of copy-pasting from throughout the thread and changing names. The name, incidentally, of the utility file I'm using to calculate the table is called PlotOwnerFunctions, which I plan to use, upon finishing it, to use for every civ of mine that needs to iterate over player-owned plots.
So these 20 lines should be placed at the top of PlotOwnerFunctions?
Do try and be more careful when you're copying and pasting, although at least you do admit as much, haha.
Otherwise, no, I would not recommend sticking the TSL Serializer stuff in such a "common/shared utility" component. The reason is that Pazyryk's TSL expects each instance of
TableSave() to come from a unique Lua context. I've technically tested firing off an all-context-save from one single context and Lua call, but as he's recommended against doing so in his TSL documentation, I reworked my Serializer to try and ensure that each save call comes from each mod's own Lua context.
If you're confused, think of "each Lua context" as "each mod's own sandbox." My mod's Lua cannot, and should not be interfering with your mod's Lua, normally.
Because of this, and the way the game seems to handle duplicates found within its VFS system, including my Serializer within a 'common component' like that could muck with the Lua contexts that the
TableSave() calls originate from. You should leave the TSL stuff in whatever your "main" Lua file is, and simply include your plot functions file afterward separately. If you still insist on doing so though, at least in my limited testing, it seemed to handle it okay, but I can't guarantee you won't run into obscure problems.
And then to save the table... well, just use TableSave(), it sounds like.
You shouldn't need to touch anything to do with
TableSave() once you've included my Serializer properly. Only in very specific circumstances would you need to considering adding a manual
TableSave() call somewhere, though depending on what it's for, you may be better off using my Serializer's replacement
LuaEvents.TSLTableSave() so that you can notify all other contexts/mods to save their TSL data at the same time.
Otherwise, with the Serializer installed, it will automatically handle the saving of data on autosaves, game saves through the menu, quick saves through the menu, game saves with the
Ctrl+S hotkeys, and quick saves with the
F11 hotkey.
As for TSL versus SaveUtils... I actually was going to use TSL because I didn't know SaveUtils could handle tables. So what's the advantage of using TSL? That it can handle more tables being saved, or...? I'm honestly not seeing the benefit here.
I decided to use TSL mainly because it felt a lot more flexible and powerful, allowing easy transition into more complex data storage without having to re-engineer the code if I ever switched. The other thing is that, at the time I looked it up, SaveUtils was already abandoned and technically in danger of obsolescence because of its reliance on
SetScriptData() or something to that extent.
It also had the bonuses on the coding side of not having to put
save() and
load() everywhere in the code when I needed to change something, which helps immensely with code clutter, and being able to address all of my data using standard Lua table manipulation allows me to work with it very easily as it basically sits invisibly in the code acting essentially as any other Lua table. No new syntax to learn is very welcome for me here, although at the time I didn't know much at all about how tables worked anyway.
The "abandoned" issue is also slightly less of an issue now since Pazyryk himself has not been around in a while, and I think sukritact has some sort of modified/updated version of SaveUtils somewhere.
The only upside I see to SaveUtils is that it's much simpler. Because you have to manually call the
save() and
load() each time, there's no "hookup code" beyond defining your mod name and such. I still feel the few minutes of setting up TSL pays off in the long run of having it be fully automatic in this respect, though.
As an aside, I started wondering how helpful it would be to other people if I compiled an index of mods most commonly and most helpfully given compatibility for, and how one goes about adding compatibility. A step-by-step tutorial of how to make E&D support and CulDiv and SaveUtils and so forth... or if everyone else already knows and really wouldn't help at all, or if it's mostly me that needs the index most of all. But I think it could make a handy reference. Any opinion about that?
I suppose it wouldn't be a bad idea, but each of those typically has detailed instructions in their own threads already. I feel it would be less a guide and more just an index of mod components. I have no real opinion one way or the other on that point, though. I'll leave it to others to decide here.
Oh, and this thread should be renamed to "DarkScythe tutors AW", since that's effectively what it's turned into.
That would be quite a lot of pressure there, since I don't really know everything, haha.
I'm playing a game against my Taiwanese civ right now and I can't for the life of me figure out why the leaderscene is showing up black. I checked load attributes, contents of the scene XML, made sure all the file references were typed in correctly and even made sure the DDS was the right size - but no dice.
