. (http://forums.civfanatics.com/showthread.php?t=326259)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) (http://grahamcox.co.uk/ffh/xienwolf/051%20Base%20CvGameCoreDLL.zip)

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


CIV4PromotionInfos.xml

<iWorkRateChange> - Can increase/decrease the Workrate of a Unit. At this point the Unit still needs to have Build Orders available through UnitInfos though.
<bRivalTerritoryExplore> - Can enter other Civilization's Territory without Open Borders.
<bRivalTerritoryBlock> - Cannot enter any non-Team Territory, even with War or Open Borders.
<bPillageOnMove> - The unit will automatically Pillage any Improvements (but not Roads) that it crosses in Enemy (at war) territory.
<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.
<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)
<bNonWarWeariness> - Loss of Unit does not cause War Weariness.
<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)
<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...)
<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.
<bCityHappy> - Unit may provide Military Happiness.
<bCityNoHappy> - Unit can no longer provide Military Happiness.
<bCanPillage> - Allows a Unit to Pillage
<bCannotPillage> - Removes the Ability to Pillage
<bCitySpy> - When in a Rival City, allows you to see their Production and get City Detail Zoom
<bNoSupport> - The Unit will no longer cost Military Support
<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.
<bNoDefenseBonus> - Unit is unable to gain Bonuses for Defense (neither terrain bonuses nor Fortification)
<bAllowDefenseBonuses> - Unit is able to gain Defensive Bonuses and may Fortify. <bNoDefenseBonus> takes precedence if both fields exist on a unit.
<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.
<bFlatMoveCost> - Spends 1 :move: per Tile Traveled, regardless of Terrain Type or Roads
<bIgnoreTerrainCosts> - Can still use Roads, but otherwise spends 1 :move: per Tile Traveled
<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.
<bAllowAttacks> - Enables the ability to attack for Units not normally able to do so.
<bFirstStrikeVulnerable> - Removes Immunity to First Strikes
<bIndependant> - Unit does not count toward the National or Team Limits.
<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).
<iCombatExtraDuration> - Bonus Number of Turns to Duration from Combat. Can be Negative as well, with fun results.
<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.
<iDurationAlter> - Modifies the Duration of a Unit like iChangeDuration, but only if it already has a Duration to begin with.
<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.

<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)
<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.
<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
<iChanceMiscast> - Modification to the Miscast Chances via Promotion. Positive and Negative values are both allowed.
<bRequireCity> - The Promotion can only be acquired while in a City
<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
<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!

<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)
<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.
<bNoXP> - The Promotion will not require XP to gain, the Unit will not gain a Level, nor Heal, upon selecting to take the promotion
<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()

<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

bApplyEnemy - This City Bonus list will apply to Enemy Cities
bApplyRival - This City Bonus list will apply to Rival Cities
bApplySelf - This Bonus list applies to your own Cities
bApplyTeam - This bonus list applies to your teamates' cities (but not your own, must set previous tag for that)
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
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
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
fDefense - Adjusts the Defense Bonus of the City Tile
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
fFood - Modifies the food gained each turn in the city
fFreeXP - Modifies free XP granted to all Units built in the City
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
fGPP - Adds/removes untyped GPP to the Cities pool
fHappy - Modifies the number of Happiness/Anger in the City
fHealth - Modifies the number of Health/Disease in the City
fProduction - Modifies Cities Production per turn
fTradeRoutes - Changes the Number of Trade Routes the City has Available
fTrainXPCap - Modifies the Training XP Cap for the unit's own unitcombat in city
fTrainXPRate - Modifies the Training XP Rate for the Unit's own Unitcombat in City
fPotency - Modifies the City's Potency Value
fShielding - Modifies the City's Shielding Value
fRitualAssist - Modifies the City's Production if the current production target is a ritual
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)
fDecayRate - Modification to all nonzero values listed in this Bonus List for every tile between the unit and the City being affected

<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)
<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)
<PrereqUnits> - Multiple entries allowed list of Unit Types required to gain a promotion
<PrereqReligions> - Multiple entries allowed list of Religion Types required to gain a promotion
<PrereqCivilizations> - Multiple entries allowed list of Civilization Types required to gain a promotion
<PrereqCivicORs> - Multiple entries allowed list of Civic Types required to gain a promotion
<PrereqTechANDs> - Multiple entries allowed list of Tech Types required to gain a promotion, all are required
<PrereqTechORs> - Multiple entries allowed list of Tech Types required to gain a promotion, at least one from the list is required
<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
<PrereqTier> - Tier required to gain a promotion
<PrereqWeaponTier> - Weapon Tier required to gain a promotion, value must be in the range defined by iWeaponTierMax & iWeaponTierMin on the UnitInfo
<PrereqTerrains> - Multiple entries allowed list of Terrain Types required on TIle to gain a promotion
<PrereqImprovements> - Multiple entries allowed list of Improvement Types required on Tile to gain a promotion
<PrereqFeatures> - Multiple entries allowed list of Feature Types required on Tile to gain a promotion
<PrereqCorporations> - Multiple entries allowed list of Corporation Types required to gain a promotion (have that Guild in any city)
<PrereqBuildingANDs> - Multiple entries allowed list of Building Types required to gain a promotion, all are required in current City
<PrereqBuildingORs> - Multiple entries allowed list of Building Types required to gain a promotion, at least one from the list is required in current City
<PrereqBonusANDs> - Multiple entries allowed list of Bonus Types required to gain a promotion, all are required
<PrereqBonusORs> - Multiple entries allowed list of Bonus Types required to gain a promotion, at least one from the list is required
<PrereqTraits> - Multiple entries allowed list of Trait Types required to gain a promotion
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


<PrereqEventANDs> - Multiple entries allowed list of Event Types required to gain a promotion, all are required
<PrereqEventORs> - Multiple entries allowed list of Event Types required to gain a promotion, at least one from the list is required
<PrereqFeatANDs> - Multiple entries allowed list of Feat Types required to gain a promotion, all are required
<PrereqFeatORs> - Multiple entries allowed list of Feat Types required to gain a promotion, at least one from the list is required
<PrereqFeatNOTs> - Multiple entries allowed list of Feat Types required UNCOPLETE to gain a promotion, all entries must be uncomplete
<iExtraDropRange> - Grants the Unit a Paradrop Range (Personal Teleporting capability), or adds to an already existing range.
<iAirCombatLimitBoost> - Enhances (or reduces if negative) the Air Combat Limit of the Unit.
<iAirCombat> - Grants the unit an AirCombat value so they can make ranged attacks
<PrereqbAllowNULLUnitCombat> - Allows authorization of the promotion to units which do not have a unitcombat
<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.
<SeeInvisible> - Same as format above but now for See Invisible capabilities.
<PromotionDegradesTo> - Gain all Listed Promotions if this promotion is lost
<PromotionExcludes> - Blocks the ability to gain all listed promotions (essentially replaces PromotionImmune1-3 with an unlimited length list)
<PromotionOverwrites> - Removes the listed promotion if already present on the unit (replaces the extra bit I added to PromotionImmune1-3 a while back)
<PromotionReplacedBy> - Removes THIS promotion if any of the listed promotions are gained
<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
<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

<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)
<fCasterXPRate> - Modifies the Rate for gaining passive XP through Training/CasterXP system
<fFreeXPCap> - Sets the cap to which FreeXP will continue to accumulate
<PrereqPermission> - Indicates that the unit must have permission granted through PromotionAllows (PromotionInfos) or AllowPromotions (UnitInfos) to take the promotion
<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.
<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)
<iAsset> & <iPower> - Same as the fields in UnitInfos. Used for AI control and judgement primarily
<bOverrideHelpText> - Blocks all automatically generated text output for the promotion and only shows the text key listed in <Help></Help>
<iPromotionRandomApplyChance> - Controls the probability of the promotion listed in PromotionRandomApply (Fair Winds, Enraged) being applied each turn
<iPromotionRandomApplyChance> - Percent Chance per turn that the promotion listed in RandomApply will actually be applied
<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
<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)
<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.
<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.
<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
<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.
<iCommandRange> - This modifies the range at which the Commander and the Minion apply promotions to each other.
<iCommandXPShareRate> - This modifies the XP gained by the Commander from his Minion's when they get XP in combat



CIV4UnitInfos.xml

<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
<PyPerTurn> - Python function run for the unit at the start of every turn
<YieldsFromKill> & <CommercesFromKill> - Yield and Commerce bonus granted to the nearest city of the player who kills this unit
<iWeaponTierMax> & <iWeaponTierMin> - Replaces <iWeaponTier> so that a range can be defined and multiple WeaponTiers created more easily
<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.
<Quote> & <Quotes> - Matches up with <Image> and <Images> fields to provide a quote for the unit pop-ups
<Images> - Matches up with <UniqueNames> field to provide Images for each Uniquename option for pop-ups
<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>
<DenyPromotions> - Unit is capable of having any promotion listed in these fields (Would be useful on the Flesh Golems for instance)
<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.
<iCommandLimit> - This modifies how many units the Commander is able to have attached to him.
<iCommandRange> - This modifies the range at which the Commander and the Minion apply promotions to each other.
<iCommandXPShareRate> - This modifies the XP gained by the Commander from his Minion's when they get XP in combat

Custom Work
(continued)

CIV4ProjectInfos.xml

<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
<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
<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
<bPrereqWar> - Requires that you are in an active War to start the Ritual
<iBlockBonuses> - Causes all Bonuses to become Obsolete for anyone whom you are currently at war with
<iRestoreBonuses> - Decreases the level of BlockBonuses affecting your team
<bPrereqBlockBonuses> - Requires that you have a non-zero BlockBonus Count to start the Ritual
<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)
<bResetProjects> - Clears all Production on Projects for both your Team and all Teams you are at War with.
<bResistable> - Indicates that the Project can be resisted on a per-city basis
<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
<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



CIV4BuildingClassInfos.xml
<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)



CIV4UnitClassInfos.xml
<bUnique> - Same as for BuildingInfos, just used a LOT more



CIV4EmphasizeInfos.xml
<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)
<bAvoidUnhealthyCitizens> - Sets the city to avoid producing any Disease (stops growth the turn before population growth if that growth would cause a disease excess)



CIV4CivilizationInfos.xml
<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.
<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)
<FeatureYieldChanges> - Modifier to the Yield value of a feautre for this Civ, applies to all tiles in their cultural control
<ImprovementYieldChanges/> - Modifiers to the yield values of an improvement for this civ, applies to all improvements in their cultural control
<TerrainYieldChanges/> - Modifier to the base terrain value of any tile in this Civ's cultural control



CIV4VictoryInfos.xml
<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)




CIV4GameSpeedInfos.xml
<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




CIV4ImprovementInfos.xml
<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
<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)
<iSpawnPerGameLimit> - Improvement is unable to spawn more than this many units per game. If the improvement is removed and rebuilt, the counter starts over
<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)
<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)
<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)
<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.




CIV4TechInfos.xml
<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
<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
<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.
<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.




CIV4HandicapInfos.xml
<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
<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)
<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)
<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
<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...)
<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.
<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
<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.




CIV4BuildingInfos.xml
<iPotency> & <iGlobalPotency> - Enhances the strength of rituals completed in the city (or all cities)
<PotencyAffinities> & <GlobalPotencyAffinities> - Array of Bonuses which enhance the Potency by float values per Bonus owned
<PotencyBonusPrereqs> & <GlobalPotencyBonusPrereqs> - Array of Bonuses which offer enhanced Potency by integer value if any of the bonus is owned
<iShielding> & <iGlobalShielding> - Enhances the defenses against enemy rituals for the City (or all cities)
<ShieldingAffinities> & <GlobalShieldingAffinities> - Array of Bonuses which enhance the Shielding by float values per Bonus owned
<ShieldingBonusPrereqs> & <GlobalShieldingBonusPrereqs> - Array of Bonuses which offer enhanced Shielding by integer value if any of the bonus is owned
<TrainXPCaps> & <GlobalTrainXPCaps> - Array of Unitcombats that the city (or all cities) can offer a float cap for free Training XP
<TrainXPRates> & <GlobalTrainXPRates> - Array of Unitcombats that the city (or all cities) can offer a float Training XP rate enhancement
<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)
<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.



CIV4LeaderHeadInfos.xml
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)
<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




CIV4SpellInfos.xml
<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.
<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.
<Quote> - Specifies the text displayed in the pop-up for Global Spells (Image used is the LeaderHead image)
<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
<PrereqIsMinion> - Spell can only be cast if the unit has a Commander Unit it is attached to
<PrereqIsNOTMinion> - Spell can only be cast if the unit has no Commander Unit it is attached to
<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.
<PrereqNotAttacked> - Requires that the unit hasn't been flagged as HasAttacked yet to be allowed to cast the spell
<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
<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



CIV4GoodyInfos.xml
<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.
<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
<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)
<iMinTurnsElapsed> & <iMaxTurnsElapsed> - Earliest and Latest in the course of a game that the goody can be granted. Weighted by gamespeed




CIV4TraitInfos.xml
<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.




CIV4FeatInfos.xml
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)




CIV4BuildInfos.xml
<TechBuildDiscounts> - Array of Technologies. Grants a discount to the iTime value for the build process based on technologies of the tile's owner




CIV4TerrainInfos.xml
<CivilizationYieldType> - **REMOVED FIELD** Replaced with function handling in CivilizationInfos file instead




CIV4ReligionInfos.xml
<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).



CIV4CorporationInfos.xml
<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).



CIV4GameOptionInfos.xml
GAMEOPTION_RELIGIOUS_HUD - Enables new Interface designs based on current Religion instead of the standard FfH interface all game long.
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.
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.
GAMEOPTION_FLAVOUR_START - Grants each Civilization a weighting value to gain a start location which matches their lore/preferences.
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...)
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)
GAMEOPTION_ENABLE_COMBAT_LOG - Enables the Combat Log regardless of the Callback settings
GAMEOPTION_NO_ANIMALS & GAMEOPTION_NO_DEMONS - Remove the Animal or Demon Barbarian Civ from the game
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)



CIV4MPOptionInfos.xml
MPOPTION_RANDOM_LOGGER - On by default, will write a log file containing every random number the game calls for in the standard logs directory.



GlobalDefinesAlt.xml
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.
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.
BROADER_POPRUSH_BASE_MODIFIER & BROADER_POPRUSH_MODIFIER - Base Alignment Shift, and Alignment Shift from each point of population lost by rushing production
BROADER_RAZE_BASE_MODIFIER & BROADER_RAZE_MODIFIER - Base Alignment Shift, and Alignment Shift per Population Point for razing a City.
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
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
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
MISCAST_PROMOTION - Identifies the promotion applied to a unit when they miscast a spell. Promotion will have a random duration assigned to it
BASE_MISCAST_DURATION - Control variable for Miscast applied promotion duration
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.
ORC/DEMON/ANIMAL _ CIVILIZATION/LEADER - Informed the DLL which Civilization and Leader to assign for the Barbarian Civilizations.
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! :p)
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 :(
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.
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




CIV4StateNameInfos.xml(New File)
<iMinNumCities> - Number of cities required to gain the statename
<iMaxNumCities> - Limit of number of cities owned for name to be valid
<bNoMinor> - Prevents Minor Civilizations from having the statename
<bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
<PrereqCivics> - Civics required active to gain the statename
<PrereqAlignments> - Alignment required for the name to be valid
<PrereqCivilization> - Civilization for which the name is valid
<PrereqReligion> - Religion required to gain the name
<iMinNumCitiesConquered> - Must conquer this many Cities to gain the name
<iMinNumVassals> - Must currently have this many vassal Civs to have the name
<bFullCiv> - For future use with Revolutions functionality and Minor Civs
<bMinorCiv> - For future use with Revolutions functionality and Minor Civs
<bSovereign> - Must be non-vassalized
<bVassal> - Must be vassalized
<bColony> - Must have been set free as a colony from another Civ
<bFemaleLeader> - Need to be a female leader
<PrereqLeader> - Restricted to a single leader
<bNoMinor> - For future use with Revolutions functionality and Minor Civs
<bNoVassal> - Must not have any vassals currently under you to have this name





Python/DLL Only
New Widget Type defined for Tooltips on Armageddon Counter and for Tooltips+Action on Slave/Master buttons
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)
CyUnit::setDisablePyDeath(bool). Disables/Enables the <PythonOnDeath> field of a unit
CyGame::getNumCivActive(eCiv) - Tells you how many currently living players are using this Civ
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)

