change to modding from summer patch

Is it me or are both Dependencies, References and Load Order totally whacked since the Summer Update? I've been hunting bugs for days now and finally I seem to have a mod set that works, everything checks ok, no error messages in logs. Then I delete cache and everything breaks again...

PS: @Deliverator: Maybe that could explain why your even moar units mods seem to work for you but not for others...

OMG: Then I clear cache and try again (no changes to mods whatsoever) and everything works ok! Only change is that first time I started a game using a loaded configuration file, but that shouldn't affect it, should it...?

\Skodkim
 
Last edited:
Here's what I've observed so far trying to get the Even Moar Units packs to work reliably for everyone;

1) The Even Moar Units mods depend on both the main Moar Units mod and 1 DLC. For example, Even Moar Units: Australia requires the
UpdateDatabase action for both Moar Units and the Australia DLC to execute before the Even Moar Units: Australia UpdateDatabase action.

2) It used to be enough simply to specify this in Dependencies:
<Dependencies>
<Mod id="E3F53C61-371C-440B-96CE-077D318B36C0" title="Australia"/>
<Mod id="8342b98d-80c7-4002-87bb-419646bd9b54" title="MOARUnits"/>
</Dependencies>
This no longer seems to affect mod load order in any way as far as I call tell. Dependencies only seems to control what mods activate what other mods in the set up screens.

3) DLCs appear to be treated identically to mods with regard to load order. It is not guaranteed that DLC database updates will run before Mod database updates.

4) The default load order seems to depend on the timestamp of the Mod/DLC folder. This means the Even Moar Units mods can work for people by accident if the timestamps of the DLCs and Moar Units folders are earlier than the Even Moar Units folders. If the folder timestamps of the DLCs or Moar Units happen to be later than the Even Moar Units packs the database updates will happen in an incorrect order and you won't be able to start a game. This is obviously not useful, but I mention it as it something that threw me off multiple times as I thought that everything was working for everybody in all cases when it wasn't.

The only reliable way I've found to enforce load order is to use the Load Order property. So I've ended up with this:

Code:
<UpdateDatabase id="MOAR_UpdateDatabase">
    <Properties>
        <LoadOrder>-1</LoadOrder>
    </Properties>
    <File>Data/MOAR_Units_Data.xml</File>
    <File>Data/MOAR_Units_Data.sql</File>
</UpdateDatabase>

<UpdateDatabase id="MOAR_Australia_UpdateDatabase">
    <Properties>
        <LoadOrder>10</LoadOrder>
    </Properties>
    <File>Data/Even_MOAR_Units_Australia_Data.xml</File>
    <File>Data/Even_MOAR_Units_Australia_Data.sql</File>
</UpdateDatabase>

So the Load Orders are now:

-1: Moar Units (could really be 0 as it can run in parallel with the DLC)
0: DLC (have the default Load Order)
10: All Even Moar Units mods

So basically if your mod depends on other mod's database updates you MUST specify a Load Order that is greater than it/them so that the code executes afterwards.

Edit: Also the Modding.log is really useful in confirming the execution order of database updates from DLC and Mods.
 
Last edited:
were you able to test <ModArt> priority ?

i didn't get report of broken R.E.D. / MOAR Units addons, can I assume dependency is still working in that case ?
 
i didn't get report of broken R.E.D. / MOAR Units addons, can I assume dependency is still working in that case ?

I guess so unless anyone has seen or reports otherwise. The only issues I've had have all been around Gameplay database updates.
 
Improvements now separate its "domain". By default, these are land improvements (that had bug the fishing boats from my mod). Now if you want to improve a sea tile you must add Domain: DOMAIN_SEA.
 
I guess so unless anyone has seen or reports otherwise. The only issues I've had have all been around Gameplay database updates.
It also applies to Text Updates. Rob has had this problem with Anno Domini Text as well as the Database actions.

Setting a LoadOrder also appears to affect "Import" actions. I've been testing a mod since a few days before the patch where I load an additionally-edited version of a UI file via a second mod, and in all the tests of differeing methods of which mod was enabled first, etc., the UI file with higher loadorder action always is the one the game uses.
 
Last edited:
Minor thing - there's a new column in Buildings table CityAdjacentTerrain. It references TerrainType.
This is why we always need to state column-names we are writing to in an SQL file. Especially for 'primary' tables. You never know when Firaxis (or some dufuss like me) is going to add a column to a table and thereby break your mod if you are not stating the column-names you are writing to.

The new column is used in the Nubian Scenario for "BUILDING_NILOMETER". It has an adjacent terrain requirement of
Code:
CityAdjacentTerrain="TERRAIN_NILE_RIVER"
The terrain for the Nile River is special for the scenario (ie, only added when the scenario is running)

