alternatives to InGame.xml

[smellymummy]

alternatively there is the Modding class that has functions to deactivate and activate mods

for k,v in pairs (Modding) do print ( k , v ); end

but its a given that when using multiple mods that are going to affect the same thing some tinkering is going to be needed to combine stuff properly

on the other hand enabling multiple mods that dont affect the same things is just a matter of activating them in the mods menu instead of merging the ingame.xml context file

 

[Ryan F. Mercer]

I don't think adding a lua to force proper execute order is an ideal solution. It would probably just lead to additional merge issues as that part of the code might then be fought over by multiple mods, same as InGame.xml.

But my real point is that now that separate mods can share the same live object and function references, it becomes very easy for two mods to "affect the same thing". Specifically, the "same thing" would be the shared reference. That's why execution order becomes so important. Two mods sharing the same reference isn't a problem if their execution order can be assured.

 

[Ryan F. Mercer]

At some point, the references list will be enabled in ModBuddy at which point this may become a non-issue. But until then, ShareData has to use InGame.xml. I don't see any reliable way around it.

 

[smellymummy]

if i were to have something access a shared variable i'd perform some checks on the data first before moving on. i think that's just sound practice

 

[Ryan F. Mercer]

Not the same thing tho. For example...

Mod one changes lead to gold.
Mod two changes gold to money and happiness.

vs.

Mod two changes gold to money and happiness.
Mod one changes lead to gold.

Oops! No money or happiness.

 

[Onni]

yes, throw some context XML into a xml sub directory, make sure it has the same name

ie, test.lua and test.xml

and the game will read in the context file. it seems to work as intended: i had a <luacontext> entry and the game loaded the extra lua file, so I'm sure you can add in <instance> objects and the like

I have been also using this method, but I stumbled upon it with pure luck.

I was just checking some of the mods that modify the InGame.xml and it seemed that almost all of them doesn't need to do that at all. There are some great tutorials out there for creating mods, but what we could really need right now is one that would concentrate on these environment scope issues and proper ways including files.

 

[Onni]

Not the same thing tho. For example...

Mod one changes lead to gold.
Mod two changes gold to money and happiness.

vs.

Mod two changes gold to money and happiness.
Mod one changes lead to gold.

Oops! No money or happiness.

With global scope you also get global responsibility. It's easy for two mods to communicate using events. Let those individual mods solve the proper ordering because that's what they should do.

 

[Ryan F. Mercer]

With ShareData it's easy for *all* mods to communicate without the annoyance of dealing directly with the LuaEvent thread. But ShareData still needs to execute first so the underlying LuaEvents exist for the other mods to use on init and share their data. Nothing yet discussed here over comes the necessity to add ShareData to the InGame.xml. That's where the super-global scope functionality is coming from in the first place.

 

[Ryan F. Mercer]

By the way, Kael's guide does have an example of a simple InGameUIAddin called Simple Clock. The InGame.xml example is ModList. The sense I got from doing them is that the InGameUIAddin is an active instance, whereas an InGame context makes an instanced window possible but not automatic. When I originally tried making ModList into an InGameUIAddin, the game started with the ModList window open and could not be closed.

I'll see if what has been discussed here will make a ModList without an InGame.xml possible. Unless someone wants to beat me to it.

 

[Ryan F. Mercer]

With global scope you also get global responsibility. It's easy for two mods to communicate using events. Let those individual mods solve the proper ordering because that's what they should do.

Actually, let me put it another way, there are two mods in the in-game mod menu that are designed to run concurrently. The first one, named Share Test (1 of 2), uses an InGame.xml to ensure it runs before Share Test (2 of 2). If you can redesign 1of2 to reliably perform the same simple operations, without an InGame.xml, and without simply duplicating all operations in both mods, then I'll be convinced that execution order isn't a problem (except for ShareData).

So by all means. Prove me wrong.

 

[smellymummy]

some quick test with _G

local mymod = "modname";
for k,v in pairs(_G.Threads) do 
	for k2,v2 in pairs(_G.Threads[k]) do 
		if (k2 == "StateName" and v2 == mymod) then 
			print ( tostring(k) ); 
		end 
	end 