Modifications Borrowed from Other Users:

Dom Pedro's Food from Animals (http://forums.civfanatics.com/showthread.php?t=238278) 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.
Grey Fox's Broader Alignments (With modifications by Vehem) (http://forums.civfanatics.com/showthread.php?t=270553) - 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
Modifications to Heal and Move_To actions based on Pep's work (http://forums.civfanatics.com/showthread.php?t=298512) 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
WoCLite (http://forums.civfanatics.com/showthread.php?t=317432) - 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


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
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.
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.
AI will split stacks when a unit becomes immobile
Combat Strength, Workrate, and Movement Rate cannot be negative
Nox Noctis units can be seen, their invisibility type is set in Global Defines
Units that upgrade are not reduced in XP
Removed the "Your Units are Under Attack" message, since the "You have been killed" or "You have killed" do quite well enough
AI units which are Immortal will use an aggressive AI type
Temporary Units will not gain free XP
Summons are Linked to their Summoner
Guardsman promotion will always be selected as a defender against Marksman promotion
Improvements will display a required Tech to connect the resource to the city until that tech is gained
Barbarians and Animals spawn all game long, Barbarians start spawning based on Difficulty setting (BarbarianCreationTurnsElapsed) and Gamespeed (BarbPercent)
Religions are adopted by units without a default religion on a more level playing field, with preference toward State Religion
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)
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.
Workers/Hawks no longer defend against Marksman units
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
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
City Art Styles are maintained based on the City Civilization type
Hidden Nationality Units can be grouped
Enraged Units leave their group at the onset of AIControl
Enraged units have a much more aggressive AI setup, and are forbidden to perform most non-aggressive actions
Enraged affects AI and an Enraged unit cannot be selected by a human
Units will not Suicide trying to attack things you couldn't see when giving an order to move beyond your visible range
Units will "wake up" when healing if they are the strongest defender on the tile and danger approaches
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++ (http://notepad-plus.sourceforge.net/uk/site.htm)
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...

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 (http://forums.civfanatics.com/showthread.php?t=328253) 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 ;)

Reserved for Past Use. :p

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?)

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...

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.

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.

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?

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)

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.

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?

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.

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,
:thumbsup:

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

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

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?

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.

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. :lol:

I really, really like the Aspect idea. Lots of stuff I'm planning on adding to the post FFH .34 FF version of the Legion is going to be terrain/plot based.

Yeah, seems like it would help with most of your unique terrains and improvements.

It kinda makes me wonder if features, improvements, and bonuses might be better if they were changed to just being aspects.

I don't know about that.... Seems to me like Aspects would be used for bonus things, like Ring of Stone, maybe some unique terrains only certain civs are allowed to have. Could possibly make it simpler to revert Deep Jungle to Jungle when the Lizards lose the terrain, or could provide the bonuses for the Scion's Haunted Lands without making the empire look completely homogenous..... Actually, think I'm gonna post that particular idea over on the Scion's thread, maybe get Tarq to pressure Xienwolf into implementing it. ;)

Features/Improvements/Resources give a graphic. That is why they are limited to 1 per tile. There are some things which each try to accomplish which do not NEED a graphic which can be aspects, but they cannot all be changed to be Aspects

Aspects could also help with the events that give extra yields (positive or negative) as well, if I'm thinking right. That way a lot of them could be reversible or temporary.

I'm thinking it could be good to add a promotion tag (which would typically be used with bAutoAcquire and bMustMaintain) that requires you be at war. A similar requirement for units and buildings could be good too.

I just had a crazy thought: would it be possible to allow promotions to change the unitcombat of units that have it without having to actually change it to a different unit? How about changing domains?


Also, how hard would it be to allow units to have multiple unitcombats? There are a lot of cases where having arcane/disciple, melee/disciple, recon/disciple, mounted/disciple, mounted/archer, and melee/mounted would make sense.

You can change absolutely any data on a unit with a promotion, it is the entire purpose behind having them.

Hey guys, i have an issue in the warhammer mod regarding the wetlands terrain and deep jungle... and im hoping that someone here can help us figure out a fix...

i sent this to Cephalo, but just figured id ask here as well.


...

i am having some crazy map bugs in the Warhammer mod which im working on and i havent a clue whats causing them or how to fix them.

i should point out i havent touched the terrain files, though i did fiddle with improvementinfo and featureinfo files a little, but the changes i mad worked fine (added some unique feature improvements and changed feature bonuses). then i moved a couple of techs around and changed the forest chopping tech, and all of a sudden im getting enourmous tracts of the 'Marsh' Terrain, as well as small spots of 'wetland' (including wetland hills) and Deep Jungle (wetland and deep jungle are taken from the Fall Further mod).

so basically im lost for thoughts and im begging you if you would take a look at my files and see if you can fix this mess for me?

thanks mate



so any thoughts?

Btw, patch O removed the crashing with modular loading. Well, either that or the full reinstall I did...

Icky... I just walked into the proverbial lion's den.


While I was working on something else, I noticed that the CurrentEra is used by the code to decide on a ton of things, most just for how the AI acts, because it assumes that the game has advanced to a certain degree (thus may be over soon, or is beyond the "exploring" phase.


Anyway... some tidbits of where the code goes horribly wrong, and makes the AI do funny things based on what religion they are following (I am curious if the religions are linked to Eras in an order which makes these work halfway decent)

Decides on GPP Actions

void CvUnitAI::AI_scientistMove()
{PROFILE_FUNC();
if (AI_discover(true, true))
return;
if (AI_construct(MAX_INT, 1))
return;
if (GET_PLAYER(getOwnerINLINE()).getCurrentEra() < 3)
if (AI_join(2))
return;
if (GET_PLAYER(getOwnerINLINE()).getCurrentEra() <= (GC.getNumEraInfos() / 2))
if (AI_construct())
return;
int iGoldenAgeValue = (GET_PLAYER(getOwnerINLINE()).AI_calculateGoldenAg eValue() / (GET_PLAYER(getOwnerINLINE()).unitsRequiredForGold enAge()));
int iDiscoverValue = std::max(1, getDiscoverResearch(NO_TECH));
if (((iGoldenAgeValue * 100) / iDiscoverValue) > 60)
{if (AI_goldenAge())
return;
if (iDiscoverValue > iGoldenAgeValue)
{if (AI_discover())
return;
if (GET_PLAYER(getOwnerINLINE()).getUnitClassCount(ge tUnitClassType()) > 1)
if (AI_join())
return;}}
else
{if (AI_discover())
return;
if (AI_join())
return;}
if ((GET_PLAYER(getOwnerINLINE()).AI_getPlotDanger(pl ot(), 2) > 0) || (getGameTurnCreated() < (GC.getGameINLINE().getGameTurn() - 25)))
if (AI_discover())
return;
if (AI_retreatToCity())
return;
if (AI_safety())
return;
getGroup()->pushMission(MISSION_SKIP);
return;}

Unit Artstyles & Unit Sounds (Cosmetic, and worked around by defining all of them to be the same, though if seZ ever gets bored he could redesign every unit to have Good/Neutral/Evil appearances)
Modifies AI Unit Upgrade Costs (based on Handicap settings, so possibly fixed already)

int CvUnit::upgradePrice(UnitTypes eUnit) const
{int iPrice;
CyArgsList argsList;
argsList.add(getOwnerINLINE());
argsList.add(getID());
argsList.add((int) eUnit);
long lResult=0;
gDLL->getPythonIFace()->callFunction(PYGameModule, "getUpgradePriceOverride", argsList.makeFunctionArgs(), &lResult);
if (lResult >= 0)
return lResult;
if (isBarbarian())
return 0;
iPrice = GC.getDefineINT("BASE_UNIT_UPGRADE_COST");
iPrice += (std::max(0, (GET_PLAYER(getOwnerINLINE()).getProductionNeeded( eUnit) - GET_PLAYER(getOwnerINLINE()).getProductionNeeded(g etUnitType()))) * GC.getDefineINT("UNIT_UPGRADE_COST_PER_PRODUCTION"));

if (!isHuman() && !isBarbarian())
{iPrice *= GC.getHandicapInfo(GC.getGameINLINE().getHandicapT ype()).getAIUnitUpgradePercent();
iPrice /= 100;
iPrice *= std::max(0, ((GC.getHandicapInfo(GC.getGameINLINE().getHandica pType()).getAIPerEraModifier() * GET_PLAYER(getOwnerINLINE()).getCurrentEra()) + 100));
iPrice /= 100;}
iPrice -= (iPrice * getUpgradeDiscount()) / 100;
//FfH Traits: Added by Kael 08/02/2007
iPrice += (iPrice * GET_PLAYER(getOwnerINLINE()).getUpgradeCostModifie r()) / 100;
CvCity* pCity = getUpgradeCity(eUnit, true);
if (pCity != NULL)
iPrice += (iPrice * pCity->getUpgradeCostModifier()) / 100;
//FfH: End Add
return iPrice;}

Opinion of Enemy Force Strength

void CvPlayerAI::AI_doEnemyUnitData()
{std::vector<int> aiUnitCounts(GC.getNumUnitInfos(), 0);
std::vector<int> aiDomainSums(NUM_DOMAIN_TYPES, 0);
CLLNode<IDInfo>* pUnitNode;
CvUnit* pLoopUnit;
int iI;
int iOldTotal = 0;
int iNewTotal = 0;
for (iI = 0; iI < GC.getMapINLINE().numPlotsINLINE(); iI++)
{CvPlot* pLoopPlot = GC.getMapINLINE().plotByIndexINLINE(iI);
int iAdjacentAttackers = -1;
if (pLoopPlot->isVisible(getTeam(), false))
{pUnitNode = pLoopPlot->headUnitNode();
while (pUnitNode != NULL)
{pLoopUnit = ::getUnit(pUnitNode->m_data);
pUnitNode = pLoopPlot->nextUnitNode(pUnitNode);
if (pLoopUnit->canFight())
{int iUnitValue = 1;
if (atWar(getTeam(), pLoopUnit->getTeam()))
{iUnitValue += 10;
if ((pLoopPlot->getOwnerINLINE() == getID()))
iUnitValue += 15;
else if (atWar(getTeam(), pLoopPlot->getTeam()))
{if (iAdjacentAttackers == -1)
iAdjacentAttackers = GET_PLAYER(pLoopPlot->getOwnerINLINE()).AI_adjacentPotentialAttackers(pL oopPlot);
if (iAdjacentAttackers > 0)
iUnitValue += 15;}}
else if (pLoopUnit->getOwnerINLINE() != getID())
{iUnitValue += pLoopUnit->canAttack() ? 4 : 1;
if (pLoopPlot->getCulture(getID()) > 0)
iUnitValue += pLoopUnit->canAttack() ? 4 : 1;}
if (m_aiUnitClassWeights[pLoopUnit->getUnitClassType()] == 0)
iUnitValue *= 4;
iUnitValue *= pLoopUnit->baseCombatStr();
aiUnitCounts[pLoopUnit->getUnitType()] += iUnitValue;
aiDomainSums[pLoopUnit->getDomainType()] += iUnitValue;
iNewTotal += iUnitValue;}}}}
if (iNewTotal == 0)
return;
//Decay
for (iI = 0; iI < GC.getNumUnitClassInfos(); iI++)
{m_aiUnitClassWeights[iI] -= 100;
m_aiUnitClassWeights[iI] *= 3;
m_aiUnitClassWeights[iI] /= 4;
m_aiUnitClassWeights[iI] = std::max(0, m_aiUnitClassWeights[iI]);}
for (iI = 0; iI < GC.getNumUnitInfos(); iI++)
{if (aiUnitCounts[iI] > 0)
{UnitTypes eLoopUnit = (UnitTypes)iI;
TechTypes eTech = (TechTypes)GC.getUnitInfo((UnitTypes)iI).getPrereq AndTech();
int iEraDiff = (eTech == NO_TECH) ? 4 : std::min(4, getCurrentEra() - GC.getTechInfo(eTech).getEra());
if (iEraDiff > 1)
{iEraDiff -= 1;
aiUnitCounts[iI] *= 3 - iEraDiff;
aiUnitCounts[iI] /= 3;}
FAssert(aiDomainSums[GC.getUnitInfo(eLoopUnit).getDomainType()] > 0);
m_aiUnitClassWeights[GC.getUnitInfo(eLoopUnit).getUnitClassType()] += (5000 * aiUnitCounts[iI]) / std::max(1, aiDomainSums[GC.getUnitInfo(eLoopUnit).getDomainType()]);}}
for (iI = 0; iI < GC.getNumUnitCombatInfos(); ++iI)
m_aiUnitCombatWeights[iI] = 0;
for (iI = 0; iI < GC.getNumUnitClassInfos(); iI++)
if (m_aiUnitClassWeights[iI] > 0)
{UnitTypes eUnit = (UnitTypes)GC.getUnitClassInfo((UnitClassTypes)iI) .getDefaultUnitIndex();
m_aiUnitCombatWeights[GC.getUnitInfo(eUnit).getUnitCombatType()] += m_aiUnitClassWeights[iI];}
for (iI = 0; iI < GC.getNumUnitCombatInfos(); iI++)
{if (m_aiUnitCombatWeights[iI] > 25)
{m_aiUnitCombatWeights[iI] += 2500;}
else if (m_aiUnitCombatWeights[iI] > 0)
m_aiUnitCombatWeights[iI] += 1000;}}

Advanced Start Explore Unit preferences, Tech selection, City Size preference (though during Advanced Start your era won't change, so that's fine)

Reaction to Raging Barbarians being active

int CvPlayerAI::AI_getTotalFloatingDefendersNeeded(CvA rea* pArea)
{PROFILE_FUNC();
int iDefenders;
int iCurrentEra = getCurrentEra();
int iAreaCities = pArea->getCitiesPerPlayer(getID());
iCurrentEra = std::max(0, iCurrentEra - GC.getGame().getStartEra() / 2);
iDefenders = 1 + ((iCurrentEra + ((GC.getGameINLINE().getMaxCityElimination() > 0) ? 3 : 2)) * iAreaCities);
iDefenders /= 3;
iDefenders += pArea->getPopulationPerPlayer(getID()) / 7;
if (pArea->getAreaAIType(getTeam()) == AREAAI_DEFENSIVE)
iDefenders *= 2;
else if ((pArea->getAreaAIType(getTeam()) == AREAAI_OFFENSIVE) || (pArea->getAreaAIType(getTeam()) == AREAAI_MASSING))
{iDefenders *= 2;
iDefenders /= 3;}
if (AI_getTotalAreaCityThreat(pArea) == 0)
iDefenders /= 2;
if (!GC.getGameINLINE().isOption(GAMEOPTION_AGGRESSIV E_AI))
{iDefenders *= 2;
iDefenders /= 3;}
if (AI_isDoStrategy(AI_STRATEGY_GET_BETTER_UNITS) && (pArea->getAreaAIType(getTeam()) != AREAAI_DEFENSIVE))
iDefenders /= 2;

if (AI_isDoStrategy(AI_STRATEGY_CULTURE3))
{iDefenders += 2 * iAreaCities;
if (pArea->getAreaAIType(getTeam()) == AREAAI_DEFENSIVE)
iDefenders *= 2; //go crazy}
iDefenders *= 60;
iDefenders /= std::max(30, (GC.getHandicapInfo(GC.getGameINLINE().getHandicap Type()).getAITrainPercent() - 20));
if ((iCurrentEra < 3) && (GC.getGameINLINE().isOption(GAMEOPTION_RAGING_BAR BARIANS)))
iDefenders += 2;
if (getCapitalCity() != NULL)
if (getCapitalCity()->area() != pArea)
iDefenders = std::min(iDefenders, iAreaCities * iAreaCities - 1); ///Note: Bad for the Lanun here.
return iDefenders;}

Notice at the end of the last section that the AI naturally despises bothering to defend any city that is not on the same landmass as the capital....

desire for a Cultural Victory

int CvPlayerAI::AI_getCultureVictoryStage()
{int iValue;
if (!GC.getGameINLINE().culturalVictoryValid())
return 0;
if (getCapitalCity() == NULL)
return 0;
if (getCapitalCity()->getGameTurnFounded() > (10 + GC.getGameINLINE().getStartTurn()))
return 0;
if (GC.getGame().getStartEra() > 1)
return 0;
iValue = 0;
if (GC.getGameINLINE().isOption(GAMEOPTION_ALWAYS_PEA CE))
iValue += 4;
for (int iI = 0; iI < GC.getNumTraitInfos(); iI++)
if (hasTrait((TraitTypes)iI))
{iValue += ((GC.getTraitInfo((TraitTypes)iI).getMaxAnarchy() == 0) ? 4 : 0);
iValue += (GC.getTraitInfo((TraitTypes)iI).getCommerceChange (COMMERCE_CULTURE) * 2);
iValue += (GC.getTraitInfo((TraitTypes)iI).getCommerceModifi er(COMMERCE_CULTURE) / 6);
iValue += (GC.getTraitInfo((TraitTypes)iI).getGreatPeopleRat eModifier() / 25);
iValue += (GC.getTraitInfo((TraitTypes)iI).getExtraYieldThre shold(YIELD_COMMERCE)) * 2 * GC.getDefineINT("EXTRA_YIELD");
iValue += (GC.getTraitInfo((TraitTypes)iI).getTradeYieldModi fier(YIELD_COMMERCE)) / 25;
iValue += ((GC.getTraitInfo((TraitTypes)iI).getMaxGlobalBuil dingProductionModifier() / 25));}
iValue += (GC.getGameINLINE().isOption(GAMEOPTION_AGGRESSIVE _AI) ? -3 : 0);
CivicTypes eCivic = (CivicTypes)GC.getLeaderHeadInfo(getPersonalityTyp e()).getFavoriteCivic();
if ((eCivic != NO_CIVIC) && (GC.getCivicInfo(eCivic).isNoNonStateReligionSprea d()))
iValue -= 3;
iValue += countHolyCities();
if ((GET_TEAM(getTeam()).isAVassal()) && (getNumCities() > 5))
{int iReligionCount = countTotalHasReligion();
if (((iReligionCount * 100) / getNumCities()) > 250)
{iValue += 1;
iValue += ((2 * iReligionCount) + 1) / getNumCities();}}
int iNonsense = 0;
iNonsense += getCapitalCity()->getX();
iNonsense += getCapitalCity()->getY();
iValue += (iNonsense % 7);
if (iValue < 10)
return 0;
if (getCurrentEra() >= (GC.getNumEraInfos() - (2 + iNonsense % 2)))
if (countTotalHasReligion() >= getNumCities() * 3)
return 3;
int iHighCultureCount = 0;
int iLoop;
CvCity* pLoopCity;
for (pLoopCity = firstCity(&iLoop); pLoopCity != NULL; pLoopCity = nextCity(&iLoop))
{if (pLoopCity->getBaseCommerceRate(COMMERCE_CULTURE) > 100)
iHighCultureCount++;
else if (pLoopCity->getCultureLevel() >= (GC.getGameINLINE().culturalVictoryCultureLevel() - 1))
iHighCultureCount++;}
if (iHighCultureCount >= GC.getGameINLINE().culturalVictoryNumCultureCities ())
return 3;
}
if (getCurrentEra() >= ((GC.getNumEraInfos() / 3) + iNonsense % 2))
return 2;
else
return 1;
FAssert(false);}




Anyway... the list goes on a bit longer. This was just the point where I ran out of time to look over everything. And there had been an item or 2 I didn't fully understand yet because it was too short to establish context (something about AI birthmarks and Stacks of Doom...)



So one of these days I have to get in there and clean all of this junk out, that is if xanaqui hasn't already gotten to it by then :) Or Kael, he cleaned up quite a few references to Era when he reworked the Strategy Hash logic.

I'd really like the ability to make promotions give combat bonuses based on the plot counter. (you know, the thing that controls hell terrain).

I'd also like the ability for promotions to (have a chance to) increase or decrease the plot counter of the unit's plot. I implemented the effect with a PyPerPurn call for several promotions in my version, but I'm thinking that as often as I used it it would be a lot better if it were handled in the dll.

Having plot counter requirements for entering tiles could be cool too, as it would be easier for me to limit upper level demons to corrupted terrains with such a tag instead of needing to make every non-hell terrain and feature impassible for these units.



Oh, I'm still waiting for my old request of letting promotions give combat bonuses based on the percent of your teams culture in the tile.

Ya know, if you released something I would be far more inclined to work on simple tweaks and changes which you have plans for, or if Vehem and I do not think it belongs in FF I would at least help walk you through how to code it so you can get a feel for how to handle some of your crazier ideas on your own.


Right now though, I am working on quite a few things which are quite possibly impossible, and have a 1 kB .txt file of other ideas for future development which need sorted before I go off on wild tangents.

EDIT: Ok, so I misremembered, it is actually 31 KB. I coulda sworn that 1 KB used to be "large" for raw .txt files

Ya know, if you released something I would be far more inclined to work on simple tweaks and changes which you have plans for, or if Vehem and I do not think it belongs in FF I would at least help walk you through how to code it so you can get a feel for how to handle some of your crazier ideas on your own.


Right now though, I am working on quite a few things which are quite possibly impossible, and have a 1 kB .txt file of other ideas for future development which need sorted before I go off on wild tangents.

Jesus. Got enough there for a few more major releases lol.

I'd like promotions with cheese, pickle, mustard and onion.

What? No tomatoes?

Ick, don't like tomatoes, myself. :)

That said, if I had any personal wishes for new features, it would definitely be to allow promotions to have a duration. More importantly, for promotions to be able to be GIVEN a duration, like units can. So that you could, for example, ~temporarily~ teach a unit a spell. Or have a spell that grants a few turns of March to every unit in the stack. Currently all of this can be done by adding new, duplicate promotions with a chance of wearing off, but it seems like some way to have limited duration promotions would be a lot cleaner. Plus having promotions that last a predictable amount of time could be useful in other ways, too.

That one is buried in the design document somewhere. Simple to code, just haven't thought of anything cool to do with it, so the idea quickly fell into the long list of "sometime soon" land. Same with duration on buildings actually.

EDIT: Though I did just think of a REALLY fun thing you can do with the functionality that is required to have promotions with duration :) You could have Entropy 3 be replaced with "Feeble Minded," a spell which causes all units in range to lose any promotion they have had for more than 50 turns :D Way powerful/fun idea, might even be enough to bump the duration thing up to the top of the docs (at least for a little while)

