Mod-Modders Guide to Fall Further

[xienwolf]

.This post is meant to provide information on precisely what has been added to Fall Further on the DLL side of things, with a bit of mention toward changes made in Python as they seem appropriate. Any questions on how to use the Sourcecode or find specific bits of functional code are quite welcome, as are comments on improvement/changes to the code base.

Base 051 DLL compile Folder
(Unpack to have the parent folder path be: Mods/Fall Further 051/CvGameCoreDLL)​

Imported Work
Gameplay Tweaks
Tips on editing in Trimmed XML Files
How to Make a Module

Important Note:

The code imported from World of Civilization (WoC) team to improve modular loading means that these following fields are available in ANY XML file. There are many areas in the schema where I did not add them because I anticipated it being unlikely that someone would actually make use of them in such a file (or rather, that it is unlikely anyone would ever modularly modify those files at all)

• bTypeDependency Indicates that this is a modification ONLY and if the Type doesn't already exist, not to bother loading what is listed here (keeps a Module which only changes the cost of a warrior from creating a brand new Warrior unit with no name and no stats, but a nice cost, if the main mod decides to delete/rename the warriors and you forget to remove the module)
• AndDependencyTypes & OrDependencyTypes - Subelement is <DependencyType> and lists the <Type> of something else which exists in the XML.
  • What this actually does is it makes the module item not load at all unless the Type requirements are met (everything from the AND list exists already, and at least 1 thing from the OR list). It is not too likely that modders will find a need for these tags any time soon, so I'll plan to just point the first person who shows interest in it at the WoC forums and then let them figure it all out and explain it to other people themselves
• bForceOverwrite - This one I added myself, WoC doesn't have anything like it that I know of. The WoC modular system allows you to change only a single line by ignoring anything in a module which uses a default value. Problem is that means you can't change something in the base XML BACK TO a default value if you want to. Set this boolean and it will completely ignore the previous entry (like how current modular loading does, but still a bit better since it will work nicely with second readpass items)

This import makes it possible to modify any XML through Module, even self-referencing items like PrereqPromotion in PromotionInfos. It also means you don't have to include any fields you don't actually change (so you can have only the Type and the one field you are changing)

Custom Work​