end

will spit out the thread of the mod. then using the table browser the thread is there along with all the variables and functions of the mod. might be worth investigating as it looks like a way to get stuff anywhere without having a wrapper

 

[Ryan F. Mercer]

I'll give it a look, but is the data stable or volatile? Meaning, have you tried saving that data to a local global and then manipulate it? I'm wondering if it suffers from the same issue of volatility we both encountered in our LuaEvent tests.

 

[smellymummy]

just some quick one liner tests in the console, im trying to find something else atm

but i can read and change a variable via _G and the change is reflected in mymod, and vice versa

 

[Onni]

Actually, let me put it another way, there are two mods in the in-game mod menu that are designed to run concurrently. The first one, named Share Test (1 of 2), uses an InGame.xml to ensure it runs before Share Test (2 of 2). If you can redesign 1of2 to reliably perform the same simple operations, without an InGame.xml, and without simply duplicating all operations in both mods, then I'll be convinced that execution order isn't a problem (except for ShareData).

So by all means. Prove me wrong.

The LuaEvents are good for notifying the other mod WHEN something needs to be done. This can't be done effectively with just a global table. Here's two scenarios where two mods wish to share tables between them at the startup.

This is how I figured you were trying to make it work right now (all sharing done using ShareData).

InGame.xml started
ShareData started

Mod A started
Mod A shares table A
Mod A wants to get table B --> failure

Mod B started
Mod B shares table B
Mod B wants to get table A --> Success

With this straightforward approach only the latter Mod can interact with the shared data in the initial phase.


Heres my suggestion how to do this. No need for InGame.xml reference because mods can be loaded in any order (all sharing done using ShareData).

Mod A started
Mod A Event.LoadScreenClose.Add(ShareTableA)
Mod A LuaEvent.TableReadyB.Add(GetTableB)
Mod B started
Mod B Event.LoadScreenClose.Add(ShareTableB)
Mod B LuaEvent.TableReadyA.Add(GetTableA)
ShareData started

Event.LoadScreenClose started
Mod A ShareTableA() -> shares table A
Mod A LuaEvent.TableReadyA()
Mod B GetTableA() -> wants to get table A --> Success

Event.LoadScreenClose started
Mod B ShareTableB() -> shares table B
Mod B LuaEvent.TableReadyB()
Mod A GetTableB() -> wants to get table B --> Success

That LoadScreenClose event launches immediately after the user has pressed that "Begin your journey" button. Of course all Mod B's actions could be started after TableReadyA-event to make it kind of "dependant" of Mod A.

 

[Onni]

just some quick one liner tests in the console, im trying to find something else atm

but i can read and change a variable via _G and the change is reflected in mymod, and vice versa

How did you get access to that _G? I have tried to get a hold of it using the Tuner with different states, but without any success.

 

[smellymummy]

LoadScreenClose, very nice, thanks for pointing that out

 

[smellymummy]

How did you get access to that _G? I have tried to get a hold of it using the Tuner with different states, but without any success.

in Main State

 

[Onni]

Holy cow! Thanks! That is a dangerous state btw. Even os.execute() works there.

 

[smellymummy]

i see what you mean. so its outside of custom lua access unfortunately

too bad, i was hoping to find some table with cached sql or diplo data, but i guess not. time to move on

still, if you can get to it in the tuner, its accessible, so whos to say there's no way whatsoever that we can't get a hold of it ourselves from loaded lua

 

[Ryan F. Mercer]

The advantage to being the dumbest one in the room is, I get to learn something.

Onni, thank you much for taking the time to explain that. It took me more than a moments study, but it finally clicked for me when I remember, duh... more than one function from more than one mod can all be notified by the same LuaEvent. Wow, I really have been away from Windows Programming for too long. I've actually worked with action event threads before, but they don't come up much in PHP and JavaScript's use of it is often held back by IE. I've definitely gotten rusty in this area.

Good thing I'm not wasting my time away playing computer games. :irony:

So if I simply move my share() statements out of the global scope, then it doesn't matter when ShareData loads either, right?