That would be amazing... Would be worth getting entropy mana, if just to go Hero hunting.

Yes, but a smart Hero would have invested in some Magical Immunity promotions :)

That would actually be a ridiculously powerful spell. And would need a rather large amount of limitations, to prevent it from stripping races, equipment, and other such promotions that shouldn't be lost.

Plus it would really suck to have your hero just suddenly "unmanned". XD

Now I would REALLY love for there to be a way to make a unit temporarily ~lose~ promotions. I have been trying forever, for example, to find a way to code a spell that causes all casters in the radius to temporarily lose 50% of their spell promotions. But I imagine that one would be a hell of a lot harder to manage.

Is it possible to have (or add) NOT requirements on spells? If so, you could do that by having a blocking promotion for each sphere and making all its spells require, say Death II and NOT Deathblock (or whatever). Then you grant a random set of those promos to affected units (including the caster I imagine, more fun that way :)) with a chance to wear off on each. I'm pretty sure you could force it to only apply ones for spheres which the target has at least one rank in if you wanted, but that might get a little processing-heavy. Of course, not doing that allows the spell a chane to backfire horribly, having no actual effect on your enemies and blocking most of the caster's own spells :)

lose any promotion they have had for more than 50 turns

Why the old ones and not the newer ones? Just wondering.

(And, btw, could someone remind me what "Entropy" in FFH is supposed to be? Is it simply disorder/randomness/loss, or something else?)

You can already do Beef's idea with some of the newer fields I added. the PromotionExclusive set will let you strip a promotion off of a unit (by applying a promotion which excludes it), and the PromotionDegrade can re-apply the promotion. So, you could have anti-Death, which excludes (removes) Death 1/2/3, and then degrades into Death 1/2/3. In order for the degrade to work properly you'd need a seperate promotion for each possible sphere, and have to make sure you only apply a promotion which is needed (if you block death 2 on a unit that does not HAVE death 2, then the block will still degrade to grant them the promotion!)


As for the idea on Entropy III, it is still just an idea, so would obviously need some tweaking or additional mechanisms attached. Taking away the more recent promotions would probably work better (any promotion which the unit has only had for 1/3 of the time it has been alive would be interesting. Almost useless against a new unit, but priceless against an older unit who just came off defender duty and gained some levels). Either way though you would be taking a gamble with hoping that you can remove anything at all.

Another random idea: Would be nice if promotions could have a tag so that they must be "maintained", the same way magically created buildings are. The basic idea would be that if any unit in the stack can cast the spell that applies the promotion, then the promotion persists. As soon as no valid caster is in the stack, the promotion is lost.

I was thinking that a mechanic like this would be great for spells like Haste, Blur, and Dance of Blades, to greatly reduce micromanagement.

Aye, I am intending to make the "Maintain" function just be that the duration of a building/promotion won't count down while a valid caster is on the stack. So all current spell-by-building would work exactly the same way they do now if you give them a duration of 1. The intention is that you should be able to apply a duration to a promotion/building via the spell which creates it. So you could create a 10 turn forge by spell, but still build normal permanent forges if you want to (without needing to duplicate the forge in XML and make the copy have a duration).

Awesome. That is EXACTLY what I was hoping for. ^_^

...Of course, with my luck, by the time you release it, I'll have forgotten everything I wanted to do with it. ^^;

First post updated a little, can't help but feel I am forgetting to do that too often. PrereqLevel removed from PromotionInfos (using Kael's MinLevel now instead, does exactly the same thing). Added bUnique to BuildingClass & UnitClass to identify UUs & UBs so that the Dawn of Man screen & Civilopedia are far better documenting the Civ's true capability.

Also added documentation of the 2 new game options, Civ Selector (not really a gameoption technically), and an option to disable automatic gain of Worker XP (they still have a unitcombat and can gain promotions, but it is nearly impossible for that to happen, would need spirit guide to hit a worker, or to choose to give a worker some equipment and go hunting with it)

Minor tweaks I don't think I have posted an update on (other than updating above) would be that Twincast capabilities from promotions can now stack (though I have not yet made it an Interger value), meaning a unit could have 5 different promotions granting Twincast, and thus be able to cast 6 spells per turn. Also, Twincast doesn't mean "Dual-Summon" it means you get to cast twice each turn (I cannot remember, but I think I made it so that you only regain a single casting from breaking a spellstaff. Otherwise if you have Twincast and Spellstaff you could cast an unlimited number of times in a turn)

As a request by the MP community, I have made all Kuriotates cities start as settlements (except the first one) in MP games, thus allowing you to decide if they are City or Settlement for yourself. AI continues to settle nothing but cities till the limit is met.

City Art Styles are maintained based on the City Civilization type, so the map should wind up looking pretty interesting, and if Decius has a good eye, he will know that the city he is about to take from Sabathiel is actually going to give him Balseraph UUs/UBs instead of Bannor ones.

As a request by the MP community, I have made all Kuriotates cities start as settlements (except the first one) in MP games, thus allowing you to decide if they are City or Settlement for yourself. AI continues to settle nothing but cities till the limit is met.


Thanks for the change. That said, it occurs to me that it could be advantageous for the AI to always settle as Settlements. That way you could give the spell Promote Settlement some AI requirements that would prevent the AI from making cities too close together. The Kuriotate AI really tends to spam cities closer together than they should be, and a bit of code that only lets them upgrade settlements that are a certain distance from a real city might help them quite a bit.

True, would be a good idea overall, especially since then we would have to make sure that the AI actually DOES promote settlements. Last I heard someone was complaining that the AI doesn't do so and can be reduced to having tons of settlements, but only the Cap as a city.

True, would be a good idea overall, especially since then we would have to make sure that the AI actually DOES promote settlements. Last I heard someone was complaining that the AI doesn't do so and can be reduced to having tons of settlements, but only the Cap as a city.

They should upgrade any settlement that has a unit in it, whenever that unit is considered for movement. I think the problem may lie with the AI skipping over some units that it considers "purely defenders" and leaves them fortified in place rather than considering casting the Settlement-Upgrade spell.

(I toyed around with this one a while ago when I was trying to play Kuriotates in MP)

As a request by the MP community, I have made all Kuriotates cities start as settlements (except the first one) in MP games, thus allowing you to decide if they are City or Settlement for yourself. AI continues to settle nothing but cities till the limit is met.


This be a wonderful thing.. :goodjob:

Further reduced animal spawn rates in the water, and also split iWeaponTier into iWeaponTierMax & iWeaponTierMin. This allows you to generate new weapon tiers more easily. So you could have Melee using metals from tier 1-5, Mounted using Mounts from Tiers 10-15, Archers using Bows from 20-25, and Arcane using Staves from 30-35. Should someone want to that is ;)

Had some time between classes, so I programmed something that I wanted to do a LONG time ago, but hadn't gotten around to (unfortunately that means I didn't program the thing that I really want, the thing that I really like, or the thing that I really need).


Also, the first post has finally broken the character limit, so I clipped the Mods from other users into the second post. Will probably have to move even more the next time I do a major update, or clip a lot of the information, but I would rather avoid that if I can.


Anyway: The new fields/abilities are....

PROMOTION DURATION!

This can be set via PromotionInfos, SpellInfos, or Python. Spellinfos overrides any value set in PromotionInfos, and python does whatever python wants.


Duration will not count down while a valid caster is in the stack, and if the promotion has a chance to expire, that chance becomes active only after the duration hits 0 (otherwise when duration hits 0 the promotion is removed). Currently you cannot refresh a promotion before the promotion fully expires (so if you set a promotion with duration of 10, you cannot restore the promotion when the duration is only 2, you have to wait for it to expire, then restore it)


The current test promotions I set up to use this are Hasted being set via SpellInfos to use a Duration of 1, meaning that if the caster hits a stack and they go walking off like normal, the spell works just like now. But if the caster stays with the stack, they stay hasted forever. Obviously this means that the Adept who has Body I will always be hasted as he is always in his own stack. Anyway, this one is set by spell because Hasted is also applied to Centaurs with the spell Sprint. That one doesn't set a duration, so for them Hasted still only lasts for the single turn. But I modified Sprint a bit as well (more later).

The other trial promotion is Dance of Blades. This one I set by PromotionInfos, so now anything that grants Dance of Blades will grant the promotion for a single turn, unless a unit on the tile is able to cast the buff, then it remains till a turn when that unit is not around.



So, more on Sprint. I removed the application of Fatigued that this spell included. Instead I made Hasted apply Fatigued naturally as a <PromotionDegrades> field. So now ANY unit that loses Hasted will gain Fatigued, even if you gained Hasted by the spell Haste, and even if you lost Hasted by the spell Slow. I feel this is justified because now a unit could be hasted for 50 turns running without micromanagement, so having to deal with a 50% chance to wear off per turn -10% strength is quite worthwhile. And I wanted to use the new field :p


THINGS YOU CAN DO:

So, nifty things you can do with this new field:

Have a spell apply a Promotion that doesn't actually do anything, but has a duration of 10, and degrades to a spell that DOES do something.

Have a spell provide a promotion that already exists (like an item) for a limited period of time. Thinking of that... I need to block promotions with durations from being treated like normal equipment... that could be a bit tricky. So just don't use items in this manner for the time being :p I guess the best approach would be to make certain that the unit which spawns has the same duration as the promotion had, and that when the unit is "picked up" that the duration goes with it. Last part is in python though, which is what makes this a messy thing to clean up. Eventually I intend for all Equipment to move out of python, as it is a HUGE chunk of code for a relatively simple function.



Anyway, new toy... have fun playing with it when next version is out.

Amazing, and I hope this is set to work with all existing spells. :)

This just occured to me: Is there a way to make a promotion-granting spell target differently than the prereqs for the promotion? For example, if I wanted to make a Charm Animal spell that worked like Charm Person but only targeted Animal and Beast units, would there be a way to do that without python or making a new promotion?

If not, is that something that could be added?

Pretty sure it would need SDK work right now. I'll make a note to add a <bIgnorePromotionPrereqs> field sometime.

I think a tag that made a spell only effect units with certain promotions could be very useful. It could make spells like Destroy undead and revelation be xml only.

I also think that there should be a tag that makes the caster immune to any effects of the spell.

I still think it would be cool if the xml could pass a list of valid targets to python to avoid the need for complex loops in python, but that might be a bit difficult.

