Replacing Frontend UI Scripts

[zzragnar0kzz]

Using AdvancedSetup as an example, the go-to method to make modifications to this script would be to copy the base game's version into your mod, make the necessary changes, and add it via an <ImportFiles> tag in your .modinfo's <FrontEndActions> section. This obviously works, but since only the last imported version of a given file exists, your changes will be overwritten if another mod imports this file after yours, or the other mod's changes will be overwritten if your mod imports this file after it. You could instead start with the other mod's file as a base and make your changes to it, but besides being rather gauche, if you wish to incorporate changes from several mods the final script would quickly bloat to account for everything. You could isolate the changes into one or more separate files and use include directives with or without pattern matching, but that still requires altering and reimporting the base file or another version thereof to include the include directives. The <ReplaceUIScript> tag that can be used to alter Ingame UI elements does not work in the Frontend. So, what do?

Major Frontend Lua contexts appear to be defined in the MainMenu.xml template. By replacing the FileName portion of a given context within this file, we can simulate the behavior of ReplaceUIScript in the Frontend; basically, the new script file contains a line to include the existing file, stores any content to be replaced with new names if necessary, and makes any required modifications. The new file can also contain additional include directives with or without pattern matching to include modifications from other sources, which allows multiple mods to make changes to a given Frontend script without any of them needing to directly alter the original file; as long as they are all modifying different things, all the changes will coexist.

I have edited my own EGHV mod to utilize this method, and have tested with it as the only active mod making changes to AdvancedSetup, where it utilizes the base game's version of that file, as well as alongside YnAMP, where it utilizes that mod's version of that file, and as far as I can tell it is working as expected in both cases. Can anyone with more knowledge and experience chime in as to whether this is a good idea, or if it may cause unforeseen gameplay problems? Much obliged!

 

[Infixo]

What would be the purpose of all this? What are you trying to achieve?

 

[zzragnar0kzz]

@Infixo In general, if Mod A, Mod B, and Mod C all alter the same Frontend script, I want them all to function properly when all of them are enabled, or when only one or two of them are. In particular, I want my mods (EGHV and ENWS) to work whether or not YnAMP is enabled, but because all of them modify AdvancedSetup.lua to varying degrees, this has proven challenging.

 

[Infixo]

How do you know that ReplaceUIScript doesnt work? Have you tried it?

 

[Zegangani]

The main problem with changes to UI files, either in FrontEnd or InGame, is that they aren't just lua scripts but also contain an xml file that defines the visual/graphic elements. So, although it's possible to rewrite certain functions in a lua file for example without replacing the whole file and keep maintaining compatibility (like Infixo has done in many of his Mods), however if there are any changes that require edits to the xml file, you won't come around replacing the whole thing (.lua and .xml). Which is why UI compatibility is always annoying, and why very few people care enough to ensure some compatibility with other UI mods that affect the same files.

In case of AdvancedSetup.lua there are somethings that require edits to the .xml file (such as adding a new popup panel), and it's also a complicated script overall ngl. I have worked on it a lot, yet I always get lost every time I open it once in a while. I'm working on a mod that adds some more customization Options to that Panel as well as QoL Features to how you set-up your Games, and I found it very difficult to ensure compatibility with the 2 Biggest mods in the Workshop that make changes to it: Gedemon's YnAMP Mod and Sukritact's Civ Selection Screen Mod. And they are the only ones I'm attempting to make it compatible with, and only bc they don't get (regular) updates (anymore). It's too much work + UI modding can be trickier than just gamepaly modding, as a single Bug can literally make your Game unplayable if something is wrong with the UI, where in a gameplay mod it would mostly mean that something doesn't work, or not as intended. More or less.

btw, what are EGHV and ENWS? The Abbreviation doesn't ring a bell in my mind tbh.

 

[zzragnar0kzz]

@Infixo I have tried putting the new file in a ReplaceUIScript action in the FrontEnd, and it is also in an ImportFiles action there, as well as in the main Files list. It appears to do nothing at all; no errors are generated in the Modding log, and the last imported AdvancedSetup script loads and runs.

 