Given the full definition of Nilometer buildng it looks like the new column should work for any "standard" sort of building to require a city center is adjacent to the given terrain. Like the way RequiresAdjacentRiver works for the Water Mill
Code:
<Row BuildingType="BUILDING_NILOMETER" Name="LOC_BUILDING_NILOMETER_NAME"
Description="LOC_BUILDING_NILOMETER_DESCRIPTION" PrereqTech="TECH_IRRIGATION"
PrereqDistrict="DISTRICT_CITY_CENTER" PurchaseYield="YIELD_GOLD"
Cost="80" AdvisorType="ADVISOR_GENERIC"
CityAdjacentTerrain="TERRAIN_NILE_RIVER"/>
 
Last edited:
I noticed that city states introduced in one of the previous DLCs (Granada, Pelenque...etc...) do not show up in worldbuilder. Anyway to fix this?
 
Various UI components are in fact now modular: an example of how to modify the TopPanel can be found here, Suk has modified the LaunchBar, and the WorldTracker has an example of how to add to it in the WorldTracker.lua file. There may still be more components that have been made modular; the buttons on the right of the screen come to mind, although I can't remember what they're called to check :p
 
Last edited:
Various UI components are in fact now modular: an example of how to modify the TopPanel can be found here, Suk has modified the LaunchBar (an example of which will probably be released soon), and the WorldTracker has an example of how to add to it in the WorldTracker.lua file. There may still be more components that have been made modular; the buttons on the right of the screen come to mind, although I can't remember what they're called to check :p
I am also very curious how that system works. For my More Lenses mod, I want to move the code for the lenses outside of MinimapPanel.lua. I did something like this:
Inside of MinimapPanel.lua
Code:
g_ModdedLensInfo = {}

include( "Lens_", true );

print(g_ModdedLensInfo[1])

and inside of Lens_Test.lua
Code:
g_ModdedLensInfo[1] = "test"

The Lens_Test.lua threw a Runtime error which makes sense since g_ModdedLensInfo is not defined, but I can't say include("MinimapPanel.lua"). Does anyone know how this system works?
 
I am also very curious how that system works. For my More Lenses mod, I want to move the code for the lenses outside of MinimapPanel.lua. I did something like this:
Inside of MinimapPanel.lua
Code:
g_ModdedLensInfo = {}

include( "Lens_", true );

print(g_ModdedLensInfo[1])

and inside of Lens_Test.lua
Code:
g_ModdedLensInfo[1] = "test"

The Lens_Test.lua threw a Runtime error which makes sense since g_ModdedLensInfo is not defined, but I can't say include("MinimapPanel.lua"). Does anyone know how this system works?
Nevermind, I realized my mistake. The comments in LaunchBar.lua made me assume the Lens_Test.lua should be a Gameplay Script file in .modinfo, but it still should be import files with InGame context.:

Code:
    <ImportFiles id="MORELENSES_LENSES">
      <Properties>
        <LoadOrder>10</LoadOrder>
        <Context>InGame</Context>
      </Properties>
      <File>Lenses/Lens_Test.lua</File>
    </ImportFiles>
 
It presumably won't then; since this system was introduced in the patch, and before the patch the include() method didn't even work properly, they'll have to wait for their update. And yea, the Lua files should be ImportFiles; equivalent to VFS I guess.
 
Here is the answer to my own question. Cakes are indeed Baking in the Test Kitchen
Spoiler huh? :
include("Filename.lua") now works in Gameplay scripts also and for any file imported into the VFS
 

Attachments

  • MyCiv6Changes.zip
    2.5 KB · Views: 121
Here is the answer to my own question. Cakes are indeed Baking in the Test Kitchen
Spoiler huh? :
include("Filename.lua") now works in Gameplay scripts also and for any file imported into the VFS
great news for complex modding.

(even if I think that I'll continue to use my workaround, I'm used to it now)
 
I’m getting reports of my Map Tacks mod conflicting with JFD’s Leader Pack: Nubia which is odd because they don’t have any files in common, but they do both use LoadOrder. The other unusual thing about my mod is that I put most of my custom code into a new script which I reference via include("maptacks.lua") in the modded base-game scripts.

I am hearing that my mod works for new games but not loaded games, which sounds like classic LoadOrder problems, but I don’t fully understand the rules, or how a non-overlapping mod would cause a conflict, or whether my custom include script matters. I already started a new post to discuss it before I found this thread. Here’s my GitHub issue with my notes so far.
 
It's a mod conflict issue but I cannot figure why as yet. With JFD's Nubia pack enabled, any mod that is set as <AffectsSavedGames>0</AffectsSavedGames> is getting disabled when a saved game is reloaded. I have two mods I am currently running besides yours that are set this way and both of them are also getting disabled when a saved game is reloaded and JFD's Nubia is also enabled. I have had no such trouble with them otherwise.
 
Top Bottom