Agreed, agreed, and agreed. :)

There is a LOT that can be done with the spellinfos to move things from python to XML. And a bit which could be done with Missions to move all of the equipment spells to be pure DLL which is automatically established by the bEquipment tags in Unit/Building/Promotion XML (so no spell at all).


Overall, there is enough to do with magic that I need to outsource it, or just wait till next summer when I (hopefully) have a lot of spare time :)

I just had a sudden burst of inspiration as to what would make an excellent addition to the spell system, if it's reasonably codable.

Could you add a "Target" xml field that calls a python function and returns a specific unit, or possibly an array of units, based on that function? Then have the spells effects only apply to units returned by the target field. This could make a good number of spells that would normally have to be entirely python be possible with only partial python.

EDIT: The "Faith" spell I mentioned to you in PM, xienwolf, would be an excellent example of a spell that would benefit greatly from this.

Not quite sure how well it would work out, but it does sound like an interesting thing to code. Might be able to dodge a few of the OOS issues with targetted spells if it is done just right too.

Link updated with our 043 sourcecode, first post not quite fully updated with our changes. Will probably take me a while to find enough time to do that since I have to juggle between 2 posts due to character limit being long since reached.

Found a use for "iDuration" almost immediately. I didn't expect a displayed turn-timer - great feature!

First posts updated with all of the new fields. I hope.

First posts updated with all of the new fields. I hope.

I think you missed these two from CIV4EmphasizeInfos:

<bAvoidAngryCitizens>
<bAvoidUnhealthyCitizens>

Not very likely anyone else will use them, but for the sake of completeness they should be in the list.

I've been trying to add a couple modmods to FF that work on Vanilla FFH. I literally just downloaded both FFH and FF, and unless somethings changed in the past couple of hours, they're up to date. FF gets an error loading XML at the start up and CtDs.

The modmod's are:
From Apepis: AltCivics; AltAmurites; Wonderspack
From Tarquelne: Holy Warriors; Calabim A&S; Elohim with Salsa; Salt Golem; Blasted Garden

I know Tarquelne's are a bit old, so I tried only with Apepis's, then one at a time, then with modular loading on, but no mods. Only the last option worked. I'm pretty tech savvy, but no modder, so I might just be doing something stupid. Help!

From Tarquelne: Holy Warriors; Calabim A&S; Elohim with Salsa; Salt Golem; Blasted Garden


I'll check mine. I checked HW and Calabim A&S sometime late 033, IIRC, and they worked. Haven't checked any in 034 so far.

There is a very good chance that they simply are not compatible with Fall Further. There aren't many things which can break a modular mod, but there are still some. Among them would be that I have removed a few XML fields from the DLL, but in that case it should just ignore them, not give you a failure to load. (Main field I can think of is that now the WeaponTier in UnitInfos is actually WeaponTierMax & WeaponTierMin instead)

...I have removed a few XML fields from the DLL, but in that case it should just ignore them, not give you a failure to load. (Main field I can think of is that now the WeaponTier in UnitInfos is actually WeaponTierMax & WeaponTierMin instead)

That's pretty much it. I started with the Salt Golem - one unit, one promotion.

I replaced the module's UnitSchema with FF's Schema. (Adding "SG_" to the file name). That prevented the loading CTD and gave me a "WTF does "WeaponTier" mean?" error. Or something like that. Deleting the WeaponTier line from the unit file allowed the Salt Golem into the game.

is the source code on the front page updated to the latest patch as well?

Yes, generally it is even more recent than the latest patch actually.

Once again I forget to update with a lot of things I have worked on. Been busy lately and squeezing in code time where I can (makes bug testing real fun when you designed something over the course of the last 3 days in small starts and stops!)


If I am actually remembering everything I did:

<iAsset> & <iPower> fields added to PromotionInfos - This will allow promotions on your units to affect the Power rating of your civilization and should keep the AI from attacking someone because they have a small VERY promoted army. So far we have not yet sat down to insert these values however, and I have not worked the <iAsset> tag into AI logic for deciding if it is willing to disband a unit (about the only thing I can tell it is used for in UnitInfos). The problem I realized after I added these is that a straight number on a promotion is silly, since it really depends on the unit you added the promotion to, so it should be a modifier, not an additive. But that change will be completley inside the DLL when it happens, so just realize that these numbers will tend to be slightly different than the ones in UnitInfos for terms of scale (should still be fairly small since a unit will wind up needing a lot of them to change his overall Power equivalent)

CityBonuses gains the tag <bFullMap> - This makes the unit affect every city in the world which is appropriate based on the other boolean identifiers for the bonus, and overrides the range (but not decay rate)


Loyalty type promotions will be removed (one of them if multiple exist on the unit) instead of a unit turning Barbarian when it fails a check and tries to defect. And if the Gameoption is set to disable barbarians, then units which fail their check will die unless they have Loyalty (which they'll lose).


<PyOnDeath> added to UnitInfos - This function will be run if the field exists for a unit whenever the unit should die (just after checking for immortality, so will not run on an immortal unit). Return a value of 1 to stop the death function from running any further. You must be VERY careful with what you do in this function, as you can cause it to call itself in quite a few ways, and if you do NOT make it attempt to call itself, then you cause the unit to be impossible to remove from the game EVER (not even worldbuilder will manage it). NOTE: This is only a concern if you return 1. Return anything else and the death function continues just fine (so for instance you could run Treants death causing a New Forest on the tile through this function. It would call your def TreantDeath function, check if the tile is allowed to have a forest, plant one, then return 0 so the treant can continue with the process of being killed)

To accompany this function is a python command CyUnit.setDisablePyDeath(bool). If you flag this on a unit, then it will disable the python call form happening again. In most cases, you will want to flag this at the start of your python function.

The unit which currently uses this function is Alcinus. He was ressurected and sent to a random new owner by death in combat previously, so if killed by a spell, or by the AI deciding they cannot afford all of their units, he was gone forever. Now however, this function is called (and immediately disabled) and a new owner is decided on. Once the new owner is selected, Alcinus is converted to their control -- That means that this copy of Alcinus is killed, and a new copy is created for the other player. And that is why it is vital to disable his python call on the initial unit, otherwise you get stuck in an endless loop handing out Alcinus units to everyone over and over.

I'm actually re-writing the code now that I think about how things work to automatically disable itself when it runs, just to save future mod-modders from making a silly mistake. You can still turn it back on if you want with the same function (just use false instead of true for the bool).


<bRequiresPermission> - Boolean in PromotionInfos which demands that a unit has been granted permission to use a promotion in order to take it. This permission can be granted by other promotions or UnitInfos (think of it as a very complicated prereqOR group in this sense)

<AllowPromotions> & <DenyPromotions> - Tags exist in both UnitInfos and PromotionInfos, but in PromotionInfos they are called <PromotionAllows> and <PromotionExcludes>. The Allow promotion is required if a promotion is flagged bRequiresPermission, but also allows a unit to ignore the UnitCombat, UnitType, Tier, and WeaponTier prereqs of the promotion. (so for instance I could grant permission to an Eater of Dreams to use City Raider 1 and he would be able to take it upon gaining the right Combat prereq (2?), but if I gave him permission to use City Raider 2 instead, he would never be able to take it since it requires CR1 and he has the wrong unitcombat to take that promotion)

bValidate will check these tags along with WeaponTier (which this system effectively replaces) and appropriate UnitCombat (which this system potentially overrides) when a unit converts.

<TechBuildDiscounts> - Field added to BuildInfos which allows an additive discount to the iTime value based on the tile owner having a certain technology (NOT based on the player constructing the improvement having that technology, but since most things must be built inside borders, this distinction won't come up often)




Pretty sure all the other new stuff has been previously mentioned. But not 100% certain.

Is it possible to prohibit an improvement from being built on a feature? Can't find a tag for it. Or better yet, reduce the yields on an improvement if it's on a certain feature...

Edit: lol. Always been improvement.. Never wrote feature, of course not...:crazyeye:

Is it possible to prohibit a feature from being built on a feature? Can't find a tag for it. Or better yet, reduce the yields on an improvement if it's on a certain feature...

Prohibit an improvement on a feature?

Maybe something like this in CvGameUtils "canBuild":



pPlayer = gc.getPlayer(iPlayer)
iBuildBeduinVillage = gc.getInfoTypeForString("BUILD_BEDUIN_VILLAGE")
if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_MALAKIM'):
pPlot = CyMap().plot(iX, iY)
if pPlot.getOwner() == iPlayer:
if (iBuild == iBuildBeduinVillage):
if pPlot.getFeatureType(-1) == gc.getInfoTypeForString('FEATURE_FLOOD_PLAINS'):
return 0

That should work, thank you. :D Will most likely have it in an update tonight... Got PT to go to atm sadly. Damn Navy....

That should work, thank you. :D Will most likely have it in an update tonight... Got PT to go to atm sadly. Damn Navy....

Sorry, I had no idea - I tried to show you the right way to do it. And if it's not it'll merely be the wrong way. Next time I'll see about figuring out the Navy way.

Although I suppose PT before updating may be it... :)

Prohibit an improvement on a feature?

Maybe something like this in CvGameUtils "canBuild":



pPlayer = gc.getPlayer(iPlayer)
iBuildBeduinSit = gc.getInfoTypeForString("BUILD_BEDUIN_SIT")
if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_MALAKIM'):
pPlot = CyMap().plot(iX, iY)
if pPlot.getOwner() == iPlayer:
if (iBuild == iBuildBeduinSit):
if pPlot.getFeatureType(-1) == gc.getInfoTypeForString('FEATURE_FLOOD_PLAINS'):
return 0



Hmm.. Where exactly do I put this? I have it in the 'canbuild' section, but it's not blocking construction.

Hmm.. Where exactly do I put this? I have it in the 'canbuild' section, but it's not blocking construction.

Right place - I think the -1 is wrong.

Try "getFeatureType()" rather than "getFeatureType(-1)."

The following prevented a scion worker from building a Cottage on a Floodplain, though it could still build one on the desert.



def canBuild(self,argsList):
iX, iY, iBuild, iPlayer = argsList
# scions start
pPlayer = gc.getPlayer(iPlayer)
iDesert = gc.getInfoTypeForString('TERRAIN_DESERT')
iBuildSCFarm = gc.getInfoTypeForString("BUILD_FARM")
pCity = argsList[0]


if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_SCIONS'):
pPlot = CyMap().plot(iX, iY)
if pPlot.getOwner() == iPlayer:
if pPlot.isCity() == False:
if pPlot.getTerrainType() == iDesert:
iBuildSCottage = gc.getInfoTypeForString("BUILD_COTTAGE")
if (iBuild == iBuildSCottage):
if pPlot.getFeatureType() == gc.getInfoTypeForString('FEATURE_FLOOD_PLAINS'):
return 0
else:
return 1

I would probably just edit CIV4BuildInfos.xml rather than touching the python. You can't block building on a feature altogether, but you could require the feature first be cleared (like forests and jungles must be cleared) and make clearing it require TECH_NEVER.

Right place - I think the -1 is wrong.

Try "getFeatureType()" rather than "getFeatureType(-1)."

The following prevented a scion worker from building a Cottage on a Floodplain, though it could still build one on the desert.



def canBuild(self,argsList):
iX, iY, iBuild, iPlayer = argsList
# scions start
pPlayer = gc.getPlayer(iPlayer)
iDesert = gc.getInfoTypeForString('TERRAIN_DESERT')
iBuildSCFarm = gc.getInfoTypeForString("BUILD_FARM")
pCity = argsList[0]


if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_SCIONS'):
pPlot = CyMap().plot(iX, iY)
if pPlot.getOwner() == iPlayer:
if pPlot.isCity() == False:
if pPlot.getTerrainType() == iDesert:
iBuildSCottage = gc.getInfoTypeForString("BUILD_COTTAGE")
if (iBuild == iBuildSCottage):
if pPlot.getFeatureType() == gc.getInfoTypeForString('FEATURE_FLOOD_PLAINS'):
return 0
else:
return 1



Actually already tried that, just forgot to put that in the code in my earlier post. Tried your Scions code also, and it just stops me from building one period... I get the feeling that python doesn't play well with modular xml files. Magister's method DOES work, however, so it will be updated now. :goodjob:

Magister's method DOES work, however, so it will be updated now. :goodjob:

I like his method better anyway. :)

Me too, as it allows me to keep it modular. Trying to keep the improvements at least somewhat balanced. ;)

I literally just downloaded both FFH and FF, and unless somethings changed in the past couple of hours, they're up to date. FF gets an error loading XML at the start up and CtDs.

I got the same problem while compiling the current vanila FF DLL code:
Failed Loading XML file xml\GameIngo/CIV4StateNameInfos.xml
Then crash

Can you post the makefile you are using?

Anyone using the Debug mode on FF with success?

EDIT: Yay! It wont crash now, I was using a savegame that seems already not compatible.
It runs ok now in Debug mode, with some asserts failed which I will look into later!
If I can I will try to use some profiler to see what is all the CPU time busy with :)
Still learning tough from this Visual C++ 2003 compiler, could take some time.

Failed Loading XML file xml\GameIngo/CIV4StateNameInfos.xml

That's because you downloaded source files are more recent than the Patch F files. The XML file which failed loading above is part of the new dynamic civilization names system for Fall Further.

Most of the Asserts you see shouldn't be of any consequence, but feel free to take a closer look. I would appreciate not to have to click ignore all the time. :)

Oops, sorry about that. I accidentally updated the linked version when we created a new XML file. I'm still getting accustomed to not being the only one with his fingers in the code ;) I'll try not to do that to you guys in the future.

Oops, sorry about that. I accidentally updated the linked version when we created a new XML file. I'm still getting accustomed to not being the only one with his fingers in the code ;) I'll try not to do that to you guys in the future.

Its ok to have the latest code, if we also have the lastest asset :D
Or you could post the vanilla patch F code if you don't want to release the latest asset.

What I suggest is both, the current patch code and the latest one, just name your source according to the patch level.

The minor downside is that I'm not careful enough to maintain backups of my source other than the latest stable version. But if you just create a file with that name and leave it blank things should work well enough for the game to actually open and run.

Not quite sure if Vehem plans to release a patch or if the next version released will be post 0.40 + our own major new features.

Is there anyway to run AI autoplay without having to mod it in myself? I'd like to let it run a few hundred turns, see how my changes affect the Malakim's rankings.

Just hit CTRL+SHIFT+Z and it'll run for a few hundred turns. Hit CTRL+SHIFT+X and it'll interrupt the AutoPlay.

Why is it that when I added settlers to unitcombat_worker they didn't get any of the promotions provided to that unitcombat by leader traits? (Neither the ones you have nor the Mobility1 from the Expansive trait or and Navigation1 from Sprawling which I added) They could still purchase promotions, but they wouldn't get any for free.

Just hit CTRL+SHIFT+Z and it'll run for a few hundred turns. Hit CTRL+SHIFT+X and it'll interrupt the AutoPlay.

Hmm... I've tried that, and it doesn't seem to work. Do I have to have the cheats enabled in the ini?

Hmm... I've tried that, and it doesn't seem to work. Do I have to have the cheats enabled in the ini?

Yes you do. If you shouldn't remember the cheat code:

chipotl

What do bTerritorial and bLeader in PromotionInfos do?

bTerritorial doesn't do anything at all. Was going to prevent any units other than your own civilization from being in the tile with that unit, didn't know how to write such a thing at the time.


bLeader is a firaxis block which identifies the promotion as being what you gain when a Great General is attached to the unit. It can ONLY be gained by that method, and requires some other fields in conjunction with it.

You say didn't know, does that mean you've figured it out? It would be nice to have that tag working.

I know a couple dozen ways to pull it off now, just haven't gotten around to it as the design doc keeps on growing and I always add new things at the top for some reason.

Is there a tag that keeps a Mimic from stealing a Promotion? bEquipment?

I don't think that there is a tag for that (except race). Reasonably certain that it removes the promotion from the victim so that you don't duplicate equipment via mimic stealing. It would be a worthwhile tag with all of the effect type promotions out there.

There is no tag to prevent mimicry. All exceptions are explicit in the postCombatMimic function.

It won't copy equipment or races, Divine, Channeling 3, Great Commander, bronze, iron or mithril. It also won't copy any promotion that the mimic already has, which is new.

It really is copying, not theft, though I don't know if there is a way for the defeated unit to survive.

