I assume your real question is how to add a button in DiploCorner pulldown (where Demographics etc. are) that will make your UI visible.
Instead using "LookUpControl" you can use LuaEvents:
LuaEvents.JiskaCallToShowUI()
and then in your file add:
LuaEvents.JiskaCallToShowUI.Add(function()
Controls.MainFrame:SetHide(false);
end)
What is more, you don't even have to mess up with DiploCorner for this:
LuaEvents.AdditionalInformationDropdownGatherEntries.Add(function(tab)
if bHuman then
table.insert(tab, {text = "Prophecies", call = function() LuaEvents.LSThebesPropheciesCall(); end});
end
end)
Firaxis is actually calling for any extra entries (gate for modders). The example above adds button named "Prophecies" that will call LuaEvents on click (under bHuman condition).
Back to ContextPtr:LookUpControl. For me it is a tool to mess up with InGame Interface without the need of replacing the files. Basically, if LuaEvents.AdditionalInformationDropdownGatherEntries would not exist I would create a button (based on instance from DiploCorner) in my OWN xml file then use lua ContextPtr:LookUpControl and ChangeParent to put it in the pulldown.
If you have full control over both files (DiploCorner) and (YourNewFile) I don't think ContextPtr:LookUpControl is needed at all.
Going further, to use LookUpControl efficiently we need to know the name of file (or more precisely full path). By using Firaxis Live Tuner (in game) we can select in Lua Console any Interface and then with command:
ContextPtr:GetID() -- get ID of the file.
For CityView.xml the ID is CityView and path is "/InGame/CityView". However some UI has ID different than name and guessing would be hard. For example DiploCurrentDeals has ID "DealsPanel". However, it is still not enough to use ContextPtr:LookUpControl from other file, because this file is actually only included by other file and we have to use:
ContextPtr:LookUpControl("/InGame/DiploOverview/DealsPanel") to get to DiploCurrentDeals (because this file exists only as an include to DiploOverview.xml). This ID can be also found in DiploOverview.xml.
Looking into steam folder we can get a proper "/InGame/","/InGame/WorldView" prefix. But we can also use Firaxis Live Tuner (example: DiploCurrentDeals):
> ContextPtr:GetID()
DealsPanel
> ContextPtr:LookUpControl(".."):GetID()
DiploOverview
> ContextPtr:LookUpControl("../.."):GetID()
InGame
> ContextPtr:LookUpControl("../../.."):GetID()
InGame
So we know that "/InGame/DiploOverview/DealsPanel" is proper full path to reference.
Modiki.
Finally, how we access new modded files? By using ContextPtr:GetID() I got nil (because I haven't defined ID of the Context). After defining context ID/FileName/Name and using all above methods I wasn't able to reference file from WorldView, the entire path ("..", "../..") was always returning the same value as GetID().
Anyway, I abandoned LookUpControl at this point. Workaround is simple, I added to my UI file lua code:
LuaEvents.CallAttemptTROControl.Add(function(name) MapModData.TROReturningControl = Controls[name] end)
From WorldView I called:
LuaEvents.CallAttemptTROControl("Title") -- (Title is ID of control i was looking for)
From WorldView I used command:
MapModData.TROReturningControl:SetHide(true) -- I wanted to hide the control and it worked.
CallAttemptTROControl and TROReturningControl are variables of your choice. If you want to use multiple Controls a lot, you can come up with something like that:
LuaEvents.CallAttemptTROControl.Add(function(name) MapModData["TROReturningControl" .. name] = Controls[name] end)
And then referencing MapModData.TROReturningControlTitle / MapModData.TROReturningControlMainFrame.
Shortly, ContextPtr:LookUpControl is great for accessing InGame UI files and LuaContext as described
here. For modding purpose you can use LuaEvents and MapModData. Well, to be honest the usage for above solution with MapModData is truely required only for Mod Mods (basically you leave a gate to access Controls in future without the need of updating the mod)?
I tried moving my files into a subfolder "UI/InGame/" but still no. I feel like this is a VFS problem even though I really don't know anything at all about the VFS, and you were very specific here:
