alternatives to InGame.xml

[Ryan F. Mercer]

smellymummy, I'm finding _G very interesting, thank you for mentioning it. A couple questions. First, how did you know to go looking for _G in the first place? You are the first person I've seen mention it. Two, is there a way to get to it from my own custom lua file, or just console?

 

[smellymummy]

i was reading stuff about the way lua treats namespace and it mentioned _G was a sort of global namespace

is it blocked out of mods?

 

[Ryan F. Mercer]

_G is nil from within my own lua state. Unless there is a way around that, then ShareData is still very useful. My next step is to version ShareData and Building Resources so they no longer require the InGame.xml.

 

[smellymummy]

a way around that? as in accessing main state and being able to use all the os stuff. i dont think it's something that should be looked into afterall

but am really curious if its possible

 

[Ryan F. Mercer]

You're an awesome reverse-engineer, smellymummy. If anyone not funded by organized cybercrime can do it, it's you.

 

[Ryan F. Mercer]

Interesting. I put a shareData() function in SaveUtils and attached it to LoadScreenClose. Works great. Decided to replace LoadScreenClose with SequenceGameInitComplete to see if that event is actually running at all. Crash.

 

[smellymummy]

through uigameaddin entrypoint right?

 

[Ryan F. Mercer]

Uploaded version 2:
Share Test (1 of 2) -- Demo
Share Test (2 of 2) -- Demo.

Demonstrates the use of ShareData and ensured execution order across mods, without an InGame.xml.

Uploaded version 6:
Building Resources -- Template

InGame.xml removed!

smellymummy, correct. Is that the cause of the problem?

 

[smellymummy]

yes can't use the gameinit event through entrypoints. it took me a long frustrating time of crashes to realize that one, and its why i put an alternative to gameinit example in the post.

however the loadscreen event might be more exact for dealing with the real first turn, its promising thats for sure, but i havent tried it yet

and good news that ingame.xml is going away. more plug and play mods for everyone

 

[Ryan F. Mercer]

Okay, sorry wasn't completely getting that the first time. And I agree, I think we might all be better off if we can do all game start mod initilization on LoadScreenClose.

 

[smellymummy]

yea it seems like the right place to do it, its pretty much 'the' correct user start of a game

 

[robk]

edit: after testing and working out a somewhat convoluted process, i ran across robk's awesome Info Addict that also has been using entrypoints for lua, but without any of the problems i kept running into! if only i had looked at it earlier i would of probably saved myself a lot of headache

The funny thing is that I actually wasn't sure what I was doing there. The part of my code that I'm loading is the data collector which isn't tied to any particular UI component; it just sets up a couple of end turn functions to collect and store data. So, I found the UIAddin part of Kael's guide and said to myself "hey, that sounds right for something that's, essentially, independent of the UI" and it worked the first time I tried it. For all the other stuff, I thought it was absolutely necessary to include them as part of InGame.xml, my thinking being that InGame was some sort of uber-context that all contexts had to be children of.