Well if equipment wasn't prevented specifically then it would be important to make it theft instead of copy, as otherwise the unit would then also drop the equipment. And you should be able to survive via Immortal promotions, and possibly defensive withdrawal.... Hrm.... Mimic vs Loki would be nice.

How much is going to change between this FF and the next, I finally have some time to work on the Legion and I don't want the conversion from 043 to take too long, especially since that's the part where I always lose steam. :( I hate delaying the Legion over and over and I really want to release a new and improved version ASAP.

How much is going to change between this FF and the next, I finally have some time to work on the Legion and I don't want the conversion from 043 to take too long, especially since that's the part where I always lose steam. :( I hate delaying the Legion over and over and I really want to release a new and improved version ASAP.

Quite a bit. We've got a handful of new features that will have a fairly big impact, but we need to finalize which are going to be in the initial 044 and which can wait for later.

Build it for the current release, and just let people know what it is valid for :) If the work is sweet enough (it generally is) then people won't mind playing a slightly outdated version of the base mod for it. And once you have players, it'll be easier to sit through a total update :)

Build it for the current release, and just let people know what it is valid for :) If the work is sweet enough (it generally is) then people won't mind playing a slightly outdated version of the base mod for it. And once you have players, it'll be easier to sit through a total update :)

What he said :D

===

The other bit that I forgot to say is that if you have any trouble with the updates - let us know. We've had to do a few over the last 10 months or so and will be happy to help where we can (in between fiddling with the new features and getting distracted by Kael's scenarios :D)

Now I just have to find my version of .34 :lol: I've learned a lot from Kael and you two and realized that a lot can be cut and thus significantly improve the mod. Hopefully the Legion module can be as complete as the the Scions, I'd love for them to have a truly evil and less civilized rival. :)

I'm sorry for asking a maybe obvious question, but I was looking for the place to change the yields for the city plot (seems to be by default 2 food + 1 hammer + 1 commerce) as I would like to remove the 1 hammer. Any idea ? :) (I checked in the XML files but got confused...)

Thanks in advance.

It is found in Assets\XML\Terrain\CIV4YieldInfos.xml, a file not included in FfH or FF because these mods don't change anything there. I often include it myself as I like to have the game get moving faster by making cities provide 1 more :food: and :hammers:.


There are 3 entries in this file Food, Production, and Commerce. Presumably you could add several more types of yields if you want, but I have not tried. The tag you are looking for is probably <iMinCity>, under <Type>YIELD_PRODUCTION</Type>.


Wow, I just realized that this file also allows me to give Peaks yields, something I had been unable to do before (without clumsy python calls). Thank you for having me look it up.

Edit: :( I just tested it, and it seems like <iPeakChange> doesn't actually do anything. :sad: I think I vaguely recall an SDK block preventing impassible terrains from producing anything, which I really wish was not the case. Xienwolf, do you care to look into it? Removing all the blocks that stop you from building improvements on impassible terrain would be appreciated too.

Thanks, it works indeed. I intended on supressing the hammer only for 1 civ, but seems it will be for all then..

Do you know if it is pôssible to use several block as :

<CivilizationYieldType>CIVILIZATION_xxx</CivilizationYieldType>
<CivilizationYieldChange>
<iYield>0</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</CivilizationYieldChange>

In the terrainInfos file ?

The desert and snow tiles have a part for malakim and illians, but I would like to change the yield also for another civ ?

As I recall, those fields were designed to only work for a single civilization, so it wouldn't be possible to list another.


As for the impassible tweaks, remind me sometime later and I might be able to look into it. Tied up with solving a few new bugs to make the next version releasable right now and can't get distracted.

Do you know if it is pôssible to use several block as :

<CivilizationYieldType>CIVILIZATION_xxx</CivilizationYieldType>
<CivilizationYieldChange>
<iYield>0</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</CivilizationYieldChange>

In the terrainInfos file ?

The desert and snow tiles have a part for malakim and illians, but I would like to change the yield also for another civ ?

As I recall, those fields were designed to only work for a single civilization, so it wouldn't be possible to list another.

That being said - we do need to enable that at some point to tidy up the way Marsh vs Wetland is handled and can enable the better yields for both Mazatl and Cualli...

I tried to go around the limitation by using a tech oriented yield change instead of civ oriented, but seems it can only apply to improvement, not to terrain or feature.
Did I do it wrong or do you concur ?

(using the following:

<TechYieldChanges>
<TechYieldChange>
<PrereqTech>TECH_ORGANIC</PrereqTech>
<TechYields>
<iYield>1</iYield>
<iYield>-1</iYield>
<iYield>0</iYield>
</TechYields>
</TechYieldChange>
</TechYieldChanges>

)

I'm also wondering why isn't the following tag used:
<HillsYieldChange/>

and then where is the +1 hammer for hills coded ? (anyway to remove it also :))

I tried to go around the limitation by using a tech oriented yield change instead of civ oriented, but seems it can only apply to improvement, not to terrain or feature.
Did I do it wrong or do you concur ?


I think that's probably the case. It's also why "swamp" was made into an improvement for the Lizardmen...

and then where is the +1 hammer for hills coded ?

May I abuse your patience insisting of this one ? :blush:

The +1 hammer (and -1 food) from hills is found in the CIV4YieldInfos.xml file I mentioned yesterday, which is not included in FfH or FF because it is unchanged from vanilla.



When you get around to making multiple civs be able to get bonuses from the same terrain could you se abut making Hills and Peaks be able to give civ specific yields bonuses too? I'd like the Khazad to find Peaks much more productive than anyone else.

While harvesting your code on allowing multiple invisibility and invisibility on promotions, I noticed what I assume to be a bug. In CvUnit.cpp it says on two places:

m_aiSeeInvisibleTypes.clear();
m_aiSeeInvisibleTypes.clear();

I assume one of those lines should be:
m_aiInvisibleTypes.clear();

Besides that , according to my basic knowledge of C++ grammar, there's a whole bunch of {}s missing. I wonder how you can get your DLL to compile. :confused:

Oops, the bane of line duplication :) Thanks for the catch, might have caused some of the incidental odd issues I've bumped into on occasion.


As for the {} signs, I am a minimalist when it comes to those (Primarily because WinMerge doesn't handle them very well in large chunks of code like CvInfos where most of your lines are JUST a bracket in the normal CIV format). Using those brackets tells the computer "This is all really just 1 line of code, I promise!", if what you wrote really IS just 1 line of code, then you don't need them at all. Of course, you have to keep this fact in mind when you revise your code, because with the normal method of using them everywhere you have a conditional or loop you just add another line and you are set, but with this approach if you add a second line where no brackets existed, then you are hosed because that new line is NOT included in the loop or conditional.

The missing braces aren't a problem per se, but it's certainly not the best kind of programming style, if you ask around. It's just too easy to forget to add them, when you add a second line of code. I'm forcing myself to use them, after running into some rather time-consuming problems with the minimalistic appoach in the past myself.

I've often run into just the opposite myself (Duplicate a line and wind up having more end-brackets than I want), but that only becomes a problem if you don't give the bracket a line to itself, which is another bad habit I have (again mostly for WinMerge's sake)

Using those brackets tells the computer "This is all really just 1 line of code, I promise!", if what you wrote really IS just 1 line of code, then you don't need them at all.

Thanks - learned something new.

I'm wondering about something else. I've read that Fall Further has a hell version of coast. Unfortunately I can't check myself how it looks in-game: I don't have FfH 2.34 anymore, and copying it over FfH2.40 gives some weird results: blackwater and blighted coast uses the hill and peak textures.

So I'm wondering, can you tell me if/how you have managed to make two coast terrains show up without conflicts? When I was experimenting with having two coast terrains, I got some rather bad results:

image removed

Vehem will have to poke his head in here and answer that one. I haven't touched the graphics very much personally, and when I have done so people have usually complained instantly :)

I'm pretty sure the issue you are seeing is still present in FF, but the darker colors just make it a bit more subtle.

So I'm wondering, can you tell me if/how you have managed to make two coast terrains show up without conflicts? When I was experimenting with having two coast terrains, I got some rather bad results:


I'm pretty sure the issue you are seeing is still present in FF, but the darker colors just make it a bit more subtle.

Aye - the FF version still isn't perfect, but I think it's a little closer to working than the screenshot. In Civ4ArtDefines_Terrain.xml, there's a field called "LayerOrder". From the screenshot I'm guessing that the new coast has this set to 50, same as the old coast? Dropping it down to 49 helps a little with the blending (but as Magister mentioned, doesn't seem to completely resolve it - I think the actual layout of the texture tiles needs a little work for that).

From the screenshot I'm guessing that the new coast has this set to 50, same as the old coast?

Nope, the layerorders were different. Layer order doesn't solve the problem. On that screenshot the trench (darkest blue) layer order seems to be the lower than the shelf layer order, with as consequence that the coastal sand part of the shelf texture extends over trench plots. Switching layer orders would also just switch the problem: trench coastal sands being displayed over shelf plots.

I don't know any graphical artists willing/able to do this, but perhaps you might, so I thought I'd throw out the idea: (I can only profit from it myself if you like it ;))

I had the idea that instead of terrain types, trenches (or in your case hell versions of ocean and coast) could be a feature type. They would then require nif files. The nif file culd be a flat coloured plane, of only minimal height/Z-axis, so that the nif would cover up the terrain textures, but still look completely flat.

One nif for all trenches/hell water would look bad though. There would be a sudden colour transition etc. Perhaps the icepack nif could be an inspiration. The icepack XML can be copied for trenches/hell. This would create some variety in trench connections, and there wouldn't be a straight line seperating trench/hell from ocean/non-hell. The dds could be the trench/hell colour of the current terrain textures, including at the side of the dds some colour transition from the trench/hell to ocean/non-hell colours.

I think that this MIGHT be all the new fields added since 043:


CIV4LeaderHeadInfos.xml
<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



CIV4BuildingInfos.xml
<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)



CIV4CivilizationInfos.xml
<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.



CIV4GoodyInfos.xml
<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



CIV4HandicapInfos.xml
<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
<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)
<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)
<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
<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...)
<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.
<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
<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.



CIV4VictoryInfos.xml
<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)



CIV4ProjectInfos.xml
<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



CIV4GameSpeedInfos.xml
<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



CIV4TechInfos.xml
<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
<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
<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.
<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.



CIV4ImprovementInfos.xml
<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
<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)
<iSpawnPerGameLimit> - Improvement is unable to spawn more than this many units per game. If the improvement is removed and rebuilt, the counter starts over
<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)
<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)
<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)
<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.



CIV4UnitInfos.xml
<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.
<Quote> & <Quotes> - Matches up with <Image> and <Images> fields to provide a quote for the unit pop-ups
<Images> - Matches up with <UniqueNames> field to provide Images for each Uniquename option for pop-ups
<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>
<DenyPromotions> - Unit is capable of having any promotion listed in these fields (Would be useful on the Flesh Golems for instance)
<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.



CIV4PromotionInfos.xml
<iPromotionRandomApplyChance> - Controls the probability of the promotion listed in PromotionRandomApply (Fair Winds, Enraged) being applied each turn
<iPromotionRandomApplyChance> - Percent Chance per turn that the promotion listed in RandomApply will actually be applied
<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
<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)
<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.



CIV4SpellInfos.xml
<Quote> - Specifies the text displayed in the pop-up for Global Spells (Image used is the LeaderHead image)






Also added by Jean Elcard is the new file CIV4StateNameInfos.xml which controls what state name modifications will happen and what conditions are required to gain them. I haven't checked out all of the inner workings, so he'll correct me if I am guessing some of these wrong off of just the XML field name :)

CIV4StateNameInfos.xml
<iMinNumCities> - Number of cities required to gain the statename
<iMaxNumCities> - Limit of number of cities owned for name to be valid
<bNoMinor> - Prevents Minor Civilizations from having the statename
<bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
<PrereqCivics> - Civics required active to gain the statename
<PrereqAlignments> - Alignment required for the name to be valid
<PrereqCivilization> - Civilization for which the name is valid
<PrereqReligion> - Religion required to gain the name


Once all valid names have been decided, there is a routine to choose precisely which one will apply. Note that when you change multiple civics at once you might go through a couple of names as each civic is changed internally one-by-one.


EDIT: As for Gameplay changes and tweaks... I didn't keep track. The one I remember right now is that Groups with a BuildOrder will not "wake up" to ask you to promote them when they gain a level. This means if you give your workers a huge list of chores, and then they promote, they remember their list instead of having you issue them all over again! But this also means if you have a warrior defending that worker and he gains XP somehow then he will NOT wake up to ask for a promotion either (though normally such XP would be gained by combat, and having an enemy nearby will have woken them up anyway)

Is the source now for 50 on the first post?

Yes, but I think I made some tweaks since the last upload, so will have another version up in about an hour (after I get back home)

Also added by Jean Elcard is the new file CIV4StateNameInfos.xml which controls what state name modifications will happen and what conditions are required to gain them. I haven't checked out all of the inner workings, so he'll correct me if I am guessing some of these wrong off of just the XML field name :)

CIV4StateNameInfos.xml
<iMinNumCities> - Number of cities required to gain the statename
<iMaxNumCities> - Limit of number of cities owned for name to be valid
<bNoMinor> - Prevents Minor Civilizations from having the statename
<bNoVassal> - Prevents a Civilization from having this statename if they are current vassalized
<PrereqCivics> - Civics required active to gain the statename
<PrereqAlignments> - Alignment required for the name to be valid
<PrereqCivilization> - Civilization for which the name is valid
<PrereqReligion> - Religion required to gain the name


You were guessing right. Congratulations. :)

Once all valid names have been decided, there is a routine to choose precisely which one will apply.

First of all, a state name is only valid for you, if you meet all conditions. Of course, it may happen, that you meet the conditions for multiple state names. What happens then? Then it applies the state name, you need and fulfill the most prerequisites for. If there should be still more than one left, you get the one further down in the XML file (should be a very rare case).

Have the schema changed with this release, or are old schema still usable? In the middle of a locked game, or I'd be playing with it to figure it out myself. ;)

Any time new fields are added Schema files change. So quite a few of them changed in this release (meaning 050, not patch A)

Would it be possible to create a new "Would you please stop building..." option under the "Lets Discus Something Else" choice on the diplomacy menu, which would allow a human with an AI Permanent Ally to tell it to stop the production of a certain World Unit/Building/Ritual?

Why would you want them to stop?

Why would you want them to stop?

Because you want to make that unit/wonder/ritual yourself? :P

Example: Having Basium and then watching him beat you to Sphener/Yvain/whoever.

Not being able to build a hero or wonder because a permanent ally is doing so (especially if it is doing sow in a low production city and so won't be able to beat a rival to it anyway) is extremely annoying, thats why. It is even worse in games where you are allied with another leader of the same civ. Kael had to block the AI from building Heroes in the Splintered Court if it has a human ally to stop that annoyance, but that block is only in that scenario and probably isn't the best way to do in in the main game, as you sometimes would want them to build the unit.

Ya see.... you guys haven't TRIED IT have you? ;)

Been trying to get some code for Oasis creation working, and while I can create an Oasis, the moment I try to go into python to require a minimum distance between Oases, the code completely fails. Stole it from the Pirate Cove code, no idea what I'm doing wrong here. Any help would be much appreciated. ;)

Edit: Code removed, got it working.

Second line in your requirement has a nice double negative. That's kinda sorta pointless, and kills your spell. If not (plot isn't a desert) would mean, if the plot IS a desert, then forbid the spell.

Actually, I noticed that just after posting, and fixed it. Had it in thinking I might not be understanding the code. Still not working after making the fix.


Edit: Nevermind, I'm an idiot. Forgot to define iOasis, working now. ;) Also, is there anyway to put in a minimum distance between improvements without making it a spell?

Only with DLL modification to my knowledge.

Damn. Might have to leave it as is then, I don't want the AI hampered by too many spells.

So, I have a nice problem here. For the sake of a few people I'm editing the Fall Further module to remove some references to non-Erebus things (that are in FfH - it's to remove the silly things from the final mod that we find a bit jarring, the Monty Python comments/buttons and Guybrush Threepwood as the Lanun hero.)

Through the course of changing Guybrush's name both of my XML editors had issues opening UnitInfos.xml, stating there was an issue at line 8412. This line is...
<Image>Art\GreatPeople\Simple\Tuatha Dé Danann.dds</Image>
It's the é in the text file which is fouling up my XML editor. Can Civ IV parse these characters, or are my xml editors just wonky?

