ModModding Guide to Wildmana
- Thread starter Sephi
- Start date
XML: Globaldefines
The Globaldefines are simply numbers (or in a few cases strings that reference a game element like Floodplains) which can be easily tweaked. They are found in Assets\XML\GlobaldefinesAlt.xml
For example the attitude change of a Neutral Leader towards another neutral Leader is listed here:
A simple text editor is all that is needed to change the globaldefines. Really easy to do but the disadvantage is that the changes cannot be done modular so they needed to be applied after every patch again.
The Globaldefines are simply numbers (or in a few cases strings that reference a game element like Floodplains) which can be easily tweaked. They are found in Assets\XML\GlobaldefinesAlt.xml
For example the attitude change of a Neutral Leader towards another neutral Leader is listed here:
Code:
<Define>
<DefineName>ALIGNMENT_ATTITUDE_NEUTRAL_TO_NEUTRAL</DefineName>
<iDefineIntVal>4</iDefineIntVal>
</Define>A simple text editor is all that is needed to change the globaldefines. Really easy to do but the disadvantage is that the changes cannot be done modular so they needed to be applied after every patch again.
XML: Making a Module to add/change game Elements
Allmost all Game Information is stored in an XML database. How much movement a warrior has, what civilizations exist, the Name of a Leader, etc. The base Files are in the Assets\XML subfolders, however many files are updated by XML Modules in the Modules Folder.
In modmodding XML changes should always be done modular. The huge advantage is that modular changes persist even if the main mode is updated to a later patch. There are two elements however which cannot be made modular: Randomevents (eventinfos.xml and eventtriggerinfos.xml) and Rituals (projectinfos.xml) [Rituals can be done modular with Wildmana 9.0]
Adding a new Element
As an example, create a new Promotion that allows a unit to fly and requires combat V and is only available to the Mercurian Civilization.
First create a folder, let's call it Wings. Then you need to add two files into the folder, the xml for the promotions and the schema file for it. Copy the Civ4PromotionsInfos.xml file from Assets\XML\units and rename it to WINGS_Civ4PromotionsInfos.xml. Open it with an editor and remove all promotions (a promotion starts with <promotioninfo> and ends with </promotioninfo>. It will look like this:
next thing to do is to copy the schema file list after "x-schema:" from Assets\XML\units to the wings folder and rename it to WINGS_CIV4UnitSchema.xml, then change the name in the file to WINGS_CIV4UnitSchema.xml.
Now everything is set up and promotions could be added to the file. The most simple promotion looks like this
the string list in Type is how the game identifies the Promotion. Since we add a new Promotion it is very important that this name is different from all others. Now all that needs to be done is to add the effects of the promotion. This is done by adding XML entries below type.
In our case it is
for a promotion name: <Description>TXT_KEY_PROMOTION_ACCURACY</Description>
for a button: <Button>Art/Interface/Buttons/TechTree/Fanaticism.dds</Button>
for a sound when acquired: <Sound>AS2D_IF_LEVELUP</Sound>
for Combat V as prereq: <PromotionPrereq>PROMOTION_COMBAT5</PromotionPrereq>
for Mercurian Civ as prereq:<PrereqCivilizations>
<PrereqCivilization>CIVILIZATION_MERCURIANS</PrereqCivilization>
</PrereqCivilizations>
and for the flying effect: <bFlying>1</bFlying>
Modifying an existing Element
Lets say the Wings Promotion already exists. To change the prereq from Combat V to Combat III all steps from above except the last one need to be done. Instead of defining all features of the Promotion only though that should be changed need to get listed.
The ModularLoadingControls XML files that you see in a few folders aren't necessary. They can be used to force the game to load one folder before the other.
Allmost all Game Information is stored in an XML database. How much movement a warrior has, what civilizations exist, the Name of a Leader, etc. The base Files are in the Assets\XML subfolders, however many files are updated by XML Modules in the Modules Folder.
In modmodding XML changes should always be done modular. The huge advantage is that modular changes persist even if the main mode is updated to a later patch. There are two elements however which cannot be made modular: Randomevents (eventinfos.xml and eventtriggerinfos.xml) and Rituals (projectinfos.xml) [Rituals can be done modular with Wildmana 9.0]
Adding a new Element
As an example, create a new Promotion that allows a unit to fly and requires combat V and is only available to the Mercurian Civilization.
First create a folder, let's call it Wings. Then you need to add two files into the folder, the xml for the promotions and the schema file for it. Copy the Civ4PromotionsInfos.xml file from Assets\XML\units and rename it to WINGS_Civ4PromotionsInfos.xml. Open it with an editor and remove all promotions (a promotion starts with <promotioninfo> and ends with </promotioninfo>. It will look like this:
Spoiler empty promotion xml file :
next thing to do is to copy the schema file list after "x-schema:" from Assets\XML\units to the wings folder and rename it to WINGS_CIV4UnitSchema.xml, then change the name in the file to WINGS_CIV4UnitSchema.xml.
Now everything is set up and promotions could be added to the file. The most simple promotion looks like this
Code:
<PromotionInfo>
<Type>PROMOTION_NAME</Type>
</PromotionInfo>In our case it is
for a promotion name: <Description>TXT_KEY_PROMOTION_ACCURACY</Description>
for a button: <Button>Art/Interface/Buttons/TechTree/Fanaticism.dds</Button>
for a sound when acquired: <Sound>AS2D_IF_LEVELUP</Sound>
for Combat V as prereq: <PromotionPrereq>PROMOTION_COMBAT5</PromotionPrereq>
for Mercurian Civ as prereq:<PrereqCivilizations>
<PrereqCivilization>CIVILIZATION_MERCURIANS</PrereqCivilization>
</PrereqCivilizations>
and for the flying effect: <bFlying>1</bFlying>
Spoiler finished promotions file :
Modifying an existing Element
Lets say the Wings Promotion already exists. To change the prereq from Combat V to Combat III all steps from above except the last one need to be done. Instead of defining all features of the Promotion only though that should be changed need to get listed.
Spoiler finished promotions file :
The ModularLoadingControls XML files that you see in a few folders aren't necessary. They can be used to force the game to load one folder before the other.
How to Make Python true Modular
Python generally cannot be made modular. If you modify cvgameutils.py for example, a later patch would erase all your changes. However what you can do is to link to python via XML. To do this you need to use the import command.
In this case the python code would be in the funnystuff.py file and everytime you apply a new Wildmana patch this file isn't touched, so your python changes persist.
Currently you can do this via spells and traits. For Spells, the requirement and result of a spell can be made modular. For traits the pythonPerTurn can be made modular.
Theoretically allmost all python could be made modular if there is a need for a modmod by adding SDK support for additional python callback via XML.
nearly Modular Python
Using this method requires a little modification of the init.xml file in the config folder and so isn't truly modular. However it is only a very small modification and it greatly expands what can be done with python modular.
For this you need to register your only Python Module in the BUG config. As an example here is what is needed to add the Module named "MyModule"
in Assets\xml\config\init.xml
in Assets\xml\config add the file MyModule.xml
and register all events from cveventmanager which you want to make modular (like onunitkilled or oncitybuild etc.)
in Assets\xml\python\contrib
add the file CvMyModule.py
in this case you would need some python which is run every time a unit is build in a city
As an example you could look at the FFHPlus module. Many python changes in Wildmana are done modular and thus could be turned off by modfiying just one(!) line (removing the load command in init.xml)
Python generally cannot be made modular. If you modify cvgameutils.py for example, a later patch would erase all your changes. However what you can do is to link to python via XML. To do this you need to use the import command.
Spoiler code for a spell whose python is made modular :
In this case the python code would be in the funnystuff.py file and everytime you apply a new Wildmana patch this file isn't touched, so your python changes persist.
Currently you can do this via spells and traits. For Spells, the requirement and result of a spell can be made modular. For traits the pythonPerTurn can be made modular.
Theoretically allmost all python could be made modular if there is a need for a modmod by adding SDK support for additional python callback via XML.
nearly Modular Python
Using this method requires a little modification of the init.xml file in the config folder and so isn't truly modular. However it is only a very small modification and it greatly expands what can be done with python modular.
For this you need to register your only Python Module in the BUG config. As an example here is what is needed to add the Module named "MyModule"
in Assets\xml\config\init.xml
Code:
<load mod="MyModule"/>and register all events from cveventmanager which you want to make modular (like onunitkilled or oncitybuild etc.)
Code:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!--
MyModule Python Events
-->
<mod id="MyModule"
name="MyModule"
author="Sephi"
version="1.0"
date="01/01/00"
module="CvMyModule">
<event type="unitBuilt"
module="MyModule" function="GuildUnitBuild"/>in Assets\xml\python\contrib
add the file CvMyModule.py
in this case you would need some python which is run every time a unit is build in a city
Code:
def GuildUnitBuild(argsList):
'Unit Completed'
city = argsList[0]
unit = argsList[1]
player = PyPlayer(city.getOwner())
pPlayer = gc.getPlayer(unit.getOwner())
if unit.getUnitType()==gc.getInfoTypeForString('UNIT_NOBLE_HOUSE_CANNITH') or unit.getUnitType()==gc.getInfoTypeForString('UNIT_HIGH_NOBLE_HOUSE_CANNITH'):
lPromoList = []
...As an example you could look at the FFHPlus module. Many python changes in Wildmana are done modular and thus could be turned off by modfiying just one(!) line (removing the load command in init.xml)
bump
(i want to see an actual post
)
+ question @ sephi/modders is there a way to implement spells that obsolete other spells, say for example i have earth 3 (==> summon earth elemental) and add a new spell (for example summon greater earth elemental), is there a way that summon greater earth elemental obsoletes summon earth elemental without removing the earth 3 promotion ?
(i want to see an actual post
)+ question @ sephi/modders is there a way to implement spells that obsolete other spells, say for example i have earth 3 (==> summon earth elemental) and add a new spell (for example summon greater earth elemental), is there a way that summon greater earth elemental obsoletes summon earth elemental without removing the earth 3 promotion ?
![[to_xp]Gekko](https://civfanatics-data.community.forum/avatars/m/74/74677.jpg?1475248346){kind=avatar}
[to_xp]Gekko
QCT junkie
this should be stickied
bump
(i want to see an actual post
+ question @ sephi/modders is there a way to implement spells that obsolete other spells, say for example i have earth 3 (==> summon earth elemental) and add a new spell (for example summon greater earth elemental), is there a way that summon greater earth elemental obsoletes summon earth elemental without removing the earth 3 promotion ?
you could add some if cancast(spell) return false argument into the pythonreq of the earth Elemental spell. If you plan something big I could also add a new XML tag for this.
@Sephi i have no clue about python (well i did not have one about the xml files either), my idea was to revamp / tweak the spell system:
-current problems:
1) too many spells cluttering the screen, especially with high lvl mages it becomes a nightmare to find the right spell
2) too many buff spells, forcing you to bring many mages along
-my solution:
if a mage has access to many spells, some would be "merged" i.e. the old spell would be removed and a new one with the effect of the old ones would take its place.
if you could provide me with a xml tag that could make spells obsolete i could go on modding it immediately.
edit: important: the tag must work in the spell.xml (not promotionsinfos)
-current problems:
1) too many spells cluttering the screen, especially with high lvl mages it becomes a nightmare to find the right spell
2) too many buff spells, forcing you to bring many mages along
-my solution:
if a mage has access to many spells, some would be "merged" i.e. the old spell would be removed and a new one with the effect of the old ones would take its place.
if you could provide me with a xml tag that could make spells obsolete i could go on modding it immediately.
edit: important: the tag must work in the spell.xml (not promotionsinfos)
I created a tag and after lots of crashes it finally works now . You can set a spell to be obsoleted by a list of other spells (works as or)
XML looks like this
you can add as many <ObsoletedBySpell> entries as you wish.
Still left to do is to check if it works fully modular and add some description for the pedia (spell replaced by X or something).
you should probably create a new thread for this project and also make all changes in a seperate Module.
. You can set a spell to be obsoleted by a list of other spells (works as or)XML looks like this
Code:
<ObsoletedBySpells>
<ObsoletedBySpell>
<SpellType>SPELL_SCORCH</SpellType>
<bObsolete>1</bObsolete>
</ObsoletedBySpell>
</ObsoletedBySpells>Still left to do is to check if it works fully modular and add some description for the pedia (spell replaced by X or something).
you should probably create a new thread for this project and also make all changes in a seperate Module.
ok i have an other question:
in the unitclass schema there is flanking and targeting of specific unit types. this does only work with units however not with promotions. am i wrong or is it simply not possible to give a unit a flanking ability towards an other unit type via promotion i tried:
the last two are just copied from the Luonnotar. strangely unitcombatmods (i.e. just increasing the strength towards a specific units) do work.
a similar problem arises with collateral damage
it is not that big of a deal, but if it would be somehow possible to assign those characteristics via promotions i would have a lot more room to add new items
in the unitclass schema there is flanking and targeting of specific unit types. this does only work with units however not with promotions. am i wrong or is it simply not possible to give a unit a flanking ability towards an other unit type via promotion i tried:
Spoiler :
Spoiler :
Spoiler :
the last two are just copied from the Luonnotar. strangely unitcombatmods (i.e. just increasing the strength towards a specific units) do work.
a similar problem arises with collateral damage
it is not that big of a deal, but if it would be somehow possible to assign those characteristics via promotions i would have a lot more room to add new items
next request:
@Sephi/Modders if you could add the lines <AddPromotionTypeX> (with X going from 1 to 8, instead of 3) it would not only save me some work but would make this project much more clearly laid out for the player, since my solution would be new promotions that are not really necessary.
(http://forums.civfanatics.com/showpost.php?p=9107521&postcount=5)
@Sephi/Modders if you could add the lines <AddPromotionTypeX> (with X going from 1 to 8, instead of 3) it would not only save me some work but would make this project much more clearly laid out for the player, since my solution would be new promotions that are not really necessary.
(http://forums.civfanatics.com/showpost.php?p=9107521&postcount=5)
xienwolf
Deity
Easier/better would be replacing it with an array where you can list as many promotions as you desire
Similar threads