Anyway, I want to try divorcing InfoAddict from InGame.xml. Do you think this will work (I won't be able to try myself for several days)? I'll create a file called InfoAddictInit.lua, load it up via InGameUIAddin and do this:

function InfoAddictInit()
  ContextPtr:LoadNewContext("InfoAddictCollector");  -- the independent collector
  ContextPtr:LoadNewContext("InfoAddictScreen");     -- the main UI context for InfoAddict
end

Events.LoadScreenClose.Add( InfoAddictInit );

The only thing I'm concerned about is the fact that my initial data loading currently happens before that button pops up and it can take up to 3 seconds when there are 600+ turns of data to load. Might seem weird to hit the button that says "I'm ready" and then there's an additional pause of 3-5 seconds.

I wonder, what if I create that same .lua file but put in a companion InfoAddictInit.xml file that looks like:

<LuaContext FileName="Lua/InfoAddictScreen" ID="InfoAddictScreen" Hidden="True" />
<LuaContext FileName="Lua/InfoAddictCollector" ID="InfoAddictCollector" Hidden="True" />

Would that load the contexts before the game starts, like it does now?

 

[Onni]

Thanks Whys for having the effort of making these tools. I'm sure that we all will benefit from them sooner or later.

I used to do some lua coding in Warhammer Online and there all mods were in one big environment. And you could normally access anybodys mod with _G["modname"]. Don't know if that is better method that Civ uses, but just different. I'm guessing that Main State = _G? And they have hopefully isolated that _G on purpose from the mods, because of those very dangerous os-commands enabled there?


I was trying to figure out how to get all your lua and xml files under one single environment/thread. You can do that with lua files using include-command, but there seemed to be no way to do this with the xml 's. You could only get a single xml file (the ones with the <Context> tags) imported into a single thread. I'm going to start little later a new thread describing how to get all your files into a single thread and perhaps try to explain why or why not to do it that way.

 

[smellymummy]

I wonder, what if I create that same .lua file but put in a companion InfoAddictInit.xml file that looks like:

yes luacontext in xml will work. it loads after vanilla's InGame.xml, but it still loads prior to the game. ContextPtr:LoadNewContext would also work. i think the only thing to watch out for is using the gameinit event that will crash the game

three ways of doing stuff at the start of a game

function third ()
	print("third");
end
Events.LoadScreenClose.Add(third);

function second ()
	print("second");
end
Events.GameplaySetActivePlayer.Add(second);

print("First");

 

[Ryan F. Mercer]

Thanks Whys for having the effort of making these tools. I'm sure that we all will benefit from them sooner or later.

Sooner. SaveUtils makes use of ShareData to keep deserialization of saved data to a minimum. When ever one mod deserializes a save slot on a player, plot, or unit, that data becomes available to all mods via the shared cache, and so long as the other mods don't disable caching, they don't have to deserialize that same data again. This makes for significant improvements in performance. It also avoids the draw back Lemmy's religion mod currently suffers from. Before ShareData, serializing and deserializing between lua states, while not efficient, was the easiest way to get data between them. Not only does that prevent the sharing of class objects and functions, but requires a significant hit to performance.

Now if someone could tell me what the events are for when a player saves their game, we could all set our cache state to 2, serialize on sync(), and SaveUtils could call that automatically on save game. Then we would only have to deserialize on game start and serialize on game save. That would be ideal for performance and could make a significant difference late game, which is already slow.

I used to do some lua coding in Warhammer Online and there all mods were in one big environment. And you could normally access anybodys mod with _G["modname"]. Don't know if that is better method that Civ uses, but just different. I'm guessing that Main State = _G? And they have hopefully isolated that _G on purpose from the mods, because of those very dangerous os-commands enabled there?

I suspect the issue is data security, since there is no "private" declaration. The advantage to blocking it, except for something like ShareData, is each lua state can then decide what data it wants to share and how it wants to share it.

 

[Ryan F. Mercer]

I've been successful at creating an instanced UI element with an InGameUIAddin. It comes and goes as asked. Now to see if I can integrate it with Kael's ModList.

 

[alpaca]

You could modify the existing UI files so they trigger your mod before triggering the save. Apart from having to keep them updated, this shouldn't generate any problems.

You could also use this: Controls.SaveButton:RegisterCallback( Mouse.eLClick, OnSave );

but I'm not sure if you can make sure your listener is executed before the one that actually saves the game.

 

[Ryan F. Mercer]

I was looking at that, but I'm concerned about adding a modified base file to SaveUtils, as that could result in merging issues. Plus I am unsure I can catch an autosave.

 

[alpaca]

I was looking at that, but I'm concerned about adding a modified base file to SaveUtils, as that could result in merging issues. Plus I am unsure I can catch an autosave.

To be honest, I don't think it's realistic to expect most Lua files can be merged except manually. People will have to start integrating your mod directly into theirs but that's more user-friendly imho than having a bunch of modules to activate, different versions of mods that your mod is not tested for, etc.

You're right about the auto-save, though, I didn't think of that. It's probably not triggered by UI. You might be able check the autosave interval, find out when the game is saved, and serialise just before that.

 

[Ryan F. Mercer]

To be honest, I don't think it's realistic to expect most Lua files can be merged except manually. People will have to start integrating your mod directly into theirs but that's more user-friendly imho than having a bunch of modules to activate, different versions of mods that your mod is not tested for, etc.

You're right about the auto-save, though, I didn't think of that. It's probably not triggered by UI. You might be able check the autosave interval, find out when the game is saved, and serialise just before that.

SaveUtils is an included file, ie: include("SaveUtils"). Thus no merging is ever necessary. All mods can include SaveUtils and when the mods are run concurrently, only one file instance of SaveUtils is loaded and it manages the shared cache for all mods. This is also why I wanted to do away with the InGame.xml for ShareData. Now merging is a non-issue for SaveUtils with ShareData. The only remaining issue being that the other mods also need to be loaded as an InGameUIAddin. Currently, anything being loaded by InGame.xml will likely have to move ShareData to the top of the InGame.xml file. But this is now a legacy software issue, not a SaveUtils or ShareData issue.

I dont' know about using an interval. It wouldn't be truly syncronized with the autosave and that could be weird for people. I mean if you get an "auto saving" message, you should feel confident that everything has been saved at exactly that point.