Secondly, upon trying to open the .PAK file to change the name of the picture (so I can have a regular e there, then change UnitInfos without breaking the link), I get an error stating "Chorus of the Damned is not a valid integer value." and cannot open the .PAK file to change this error, to change the other error, to fix one small letter so I can just rename Guybrush... I've been on this escapade an hour or so... can anybody assist with where my problems lie? 0_o

Yes, Civ handles the name just fine. Use Notepad++ to edit, it is very nice and has no issue with such characters :)

You generally don't want to edit inside the PAK, as you then have to repack it and distribute all of the art all over. Just place an image in the Assets/Art folder with the same path/name as the button you wish to replace, or point the file at a new location for your new button.

One of my coder buddies pointed me to a different editor that has more features and will handle the character fine, too. So no harm was done.

Started modding Fall Further, now I can't stop messing with stuff >_> Is this how you guys started? :D

Started modding Fall Further, now I can't stop messing with stuff >_> Is this how you guys started? :D

Yup - exactly :D

Not sure where the correct place to ask this, but maybe here.

What do I need to do in order to use/make maps for FF? I have no problems with just FfH, but in FF I get a CTD.

We allow a maximum of 50 teams, so you have to account for that properly.

Also, updated the sourcecode zipfile just now, contains some of the fixes which will go with next patch, but doesn't require any supporting python or XML changes.

I'll check stuff for the next patch, but currently if I make a random map, save it in world builder, then try and load it as a scenario, I get a CTD, no python errors.

Far as I know THAT should work fine. I would suspect the issue might be tied to the worldbuilder save trying to maintain a record of what the game time was.... I messed with that heavily to get the gameturn to show up in the replay screens, had a few unexpected issues along the route (function is used for a LOT of things)

Are there any premade maps that you know work that I can try, so I can make sure the problem isnt something on my end?

I don't know an answer for that one myself, hopefully someone else can chime in with assistance.

Well, just to check everything on my end, I uninstalled then reinstalled everyting and one of them seems to be working now.

Hmm... What files need to be edited to increase the width of the civics screen? I have it working, but it seems to cause a slowdown when starting the game.

I don't know i this is were I'm supposed to ask this question, but I don't anywere else to ask it.
I have replaced Fall Furthers ARTSTYLE_DARK with C.Rolands ARTSTYLE_CALABIM. What do I do if I want have them as seperate artstyles instead?

If you have some old copies of FfH from before Kael removed the civic category, compare their interface screens and you'll easily see where to modify the width of the screen. I believe there were 3 or 4 places in the file you needed to tweak things.

For the artstyle, just don't overwrite anything and you can keep them both. Be sure to list them in the proper order of course in the GlobalTypes.xml

If you have some old copies of FfH from before Kael removed the civic category, compare their interface screens and you'll easily see where to modify the width of the screen. I believe there were 3 or 4 places in the file you needed to tweak things.

That's about what I thought... Been trying to find something, may just end up having to see if I can get the old comp working well enough to grab the values out of it.

Is there any specific reason I shouldn't simply replace the current CvCivicsScreen.py with the old, pre-.50 one, or was it not just resized?

So - question... Is there any way to lock rituals off to certain leaders of a civ, as opposed to just certain civs?

I've been thinking about giving the Illians a second leader that isn't out to Ascend and bring a second age of winter in a modmodmod, but of course he'd have to lose access to the building-up rituals for this to work how I want. (Honestly, would like to give him a different worldspell too.) Still toying with the idea though, but would like to know if it's even workable first.

Flat out replace might work. I don't recall anything important being changed.


Ice: Might be best to make it an offshoot Civilization to make things easy on yourself for changing worldspell and ritual access. But otherwise, the only readily available method would be to activate the python callback for CanConstruct on Projects and place a block there for your new leader. Would be much the same for the worldspell, you'd just create 2 worldspells for Illians, and have a PythonPrereq for each which limits it to only the proper leader.

Flat out replace might work. I don't recall anything important being changed.

Works perfect. :goodjob:

Finally broke down and got WinMerge, also...... Can't believe I haven't been using it till now, makes life so much easier. :)

Xien - thanks. I'll try that whenever I get my coding fingers ready to take on something of a greater magnitude than tweaks and whatnot.

Is it possible to have a unit require one civic to be built, but have two valid civic options to not abandon you?

New fields added to GoodyInfos:

<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)


<iMinTurnsElapsed> & <iMaxTurnsElapsed> - Earliest and Latest in the course of a game that the goody can be granted. Weighted by gamespeed


The first set is hopefully going to stop the "sticky interface" issues for good. The second is for keeping you from getting a map after you already have Omniscience, or a Death Knight before you have diapers to soil.


EDIT: Not possible without DLL modification or Python prereq layout Valk. The Abandon code specifically checks the same requirements as are listed to build the unit. So if you hide the prereq in python, the DLL doesn't know it needs to check it (to bypass some abandon checks). To add an extra check you would need a PyPerTurn check on the unit, which tends to slow things down a bit if you get too many of them.

Damn. Most things involving Python are like Greek to me... Maybe I can have two identical units, have it check when you switch civics and switch the one to the other? That much is probably within my abilities, if not as clean...

Hmm... If I make a promotion using the <bNonAbandon> tag, requiring a civic other than crusade, would it apply before or after demagogs are destroyed?

Is it possible to use a promotion to change a unit's Unit Category - in this particular case, a leader trait's free promotion that shifts all Disciple class units to Arcane units? If it's not possible I'll need to go think on other ways to get it done or drop the idea, I suppose... but I've been accused of not being the sharpest knife in the drawer.

Is it possible to use a promotion to change a unit's Unit Category - in this particular case, a leader trait's free promotion that shifts all Disciple class units to Arcane units? If it's not possible I'll need to go think on other ways to get it done or drop the idea, I suppose... but I've been accused of not being the sharpest knife in the drawer.

<TempUnitCombat> should be what you want. Only know about it myself because I've been looking at each field in the first few posts here today. ;)

Aye, there are a TON of new fields, so it's easy not to be familiar with all of them :) TempUnitcombat will work nicely, but you have to be careful with when/how you apply the promotion. Before the promotion applies they are the standard unitcombat, after it applies they are the new unitcombat. This seems silly, but it is potentially problematic.


Most routines done with promotions or anything else are done from the first listed to the last listed. So if you were to have a leader who applies this promotion to all Disciple units and nothing else, you are pretty well off. But if you also had Spiritual (applies Potency to Disciples, right?) then it becomes tricky. If spiritual is listed in the XML before your new trait, then your disciple units will be born as Potent Arcane units. If however Spiritual was listed AFTER your new trait, then it wouldn't ever apply the Potency promotion to anybody.

Now if you have your new trait apply 2 promotions to Disciple type units, then you have to be careful of how the XML files list promotions. If you wanted Disciples to be Weak + Arcane, and listed Arcane before Weak in the XML then Arcane hits and they become no longer a Disciple type of unitclass, so they won't get Weak.


Complications can be listed for quite a while, but I think you get the point at this stage, or are lost :)

That is exactly what I needed! And yeah, I went through the list of codes and stuff in the FF/FFH modmodders guides but didn't see what I needed. I thought i'd seen it done before, though.

EDIT: It makes me feel a little better that the only place this field seems to be used is in the example test/template promotion :D so I didn't overlook it.

EDIT to avoid doubleposting:

New question - where in the Python is the codework for postCombatMimic? I'd like to double it and set it up so that the unit that will have the second copy can ONLY steal Divine from a defeated unit... but I've been through all of the Python and unable to pull up anything that lists that function.

EDIT 3: The racial promotions seem to be getting in the way of letting the Usurper trait promotion change anything regarding unitinfos. The percentage bonuses work - but the units are all still disciples... :( Still trying to puzzle on this one. If I move the new promotions to the top everything goes way out of whack, with haunted land stuff appearing on units anywhere and units going totally crazed. 0_o
Nix that, any other added promotion fouls it up... I may have to come up with a more roundabout solution. Crud.

Are there Python commands for 1) Reading if a unit has a promotion and 2) forcing a unit's UnitCombat ?

Hmmm. Mayhaps I should have doubleposted to bump the thread.:D

Is it possible to use a promotion to change a unit's Unit Category - in this particular case, a leader trait's free promotion that shifts all Disciple class units to Arcane units?

What's the final result you want, Iceciro? (Disciple units can be built, but their unit-combat is Arcane rather than Disciple?)

That's precisely what I want. Some background to better understand...

I have a leader in my game who is Charismatic/Usurper. For a while he was Intolerant, but I wanted to represent the ability to twist the religions his people follow.
In a perfect world Usurper would be working as such (aside from giving the benefits of Conqueror and -1 culture in all cities) - whenever he builds a Disciple unit, it receives the Charlatan promotion, which changes its UnitCombat to Arcane, and makes it lose Divine. Because t2/t3 priests get Channeling, this means his priests are really mages in disguise - they use the tricks and spells to keep the people in line and worshiping. (The object of thier worship being not say, Junil or Kilmorph, but the leader in actuality.)

This culminates at Divine Essence where any level 10 Preist unit drops Charlatan and picks up Thief of the Divine, granting him the Divine ability and he can now cast Divine spells too.

That's the idea, anyways. Implementation is proving to be a lot trickier. Right now, when a unit is built under him as the Cabalim, it works fine... until the unit picks up any other type of promotion, at which point it reverts back to being a disciple. When I load him up as the Scions, the undead promotion the Legates/et-al get is enough to stop the changeover. In a Worldbuilder test this remains the case with pretty much any promo regardless of what it does, including Channeling (destroying the whole point!)

Ok, the explanation that they do go Arcane, but then upon getting another promotion revert to normal makes it pretty clear that the problem is in my code. I tested that the unitcombat changes, not sure I ever tested that it STAYS. :)

Mimic is located in the Assets/Python/Entrypoints/SpellInterface.py, the specific function name is listed in the Mimic's XML under the PyPostCombat field.


Having a promotion you add to the top of the XML list screw other things below it up generally means that you are trying to use the same TYPE_??? name as something else already uses. That messes up the enumeration for the second and third readpass, resulting in a lot of promotions shifting their data (it was why Werewolves weren't upgrading for a while)

Appreciate the help with the mimic, in any case, and now I know that for the time being the unitcombat change idea, through the promotion itself, won't work. I'll have to puzzle up something else.

Hello there!

I really like the dynamic state name mechanics; thus I searched for it in the files and I eventually found the xml ones. I have some questions: 1) Is there a python file that manage the changes? I remember that there is one for the original Dynamic Civ Name component that came with Revolution.

2a) Is there a tag that tell if a civ has a vassal? Is there one that tell how many vassals the civ got?

2b) Is there a tag that tell how many owned cities were aquired through conquest rather than through founding?

3) If there isn't such tags, how could I create them?

4) Is it possible to use any tags in the CIV4StateNameInfos.xml file? Or are usable only those listed in the first post?

5) If not, how could I make them usable? For instance, I would like to have <bFemale> usable.

Finally, I must apologize if any of these questions is silly. I searched through the Fall Further forum and used the search functions but I didn't find much information...

I really like the dynamic state name mechanics;

I'm happy you like it. We didn't get much feedback on this feature, but I suppose that's ok for a for-flavour-only-feature. ;)

1) Is there a python file that manage the changes? I remember that there is one for the original Dynamic Civ Name component that came with Revolution.

No, there is no Python file, I decided to rewrite the dynamic civ names system completely to be more in line with how things are handled in Vanilla Civ4, to make it faster and to make it modable more easily (to a degree) by people which aren't familiar with Python.

2a) Is there a tag that tells if a civ has a vassal? Is there one that tell how many vassals the civ got?

2b) Is there a tag that tell how many owned cities were aquired through conquest rather than through founding?

No, sorry, not in the current version.

3) If there isn't such tags, how could I create them?

To create new ones is difficult. You would have to change the SDK to make them work. That's the way it is with all tags in Civ4. This said, I'm always open for suggestions and would be happy to add new tags if the need arises.


4) Is it possible to use any tags in the CIV4StateNameInfos.xml file? Or are usable only those listed in the first post?

Only the eight tags mentioned in the first post.

5) If not, how could I make them usable? For instance, I would like to have <bFemale> usable.

This one is going to come. I just forgot to implement it, when making the first version of the state name system.

Finally, I must apologize if any of these questions is silly. I searched through the Fall Further forum and used the search functions but I didn't find much information...

No, no need to apologize, your questions are definitely not silly. :)

Give me some examples, which names you would like to see in the game and I'll try to tell you, what's possible and what's not.

I'd honestly like some references to having a few vassals, have it called Empire rather than Kingdom... Maybe a Holy -civ name here- Empire for God King/Religion/2 or more vassals. Could use a vassal tag in quite a few ways.

Jean Elcard:

Like Valkrionn said, I would like to be able to count vassals and/or the number of cities the civilization conquered to bestow or not the title "Empire". I thought of adding "Federation" but I don't know what would make one yet.

Otherwise, I wanted to use <bFemale> for Queendom; or Matriarchy for, say, a female leader of Clan of Embers rehabilitating it by having both Theocracy and Religion civics. By the way, I would like to be able to have <PrereqLeader> too. Given the different personnalities of the leaders, it would be nice to create some variation inside the same civ.

At first, I just thought of creating more "flavoured" state names. I think a lot is doable, given, again, the diversity of the mod. Most are based on civics, civilization or religion, though; thus no help needed here.

To sum up, here are the tags I miss, ordered by "necessity":
<bFemale>
<PrereqLeader>
<bColony> (is or not a colony)
<bMaster>/<iVassal> (number of vassals)
<iCitiesAcquired> (number of cities taken from other civs)

Of course, this is just a thought. Well, I already began working on some names, but, basically, a thought.

Edit: I already successfully added "Motherdom" to the Archos civilization. I think we could put a lot of emphasis on their Mother-cult by expressing it in their state name. I'd also do something about the magic-structured Amurites.

Jean Elcard:

Like Valkrionn said, I would like to be able to count vassals and/or the number of cities the civilization conquered to bestow or not the title "Empire". I thought of adding "Federation" but I don't know what would make one yet.


Federation could be City States, with a number of vassals.

Question - what's the simplest way to tone down the numbers of barbarian stacks that spawn and gatecrash player/AI cities? I love the pillaging packs of barbs, but I hate the sheer number of stacks that can come to any one civ at a single moment, severely retarding the growth of their current picking, player or AI.

No easy way to control where the barbarians head to and keep too many from heading to a single location. With the next patch you can control the limitation on spawned stack sizes if you want to try that out though.

Any idea when the next patch is being released?

Federation could be City States, with a number of vassals.

No, in a federation every member should have the same rights. Maybe a name that better suites a permanent alliance.

No, in a federation every member should have the same rights. Maybe a name that better suites a permanent alliance.

True, I'm just trying to give you a reason to add in a number of vassals requirement... I want my empire. :D

I noticed that when I started a game as the Infernals instead of summoning them the usual way that I was not at peace with the demonic "barbarians." Given how all my territory would revert back to demon spawning terrain every turn, that was a big problem. I didn't last long enough to build Pax Diabolus.

I'm thinking the Infernals need to always start at peace with the other demons, and maybe even always stay at peace with them.

(Granted, I may be a couple patched behind.)

I noticed that when I started a game as the Infernals instead of summoning them the usual way that I was not at peace with the demonic "barbarians." Given how all my territory would revert back to demon spawning terrain every turn, that was a big problem. I didn't last long enough to build Pax Diabolus.

I'm thinking the Infernals need to always start at peace with the other demons, and maybe even always stay at peace with them.

Has been changed so that both Infernals and Sheaim benefit from the "AV-Demon Peace Rule". Incidentally, this makes it rather difficult for Hyborem to pull off the Basium-Switch...

Infernals are not MEANT to be in the game from turn 1. I don't go out of my way to block them from the Civ Selector because it is sometimes useful to have them available for debugging reasons. But they have such a giant advantage from the start of the game due to all the free buildings that I personally think not having peace with the demons would be a nice counter-balance.

@ Vehem or Xienwolf:

Im wanting to start remaking the warhammer mod from scratch using Fall Further as a base for the excelent new content you guys have added. when do you think the most stable version will be out (ie do you forsee many more patches to be released in the future)? also, will i be wasting my time remaking the entire mod from scratch or is there an easyer way to add all the Fall Further stuff to Warhammer (i suspect no).