1. CIV4PromotionInfos.xml
   1. <iWorkRateChange> - Can increase/decrease the Workrate of a Unit. At this point the Unit still needs to have Build Orders available through UnitInfos though.
   2. <bRivalTerritoryExplore> - Can enter other Civilization's Territory without Open Borders.
   3. <bRivalTerritoryBlock> - Cannot enter any non-Team Territory, even with War or Open Borders.
   4. <bPillageOnMove> - The unit will automatically Pillage any Improvements (but not Roads) that it crosses in Enemy (at war) territory.
   5. <bSelfPillage> - The unit will automatically Pillage any Improvements (or road if no improvements present) in Neutral territory or that of your Team (to include yourself). Pillaging won't cost Move points nor provide Gold.
   6. <bGetCasterXP> - Allows the unit to gain XP from Caster/Worker type promotions (so requires the field <iCasterXP> to have a net value among all promotions on the unit to actually do anything)
   7. <bNonWarWeariness> - Loss of Unit does not cause War Weariness.
   8. <bNoMapReveal> - Unit cannot move in such a manner as to reveal new Map space (the pure black areas where you don't even know the terrain yet)
   9. <bCannotCapture> - Unit will not capture units in battle and cannot take Cities (might split this one into 2 seperate fields later now that I think about it...)
   10. <bNonAbandon> - Unit will not Abandon the Civilization when Civic or Religion pre-Reqs are no longer met. Check is performed BEFORE temporary Promotions are lost, so it is possible to keep the Unit even with a 100% chance to wear off each turn, thus forcing you to re-apply it till you meet requirements again. If you make this a MustMaintain Promotion, and have it with the same Civic & Religion pre-Reqs, then you can make it essentially a "1 shot deal" for dodging the Abandonment.
   11. <bCityHappy> - Unit may provide Military Happiness.
   12. <bCityNoHappy> - Unit can no longer provide Military Happiness.
   13. <bCanPillage> - Allows a Unit to Pillage
   14. <bCannotPillage> - Removes the Ability to Pillage
   15. <bCitySpy> - When in a Rival City, allows you to see their Production and get City Detail Zoom
   16. <bNoSupport> - The Unit will no longer cost Military Support
   17. <bStartGoldenAge> - Unit is capable of being sacraficed for Golden Ages. Selection of which units are Sacrificed is largely based on Proximity, so I advise stacking the units you want to use. Thus far the AI doesn't seem to understand this Promotion Field though.
   18. <bNoDefenseBonus> - Unit is unable to gain Bonuses for Defense (neither terrain bonuses nor Fortification)
   19. <bAllowDefenseBonuses> - Unit is able to gain Defensive Bonuses and may Fortify. <bNoDefenseBonus> takes precedence if both fields exist on a unit.
   20. <bMoveImpassable> - Unit may move through Impassable Tiles. Tested with Mountains because it was all I could think of at the time, but should work on Ice as well.
   21. <bFlatMoveCost> - Spends 1 per Tile Traveled, regardless of Terrain Type or Roads
   22. <bIgnoreTerrainCosts> - Can still use Roads, but otherwise spends 1 per Tile Traveled
   23. <bAttackNoWar> - This is <bAlwaysHostile>, it allows the unit to fight everything else without needing DoW, but unlike Hidden Nationality you can still be seen as belonging to your native Civilization.
   24. <bAllowAttacks> - Enables the ability to attack for Units not normally able to do so.
   25. <bFirstStrikeVulnerable> - Removes Immunity to First Strikes
   26. <bIndependant> - Unit does not count toward the National or Team Limits.
   27. <iSlaveGenerationChance> - Percent chance to generate a slave after combat. Adds with UnitInfo field, and thus you could use a negative value if you really wanted to. Also added a text notification for generation of a slave, capture of a unit (like, with Command), or conversion of a unit (Like with Baron Duin), and an indicator on the unit of the exact chance to generate a slave in combat (adds Civic, Unit & Promotion Fields).
   28. <iCombatExtraDuration> - Bonus Number of Turns to Duration from Combat. Can be Negative as well, with fun results.
   29. <iChangeDuration> - Adds a Duration to the Unit, positive or negative. If adding a positive value, you can cause a permanent unit to become temporary, and they have to remove the promotion before the timer runs out in order to become permanent again.
   30. <iDurationAlter> - Modifies the Duration of a Unit like iChangeDuration, but only if it already has a Duration to begin with.
   31. <iDurationPerTurn> - Modifies how quickly the Duration of a Unit will expire. Can be Positive 1 to make them Permanent (until the Promotion is lost), or even larger to enhance their duration greatly over time. As a negative value it causes their duration to dwindle quicker.
       • The Duration Series of Promotions were really designed with each other in mind. An interesting thing you can do is to limit the number of attacks a unit can effectively make. If you set them to gain 1 Duration per Turn, then the Duration is no longer linked to Time. Make them lose 1 Duration per Combat, and you have now placed a limitation on how many fights they can handle before needing to remove the promotion
       • I have modified how Duration displays. The number of turns you have remaining is displayed to account for the Duration Per Turn (it is only displayed if counting down). Below that it displays the total duration points on the unit and the change per turn it is currently recieving. Also, when you will lose the unit at the start of your next turn it displays that information clearly, rather than leaving you to wonder when precisely that last "Unit Dies in 1 Turn" is counted.
   32. <bEffectProm> - Sets the Promotion to bGraphicalOnly (not listed in Pedia) and removes the icon from being seen in-game on the Unit Mouseover, or the Detail screen. Future work will aim to remove the promotion from being displayed on Units who are set to start with an Effect Promotion, and instead display the Promotion's Information as if it was set in UnitInfo (Thus effectively importing all Promotion Fields to UnitInfos)
   33. <iExtraSupport> - Unit will Cost (or Supply if Negative) extra Gold per turn. If costing Gold per turn overall, the value is reduced according to Difficulty Settings. Charged value shows up in the F2 menu as "Extra Unit cost" (Under "Unit Cost" Mouseover) and is the same as the Unit field iExtraCost.
   34. <iCombatDmgCapBoost> - Kael added a Hard Limit function to Promotions to bring the combat Limit down, but I wanted something more flexible, so I have added a modifier which can be positive or Negative. This is applied to the lowest limit on the unit via UnitInfos and Kael's tag, and cannot bring the combat limit below 0 or above 100
   35. <iChanceMiscast> - Modification to the Miscast Chances via Promotion. Positive and Negative values are both allowed.
   36. <bRequireCity> - The Promotion can only be acquired while in a City
   37. <iGoldCost> - Promotion is Purchased with Gold rather than Experience (No Level is gained for doing so). If a negative Value is entered, you gain Gold when taking the Promotion
   38. <bStackEffect> - The Promotion may be gained or lost multiple times. No graphical effect to signify that this has happened, but all of the modifications from the promotion will happen to the unit.
       • Thus if you make Combat 5 be StackEffect, then you have essentially made an unlimited number of total Combat Promotions (every Level they can buy Combat 5 again for another 20% bonus).
       • This has some drawbacks of course. The unit still only has 1 of that promotion, so only 1 of them will be automatically removed (if you make Hasted StackEffect, then you can cast Haste on a unit 20 times in a turn to gain 20 move points. But at the start of next turn they lose the Hasted Promotion 1 time, meaning they still have 19 more move than normal...).
       • The fact that the promotion can be removed even if the unit does not have the promotion means you must be very careful with this tag, because a lot of code in the game will not check if you have a promotion before removing it. Thus if you make Withered be StackEffect, then every time you walk across the Pool of Tears you would GAIN stats inverse to what Withered normally removes from the unit!
   39. <bAutoAcquire> - As soon as the Pre-Reqs are met, the Promotion will be applied to the unit. That means the moment it would normally ask you to select a promotion for your new level (unless you flagged it bNoXP as well), or as soon as you get enough gold, it will steal that from you and apply the promotion. Of course, if the Promotion doesn't actually cost anything, then it is just free and instant (and unaviodable)
   40. <bMustMaintain> - If the unit ever fails to maintain the Pre-Reqs for acquiring the Promotion (access to Resources, appropriate PreReqPromotions, MaxAge...) then the promotion is removed at the start of the next turn. The only PreReqs which are ignored would be having XP or Gold to spend on the Promotion.
   41. <bNoXP> - The Promotion will not require XP to gain, the Unit will not gain a Level, nor Heal, upon selecting to take the promotion
   42. <NewName> - Replaces the Unit's natural <Description> flag completely. You can still rename the unit and will wind up with something like "Sidar Killer (<NewName>)" instead of the normal "Sidar Killer (<Desc>)"
       • Has been exposed to Python for manipulation as CyUnit.setNewName(STRING) and CyUnit.clearNewName()
   43. <CityBonuses> - SubTypes are <CityBonus> entries, subs of those listed below. Unlimited entries are allowed of any mix among the elements. Only those elements used need be included. Many more elements can easily be included in the list, these ones are just my initial thoughts for the setup
       1. bApplyEnemy - This City Bonus list will apply to Enemy Cities
       2. bApplyRival - This City Bonus list will apply to Rival Cities
       3. bApplySelf - This Bonus list applies to your own Cities
       4. bApplyTeam - This bonus list applies to your teamates' cities (but not your own, must set previous tag for that)
       5. bFullMap - Overrides the iRange field and forces the CityBonus to be applied to the entire map, where appropriate based on the Alliance Booleans also listed
       6. fCulture - Will modify the Culture gain (for the City Owner only) of the target Cities. If the culture of the target goes below 0 for the owner, then it will begin to insert culture for the Unit Owner into the city. In the odd cases where the unit and city belong to the same player, it will begin to insert Barbarian Culture instead
       7. fInfectCulture - Culture value that is implanted into the city. This field only affects the culture affiliated with the unit holding the bonus, while fCulture affects the Native culture
       8. fDefense - Adjusts the Defense Bonus of the City Tile
       9. fDiplo - Modifies relations with the Owner of the City each turn that the unit remains in range. This is meant to be set as a balancing factor primarily, but has plenty of uses
       10. fFood - Modifies the food gained each turn in the city
       11. fFreeXP - Modifies free XP granted to all Units built in the City
       12. fGold - Will transfer gold between Unit owner and City Owner each turn, or simply add/remove gold from the treasury if Owners are the same
       13. fGPP - Adds/removes untyped GPP to the Cities pool
       14. fHappy - Modifies the number of Happiness/Anger in the City
       15. fHealth - Modifies the number of Health/Disease in the City
       16. fProduction - Modifies Cities Production per turn
       17. fTradeRoutes - Changes the Number of Trade Routes the City has Available
       18. fTrainXPCap - Modifies the Training XP Cap for the unit's own unitcombat in city
       19. fTrainXPRate - Modifies the Training XP Rate for the Unit's own Unitcombat in City
       20. fPotency - Modifies the City's Potency Value
       21. fShielding - Modifies the City's Shielding Value
       22. fRitualAssist - Modifies the City's Production if the current production target is a ritual
       23. iBonusRange Sets the range of effect for this Bonus List, Range is by Squares radiating out from the unit (so 0 means current tile only, 1 means 9 tiles total)
       24. fDecayRate - Modification to all nonzero values listed in this Bonus List for every tile between the unit and the City being affected
   44. <PrereqMinAge> - Sets a Number of Turns that the Unit must have existed to gain the Promotion. Modified by Gamespeed (300% for Marathon, 150% for Epic, 67% for Quick. <iGrowthPercent> variable for custom speeds)
   45. <PrereqMaxAge> - Maximum Age by which a Promotion must be gained. Inspired by the MustMaintain tag as a modification to MinAge, it is meant primarily for removing promotions after some period. But can also simulate "Can't Teach an Old Dog New Tricks" type of behavior, or when set to 1 & Combined with AutoAcquire it can be used to simulate FreePromotion Tags, but only after certain other conditions are met (like the Nightmare Promotion if you have access to Nightmare Resources. That can be done by setting bAutoAcquire = 1 & iMaxAge = 1)
   46. <PrereqUnits> - Multiple entries allowed list of Unit Types required to gain a promotion
   47. <PrereqReligions> - Multiple entries allowed list of Religion Types required to gain a promotion
   48. <PrereqCivilizations> - Multiple entries allowed list of Civilization Types required to gain a promotion
   49. <PrereqCivicORs> - Multiple entries allowed list of Civic Types required to gain a promotion
   50. <PrereqTechANDs> - Multiple entries allowed list of Tech Types required to gain a promotion, all are required
   51. <PrereqTechORs> - Multiple entries allowed list of Tech Types required to gain a promotion, at least one from the list is required
   52. <PrereqAlignments> - Multiple entries allowed list of Alignment Types required to gain a promotion, base Good/Neut/Evil right now, no support for Broader Alignments fine-tuning
   53. <PrereqTier> - Tier required to gain a promotion
   54. <PrereqWeaponTier> - Weapon Tier required to gain a promotion, value must be in the range defined by iWeaponTierMax & iWeaponTierMin on the UnitInfo
   55. <PrereqTerrains> - Multiple entries allowed list of Terrain Types required on TIle to gain a promotion
   56. <PrereqImprovements> - Multiple entries allowed list of Improvement Types required on Tile to gain a promotion
   57. <PrereqFeatures> - Multiple entries allowed list of Feature Types required on Tile to gain a promotion
   58. <PrereqCorporations> - Multiple entries allowed list of Corporation Types required to gain a promotion (have that Guild in any city)
   59. <PrereqBuildingANDs> - Multiple entries allowed list of Building Types required to gain a promotion, all are required in current City
   60. <PrereqBuildingORs> - Multiple entries allowed list of Building Types required to gain a promotion, at least one from the list is required in current City
   61. <PrereqBonusANDs> - Multiple entries allowed list of Bonus Types required to gain a promotion, all are required
   62. <PrereqBonusORs> - Multiple entries allowed list of Bonus Types required to gain a promotion, at least one from the list is required
   63. <PrereqTraits> - Multiple entries allowed list of Trait Types required to gain a promotion
   64. Locality Series - These 5 are individual tags, but follow a common theme and are essentially linked to each other. If none of these are set, then things work as normal and the territory the unit is in will be ignored. However, if any one of these 5 are set, then at least 1 of them must be satisfied for the promotion to be available.
       • <PrereqInBorderEnemy> - Available when in the Cultural Borders of someone whom you are at war with
       • <PrereqInBorderNone> - Available when outside of all Cultural Borders
       • <PrereqInBorderRival> - Available when in the Cultural borders of someone whom you are not at war with, nor share a team with
       • <PrereqInBorderSelf> - Available when inside your own borders
       • <PrereqInBorderTeam> - Available when insde the Cultural Borders of a Teammate, but not yourself
   65. <PrereqEventANDs> - Multiple entries allowed list of Event Types required to gain a promotion, all are required
   66. <PrereqEventORs> - Multiple entries allowed list of Event Types required to gain a promotion, at least one from the list is required
   67. <PrereqFeatANDs> - Multiple entries allowed list of Feat Types required to gain a promotion, all are required
   68. <PrereqFeatORs> - Multiple entries allowed list of Feat Types required to gain a promotion, at least one from the list is required
   69. <PrereqFeatNOTs> - Multiple entries allowed list of Feat Types required UNCOPLETE to gain a promotion, all entries must be uncomplete
   70. <iExtraDropRange> - Grants the Unit a Paradrop Range (Personal Teleporting capability), or adds to an already existing range.
   71. <iAirCombatLimitBoost> - Enhances (or reduces if negative) the Air Combat Limit of the Unit.
   72. <iAirCombat> - Grants the unit an AirCombat value so they can make ranged attacks
   73. <PrereqbAllowNULLUnitCombat> - Allows authorization of the promotion to units which do not have a unitcombat
   74. <Invisible> - Multiple field listable Invisible types for the unit to possess. Seperate each type with a comma, no spaces. So >INVISIBLE_LAND,INVISIBLE_ANIMAL< would be proper format. If a unit has multiple Invisibility types it cannot be seen unless EACH invisibility type has been seen through.
   75. <SeeInvisible> - Same as format above but now for See Invisible capabilities.
   76. <PromotionDegradesTo> - Gain all Listed Promotions if this promotion is lost
   77. <PromotionExcludes> - Blocks the ability to gain all listed promotions (essentially replaces PromotionImmune1-3 with an unlimited length list)
   78. <PromotionOverwrites> - Removes the listed promotion if already present on the unit (replaces the extra bit I added to PromotionImmune1-3 a while back)
   79. <PromotionReplacedBy> - Removes THIS promotion if any of the listed promotions are gained
   80. <bFreeUnit> - Grants 1 extra Free Unit slot for the Player, thus balancing the 1 Unit Slot taken up by the promoted unit and making it cost no Maintenance
   81. <iDuration> - Sets a duration on the Promotion
       • If the promotion has a chance to expire, the chance becomes active after this duration hits 0, otherwise when it hits 0 this promotion is lost
       • Duration will not count down while there is anyone on the tile capable of casting a spell to provide the promotion (thus if you have an adept with Body I, he will ALWAYS have haste, as he is always in his own stack)
       • Value can be overridden by either SpellInfos or Python
   82. <TempUnitCombat> - Assigns the unit a new Unitcombat. Currently written "dumb" such that only the most recent promotion gained counts (so if you started as Melee, gained Archery, then Gained Mounted, you count as being Mounted. If you lose Mounted, then you return to just being Melee, even though you still should have Archery)
   83. <fCasterXPRate> - Modifies the Rate for gaining passive XP through Training/CasterXP system
   84. <fFreeXPCap> - Sets the cap to which FreeXP will continue to accumulate
   85. <PrereqPermission> - Indicates that the unit must have permission granted through PromotionAllows (PromotionInfos) or AllowPromotions (UnitInfos) to take the promotion
   86. <PromotionAllows> - Required for a promotion with <PrereqPermission> set, and also allows a unit to ignore UnitCombat, UnitType, Tier, and WeaponTier prereqs on any allowed promotion.
   87. <PythonOnDeath> - Python function called any time the unit is killed, even if from worldbuilder. Can be toggled on/off with CyUnit.setDisablePyDeath(bool). Return a value of 1 to prevent the death function from running past this point (just after immortal rebirth is checked)
   88. <iAsset> & <iPower> - Same as the fields in UnitInfos. Used for AI control and judgement primarily
   89. <bOverrideHelpText> - Blocks all automatically generated text output for the promotion and only shows the text key listed in <Help></Help>
   90. <iPromotionRandomApplyChance> - Controls the probability of the promotion listed in PromotionRandomApply (Fair Winds, Enraged) being applied each turn
   91. <iPromotionRandomApplyChance> - Percent Chance per turn that the promotion listed in RandomApply will actually be applied
   92. <iNoBadExplore> - Percent chance to avoid a bBad Goody result when gaining Lair rewards via Goody Validation. In most cases there is a list of possible results which gets populated, then one is chosen randomly from that list. This field in those cases just means a slightly smaller list. If you manage to dodge all possible bad results and there weren't any non-bad possibilities, typically you gain Goody_Small_Gold
   93. <PrereqPromotionsNOTOnTile> & <PrereqPromotionsOnTile> - Promotion is only allowed when a unit in the same tile has (doesn't have) the listed promotions (All listed promotions are required to be on the tile to pass the second check, none of the listed promotions are allowed to be on the tile to pass the first)
   94. <PrereqUnitClassesNOTOnTile>, <PrereqUnitClassesOnTile>, <PrereqUnitTypesNOTOnTile> & <PrereqUnitTypesOnTile> - As with the Promotion On Tile fields, either all the units listed have to be present, or none of them can be present, depending on which is used.
   95. <PythonPostCombatWon> & <PythonPostCombatLost> - Imported Python routines from UnitInfos, import work initially done by GreyFox. A python function listed here will be run at the appropriate point after battle has been decided between two units. DO NOT KILL EITHER UNIT HERE! There is still a lot of work handled by the DLL which refers to each of the units involved in the fight, so just be sure not to delete either one with a pUnit.kill or pUnit.convert type of function. No safeguards exist to prevent the crash which doing such a thing will cause.
   96. <CommanderPromotion>, <MinionPromotions>, <MasterPromotions> & <SlavePromotions> - These fields specify Promotions which the unit will grant to other units in this relationship with itself. <MinionPromotions> are granted to any Minions(Followers) attached to the unit, so are useful for Commanders. <MasterPromotions> are granted to the unit who summoned you into being, so are useful on summons...
       • Commander and Minion promotions are limited by the CommandRange of the Commander in the relationship. If the Minion also has a Command Range, that doesn't matter at all.
       • MinionPromotions must pass CvUnit::isPromotionValid checks, which primarily means that the Minion must have a valid UnitCombat for the promotion which is being attached to him, otherwise he won't gain anything. For Minions capable of changing UnitCombat, I advise that you set any promotions limited by UnitCombat to <bValidate> so they are removed from the Minion automatically when he changes to an invalid UnitCombat type
   97. <iCommandLimit> - This modifies how many units the Commander is able to have attached to him. Units are not forced to stop following the Commander when his Command Limit is reduced (by gaining a negative or losing a positive), so python needs to force the units off of the Commander when doing such a thing, or you just have to allow the Commander to have some extra Followers for a while.
   98. <iCommandRange> - This modifies the range at which the Commander and the Minion apply promotions to each other.
   99. <iCommandXPShareRate> - This modifies the XP gained by the Commander from his Minion's when they get XP in combat
   
   
2. CIV4UnitInfos.xml
   1. <iPrereqBroadAlignment> & <iAlignmentModifier> - For use with Broader Alignments system, specifies alignment required for the unit and how much owning one of the units will affect your alignment
   2. <PyPerTurn> - Python function run for the unit at the start of every turn
   3. <YieldsFromKill> & <CommercesFromKill> - Yield and Commerce bonus granted to the nearest city of the player who kills this unit
   4. <iWeaponTierMax> & <iWeaponTierMin> - Replaces <iWeaponTier> so that a range can be defined and multiple WeaponTiers created more easily
   5. <AllowPromotions> & <DenyPromotions> - Replaces the above modification to WeaponTier with an ability to handle non-linear weapon progression/availability. Works just like <PromotionAllows> and <PromotionExcludes> fields in PromotionInfos.
   6. <Quote> & <Quotes> - Matches up with <Image> and <Images> fields to provide a quote for the unit pop-ups
   7. <Images> - Matches up with <UniqueNames> field to provide Images for each Uniquename option for pop-ups
   8. <AllowPromotions> - Grants the unit permission to gain listed promotions regardless of unit-centric prerequisites (PrereqUnitClass, PrereqUnits, PrereqTier, PrereqWeaponTier). Also the unit must list any promotion in this field if the promotion is flagged as <bRequiresPermission>
   9. <DenyPromotions> - Unit is capable of having any promotion listed in these fields (Would be useful on the Flesh Golems for instance)
   10. <PythonOnDeath> - Function run any time that the unit attempts to be killed. If the function returns a 1, the kill process will not continue (like Immortality). This call is made AFTER Immortal rebirth stops the kill function. There is a python exposed command to disable this call from being made by the unit anymore (PyUnit.setDisablePyDeath(true)), and this function will not run when the unit is killed at the end of converting.
   11. <iCommandLimit> - This modifies how many units the Commander is able to have attached to him.
   12. <iCommandRange> - This modifies the range at which the Commander and the Minion apply promotions to each other.
   13. <iCommandXPShareRate> - This modifies the XP gained by the Commander from his Minion's when they get XP in combat

 

[xienwolf]

Custom Work
(continued)​

1. CIV4ProjectInfos.xml
   1. <iRevealAllBonuses> - Number of additional Turns for which the Player's Team will be able to see all resources on the map (Does not allow connection of the resources for City Trade, still need the appropriate tech - if any - to accomplish that). Duration modified by Gamespeed
   2. <iSeeInvisible> - Number of additional Turns for which the Player's Team will be able to see all Invisible Units in their Territory (Empyrean Shrine Effect). Duration modified by Gamespeed
   3. <iHideUnits> - Number of additional Turns for which the Player's Team will be able to hide all their Units inside Culture Borders but not Cities (Nox Noctis Effect). Duration modified by Gamespeed
   4. <bPrereqWar> - Requires that you are in an active War to start the Ritual
   5. <iBlockBonuses> - Causes all Bonuses to become Obsolete for anyone whom you are currently at war with
   6. <iRestoreBonuses> - Decreases the level of BlockBonuses affecting your team
   7. <bPrereqBlockBonuses> - Requires that you have a non-zero BlockBonus Count to start the Ritual
   8. <iCooldown> - Number of turns until the fact you built the Ritual is erased from your Team/Global limits. Number is counted down for each instance of the ritual, so if you are allowed 4 of a ritual with a 200 turn cooldown, you could build 4 of them finishing on the same turn and then start building 4 more 200 turns later. Or you could finish each of your 4 50 turns apart and be allowed to start a new one as soon as the last finishes (200 turns after the first finished) and a new one 50 turns after that (200 turns after the second finished)
   9. <bResetProjects> - Clears all Production on Projects for both your Team and all Teams you are at War with.
   10. <bResistable> - Indicates that the Project can be resisted on a per-city basis
   11. <iResistBase>, <iResistMax> & <iResistMin> - Base, Min & Max chance of Ritual to be Resisted by cities. Exact chances of resistance are set by modification of the Base value by a difference between Potency of attacking city and Shielding of defending city
   12. <ForcePeaceWithCivilization> - If the Civilization listed in this field is in the game, it forces peace with them. This is meant for use with the Barbarian Civilizations, but can be used on other Civilizations as well if one really wanted to. Setting this field also means that you MUST be at war with some player of that Civilization type in order to perform the ritual
   
   
2. CIV4BuildingClassInfos.xml
   1. <bUnique> - Automatically loads a Unique Building value of NONE into the Civilization Infos when the XML is being read for that file. This means that if you set this flag that as far as CivilizationInfos cares, the Default Building is NONE, so you have to list the default building as a unique building for the Civilization whom you want to be able to use the building (ie - marking bUnique on the Warrens means instead of listing BUILDINGCLASS_WARRENS is replaced by NONE for all civs except Clan of Embers, I only have to list that BUILDINGCLASS_WARRENS is BUILDING_WARRENS for the Clan)
   
   
3. CIV4UnitClassInfos.xml
   1. <bUnique> - Same as for BuildingInfos, just used a LOT more
   
   
4. CIV4EmphasizeInfos.xml
   1. <bAvoidAngryCitizens> - Sets the city to avoid producing any Angry Citizens (stops growth the turn before population growth if that growth would cause an anger excess)
   2. <bAvoidUnhealthyCitizens> - Sets the city to avoid producing any Disease (stops growth the turn before population growth if that growth would cause a disease excess)
   
   
5. CIV4CivilizationInfos.xml
   1. <bLimitedSelection> - Setting this boolean forces all UnitClasses to be initialized as NONE for this civilization, the only units they will have access to are those you specifically allow them by stating the normal UNIQUEUNITS area.
   2. <FeatureHealthPercentChanges> - Modifies the health effects of the feature on the civilization - Cannot create health benefits/issues where none already exist, but can remove or enhance existing benefits/drawbacks (so to make a civ which finds unhealth from forests, you use a negative percentage greater than 100%. But to give a civ Health from Scrubs you would have to apply the health TO the scrub feature, then give every OTHER civ this field to cancel it out)
   3. <FeatureYieldChanges> - Modifier to the Yield value of a feautre for this Civ, applies to all tiles in their cultural control
   4. <ImprovementYieldChanges/> - Modifiers to the yield values of an improvement for this civ, applies to all improvements in their cultural control
   5. <TerrainYieldChanges/> - Modifier to the base terrain value of any tile in this Civ's cultural control
   
   
6. CIV4VictoryInfos.xml
   1. <LinkedVictories> - Victories specified in this field cannot be selected at the same time as this victory (they can all be turned off, but turning this one on turns the others off automatically). This is mainly just so that the F8 Victory Progress screen doesn't waste your time by listing multiple possible Religious Victories when one of them is obviously going to happen before any of the others (due to having lower settings)
      
   
   
7. CIV4GameSpeedInfos.xml
   1. <iTurnsPerLairCycle> - Specifies the number of turns which must elapse between each Lair Cycle, at which point the HandicapInfos field controls how many lairs will attempt to spawn throughout the map
      
   
   
8. CIV4ImprovementInfos.xml
   1. <SpawnUnitCiv> - Specifies which Civilization the unit listed in SpawnUnitType will spawn for. Assuming that Civilization is in the game (intended for use with Barbarians, can be used with other civilizations as well though, but then it must be combined with bSpawnOnlyForOwner
   2. <bSpawnOnlyForOwner> - Prevents the units the improvement spawns from being spawned unless the improvement is owned by the appropriate Civilization (For Barbarians this means unowned, or the owner is at peace with the Barbarian Civ)
   3. <iSpawnPerGameLimit> - Improvement is unable to spawn more than this many units per game. If the improvement is removed and rebuilt, the counter starts over
   4. <iSpawnAtOnceLimit> - Improvement is unable to spawn more than this many units at once time. If the improvement is removed and rebuilt, the counter starts over. Can be combined with iSpawnPerGameLimit if desired (ie - AtOnceLimit of 1, and PerGameLimit of 5 means that each time the unit is killed the lair is allowed to spawn another one, but after 5 have been killed it never spawns again, till rebuilt elsewhere, or destroyed/rebuilt in the same time)
   5. <bExplorable> - Tells any unit on Automated Exploration to stop at this tile and wake up (request user input). Also makes them desire to move to this tile like it was a GoodyHut. This last part MIGHT get a bit annoying if you don't WANT to explore the lair and attempt to re-automate the unit without first moving him away a little bit. (NOTE: This field makes it so that the AI rather aggressively pursues Lairs to explore. Also note that since most units spawned from a lair are spawned by Goody, it isn't easy to have units popping up too close to your only city, or too early in the game)
   6. <iLairCreationWeight> - Weight for the Improvement to be selected for spawning during each LairCreationCycle (All weights of all improvements with a weight are added, and one is selected randomly from that weighted list to try and spawn. A valid tile must be found for the improvement to spawn though, otherwise another one is selected instead)
   7. <iBasePlotCounterModify> - Modifies the PlotCounter by this value. True value of the Plot Counter still cannot go above 100 or below 0, so this field if set under -92 will make the tile incapable of becoming Hell, and if set over 10 will make it impossible for the tile to NOT be Hell.
      
   
   
9. CIV4TechInfos.xml
   1. <BonusCostShifts> - Adjusts the cost of the technology based on Bonuses (Resources) which the player has access to. Number listed is directly added to the cost of the tech
   2. <TechCostShifts> - Adjusts the cost of the technology based on Technologies which the player has learned. Number listed is directly added to the cost of the tech
   3. <BonusCostMods> - Adjusts the cost of the technology based on Bonuses (Resources) which the player has access to. Number listed is multiplied as a percent value adjustment of the TechCost (plus any Shifts). By default this field is 100, listing a lower value makes the tech cheaper, listing a high one makes it more expensive.
   4. <TechCostMods> - Adjusts the cost of the technology based on Technologies which the player has learned. Number listed is multiplied as a percent value adjustment of the TechCost (plus any Shifts). By default this field is 100, listing a lower value makes the tech cheaper, listing a high one makes it more expensive.
      
   
   
10. CIV4HandicapInfos.xml
    1. <iUnownedWaterTilesPerGameAnimal> - XML exposed control for how many tiles of a water area are required unowned/at peace with animals for an additional animal to spawn. Previously the game just divided the BarbarianWater field by 5 or something like that, so it was hard to tweak how many Serpents/Tortoises you got
    2. <iAnimalEscalationTurnsElapsed> - Combines with a new Global Define (MAX_ANIMAL_ESCALATIONS) to control the automatic strengthening of units belonging to the Animal Civilization. Every turn multiple of this number after birth the animal unit will gain a point of strength, up to the defined limit (So if you leave an elephant alive too long, he'll be even harder to take down, but even more worthwhile when you make him into a war elephant)
    3. <iLairSpawnChance> - Discarded field, lair generation mechanism was revised and I forgot this field existed. So till it has a purpose it is a nice "blank" which mod-mod-modders can use for their own designs (since it is python exposed)
    4. <iLairsPerCycle> - Each Lair cycle (determined by new field in GameSpeedInfos) this is how many new lairs will attempt to spawn on the map. In general this many WILL spawn, but it is possible if all land is claimed and nobody is at peace with any Barbarians that there won't be any new lairs at all
    5. <iPercentDemonsPerUnownedEvilPlot> & <iDemonGlobalCountSpawnBoostInterval> & <iDemonGlobalCountSpawnBoostRate> & <iDemonSpawnRateGlobalCounterEnhancementPercent> - Controls for spawning of Demons. Demons only spawn in Hell Terrain (well, in tiles with a Plot Counter over 9, so also in Ice and Tundra), the number of demons allowed to spawn is controlled by the number of evil (hell) tiles in the world (just plain unowned tiles don't matter, and it doesn't matter if they are owned or not). The PercentPerEvilTile is inflated by the BoostRate for every multiple of the BoostInterval of the current AC (at higher difficulty levels, this means that when approaching 100 AC you will wind up with a max limit of demons in the area which is MORE than 1 per Hell tile). The EnhancementPercent increases how many of the "missing" demons from the max allowed will spawn per turn. By default it is 1/8 of the missing demons that spawn, and on Settler you won't change from this value much. On deity, somewhere around 85 AC you begin respawning ALL demons which are allowed in the area every turn (ie - Deity Armageddon probably hurts. Lots. Unless you have Pax Diabolis...)
    6. <iDemonGlobalCounterFreeXPPercent> - Percentage of the AC which is granted as free XP to every demon civilization unit upon spawning. This is in addition to any free XP for all AI civs due to Kael's Handicap settings.
    7. <iDemonPerTurnKnownTechsPercent> - Each turn, for every player who knows a tech that the demons do not have, they gain this percentage toward knowing it themselves. ie - If set at 10, and only 1 player knows the tech, the demons will gain that tech 10 turns later. If that player immediately traded the tech to 4 other players, then the demons will know the tech within 3 turns (gaining 50% rounded down each turn, so if the beaker cost is an even number they'll know it in 2 turns). Techs are the primary control over what type of units the demon Civilization will spawn
    8. <iDemonBonus> & <iAIDemonBonus> - Bonus that the Human and the AI gain against units from the Demon Civilization. It should be noted that the corresponding field for Barbarians applies to the Orc Savages only, and that the Animal bonus now applies to the Animal Civilization and NOT to units marked with bAnimal.
       
    
    
11. CIV4BuildingInfos.xml
    1. <iPotency> & <iGlobalPotency> - Enhances the strength of rituals completed in the city (or all cities)
    2. <PotencyAffinities> & <GlobalPotencyAffinities> - Array of Bonuses which enhance the Potency by float values per Bonus owned
    3. <PotencyBonusPrereqs> & <GlobalPotencyBonusPrereqs> - Array of Bonuses which offer enhanced Potency by integer value if any of the bonus is owned
    4. <iShielding> & <iGlobalShielding> - Enhances the defenses against enemy rituals for the City (or all cities)
    5. <ShieldingAffinities> & <GlobalShieldingAffinities> - Array of Bonuses which enhance the Shielding by float values per Bonus owned
    6. <ShieldingBonusPrereqs> & <GlobalShieldingBonusPrereqs> - Array of Bonuses which offer enhanced Shielding by integer value if any of the bonus is owned
    7. <TrainXPCaps> & <GlobalTrainXPCaps> - Array of Unitcombats that the city (or all cities) can offer a float cap for free Training XP
    8. <TrainXPRates> & <GlobalTrainXPRates> - Array of Unitcombats that the city (or all cities) can offer a float Training XP rate enhancement
    9. <PrereqTeamBuildingClassANDs>, <PrereqTeamBuildingClassNOTs>, <PrereqTeamBuildingClassORs>, <PrereqGlobalBuildingClassANDs>, <PrereqGlobalBuildingClassNOTs> & <PrereqGlobalBuildingClassORs> - These can list any number of buildingclasses and any number of each of those as a prereq (or limit) for construction of another building. Formatting is the same as <PrereqBuildingClasses> (which depends only on the buildingclasses that the player himself owns, if you wonder how that is different than the new TeamANDs field)
    10. <EquipmentPromotion> - This field is required for the new "no Unit's" approach to Equipment. If a building is "portable" like the Crown of Akharien and Dragon's Horde, identify what promotion carries the building with this field.
    
    
12. CIV4LeaderHeadInfos.xml
    1. These 4 tags are all added to facilitate the CityBonuses field fProximityDiplo from PromotionInfos
       • <iProximityMemoryDecayDelay> - Defines a number of turns which must pass without any new adjustments via fProximityDiplo before the Attitude adjustment will begin to decay.
       • <fProximityMemoryDecaySpeed> - Defines a minimum speed of decay per turn (after the delay) for the Diplomacy Value
       • <iProximityMemoryDecayRand> - Random Cap on a Percentile bonus to the DecaySpeed per turn (so if set to 100 the decay rate can be up to twice the minimum per turn)
       • <iProximityMemoryLimit> - Maximum value the fProximityDiplo Bonus can affect this Leader by (both Positive and Negative)
    2. <Images> & <DefeatQuotes> - These tags are used to display the pop-up when you defeat a leader without the requirement of specifying each leader seperately in Python
       
    
    
13. CIV4SpellInfos.xml
    1. <bSummonMaster> - If the unit was summoned (Has a Master Unit), it will call that Master Unit to the current tile (if the Master Unit is allowed to be on that tile).
       • AI has a fairly solid grasp of how to use this function to keep the Master Unit alive and make strikes of opportunity.
    2. <iPromotionDuration> - Sets a duration on any Promotions which are applied by the spell, this value overrides any natural duration set in PromotionInfos (Default value for this field is -1, placing a 0 makes certain that there is no duration set by any of the promotions which the spell applies.
    3. <Quote> - Specifies the text displayed in the pop-up for Global Spells (Image used is the LeaderHead image)
    4. <PrereqAvailableCommander> - Spell can only be cast if there is any Commander on the tile other than the unit trying to cast the spell which has free space in its Command Limit
    5. <PrereqIsMinion> - Spell can only be cast if the unit has a Commander Unit it is attached to
    6. <PrereqIsNOTMinion> - Spell can only be cast if the unit has no Commander Unit it is attached to
    7. <PyHelp> - Allows you to add Help Text using Python to indicate certain things which the DLL might not be able to pick up (mostly those which are situational to your spell, like targetting data). Available fields are the spell being cast and the unit who is currently selected (Or possibly the leader of the group which the unit currently selected belongs to, not QUITE certain on that one...), as typically that is the caster.
    8. <PrereqNotAttacked> - Requires that the unit hasn't been flagged as HasAttacked yet to be allowed to cast the spell
    9. <bSetHasAttacked> - Marks the unit as having attacked for the turn. Note that if the unit is Blitz they can still attack until their move points are all spent. Also remember that defensive strikes are linked to your HasAttacked field
    10. <bRemoveHasAttacked> - Clears the HasAttacked flag from the unit. This means even if you don't have Blitz you would be able to attack or perform a Defensive Strike between turns. Also note that if a unit is out of movement points it is relatively useless (except for defensive strikes) to gain back the ability to attack
    
    
14. CIV4GoodyInfos.xml
    1. <iScience>, <iScienceRand1>, <iScienceRand2> - Functions like iGold and partners to grant research toward current Tech being researched. These values are Percentages, the first is guaranteed and each of the others are random caps. So you could set iScienceRand1 to 100 for a completely random addition of Research, or set iScience to 100 for a guaranteed finishing of current research. These values can be negative as well as positive, and will never provide overflow research. Percentage is modified by gamespeed, so on Marathon games you will gain 1/3 of the listed percent, and on Quick games you will gain ~130% the listed. Thus to get a free Tech (just started researching it) on Marathon, you would need a Science value of 300 after both Randoms, but to get a free tech on quick you would only need a 67 after both randoms.
    2. <BarbarianCivilization> - Specifies which Civilization the units listed in BarbarianClass will spawn for. During validation of CvPlayer::canReceiveGoody it will not allow this goody type if you are at peace with this civilization
    3. <PromotionAdds> & <PromotionRemoves> - Promotions listed will be granted to (revoked from) the unit popping the goody, or to any unit created by the goody instead (for free units or Barbarians). If promotion is being given to the unit who popped the result then it must be a valid promotion for the unit (ie - proper unitcombat)
    4. <iMinTurnsElapsed> & <iMaxTurnsElapsed> - Earliest and Latest in the course of a game that the goody can be granted. Weighted by gamespeed
       
    
    
15. CIV4TraitInfos.xml
    1. <iModReligionSpreadChance> - Percentage Modification to chances of Religion spreading (passive only, pending AI understanding for Disciples). Value can be positive (100 means twice as likely) or negative (-100 means will not spread). A value below -100 will prevent Holy Cities from being founded by the player should they discover a Tech capable of Founding a Religion. So far the Holy City will not instantly spawn for the next player to acquire the technology, but it will show up naturally at some point.
       
    
    
16. CIV4FeatInfos.xml
    1. Moved all Feats out of the DLL and into the XML. This is done with a file in the Assets/BasicInfos folder. Current fields are just the type of Feat and a Description. Descriptions are intended to be used when a Feat is made a Prereq Item for a Promotion. Unfortunately the system isn't quite perfect yet and you still need to add each item to the DLL (just like GameOptions)
       
    
    
17. CIV4BuildInfos.xml
    1. <TechBuildDiscounts> - Array of Technologies. Grants a discount to the iTime value for the build process based on technologies of the tile's owner
       
    
    
18. CIV4TerrainInfos.xml
    1. <CivilizationYieldType> - **REMOVED FIELD** Replaced with function handling in CivilizationInfos file instead
    
    
19. CIV4ReligionInfos.xml
    1. <iTGAIndex> - This indicates which TGA icon to use for the Religion. It allows you to link the icons to the Religions in any order you desire, and even skip some if you want to. Note that you are saying what order they go in, not which TGA slot to use (as each Religion actually uses 2 slots, so the number here is multiplied by 2 to choose the main slot, and 1 is added to that to get the Holy City slot).
    
    
20. CIV4CorporationInfos.xml
    1. <iTGAIndex> - This indicates which TGA icon to use for the Corporation. It allows you to link the icons to the Corporations in any order you desire, and even skip some if you want to. Note that you are saying what order they go in, not which TGA slot to use (as each Corporation actually uses 2 slots, so the number here is multiplied by 2 to choose the main slot, and 1 is added to that to get the HQ slot).
    
    
21. CIV4GameOptionInfos.xml
    1. GAMEOPTION_RELIGIOUS_HUD - Enables new Interface designs based on current Religion instead of the standard FfH interface all game long.
    2. GAMEOPTION_NO_AI_LEVEL_REQ - Allows AI to ignore minimum level requirements on building and upgrading units. Primarily meant to increase use of Casters, has the side effect of making the Mercurian more capable of waging war.
    3. GAMEOPTION_BROADER_ALIGNMENTS - Allows Player Alignment to be based on a sliding scale which will adjust based on in-game actions instead of simply religion choice.
    4. GAMEOPTION_FLAVOUR_START - Grants each Civilization a weighting value to gain a start location which matches their lore/preferences.
    5. GAMEOPTION_NO_WORKER_XP - Freezes automatic XP gain on Worker Unitcombat. XP can still be gained by other means and spent on worker promotions though (like Spirit Guide, and if you buy some defense, normal defending after that point. Or you could give a worker Orthus's Axe and a Golden Hammer I suppose...)
    6. GAMEOPTION_LIMITED_CIVILIZATION_SELECTION - Cannot actually be turned on (automatically turns itself off), but launches a pop-up window where you can control the <bPlayable> and <bAIPlayable> tags for CIV4CivilizationInfos.xml. These changes will last until modified in this screen again or Civ loads the XML again (ie - you quit to desktop)
    7. GAMEOPTION_ENABLE_COMBAT_LOG - Enables the Combat Log regardless of the Callback settings
    8. GAMEOPTION_NO_ANIMALS & GAMEOPTION_NO_DEMONS - Remove the Animal or Demon Barbarian Civ from the game
    9. GAMEOPTION_DARK_FORESTS - Controls the presence of Dark Forests or Daikanos as an extra early game hazard (which one of the two you actually get is randomly selected)
    
    
22. CIV4MPOptionInfos.xml
    1. MPOPTION_RANDOM_LOGGER - On by default, will write a log file containing every random number the game calls for in the standard logs directory.
    
    
23. GlobalDefinesAlt.xml
    1. NULL_PROMOTION - Defines a promotion which is made available to any unit when they have enough XP for gaining a level, but no other promotion options.
    2. AI_PROJECT_CHANCES & AI_UNIT_CHANCES - Percent chance that a Bored AI City (one which has no DESIRE to build anything) will check Projects or Units before checking Buildings for something which it is merely WILLING to build, before resigning itself to building wealth/culture/science. Should be fairly rare for an AI routine to make it this far in the decision process.
    3. BROADER_POPRUSH_BASE_MODIFIER & BROADER_POPRUSH_MODIFIER - Base Alignment Shift, and Alignment Shift from each point of population lost by rushing production
    4. BROADER_RAZE_BASE_MODIFIER & BROADER_RAZE_MODIFIER - Base Alignment Shift, and Alignment Shift per Population Point for razing a City.
    5. BROADER_ALIGNMENT_EVIL_MIN, BROADER_ALIGNMENT_EVIL_MAX, BROADER_ALIGNMENT_GOOD_MIN & BROADER_ALIGNMENT_GOOD_MAX - Interger values at which Alignment will change when using Broader Alignments option
    6. CURRENT_RESEARCH_CONQUEST_TECH_PERCENT - Bonus to any Research Gained when killing a unit returns research points to a player if they are currently researching the same tech
    7. PILLAGE_COMM_VARIABLE_PERCENT - Random boost to the amount of any Commerce gained after killing a unit is meant to return some quantity of Commerce to a player
    8. MISCAST_PROMOTION - Identifies the promotion applied to a unit when they miscast a spell. Promotion will have a random duration assigned to it
    9. BASE_MISCAST_DURATION - Control variable for Miscast applied promotion duration
    10. MAX_ANIMAL_ESCALATIONS - Sets the number of times that Animal Civilization Units can have their strength augmented. Speed that it happens is set by Handicap settings.
    11. ORC/DEMON/ANIMAL _ CIVILIZATION/LEADER - Informed the DLL which Civilization and Leader to assign for the Barbarian Civilizations.
    12. GAMEFONT_TGA_RELIGIONS & GAMEFONT_TGA_CORPORATIONS - Specifies how many blocks are available for Coporations and Religions in the TGA. This is required so that the Corporations and Bonuses start to load from the proper location. Change this if you modify the dimensions of the TGA for some reason (which you would only really do if you were seeking to add more than 46 total religions/Corporations to the game, which is just sick and wrong! )
    13. EQUIPMENT_HOLDER - Informs the DLL which Unit to use to place Promotions on when items are dropped in the field. This unit should always be flagged bNeverHostile and bCommunalProperty or things massively fail for the system. I know, hardcoding sucks, but sometimes it is needed
    14. BASE_COMMANDER_XP_SHARE - Sets the basic percentage of XP gained in Combat by a Follower which is also granted to his Commander. Tags in UnitInfos and PromotionInfos further modify this value. Negatives are allowed, though I wouldn't advise it as I never set up safeguards to prevent negative total XP on a unit and don't know what will happen if that comes to be.
    15. COMMANDER_UNITCLASS - Replaces the Firaxis method of choosing what unit to spawn as a Great General. Rather than choose randomly from all units with a LeaderPromotion or XP granting ability, it takes this UnitClass
    
    
24. CIV4StateNameInfos.xml(New File)
    1. <iMinNumCities> - Number of cities required to gain the statename
    2. <iMaxNumCities> - Limit of number of cities owned for name to be valid
    3. <bNoMinor> - Prevents Minor Civilizations from having the statename
    4. <bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
    5. <PrereqCivics> - Civics required active to gain the statename
    6. <PrereqAlignments> - Alignment required for the name to be valid
    7. <PrereqCivilization> - Civilization for which the name is valid
    8. <PrereqReligion> - Religion required to gain the name
    9. <iMinNumCitiesConquered> - Must conquer this many Cities to gain the name
    10. <iMinNumVassals> - Must currently have this many vassal Civs to have the name
    11. <bFullCiv> - For future use with Revolutions functionality and Minor Civs
    12. <bMinorCiv> - For future use with Revolutions functionality and Minor Civs
    13. <bSovereign> - Must be non-vassalized
    14. <bVassal> - Must be vassalized
    15. <bColony> - Must have been set free as a colony from another Civ
    16. <bFemaleLeader> - Need to be a female leader
    17. <PrereqLeader> - Restricted to a single leader
    18. <bNoMinor> - For future use with Revolutions functionality and Minor Civs
    19. <bNoVassal> - Must not have any vassals currently under you to have this name
    20. 
        
    
    
25. Python/DLL Only
    1. New Widget Type defined for Tooltips on Armageddon Counter and for Tooltips+Action on Slave/Master buttons
    2. new function exposed to Python: CyCity::isResisted. Need to pass another City and a Project Type and it will check for resistance of whatever the attack is. Function may change in the future to require passing a Potency & Min/Max/Base Resistance chance instead for increased flexibility (resist spells and/or armageddon)
    3. CyUnit::setDisablePyDeath(bool). Disables/Enables the <PythonOnDeath> field of a unit
    4. CyGame::getNumCivActive(eCiv) - Tells you how many currently living players are using this Civ
    5. CyGame::getCivActivePlayer(eCiv, int) - Gives you the player number of the person who is using this Civ (use in a loop over previous function range)

 

[xienwolf]

Modifications Borrowed from Other Users:​

1. Dom Pedro's Food from Animals
   • New Fields to allow Yields and Commerces to be gained by Combat
     • Basic MODCOMP provided fields in Traits so that all your units can gain when they win, and fields in Units so that when the unit loses the victor gains.
     • My Revisions make Promotions able to allow for either one, though Traits are still the only place where you can get a percentage modifier.
2. Grey Fox's Broader Alignments (With modifications by Vehem) - Places Alignment on a Sliding scale setup so that more than religion can affect your standings. No graphical inclusion so far (Alignment Meter). System is due for a massive overhaul someday, current is considered a Beta at best
   • Includes PyPostCombat Win & Lose functions and a SpellRange Modification tag for Promotions
3. Modifications to Heal and Move_To actions based on Pep's work
   • Units set to Heal will now wake up when danger approaches, and units instructed to move will not attack an enemy that wasn't visible when the order was given
4. WoCLite - Allows Modular Mods to work far better. You are able to have a modular file change just a single line item for any XML file, and you are allowed to use things which reference within the same file (or files not yet loaded) without issue as well. Framework modified slightly to work with our more complicated code
   

Minor Tweaks​

1. bValidate in PromotionInfos checks WeaponTier and Allow/Deny fields in addition to appropriate unitcombat to ensure promotion is still allowed after Convert function is performed
2. Loyalty type spells will be lost instead of units turning Barbarian when they fail a random check to abandon the civilization. If Barbarians are disabled, units attempting to become barbarian are killed instead of simply left alone.
3. isPromotionValid check with 3 inputs (Gamecore function) no longer used in the DLL, since all checks which are still worthwhile from the function are unit dependant.
4. AI will split stacks when a unit becomes immobile
5. Combat Strength, Workrate, and Movement Rate cannot be negative
6. Nox Noctis units can be seen, their invisibility type is set in Global Defines
7. Units that upgrade are not reduced in XP
8. Removed the "Your Units are Under Attack" message, since the "You have been killed" or "You have killed" do quite well enough
9. AI units which are Immortal will use an aggressive AI type
10. Temporary Units will not gain free XP
11. Summons are Linked to their Summoner
12. Guardsman promotion will always be selected as a defender against Marksman promotion
13. Improvements will display a required Tech to connect the resource to the city until that tech is gained
14. Barbarians and Animals spawn all game long, Barbarians start spawning based on Difficulty setting (BarbarianCreationTurnsElapsed) and Gamespeed (BarbPercent)
15. Religions are adopted by units without a default religion on a more level playing field, with preference toward State Religion
16. Unique Improvements cannot be generated on top of each other during map creation (was very common for both Letum Frigus and Ring of Carcer to desire the same location, resulting in a Brigit without a level requirement to capture)
17. Summoned Units do not cost basic Unit Support (or more accurately, they provide a free Unit Support Slot to cover themselves). It is still possible to be charged Military or Extra support costs for the Summons however.
18. Workers/Hawks no longer defend against Marksman units
19. Twincast can now stack, and Twincasting units get to select a second (third, fourth...) spell to cast instead of just getting twice as many summons
20. In Multi-player games, all cities after your first one settled as the Kuriotate will start as a settlement instead of starting as a city
21. City Art Styles are maintained based on the City Civilization type
22. Hidden Nationality Units can be grouped
23. Enraged Units leave their group at the onset of AIControl
24. Enraged units have a much more aggressive AI setup, and are forbidden to perform most non-aggressive actions
25. Enraged affects AI and an Enraged unit cannot be selected by a human
26. Units will not Suicide trying to attack things you couldn't see when giving an order to move beyond your visible range
27. Units will "wake up" when healing if they are the strongest defender on the tile and danger approaches
28. Groups which are performing Build Orders will not "wake up" when a new promotion is available, but they will still glow blue.

How to edit our trimmed XML:​

1: Use Notepad++
2: Right click on the TAB for the file you have opened
3: Select "Clone to Another View"
4: Welcome to split-screen view! You now see 2 copies of the same file, who cares?!
4.5: Make sure that you are split vertically (side-by-side) instead of Horizontally (I get the top!)
5: In one copy, focus on what you want to change/add
6: In the other copy, scroll down to "Test Promo" (actually, just search. As long as you include a space before/after any word, it searches very nicely to the commented name instead of the 5,000 other lines of code that use that word somehow...)
7: Now that you have the test promotion (all fields) right next to your change/addition, you can see the precise order required for all fields, and only use the ones which matter in some way!

8 (occasional): If your field requires sub-elements, and nothing else actually USES those subelements, open up the Schema file and pray that you understand how to read them (just encase the <> value you need subelements for in "" marks and you should get a result which lists what comes inside of it. You may have to also search for each of those for the REALLY nested entries...)


Yes, the trimmed XML can make adding things to the file a PITA, but it makes figuring out what the file actually DOES a lot quicker/easier in the end since you don't have to scroll through 500 cases of >0< or >NONE< and pray you don't overlook the >1< which is causing you issues...

 

[xienwolf]

How to Make a Module:​

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.

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

 

[MagisterCultuum]

Reserved for Past Use.

 

[Tarquelne]

This thread a good place for modding questions?

I'm thinking about giving the Scions a 1-use-only "Appease the Gods" effect. ("Emperor's Boon", or "Emperor's Intercession", something like that.)

Is setting up a Project that requires the Scions-only tech and has 1 "maxglobalinstance" the only way to do it via XML? (Or, I guess, 5 instances to fully cancel 1 use of Curse the Lands?)

 

[Vehem]

This thread a good place for modding questions?

I'm thinking about giving the Scions a 1-use-only "Appease the Gods" effect. ("Emperor's Boon", or "Emperor's Intercession", something like that.)

Is setting up a Project that requires the Scions-only tech and has 1 "maxglobalinstance" the only way to do it via XML? (Or, I guess, 5 instances to fully cancel 1 use of Curse the Lands?)

You can actually set one ritual to remove multiple "curse levels" - so one ritual could remove multiple levels of curse, so a single use could completely negate a single Curse the Lands. Fairly potent though, and I'm not sure the Scions are lacking in unique mechanics as it is - it might make a better option for the Grigori...

 

[Tarquelne]

Fairly potent though, and I'm not sure the Scions are lacking in unique mechanics as it is

True - I'm assuming it'd be one part of a general "gunning up" on Rituals all/most civs would participate in.

Luxury resources being a big part of the Scion's spawning modifier I was also worried CtL would be extra-effective against them. I've decided it wouldn't be, or not much: They're nearly immune to problems from the Health resources being cut off.

I think the Elohim are also be a good candidate for a cheap Appease effect - or maybe even an automatic one: The first Curse cast against them doesn't work.

 

[Falc]

Semi bug report, but since it's only really important for modmodders I'll place it here.

I've been having some issues with Modular Loading and FF. I turned it on in the .ini and either Civ crashed when making the map, or it 'crashed' after I had closed it and had already been returned to my desktop.

I tested the same setup in vanilla FfH and it worked there.

 

[Vehem]

Semi bug report, but since it's only really important for modmodders I'll place it here.

I've been having some issues with Modular Loading and FF. I turned it on in the .ini and either Civ crashed when making the map, or it 'crashed' after I had closed it and had already been returned to my desktop.

I tested the same setup in vanilla FfH and it worked there.

Is that with modular loading turned on at all, or with a specific module included to load? Does it crash with just the ini file change and no modules included?

 

[Falc]

It crashes with Modular Loading turned on, even if there's no modules present.

Furthermore, it crashes when it's creating a map. If I load an existing save, or a scenario map, it crashes afterwards. (As far as I can tell)

 

[xienwolf]

Been forgetting to update this, so here are some items which I posted a while ago and a bunch of new ones I just wrote up tonight on a whim.


PromotionInfos:
iExtraDropRange - Grants the unit the ability to teleport farther (or at all if they weren't able to before)

iAirCombatLimitBoost - Allows the unit to do more total damage with ranged attacks (or at all if they weren't able to before)

iAirCombat - enhances ranged attack strength (or grants ranged attack strength)
PrereqbAllowNULLUnitCombat - Allows the promotion to be available for units with no UnitCombat (needed for certain spells, and could be nice to let the golems & Loki have access to at least 1 promotion...)

Invisible - Allows multiple Invisible types to be assigned per promotion and stacked onto the unit. Proper format would be the same as seeinvisible in UnitInfos (<Invisble>INVISIBLE_LAND,INVISIBLE_ANIMAL</Invisible>). Can't remember if I added this to Unitinfos as well....

SeeInvisible - Same as above, exact copy of how things were already done in UnitInfos (not that many people realized you could list multiple Invis types to begin with...)

PromotionDegradesTo - When you lose the promotion, you will gain all listed promotions (unless immune to them of course)

PromotionExcludes - Replacement for PromotionImmune1-3 with a list of variable length. Can now be immune to everything you care to be.

PromotionOverwrites - Removes the listed promotions from the unit when this promotion is gained (does not block you from gaining them later though, that is PromotionExcludes job). I had added this feature to PromotionImmune1-3 a while back, but realized it is useful to seperate them (for Naval Crews most notably)

PromotionReplacedBy - When you gain one of the listed promotions, you will lose this promotion. Sort of the previous listed promotion, but done in reverse. Now that I think of it that way I am not entirely certain why it is needed... I am sure I had a decent reason at the time....

PrereqWeaponTier - Added it now after realizing that I wanted to add it long ago and apparently did not. Probably I just didn't feel like re-writing the WeaponPromotions to use PromotionImmune1-3. Anyway, with this field and the above listed fields it is now trivial to add as many more tiers of weapons as you would like.

bFreeUnit - Adds 1 Free Unit to the player's Base Free Units value, effectively making this unit cost no maintenance. Also set all Summons to start with this feature active.


ProjectInfos

iCooldown - Time delay until you can complete a ritual again. This just works to restore your Team/Global limits, so if you are allowed to build 5 of a ritual and it has a cooldown, you can build all 5 at once, or immediately after each other. Timer is linked to each instance of constructing the ritual as well, so it doesn't start over at 0 when you complete a new copy of a ritual. This was one of the major "new balance" ideas for Curse the Lands. Now it can be limited to a single use in a LONG time period for each team.

bResetProjects - My first attempt at a counter-strike method for Curse the Lands. Pending balance decisions for precisely how to make use of it of course. And quite likely it will need some massive rebalancing shortly since the Illians appear to use quite a few rituals, but I like that there will be a counter for them as well (and a tactical decision between using this to stop Mulcarn, or saving it to save your bacon from Curse the Lands). Anyway.... it will set the current production to 0 for all Rituals for both your team and everyone that you are at war with.


Gameoption

New gameoption to cause all unique features to spawn on the map.

 

[MagisterCultuum]

Nice. Now, is there any chance we can get you to focus on improvements, including implementing (the equivalent of) Jeckel's JCultureControl and JImprovementLimit modcomps. Not necessarily the same code, but functionality like having distance requirements between improvements, letting existing improvements on a tile be a prereq for building better ones (might be a good idea to let such improvements be build even over permanent improvements, as the ability to convert one Unique feature to another could be quite nice), letting improvements have specific owners, letting them have cultural borders (this might be good as a game option), letting different civs have unique improvements, maybe letting promotions give build orders, setting maintenance costs for improvements, settling limits on how many of specific improvements may exist, etc?

 

[xienwolf]

Not likely to get me to do much of anything but bug fix and merge for a little while now. Got some other work I need to focus on, so any code that happens is just code that is stuck in my head or relaxing to complete.

And I'd be more likely to create my "Aspects" idea than touch any existing tile data anyway at this point.

 

[Tarquelne]

Good stuff! I'll see if I can remember all the features I wanted to add but couldn't previously.

Or maybe I'll just think up excuses to use the new fields.

Anyway,

 

[MagisterCultuum]

Care to explain more about what these "Aspects" will be?

 

[xienwolf]

Quite simple. Aspects are to Plots what Promotions are to Units and Building are to Cities (and I guess Traits to Players)

 

[MagisterCultuum]

Ok, but what will they do? Change yields, defenses, movement rates? Will they be able to have python calls like improvements and features now can? to spawn units? to deal damage? to effect health and happiness? to be impassible to certain units? to be used as prereqs for units promotions and cities buildings? to effect culture? etc?

 

[xienwolf]

They'll do whatever you want to program them to do. So the short answer would be "Yes"

If you mean to ask what I will initially program them for, primarily defense adjustments, heal rates, yield modifications, attributes to be used as pre-reqs for other things (improvements, features, whatever), Level requirements to enter the tile, targets for modification by spells, and the single most important reason will be to establish AI Weighting values for each individual tile in regards to risk/reward factors. Then you can have units set on automated explore who will not walk right past a lair, but instead move to stand on it, then cancel the automation so you can explore it manually. Elohim explorers who understand they want to visit the Unique Features, Illian Explorers who understand that they do NOT walk right past Letum Frigus, an inborn understanding that there is equipment sitting on a tile waiting to be picked up.... list could go on for a while about the number of things that the Aspects will help to track so that the AI can make informed decisions. And once the framework is there it will be a matter of time till ideas flood in for how to use it all effectively. Hell, might even come up with a Civilization of sapient plants whose entire theme is that their Plots gain XP and cast spells and on occasion they happen to also make use of a "standard unit" to interact with the other civilizations.

 

[Valkrionn]

First off, I really hope you stick with this Aspects idea... At the very least, it would greatly improve exploration, as you wouldn't have to constantly check on your scouts to see if they passed anything by, and would help make the Elohim AI a bit more formidable... Would actually be able to gain the extra traits and other bonuses.

Second, I would totally play the plant race.