[zzragnar0kzz]

@Zegangani EGHV is Enhanced Goodies and Hostile Villagers, and ENWS is Enhanced Natural Wonder Selection. The former adds a picker for choosing which tribal village rewards are enabled, along with a slider for adjusting the frequency of goody huts that appear ingame. The latter changes the Natural Wonders picker to resemble the City States picker, complete with a slider that can adjust the number of NWs that will appear ingame.

Since they are both "new" pickers, this did necessitate altering the AdvancedSetup.xml template to include references to the new files. I presently have no experience with Sukitract's mod, but in the case of YnAMP, this does of course break its ability to preload the gameplay DB, which can be worked around by including its new header elements in my file. Its actual configuration options don't seem to require editing the XML, but its modified AdvancedSetup.lua script that implements everything is roughly double the size of the base game's version. I don't want my mods to have to rely on additional mods being present in order to function, but I also want those other mods to continue to function if mine are present, which is what prompted me to come up with the solution in the OP.

 

[Zegangani]

Now I remember the Enhanced Natural Wonder Selection Mod. Though I'm not familiar with your other Mod.

Regarding YnAMP, yeah, I understand you. And tbh, the Mod isn't receiving any updates anymore, or at least hasn't since years, so the easiest way to ensure compatibility is to simply make to versions of the Mod, one for vanilla, one for YnAMP. I remember taking a look at your Natural Wonder Picker once, and it didn't seem to change much, so it shouldn't be a lot of work to add compaibility, but it seems you already did.

Writing the AdvancedSetup files so they change based on whether YnAMP is active or not is possible, but it's too much work if you ask me. And unfortunately, in FrontEnd, you can't check whether a Mod is active or not via Modinfo, so ActionCriteria can't help here.

 

[Infixo]

Ok, I did some testing to better understand the topic and the issue at hand. Also, I am working on some FrontEnd features, so I'd probably would encounter similar problem soon.
I came with the following idea that would simulate (sort of) the ReplaceUIScript action. Not yet tested.
1. Each FE script is loaded via <LuaContext> in either MainMenu.xml or FrontEnd.xml. There is an actual file name given.
2. Instead of having a direct <LuaContext> in the .xml, there should be Include statements with some generic names. Like: <Include File="AdvancedSetupWrapper" />
3. AdvancedSetupWrapper.xml would be a simple file with <LuaContext> definition.
4. Then modders could overwrite this file with its own and in your unique .lua file you would include whatever you need - base file, other modders, etc.
Virtually overwriting this wrapper would work like ReplaceUIScript, i.e. making you responsible for the context, but you don't need to change MainMenu nor FrontEnd, etc.
For this idea to work, there must be a single mod that would lay ground for such architecture and then everyone would need to reference it and use it. "Community FrontEnd Base" or something like that.

 

[zzragnar0kzz]

@Zegangani The lack of ActionCriteria in the FrontEnd definitely makes this more difficult. This method works pretty well with the script files, but the XML elements are another matter entirely. Beyond simply hiding a few buttons, I lack the knowledge to craft a version that incorporates elements from multiple mods and turns them on or off depending on the presence and status of their source mods. For now though, it works with YnAMP enabled, and I can live with that.

 

[zzragnar0kzz]

@Infixo This is essentially what I'm doing. Unless I'm missing something, though, in the case of AdvancedSetup, wouldn't MainMenu.xml still need to be edited to point to the new wrapper files? Then the wrappers would include the existing/last imported AdvancedSetup, and other files as needed. Otherwise, how would the game know to use the wrappers? Having the wrapper include the existing file works pretty well with the Lua scripts, but as I mentioned above, I haven't been able to make it work on the XML side. I see that the base version of AdvancedSetup.xml has an include statement for PopupDialog, so this is most definitely a "me" issue, and it should be possible for someone with more skill.