and finally, any advice in how to proceed with this task? im not too sure where to start. should i start with civs, or python, or religions???

thanks in advance!

It really takes a different mental framework to build a mod which uses our added features instead of the standard python workarounds, and to think in terms of promotion application instead of event use, or adding tags to other items which can be prereqs for promotions instead. So I do not think that a ground-up rework would be a bad idea, but I do think you might benefit from first seeing which of your current mechanics can be moved to our new framework and practicing at re-writing them (which is basically a ground-up rewrite with a compare afterward... so I guess I didn't say much...)


As for stability: Right now the only major issue is with loading a game after having played for a while. This is almost 100% due to the extra Barbarian factions. Thus far, no ideas on precisely where it is happening, so no clue when it'll be fixed. But I do know that there are still a LOT of features on the plate for adding to the game, so as soon as we have more time and have things any more stable (or are convinced we cannot find better stability anytime soon), we will probably add something new and make it once more highly unstable :)


All in all, now is a good time to grab the mod I bet. If you don't want to use the multiple Barbarian factions, I would advise that you remove them from the DLL and see if it makes you more stable (in other words: if you don't have PLANS for extra barbarians, don't make any ;)) Also worth noting that the extra Barbarians currently have issues with properly settling cities (citybar doesn't display properly). Works fine for us since the extra 2 aren't allowed to have cities anyway.

So, FF guys, I have a laundry list of questions for you regarding my old issue with making the Usurper trait turn religious units into Arcane ones. I'm going to make this happen or collapse in modding stupor.

Is there any easy way to, through Python, see if a unit has a certain promotion and set its UnitCombat there, and if it works, would it work BETTER than having the promotion set the UnitCombat itself, since no matter what Python would see the unit having that promotion and try to slap it into behaving?

Failing that, is there a way to set a Unique Unit list for a leader as opposed to a Civ, since the leader in question can be in command of multiple civilizations?

Failing THAT, how difficult would it be to set a Python event that reads "leadertrait: Usurper" and pulls a clone of the unit with the same stats, but with Arcane Unitcombat? (I realize this would probably mean adding a lot of cloned units...)

I don't think that setUnitCombat is exposed to python, so you'd need to mod the DLL for any of those to work, except the last one I suppose, which is pretty cludgy.


I have a feeling next patch is fairly soonish, we've added and tweaked a few things, to include unbreaking Hell Terrain (which is what might lead to a soonish patch). Once the new patch is out your promotion to switch unitcombat will work perfectly fine.

*ahem*

Woooooooooooooooooooooooooooooooooooooooot. Thank you, Xien. That's what's been holding me back from getting Usurper up like I wanted, the inability to add that promotion swapping thing. Now I just have to not...go...insane...while...waiting...

Oh wait, I'll just go play Fall Further now. :D

It really takes a different mental framework to build a mod which uses our added features instead of the standard python workarounds, and to think in terms of promotion application instead of event use, or adding tags to other items which can be prereqs for promotions instead. So I do not think that a ground-up rework would be a bad idea, but I do think you might benefit from first seeing which of your current mechanics can be moved to our new framework and practicing at re-writing them (which is basically a ground-up rewrite with a compare afterward... so I guess I didn't say much...)


As for stability: Right now the only major issue is with loading a game after having played for a while. This is almost 100% due to the extra Barbarian factions. Thus far, no ideas on precisely where it is happening, so no clue when it'll be fixed. But I do know that there are still a LOT of features on the plate for adding to the game, so as soon as we have more time and have things any more stable (or are convinced we cannot find better stability anytime soon), we will probably add something new and make it once more highly unstable


All in all, now is a good time to grab the mod I bet. If you don't want to use the multiple Barbarian factions, I would advise that you remove them from the DLL and see if it makes you more stable (in other words: if you don't have PLANS for extra barbarians, don't make any ) Also worth noting that the extra Barbarians currently have issues with properly settling cities (citybar doesn't display properly). Works fine for us since the extra 2 aren't allowed to have cities anyway.

great thanks :)

the multiple barbarian thing is actually one of our more desired features, so i think ill wait a couple more weeks to see if you can manage to sort it out :) (which i know you guys will :p)

is there any chance that you could tell me what are the new features you still plan to add? it would save me reworking it twice if i know you will adda feature that would be useful for Warhammer :p

It is a giant list, many of which might not see the light of day. Tons of which aren't written down anywhere. Some of which were accidentally leaked with our sourcecode (in a huge rambling file which contains things from when I first opened the DLL still).

I'll PM you with some of the larger and more likely items. I don't like to state them publically because they might never happen and people might get disappointed. Or they might happen but be in a much altered state by final product.

But mostly, few will happen before the start of the next schoolyear most likely. Or at least, not by my hands (And Vehem is stuck on Balancing/Tweaking/Refining since he has the unfortunate position of being in charge of the mod, and Jean is likely to be working on Revolutions. So that means it's unlikely to happen by other hands too). I have to study hard for my qualifiers this summer, so my time will be consumed.

if you could PM me the more likely possible future additions id be very greatful, this would help me decide on my plan of action. by the sounds of things i will just go ahead anyway, but there is always the possibility that some new addition could be exactly what i need. (oviously you have my word not to leak any of what you send in your PM)

thanks again!

When setting PromotionDegradesTo in a promotion, will the target promotion show up no matter how the master promotion is removed, or only if it degrades naturally?

My chief question is if I set the master promotion to "Must Maintain" and the unit no longer meets the requirements, will the promotion it's set to degrade to instantly appear on the unit, or will the cycle just be broken? (I'm hoping the cycle breaks, then I can use it for education-type-promotions, requiring the unit to remain in the city to earn the second promotion but giving the player the option to leave early if necessary.)

When setting PromotionDegradesTo in a promotion, will the target promotion show up no matter how the master promotion is removed, or only if it degrades naturally?

My chief question is if I set the master promotion to "Must Maintain" and the unit no longer meets the requirements, will the promotion it's set to degrade to instantly appear on the unit, or will the cycle just be broken? (I'm hoping the cycle breaks, then I can use it for education-type-promotions, requiring the unit to remain in the city to earn the second promotion but giving the player the option to leave early if necessary.)

It should degrade to the second promotion if the first is removed in anyway.

If I'm understanding correctly though, you're looking for;

"LearningPromotion degrades to LearntPromotion and you want both to be in the city?"

Assuming LearntPromotion is permanent, then...

LearningPromotion (requires City, mustMaintain, degrades to GraduatePromotion)
GraduatePromotion (requires City, mustMaintain, effectPromotion (which makes it invisible and not reported in text))
LearntPromotion (autoAcquire, requires GraduatePromotion, requires City)

... should do it. The LearningPromotion is lost when you leave the city, degrades into graduate which is lost straight away if not in a city. LearntPromotion is never acquired as you were never both in the city and had the graduate promotion.

===

Won't work for existing promotions (as you need to change the requirements for LearntPromotion - which would be bad for things like Combat) - but would for any new ones. Not sure what the goal is (or if this is even close to it) - but PromotionUpgradesTo and PromotionUpgradeTime (same behaviour, but only triggered by the duration running out) does sound like a good idea for a future addition.

I've gotten lazy and just given the learning promotions a -10 to movement range, forcing the unit to stay in the city until it's finished "learning".

But the way you've explained out there is pretty interesting too. I may try that, I think it's a slightly more complicated but far better way of handling it.
----------------------------
New question: Can you change a unit's religion through a spell or ability?
And if so, as I understand it, do correct me if I'm wrong, the high level religious spells are tied to Divine -> Channeling II/III -> Unit has Religion. Thus a Prior who had been swapped through an ability to say, Octopus Overlords religion would be able to cast Tsunami and Summon Kraken?

Yes, religious spells rely on religion of the unit. I am reasonably certain you can change a unit's religion through python, but nothing has been added directly to the XML to control it so far.

Hmmm. Allright, I can work with that, I think...

Next question! Boy I hope I'm not driving the modmod team nuts here >_>

Is there any way to control a specific unit being built being reliant on a leadertrait, or will I need to make a building that relies on the trait, then make the unit rely on the building? I notice that's how the Scions did it, but I want to make a unit that only upgrades from another unit, so the building thing isn't going to work as well.

Changing religion though python is quite simple.

unit.getReligion()
newUnit.setReligion(iReligion)


Making a unit depend on a trait can be easily handled in python, but not in xml.

That works fine then... now that I think about it I think I know how, with the same can/cannot build lists that other things are tied to. Do'h. Brain just needed a nudge in the right direction.

Building requirements still apply for upgrading units, so it would still work. I don't think there is any better approach for it available right now.

Blocking it off in Python seems to have worked just fine. Thanks again.

With Python I was able to get even more specific and block it off to a single leader, so it worked MUCH better.

Should


def spellLieToOO(caster):
caster.setReligion('RELIGION_OCTOPUS_OVERLORDS')

for

<PyResult>spellLieToOO(pCaster)</PyResult>

work as the only python effects of the spell, or do I need more code than that?

I feel pretty odd about having to ask since MC said it'd be easy, and it looks like it should be easy, but I figure I must have the code wrong because it has all the attached sound/light/fury of the spell I've given it in xml, but does nothing to the unit religion. Obviously I have the rest of the xml stuff coded in, not just PyResult >_>

iReligion is an integer representing the index of the religion in the CIV4ReligionInfos.xml, not the string representing the religion's name.


If you want to hard code it then
def spellLieToOO(caster):
caster.setReligion(2) would work, as OO is the 3rd religion the file lists and it starts at index 0. Using -1 would remove the religion, 0 would set FoL, 1 would set Order, 3 would set RoK, 4 AV, 5 the Empyrean, and 6 CoE. Of course, if you wanted to rearrange the file (so that the religions would be in order based on aliment, for example) then the spells would all be thrown off (as would some graphics if you didn't change the gamefont).


It is better to use:

def spellLieToOO(caster):
caster.setReligion(gc.getInfoTypeForString('RELIGI ON_OCTOPUS_OVERLORDS'))




I'd personally prefer:


def spellConvert(caster, sReligion):
iReligion = gc.getInfoTypeForString(sReligion)
caster.setReligion(iReligion)



<PyResult>spellConvert(pCaster, 'RELIGION_OCTOPUS_OVERLORDS')</PyResult>


So you could use the same python code for multiple xml spells converting to different religions.

iReligion is also what .getReligion() returns, so it should be easy to add a spell that lets a priest spread its own religion to units in its stack. Some weird indexing issues have made it so that it never seems to effect the first unit in the stack when I tried adding such a spell a while back (without risking a crash).

Behold, I have been educated.

The Python if-then-else code is simple, but when it starts pulling things from xml/other sources is where I start to trail off and get confused - which is why having the people who made the mod behave in the first place is an utterly invaluable resource to people like me who are trying to beat the code into a slightly different shape. :D Thanks. And I'm only looking at the unit swapping it's own religion so the final code is fantastic.

Back to religions and Python... is there an easy way to tell if a religion has already been founded? As in a sort of "if religionfounded = getinfo (ASHEN_VEIL)" sort of list?

Additionally a way to tell if the AI/Player in question has any state religion at all?

if CyGame.isReligionFounded(gc.getInfoTypeForString(' RELIGION_THE_ASHEN_VEIL')):

if pPlayer.getStateReligion() != gc.getInfoTypeForString('RELIGION_COUNCIL_OF_ESUS' ):

(getStateReligion() should return -1 if there is no state religion)

I was going to link you to Zebra 9's Civ IV Python API, but then I realized that I had downloaded it and a link to My Documents probably wouldn't work so well.

You are a man among men Magister.

(That's alright, I have google ;-) Found the API myself.)

Allright - is there any sort of setting or code bit I can muck with that makes the AI slightly less stupidly suicidal about tribute when it's a Vassal? With my score at 2564, Dain with one city, a score of 275, and an army of a grand total of two adepts and a mage, with refused to give me his mana in tribute.

How is that suicidal? You can't attack him when he is already your vassal :P

Not sure where you would fiddle with things for that effect. Personally I'd be inclined to move it the other way though (Vassals less likely to grant you mana for free)

LeaderheadInfos:
<VassalRefuseAttitudeThreshold>NONE</VassalRefuseAttitudeThreshold>
<iVassalPowerModifier>0</iVassalPowerModifier>


Messing around with those made the AI less eager to pledge blood and soul to the first civ happening onto Feudalism. Less suicidal is a tall order, but those are the two I know about.

How is that suicidal? You can't attack him when he is already your vassal :P

It's suicidal because when a vassal refuses a tribute, it unvassals and war is automatically declared. Part of the whole Vassal system is the Master has the right to demand the Vassal give up any resources it may have that he wants.

The only reason I bother to Vassal civs is to get access to the palace mana, since even Conquerors can't build the other civ's palaces and still keep their own...

It's auto-war if they refuse? In that case they should be a bit less hesitant I suppose, but it sure doesn't seem right on either end of the scales. Personal preference would be that the capital of any civ which has just been eliminated should spawn a raw mana node if razed (hrm... maybe make the tile of any capital city provide the Mana which the Civ is supposed to embody (and remove it from their palace)? Make it a bit hard for the FF Civs to decide on what to have, but then you'd have a reward if you razed or not).

Probably be slightly easier to create "Relics" for each Civ which are placed in their last city when captured. They would be a building which is mobile (ie - Dragon's Horde) and provides that Civ's base Mana (just the primary mana of the civ, not the full palace). Then you cover both razing and keeping of the city elegantly.

And for vassals, I really think that they ought to cost a TON of maintenance if their score is too much lower than their master's score. That way a vassalization to stop a long and drawn out war (near-equals), or a master who provides for his Vassal will gain the full standard benefits, and someone who cracks the whip to exploit their palace has to pay out the nose to keep them in line.

I dunno. It seems far more thematic for a Conqueror trait - you let them have the administration of the capital city, you handle the main administration of everywhere else and all the effort goes to somewhere.

A lot of it is mainly because there is no such relic system. I'd actually be inclined to create one - python scripting it right? If there's a function to handle discerning if that was the enemy's last city... I could probabaly roll it out pretty fast. Ideally, it'd be a choice for the conqering civ of the three palace mana that civ spawns with, through an event, then it drops the relic which is just Conquest Mana: Law, or somesuch that can be put in YOUR capital.

Alright, now I've gotten myself exited. Is there function for "last city of X civ, run event code X"? Or a nudge in the right direction?

Look at how the Illians trigger the ability ot cast the Awake from Slumber ritual. There is a specific call for when a civilization is destroyed, and whatever pieces of that are exposed to python are linked in with the Illians and nowhere else I can think of right now. Once you identify that call to point out that a Civ has been destroyed, you just have to check what their Unique Building is for the Palace and see what resources it provides for free. Then look at how Hyborem's Whisper works to see how to give the player a 3 option pop-up, design your relics and you are done.

Heck, you could even have a check to see if the Leader (capturing the city) has Conqueror Trait and allow them to pick twice (Or preferably have them get a different popup where they choose one mana to NOT gain. Automatically granting them both Mana in cases like Mercurian/Hippus where there are only 2 Mana anyway)

Look at how the Illians trigger the ability ot cast the Awake from Slumber ritual. There is a specific call for when a civilization is destroyed, and whatever pieces of that are exposed to python are linked in with the Illians and nowhere else I can think of right now.

Hmmm. No dice.

if eProject == gc.getInfoTypeForString('PROJECT_STIR_FROM_SLUMBER '):
if pPlayer.getPlayersKilled() == 0:
return True

It only cares if you've killed a civ - not which one, sadly.

I tried looking at the Python code for the defeat popup messages too, but that seems to be run from a different side of it than I'd need it to be... the idea may need to be shelved for now as I can't think of anywhere else the defeat code might pop up.

I'd look at the callbacks and see if there is one for onCityCaptured next (not onCityAcquiredAndKept or onCityRazed preferably, but if there is no call before the decision is made, then look for both of those options)

If you find such a function, then check if the player losing the city has any other cities (getNumCities) and do it that way.

Keep in mind, that losing the last city, because of the "complete kills" option, doesn't necessarily mean, that the player has lost the game

Keep in mind, that losing the last city, because of the "complete kills" option, doesn't necessarily mean, that the player has lost the game

Hmmm. Point taken - though I've shelved the idea for the time being until I cook up a complete way to do it right, given Jean's note and the fact that I can't even proof of concept it (Couldn't find "capture" anywhere in the Callbacks. Assuming those are stored in PythonCallbackDefines.xml. But I also couldn't find anything related in any of the event managers in Python...)

Anyways, I have a new question for a new problem. I know the two Scion leaders with slightly different trees have their uniques blocked off by LeaderTrait, in the Python code. It even pops up in the Technology Adviser stating it requires you to be the trait, so that's good.

Is there any way to either 1) Have something similar only show up in the Technology Advisor when you meet the requirements or 2) set a unit's requirements in Python so the unit doesn't appear in the Tech Adviser at all.

A little background, so maybe this makes more sense - I want a leader to have a custom set of disciples like the Dural have with Students of *** (only not students.) Anyways, as this is a multi-civ leader ala Decius the only thing I can really do is lock the units away behind a Leader Trait. (Locking the existing units away is easy, and I have no problem with.)

Problem is, doing it this way the unit comes up in everyone's tech adviser (though saying you don't meet the requirements) and I think it might clutter the adviser up too much to have a copy of this for each religion. Hence why I'd even rather them show up for nobody than the leader they attach to (I was wondering if I could assign them to NEVER in the XML but make a python code that gives the leader the ability to build them at the right tech and with the right trait.)

Of course, if there was a way to assign Unique Units to leaders as opposed to civs, that'd be spiffy - but I'm pretty sure there's not or the Scions would be using it...

There was a request for new XML tags some time ago. These are the ones I've just added to the internal version:


iMinNumCitiesConquered: minimum number of razed or conquered enemy cities by this player
iMinNumVassals: minimum number of vassalized civs, including colonies
bFullCiv: name valid for non-minor civilizations
bMinorCiv: valid for minor civilizations
bSovereign: valid for non-vassalized civilizations
bVassal: valid for vassalized civilizations, inlucluding colonies
bColony: valid for colonies
bFemaleLeader: valid for female leaders only
PrereqLeader: valid for a certain leader only

Removed XML Tags: bNoVassal, bNoMinor

I'm open for suggestions to put them to good use. For now I've added "<civname> Colony" for colonies and "<civname> Horde" for evil players running despotism and having at least conquered or razed one city.

I have recently imported some more of the custom promotion fields and must say they make modder's life much easier. Thanks!

However, I run into two problems.
First, does iCollateralLimitCap and related fields really work? I tried them (both in FF and imported to Orbi) and they do not seem to change anything.

Second, iExtraSupport always display as positive, even if the amount is negative. It works fine, only display is broken (again, both in FF and Orbi).

Am I right or it is just some stupid mistake I make... ?

By the way, a small question. The ability to build foreign palaces in tolerant/conqueror owned cities is really broken IMHO. A lot of special features of civs are linked to them, so building one in fact transforms a civ to some kind of hybrid. Any idea how to block it? I tried to and think the fix probably is short and simple, but my programming skills are far from sufficient.
Also, one more complicated question. Is there any way to make sprawling trait increase city radius as normal, but making settlements normal cities limited to one-tile radius?

I haven't written iCollateralLimitCap yet. That a a couple other fields are from when I was just learning how to mod the DLL and I was slowly working my way up from Boolean->INT->String->Array->NestedArray. There were a TON of INT fields to import from UnitInfos to PromotionInfos, and about in the middle of them I wound up needing a couple of Strings and Arrays. Turns out that by that point my learning curve was VERY advanced and I just kinda took off. Haven't made it back to finishing those fields, but since I always did the .h work in advance of the .cpp work they exist, and do nothing (but they are available to python, so I suppose they COULD do something...)


ExtraSupport I made a note to fix for myself, and again.. it got burried because nothing really uses the field. Will have to check that one out again sometime...


But yes, you did proper on the import, my code just contains a few dropped projects still :) And I agree that many of the fields make modding cakewalk :)


