xienwolf
Deity
In Fall Further you now have far more control over what you can do with a module. We have included a module with the release of 0.51 which demonstrates nearly all of the new capabilities of modular modding in a fairly compact little frame.
That module is Bannor Chain of Command and is included as an attachment to this post because it will either stop being distributed with future releases of the mod, or simply be incorporated as a non-modular aspect of the mod. It is released as a module now because it works excellently as a demonstration of Modular capabilities and because the team still hasn't decided if we think it is the proper answer for making the Bannor unique and flavorful.
Modular Python:
I put this one first because it isn't possible. It might be some day, but it isn't yet and I personally don't plan to make it possible any time too soon. There are a few ways you can make it NEARLY modular though.
One approach is to make the main python files call out to your new python files with a single line in each function you want to add to. Then you have minimal code to merge on each update no matter how complex you make your own additions. I provide no examples of this as I don't know if it causes a notable performance hit and I didn't need anything THAT elaborate.
Another method, the one which Bannor Chain of Command demonstrates, is to slip your python into the main code with a conditional statement that verifies the module has indeed been loaded. This makes it so that you can include the python changes with your module and stll convince people that it can be removed from their installation of the game quite easily. Also if all module writers can collaborate and include one another's python inserts there is less of a fuss to make modules compatible with one another. And if the module is liked enough by the team and the python really does seemlessly remove itself when the module isn't loadaed, the python portion just might be included in future patches.
In our case, we simply check the info type of one of the new promotions introduced in the module. If that promotion exists, the module loaded (or someone happened to choose the same name for their own promotion, oops), if it doesn't, then the module most certainly isn't included and the code is simply skipped. You can find the code in the CvSpellInterface.py function for selecting a commander unit to attach to.
Deleting stuff from the game:
Bet you never thought a module could do this one
Well, they can't really. But they can make it impossible to use or find stuff, which is the next best thing. To accomplish this you need only set the prerequisites for the item to something impossible, and then make it bGraphicalOnly. The main trick is figuring out how to make it impossible to get, but most things which matter significantly (and are thus prone to deletion) are pretty easily made forbidden.
In our case, we delete a spell which works kind of like Wane for the Bannor to allow them to promote high level units into Commanders. This means that if the module isn't loaded then the Bannor still have SOMETHING which connects them more heavily to Commanders than any other Civ and allows access to them without direct warfare (ie - through Barbarian fights), even if it is just a small patch-measure. But of course such a spell would be wildly innapropriate if combined with Bannor Chain of Command, so we effectively delete it by making use of one of the new Modular Commands.
<bForceOverwrite> means that anything which was already loaded for this <Type> is removed and ONLY what is included in this modular file (and anything loaded after it) will be relevent. A spell which doesn't do anything is never castable, so we just leave it blank except for bGraphicalOnly which hides it from the Pedia.
Small Tweaks:
The greatest functionality of this new system is that if you just want something to be SLIGHTLY different, you can make ONLY the small change which you want, so long as that change isn't to REMOVE something, but to ADD it. Unfortunately you cannot make both of them be easy at the same time, and adding tends to be done more than subtracting, so that's what we make easy.
In our case, we demonstrate this by adding an extra free promotion (One of our new ones) to a unit (The Bannor UU replacement for the Great Commander). We simply state the unit and the free promotion, nothing else. He retains his other stats which were already loaded in the main XML, including the Free Promotions already assigned to him. Should the main mod change his strength, Unitcombat, Cost, Prereqs or anything else, our module needs no work to update at all.
Self-Referencing Fields:
This is something you don't completely understand without looking at the DLL or hearing about it before, but the main previous issue with Modules was the ability for text strings which refer to the file itself (or to files which are loaded later) to properly link up. This was an INFURIATING limitation, because Technologies and Promotions both require self-reference to be interesting in any way at all, and some of the more interesting units refer to other units in some way (like Air Elementals which spawn Lightning Elementals). And quite a few files happen to reference other files which load after themselves (due to referencing each other in some roundabout way, like Units and Civilizations).
This is (obviously) demonstrated by our promotions being added with each other as prereqs to form a promotion chain. Very simple thing to do, but previously impossible.
Structure:
We do not go out of our way to demonstrate this aspect of modular loading because the earnest hope is that it will never be required. But our new modular system makes it so that a module can be made to modify another module. In this case you need to ensure that the other module was loaded first so that your changes apply over the top of it. Doing that used to be possible by making sure that your module came last in alphabetical order, but sometimes that wasn't such an exact science as one would imagine. Now you know without a doubt which module will load when, by using the MLF files to control the load order. If you do not care about how a folder's contents load, you include a blank MLF (as we have done inside the Modules/NormalModules folder, as well as a few others). This last step is vital, as a folder which contains no MLF file at all will not load any deeper into the folder structure (but it will load XML within that folder itself).
This can be exploited to remove a module from loading without removing the full contents, just delete the MLF in the folder above it. But if there are multiple modules in the same folder and you want to stop loading only one of them, then you can edit the MLF to state that you wish not to load that Module (just by changing a 1 to a 0). Mostly it will be the Module Makers who worry about MLF files, and the Module Adicts who have so many of them and for some reason decide to see what life is like without one or two
That module is Bannor Chain of Command and is included as an attachment to this post because it will either stop being distributed with future releases of the mod, or simply be incorporated as a non-modular aspect of the mod. It is released as a module now because it works excellently as a demonstration of Modular capabilities and because the team still hasn't decided if we think it is the proper answer for making the Bannor unique and flavorful.
0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
Modular Python:
I put this one first because it isn't possible. It might be some day, but it isn't yet and I personally don't plan to make it possible any time too soon. There are a few ways you can make it NEARLY modular though.
One approach is to make the main python files call out to your new python files with a single line in each function you want to add to. Then you have minimal code to merge on each update no matter how complex you make your own additions. I provide no examples of this as I don't know if it causes a notable performance hit and I didn't need anything THAT elaborate.
Another method, the one which Bannor Chain of Command demonstrates, is to slip your python into the main code with a conditional statement that verifies the module has indeed been loaded. This makes it so that you can include the python changes with your module and stll convince people that it can be removed from their installation of the game quite easily. Also if all module writers can collaborate and include one another's python inserts there is less of a fuss to make modules compatible with one another. And if the module is liked enough by the team and the python really does seemlessly remove itself when the module isn't loadaed, the python portion just might be included in future patches.
In our case, we simply check the info type of one of the new promotions introduced in the module. If that promotion exists, the module loaded (or someone happened to choose the same name for their own promotion, oops), if it doesn't, then the module most certainly isn't included and the code is simply skipped. You can find the code in the CvSpellInterface.py function for selecting a commander unit to attach to.
0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
Deleting stuff from the game:
Bet you never thought a module could do this one
Well, they can't really. But they can make it impossible to use or find stuff, which is the next best thing. To accomplish this you need only set the prerequisites for the item to something impossible, and then make it bGraphicalOnly. The main trick is figuring out how to make it impossible to get, but most things which matter significantly (and are thus prone to deletion) are pretty easily made forbidden.In our case, we delete a spell which works kind of like Wane for the Bannor to allow them to promote high level units into Commanders. This means that if the module isn't loaded then the Bannor still have SOMETHING which connects them more heavily to Commanders than any other Civ and allows access to them without direct warfare (ie - through Barbarian fights), even if it is just a small patch-measure. But of course such a spell would be wildly innapropriate if combined with Bannor Chain of Command, so we effectively delete it by making use of one of the new Modular Commands.
<bForceOverwrite> means that anything which was already loaded for this <Type> is removed and ONLY what is included in this modular file (and anything loaded after it) will be relevent. A spell which doesn't do anything is never castable, so we just leave it blank except for bGraphicalOnly which hides it from the Pedia.
0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
Small Tweaks:
The greatest functionality of this new system is that if you just want something to be SLIGHTLY different, you can make ONLY the small change which you want, so long as that change isn't to REMOVE something, but to ADD it. Unfortunately you cannot make both of them be easy at the same time, and adding tends to be done more than subtracting, so that's what we make easy.
In our case, we demonstrate this by adding an extra free promotion (One of our new ones) to a unit (The Bannor UU replacement for the Great Commander). We simply state the unit and the free promotion, nothing else. He retains his other stats which were already loaded in the main XML, including the Free Promotions already assigned to him. Should the main mod change his strength, Unitcombat, Cost, Prereqs or anything else, our module needs no work to update at all.
0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
Self-Referencing Fields:
This is something you don't completely understand without looking at the DLL or hearing about it before, but the main previous issue with Modules was the ability for text strings which refer to the file itself (or to files which are loaded later) to properly link up. This was an INFURIATING limitation, because Technologies and Promotions both require self-reference to be interesting in any way at all, and some of the more interesting units refer to other units in some way (like Air Elementals which spawn Lightning Elementals). And quite a few files happen to reference other files which load after themselves (due to referencing each other in some roundabout way, like Units and Civilizations).
This is (obviously) demonstrated by our promotions being added with each other as prereqs to form a promotion chain. Very simple thing to do, but previously impossible.
0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0
Structure:
We do not go out of our way to demonstrate this aspect of modular loading because the earnest hope is that it will never be required. But our new modular system makes it so that a module can be made to modify another module. In this case you need to ensure that the other module was loaded first so that your changes apply over the top of it. Doing that used to be possible by making sure that your module came last in alphabetical order, but sometimes that wasn't such an exact science as one would imagine. Now you know without a doubt which module will load when, by using the MLF files to control the load order. If you do not care about how a folder's contents load, you include a blank MLF (as we have done inside the Modules/NormalModules folder, as well as a few others). This last step is vital, as a folder which contains no MLF file at all will not load any deeper into the folder structure (but it will load XML within that folder itself).
This can be exploited to remove a module from loading without removing the full contents, just delete the MLF in the folder above it. But if there are multiple modules in the same folder and you want to stop loading only one of them, then you can edit the MLF to state that you wish not to load that Module (just by changing a 1 to a 0). Mostly it will be the Module Makers who worry about MLF files, and the Module Adicts who have so many of them and for some reason decide to see what life is like without one or two
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