To block building foreign palaces, you just have to intercept the ::canConstruct(eBuilding) function with a check like:

if kBuildingInfo.isGovernmentCenter() && getCivilizationType != GET_PLAYER(getOwner()).getCivilizationType
return false;

You can get slightly more complex and make it allow you to build your palace in captured cities INSTEAD of the other person's palace, but that would require me actually opening the code, and then I would get sucked in and try fixing bugs all weekend (got to work on a project instead though).


The settlement modification would be quite simple. I have modified how the radius is applied to city/settlement so that the Worldbuilder control would work a bit smoother, so the main important areas are marked for you (for controlling workable radius). For making the settlements function like a normal city (can build things) you just have to search for isSettlement() across the whole project and you'll see that it shows up at the start of numerous fairly self-explanatory functions (ie - CvCity::getMaintenance(), or CvCity::canConstruct...). Clip the check and return out of those functions you want to re-enable for settlements and you are done (presumably... But if you imported my worldbuilder modification then it is REAL easy to check and be certain)



EDIT:

The fields which are written and don't do anything yet in PromotionInfos are:

iCollateralLimitCap
iCollateralLimitBoost
iCollateralTargetsLimit
iCollateralExtraTargets
iHammerSacrifice
iExtraHammerPerPop
iFoodSacrifice
iPopulationAdd
iBeakerSacrifice
iExtraBeakerPerPop
iGoldSacrifice
iExtraGoldPerPop
iCultureSacrifice
iExtraCulturePerPop
iChanceDieInCombat
iXPTranserRate


Well, the last 2 might not be written yet, but I am pretty sure all the Great Person Mission tags and the Collaterals are written. Till I get around to them (Collateral might happen sometime soonish, the GP ones aren't too likely, though I guess if you just lost the promotion instead of being KILLED then they would be nicer fields which were likely to get used.... Hrm, could be great rewards from lairs actually.... hrm... DAMNIT! This is why I am refusing to open the code BTW. Too many ideas....).

Anyway, till those are written they are just nice bonus fields for someone to utilize in python for their own nefarious purposes.

You can get slightly more complex and make it allow you to build your palace in captured cities INSTEAD of the other person's palace, but that would require me actually opening the code
That would be ian ideal solution :)
I tried the code you posted but could not make it work (not with limited abilities I have). I will then patiently wait till you have time to look into it - that is, if you do not mind...
The settlement modification would be quite simple. I have modified how the radius is applied to city/settlement so that the Worldbuilder control would work a bit smoother, so the main important areas are marked for you (for controlling workable radius).
Well, the problem is the last source I have comes from the main download (26/01/2009), while the last patch dll is from 08/02/2009. I guess it might be added in that gap (as I could not find any wourldbuilder/workable radius marks), but I am confused where to get an up-to date source. Patches do not seem to contain it (tried d to g)...
For making the settlements function like a normal city (can build things) you just have to search for isSettlement() across the whole project and you'll see that it shows up at the start of numerous fairly self-explanatory functions (ie - CvCity::getMaintenance(), or CvCity::canConstruct...). Clip the check and return out of those functions you want to re-enable for settlements and you are done
Thanks - works great. I was able to make settlements to work as I want them to. Well, I was not able to make wonders not to show in city building menu, but they are still unbuildable so it is just my inner perfectionist speaking ;)

Edit: Ok, now I know what you meant. I managed to limit settlements to radius 1 :)

Hrm, the DLL should show up in your Fall Further directory (Mods\Fall Further 050\dll). But the changes for worldbuilder happen in python mostly. Loading up my copy of our official release it claims to have Patch G installed and the button does show up in worldbuilder (select the EDIT CITY mode, choose a city and there is a checkbox just under the city name edit bar)

Wonders aren't buildable, but still show up? That means you placed the block for them inside of an "if (!bVisible)" check. So when it is checking if it should show the button it says yes, but whenever checking to allow you to build it, it says no.


Anyway, next weekend post about the palaces again. Will be spring break for the college, so I'll have half the week off (and spring break for the gradeschool the next week, so I'll have the short half of THAT off...). I finish all my big tests/projects during this week, so I should be pretty free over the two spring breaks.

Hrm, the DLL should show up in your Fall Further directory (Mods\Fall Further 050\dll).
It does, but it seems that source came with the main download and was not updated by patches (and the dll itself was). I tried to unpack patches to other directory and no dll directory was even created (other were fine).
Wonders aren't buildable, but still show up? That means you placed the block for them inside of an "if (!bVisible)" check.
That I did. It was the only thing I tried that did not cause crash when viewing settlements.
By the way, It seems that I placed setPlotRadius(1); in wrong place. It still has 2 plot radius, unless the settlement was build after the city limit was reached... I will keep trying, but if anyone can give me a pointer to a section I should put the code (and tell me if above is all I should insert...), that would save me a lot of trouble. SDK changes are still really painfull...

Edit: I forgot to edit the popup result as well... Now it seems to work.
Anyway, next weekend post about the palaces again. Will be spring break for the college, so I'll have half the week off
Thanks :) I will.

Ah, I'll talk to Vehem about making sure that the DLL file is updated each patch. I'll pack up the last source I have and make it available, should still run fine with the current XML.

Ah, I'll talk to Vehem about making sure that the DLL file is updated each patch. I'll pack up the last source I have and make it available, should still run fine with the current XML.

Ah, that's explains a few things.

And if you hadn't seen, that latest source is on the first post now. It is up to date for FfH patch Y as well.

And if you hadn't seen, that latest source is on the first post now. It is up to date for FfH patch Y as well.

I had, I've almost got the new stuff merged. Thank you so much.

Has the source link been updated with the new patch?

Vehem included the latest source with the patch, so your Fall Further 050/dll folder contains the exact code for this release.

Thank you.

Saw quite a few changes in the lair exploration code, hope it's fixed. :goodjob:

Does the PrereqCivics field work now?

I vaguely remember toying with that briefly... so I can't say for sure if it does or not.

Is it possible to remove features via Python, rather than simply change it to a different type? Tried pPlot.setFeatureType(gc.getInfoTypeForString(),0), but it does nothing... Trying to make it so scorching a plains forest tile has a chance to reduce the forest to scrub. That much works, but I can't remove the forest if it fails the check, so I still have desert forests....

No need for a gc.getInfoTypeForString() call; just use -1.

Ha. I THOUGHT I had tried that, actually, but it turns out I had only made the edit in my mod folder, not in the actual installation... Never made it in game for me to test. :goodjob:

Edit: Doesn't seem to work with features. Thought I had something horribly wrong, so I finally just reduced my code to if pPlot.getTerrainType() == gc.getInfoTypeForString('TERRAIN_DESERT'):
pPlot.setFeatureType(-1) Still doesn't remove the forest. Exact same code applied to improvements works just fine.

Ha. I THOUGHT I had tried that, actually, but it turns out I had only made the edit in my mod folder, not in the actual installation... Never made it in game for me to test. :goodjob:

Edit: Doesn't seem to work with features. Thought I had something horribly wrong, so I finally just reduced my code to if pPlot.getTerrainType() == gc.getInfoTypeForString('TERRAIN_DESERT'):
pPlot.setFeatureType(-1) Still doesn't remove the forest. Exact same code applied to improvements works just fine.

setFeatureType has 2 arguments - the first is the feature, the second is the "variety" (so for trees, that'd be temperate, snowy etc).

pPlot.setFeatureType(-1, -1)

...should remove the feature for the plot.

EDIT: pPlot.setFeatureType(gc.getInfoTypeForString(),0)

That one was almost right, but getInfoTypeForString requires 1 argument, so it'd need to be getInfoTypeForString("") [which is an empty string as an argument]. As Magister said though, no need to do it that way as all it will return is -1. Also not sure what it would make of specifying "variety 0" for a NO_FEATURE - but I suspect that would be ok.

I have got another problem with my code "recycling" ;)

I try to import DenyPromotions promotions to Orbis (want to use it to block fort commanders from being able to get mobility, which is useless for them)

I have some problems with SDK, but the main problems is in CIV4UnitSchema.xml
I have added to the unit part of the file:

<element type="DenyPromotions" minOccurs="0"/>

and following to promotion part (same way it is in FF file - tried placing it in unit part as well)
<ElementType name="DenyPromotions" content="eltOnly">
<element type="Promotion" minOccurs="0"/>
</ElementType>

I get "failed to load CIV4UnitClassInfos.xml". Not the normal "unexpected field", fails to load at all.
Any idea what am I doing wrong? Is there any particular order it should follow? Or any other field that is required for it to work properly?
My knowledge of the schema files is limited, but so far my "cut and paste in the proper order" did work

<ElementType name="DenyPromotions" content="eltOnly">
<element type="Promotion" minOccurs="0"/>
</ElementType>

I get "failed to load CIV4UnitClassInfos.xml". Not the normal "unexpected field", fails to load at all.
Any idea what am I doing wrong? Is there any particular order it should follow? Or any other field that is required for it to work properly?
My knowledge of the schema files is limited, but so far my "cut and paste in the proper order" did work

In this section of the schema, you tell it that "DenyPromotions" contains zero or more "Promotion" elements. If I remember correctly that element doesn't exist in base FfH, but is used for Deny/Allow/Exclude/Replace promotions in FF.

You'll need...

<ElementType name="Promotion" content="textOnly"/>


...somewhere in it - probably best to put it right after the ElementType definition for Promotion.

"content=eltonly" states that the element contains only other elements (in this case a list of Promotion elements). "content=textOnly" states that the "Promotion" element contains only text - in this case, the name of a promotion ("PROMOTION_COMBAT1" etc).

Woot, thank you so much. Working fine now.... Had no idea it had two arguments, although that should have been obvious if I looked at anything setting a feature... :crazyeye:

Is it possible to use pPlot.isRiverSide outside of CvFlavourInterface.py? Trying to adapt it to cause scorching riverside plains result in desert floodplains, but it's just disabling scorch completely.

It should be. I've used it in def doHell to decide whether Obsidian Planes should turn to Scrub or Flood Plains, but haven't tested it much.

If you left the parentheses off like you did there it wouldn't work of course.

Should be quite possible to use it from any python file if already used in one somewhere. Are you certain that the tile you were attempting to cast in was a Riverside tile? (and why would you mess with the prereq at all, sounds like you are trying to make it act different if you happen to be on a riverside)


Wouldn't you have to dig out a lot of land in addition to removing the grass to make a plains become a floodplains? I thought the main point was that it was sub-water level, so when water was high it covered the whole area or something.

Should be quite possible to use it from any python file if already used in one somewhere. Are you certain that the tile you were attempting to cast in was a Riverside tile? (and why would you mess with the prereq at all, sounds like you are trying to make it act different if you happen to be on a riverside)

What do you mean prereq?

Wouldn't you have to dig out a lot of land in addition to removing the grass to make a plains become a floodplains? I thought the main point was that it was sub-water level, so when water was high it covered the whole area or something.

Actually not so much. Quite a few rivers flood their banks, but the vegetation along the river banks tend to slow the water's spread enough that the flood might as well not have happened. Removing the vegetation along flood-prone rivers can drastically extend the range of the floods... Caused alot of problems in some areas of Southern California especially until the residents decided it wasn't worth the floods... the land is now light forest, and used as flood control. It's also the exact thing causing so many problems along the southern Mississippi... Concrete is worse than bare ground at slowing the flow of water.

I'm not going to make ALL desert rivers floodplains, although that's the way Firaxis went. Rather, I'm thinking a 10-20% chance. My code is in defSpellScorch, and is run after plains become desert... Same basic check worked with making forests scrub, but in this case it simply disables Scorch.

if pPlot.getTerrainType() == gc.getInfoTypeForString('TERRAIN_DESERT'):
if pPlot.isRiverSide():
pPlot.setFeatureType(gc.getInfoTypeForString('FEAT URE_FLOOD_PLAINS')

I assumed you were modifying a pythonprereq type of field if it was disabling your ability to even cast the spell. Anything you place in the pythonresult should have absolutely no bearing on ability to cast the spell one way or another. It can just make it have no effect at best.

Cool note on the flooding though. I just assumed the vegetation helped to prevent erosion and thus kept the ground naturally higher.

I think it's better to use isRiver() instead of isRiverSide(), because isRiverSide returns False for one of the plots at the outside of a river bend. And doesn't setFeatureType need two parameters?

I think it's better to use isRiver() instead of isRiverSide(), because isRiverSide returns False for one of the plots at the outside of a river bend. And doesn't setFeatureType need two parameters?

Yeah, I'd actually fixed that after posting. I'll try isRiver().... I have no idea why it's disabling scorch when I'm not touching the req, but it is. :wallbash: