[MODCOMP] - XML Cleanup & Expansion

xienwolf

Deity
Joined
Oct 4, 2007
Messages
10,589
Location
Location! Location!
MODCOMP Version "Massively Out of Date"
(Check the Fall Further thread for a link to the latest sourcecode, and steal the required bits of pythong/xml out of there too. I'm not sure if I'll ever update for base FfH again honestly. I changed so much now that it isn't really practical)


Custom Work

Spoiler Changes I have made personally :
  1. CIV4PromotionInfos.xml
    1. <iWorkRateChange> - Can increase/decrease the Workrate of a Unit. At this point the Unit still needs to have Build Orders available through UnitInfos though.
    2. <bRivalTerritoryExplore> - Can enter other Civilization's Territory without Open Borders.
    3. <bRivalTerritoryBlock> - Cannot enter any non-Team Territory, even with War or Open Borders.
    4. <bPillageOnMove> - The unit will automatically Pillage any Improvements (but not Roads) that it crosses in Enemy (at war) territory.
    5. <bSelfPillage> - The unit will automatically Pillage any Improvements (or road if no improvements present) in Neutral territory or that of your Team (to include yourself). Pillaging won't cost Move points nor provide Gold.
    6. <bGetCasterXP> - Allows the unit to gain XP from Caster/Worker type promotions (so requires the field <iCasterXP> to have a net value among all promotions on the unit to actually do anything)
    7. <bNonWarWeariness> - Loss of Unit does not cause War Weariness.
    8. <bNoMapReveal> - Unit cannot move in such a manner as to reveal new Map space (the pure black areas where you don't even know the terrain yet)
    9. <bCannotCapture> - Unit will not capture units in battle and cannot take Cities (might split this one into 2 seperate fields later now that I think about it...)
    10. <bNonAbandon> - Unit will not Abandon the Civilization when Civic or Religion pre-Reqs are no longer met. Check is performed BEFORE temporary Promotions are lost, so it is possible to keep the Unit even with a 100% chance to wear off each turn, thus forcing you to re-apply it till you meet requirements again. If you make this a MustMaintain Promotion, and have it with the same Civic & Religion pre-Reqs, then you can make it essentially a "1 shot deal" for dodging the Abandonment.
    11. <bCityHappy> - Unit may provide Military Happiness.
    12. <bCityNoHappy> - Unit can no longer provide Military Happiness.
    13. <bCanPillage> - Allows a Unit to Pillage
    14. <bCannotPillage> - Removes the Ability to Pillage
    15. <bCitySpy> - When in a Rival City, allows you to see their Production and get City Detail Zoom
    16. <bNoSupport> - The Unit will no longer cost Military Support
    17. <bStartGoldenAge> - Unit is capable of being sacraficed for Golden Ages. Selection of which units are Sacrificed is largely based on Proximity, so I advise stacking the units you want to use. Thus far the AI doesn't seem to understand this Promotion Field though.
    18. <bNoDefenseBonus> - Unit is unable to gain Bonuses for Defense (neither terrain bonuses nor Fortification)
    19. <bAllowDefenseBonuses> - Unit is able to gain Defensive Bonuses and may Fortify. <bNoDefenseBonus> takes precedence if both fields exist on a unit.
    20. <bMoveImpassable> - Unit may move through Impassable Tiles. Tested with Mountains because it was all I could think of at the time, but should work on Ice as well.
    21. <bFlatMoveCost> - Spends 1 :move: per Tile Traveled, regardless of Terrain Type or Roads
    22. <bIgnoreTerrainCosts> - Can still use Roads, but otherwise spends 1 :move: per Tile Traveled
    23. <bAttackNoWar> - This is <bAlwaysHostile>, it allows the unit to fight everything else without needing DoW, but unlike Hidden Nationality you can still be seen as belonging to your native Civilization.
    24. <bAllowAttacks> - Enables the ability to attack for Units not normally able to do so.
    25. <bFirstStrikeVulnerable> - Removes Immunity to First Strikes
    26. <bIndependant> - Unit does not count toward the National or Team Limits.
    27. <iSlaveGenerationChance> - Percent chance to generate a slave after combat. Adds with UnitInfo field, and thus you could use a negative value if you really wanted to. Also added a text notification for generation of a slave, capture of a unit (like, with Command), or conversion of a unit (Like with Baron Duin), and an indicator on the unit of the exact chance to generate a slave in combat (adds Civic, Unit & Promotion Fields).
    28. <iCombatExtraDuration> - Bonus Number of Turns to Duration from Combat. Can be Negative as well, with fun results.
    29. <iChangeDuration> - Adds a Duration to the Unit, positive or negative. If adding a positive value, you can cause a permanent unit to become temporary, and they have to remove the promotion before the timer runs out in order to become permanent again.
    30. <iDurationAlter> - Modifies the Duration of a Unit like iChangeDuration, but only if it already has a Duration to begin with.
    31. <iDurationPerTurn> - Modifies how quickly the Duration of a Unit will expire. Can be Positive 1 to make them Permanent (until the Promotion is lost), or even larger to enhance their duration greatly over time. As a negative value it causes their duration to dwindle quicker.
      • The Duration Series of Promotions were really designed with each other in mind. An interesting thing you can do is to limit the number of attacks a unit can effectively make. If you set them to gain 1 Duration per Turn, then the Duration is no longer linked to Time. Make them lose 1 Duration per Combat, and you have now placed a limitation on how many fights they can handle before needing to remove the promotion
      • I have modified how Duration displays. The number of turns you have remaining is displayed to account for the Duration Per Turn (it is only displayed if counting down). Below that it displays the total duration points on the unit and the change per turn it is currently recieving. Also, when you will lose the unit at the start of your next turn it displays that information clearly, rather than leaving you to wonder when precisely that last "Unit Dies in 1 Turn" is counted.
    32. <bEffectProm> - Sets the Promotion to bGraphicalOnly (not listed in Pedia) and removes the icon from being seen in-game on the Unit Mouseover, or the Detail screen. Future work will aim to remove the promotion from being displayed on Units who are set to start with an Effect Promotion, and instead display the Promotion's Information as if it was set in UnitInfo (Thus effectively importing all Promotion Fields to UnitInfos)
    33. <iExtraSupport> - Unit will Cost (or Supply if Negative) extra Gold per turn. If costing Gold per turn overall, the value is reduced according to Difficulty Settings. Charged value shows up in the F2 menu as "Extra Unit cost" (Under "Unit Cost" Mouseover) and is the same as the Unit field iExtraCost.
    34. <iCombatDmgCapBoost> - Kael added a Hard Limit function to Promotions to bring the combat Limit down, but I wanted something more flexible, so I have added a modifier which can be positive or Negative. This is applied to the lowest limit on the unit via UnitInfos and Kael's tag, and cannot bring the combat limit below 0 or above 100
    35. <iChanceMiscast> - Modification to the Miscast Chances via Promotion. Positive and Negative values are both allowed.
    36. <bRequireCity> - The Promotion can only be acquired while in a City
    37. <iGoldCost> - Promotion is Purchased with Gold rather than Experience (No Level is gained for doing so). If a negative Value is entered, you gain Gold when taking the Promotion
    38. <bStackEffect> - The Promotion may be gained or lost multiple times. No graphical effect to signify that this has happened, but all of the modifications from the promotion will happen to the unit.
      • Thus if you make Combat 5 be StackEffect, then you have essentially made an unlimited number of total Combat Promotions (every Level they can buy Combat 5 again for another 20% bonus).
      • This has some drawbacks of course. The unit still only has 1 of that promotion, so only 1 of them will be automatically removed (if you make Hasted StackEffect, then you can cast Haste on a unit 20 times in a turn to gain 20 move points. But at the start of next turn they lose the Hasted Promotion 1 time, meaning they still have 19 more move than normal...).
      • The fact that the promotion can be removed even if the unit does not have the promotion means you must be very careful with this tag, because a lot of code in the game will not check if you have a promotion before removing it. Thus if you make Withered be StackEffect, then every time you walk across the Pool of Tears you would GAIN stats inverse to what Withered normally removes from the unit!
    39. <bAutoAcquire> - As soon as the Pre-Reqs are met, the Promotion will be applied to the unit. That means the moment it would normally ask you to select a promotion for your new level (unless you flagged it bNoXP as well), or as soon as you get enough gold, it will steal that from you and apply the promotion. Of course, if the Promotion doesn't actually cost anything, then it is just free and instant (and unaviodable)
    40. <bMustMaintain> - If the unit ever fails to maintain the Pre-Reqs for acquiring the Promotion (access to Resources, appropriate PreReqPromotions, MaxAge...) then the promotion is removed at the start of the next turn. The only PreReqs which are ignored would be having XP or Gold to spend on the Promotion.
    41. <bNoXP> - The Promotion will not require XP to gain, the Unit will not gain a Level, nor Heal, upon selecting to take the promotion
    42. <NewName> - Replaces the Unit's natural <Description> flag completely. You can still rename the unit and will wind up with something like "Sidar Killer (<NewName>)" instead of the normal "Sidar Killer (<Desc>)"
      • Has been exposed to Python for manipulation as CyUnit.setNewName(STRING) and CyUnit.clearNewName()
    43. <CityBonuses> - SubTypes are <CityBonus> entries, subs of those listed below. Unlimited entries are allowed of any mix among the elements. Only those elements used need be included. Many more elements can easily be included in the list, these ones are just my initial thoughts for the setup
      1. bApplyEnemy - This City Bonus list will apply to Enemy Cities
      2. bApplyRival - This City Bonus list will apply to Rival Cities
      3. bApplySelf - This Bonus list applies to your own Cities
      4. bApplyTeam - This bonus list applies to your teamates' cities (but not your own, must set previous tag for that)
      5. 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
      6. fDefense - Adjusts the Defense Bonus of the City Tile
      7. 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
      8. fFood - Modifies the food gained each turn in the city
      9. fFreeXP - Modifies free XP granted to all Units built in the City
      10. 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
      11. fGPP - Adds/removes untyped GPP to the Cities pool
      12. fHappy - Modifies the number of Happiness/Anger in the City
      13. fHealth - Modifies the number of Health/Disease in the City
      14. fProduction - Modifies Cities Production per turn
      15. fTradeRoutes - Changes the Number of Trade Routes the City has Available
      16. 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)
      17. fDecayRate - Modification to all nonzero values listed in this Bonus List for every tile between the unit and the City being affected
    44. <PrereqLevel> - Sets a Level Requirement for Gaining a Promotion. If Negative, makes the Promotion unavailable for gaining by XP (so PreReqTech NEVER is no longer needed). Main benefit of blocking promotions this way instead of through TECH_NEVER is that it will actually display right on the promotion that you cannot gain it via XP.
    45. <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)
    46. <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)
    47. <PrereqUnits> - Multiple entries allowed list of Unit Types required to gain a promotion
    48. <PrereqReligions> - Multiple entries allowed list of Religion Types required to gain a promotion
    49. <PrereqCivilizations> - Multiple entries allowed list of Civilization Types required to gain a promotion
    50. <PrereqCivicORs> - Multiple entries allowed list of Civic Types required to gain a promotion
    51. <PrereqTechANDs> - Multiple entries allowed list of Tech Types required to gain a promotion, all are required
    52. <PrereqTechORs> - Multiple entries allowed list of Tech Types required to gain a promotion, at least one from the list is required
    53. <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
    54. <PrereqTier> - Tier required to gain a promotion
    55. <PrereqTerrains> - Multiple entries allowed list of Terrain Types required on TIle to gain a promotion
    56. <PrereqImprovements> - Multiple entries allowed list of Improvement Types required on Tile to gain a promotion
    57. <PrereqFeatures> - Multiple entries allowed list of Feature Types required on Tile to gain a promotion
    58. <PrereqCorporations> - Multiple entries allowed list of Corporation Types required to gain a promotion (have that Guild in any city)
    59. <PrereqBuildingANDs> - Multiple entries allowed list of Building Types required to gain a promotion, all are required in current City
    60. <PrereqBuildingORs> - Multiple entries allowed list of Building Types required to gain a promotion, at least one from the list is required in current City
    61. <PrereqBonusANDs> - Multiple entries allowed list of Bonus Types required to gain a promotion, all are required
    62. <PrereqBonusORs> - Multiple entries allowed list of Bonus Types required to gain a promotion, at least one from the list is required
    63. <PrereqTraits> - Multiple entries allowed list of Trait Types required to gain a promotion
    64. Locality Series - These 5 are individual tags, but follow a common theme and are essentially linked to each other. If none of these are set, then things work as normal and the territory the unit is in will be ignored. However, if any one of these 5 are set, then at least 1 of them must be satisfied for the promotion to be available.
      • <PrereqInBorderEnemy> - Available when in the Cultural Borders of someone whom you are at war with
      • <PrereqInBorderNone> - Available when outside of all Cultural Borders
      • <PrereqInBorderRival> - Available when in the Cultural borders of someone whom you are not at war with, nor share a team with
      • <PrereqInBorderSelf> - Available when inside your own borders
      • <PrereqInBorderTeam> - Available when insde the Cultural Borders of a Teammate, but not yourself
    65. <PrereqEventANDs> - Multiple entries allowed list of Event Types required to gain a promotion, all are required
    66. <PrereqEventORs> - Multiple entries allowed list of Event Types required to gain a promotion, at least one from the list is required
    67. <PrereqFeatANDs> - Multiple entries allowed list of Feat Types required to gain a promotion, all are required
    68. <PrereqFeatORs> - Multiple entries allowed list of Feat Types required to gain a promotion, at least one from the list is required
    69. <PrereqFeatNOTs> - Multiple entries allowed list of Feat Types required UNCOPLETE to gain a promotion, all entries must be uncomplete
    70. <iExtraDropRange> - Grants the Unit a Paradrop Range (Personal Teleporting capability), or adds to an already existing range.
    71. <iAirCombatLimitBoost> - Enhances (or reduces if negative) the Air Combat Limit of the Unit.
    72. <iAirCombat> - Grants the unit an AirCombat value so they can make ranged attacks

  2. CIV4LeaderHeadInfos.xml
    1. These 4 tags are all added to facilitate the CityBonuses field fProximityDiplo from PromotionInfos
      • <iProximityMemoryDecayDelay> - Defines a number of turns which must pass without any new adjustments via fProximityDiplo before the Attitude adjustment will begin to decay.
      • <fProximityMemoryDecaySpeed> - Defines a minimum speed of decay per turn (after the delay) for the Diplomacy Value
      • <iProximityMemoryDecayRand> - Random Cap on a Percentile bonus to the DecaySpeed per turn (so if set to 100 the decay rate can be up to twice the minimum per turn)
      • <iProximityMemoryLimit> - Maximum value the fProximityDiplo Bonus can affect this Leader by (both Positive and Negative)

  3. CIV4ProjectInfos.xml
    1. <iRevealAllBonuses> - Number of additional Turns for which the Player's Team will be able to see all resources on the map (Does not allow connection of the resources for City Trade, still need the appropriate tech - if any - to accomplish that). Duration modified by Gamespeed
    2. <iSeeInvisible> - Number of additional Turns for which the Player's Team will be able to see all Invisible Units in their Territory (Empyrean Shrine Effect). Duration modified by Gamespeed
    3. <iHideUnits> - Number of additional Turns for which the Player's Team will be able to hide all their Units inside Culture Borders but not Cities (Nox Noctis Effect). Duration modified by Gamespeed
    4. <bPrereqWar> - Requires that you are in an active War to start the Ritual
    5. <iBlockBonuses> - Causes all Bonuses to become Obsolete for anyone whom you are currently at war with
    6. <iRestoreBonuses> - Decreases the level of BlockBonuses affecting your team
    7. <bPrereqBlockBonuses> - Requires that you have a non-zero BlockBonus Count to start the Ritual

  4. CIV4SpellInfos.xml
    1. <bSummonMaster> - If the unit was summoned (Has a Master Unit), it will call that Master Unit to the current tile (if the Master Unit is allowed to be on that tile).
      • AI has a fairly solid grasp of how to use this function to keep the Master Unit alive and make strikes of opportunity.

  5. CIV4GoodyInfos.xml
    1. <iScience>, <iScienceRand1>, <iScienceRand2> - Functions like iGold and partners to grant research toward current Tech being researched. These values are Percentages, the first is guaranteed and each of the others are random caps. So you could set iScienceRand1 to 100 for a completely random addition of Research, or set iScience to 100 for a guaranteed finishing of current research. These values can be negative as well as positive, and will never provide overflow research. Percentage is modified by gamespeed, so on Marathon games you will gain 1/3 of the listed percent, and on Quick games you will gain ~130% the listed. Thus to get a free Tech (just started researching it) on Marathon, you would need a Science value of 300 after both Randoms, but to get a free tech on quick you would only need a 67 after both randoms.

  6. CIV4TraitInfos.xml
    1. <iModReligionSpreadChance> - Percentage Modification to chances of Religion spreading (passive only, pending AI understanding for Disciples). Value can be positive (100 means twice as likely) or negative (-100 means will not spread). A value below -100 will prevent Holy Cities from being founded by the player should they discover a Tech capable of Founding a Religion. So far the Holy City will not instantly spawn for the next player to acquire the technology, but it will show up naturally at some point.

  7. CIV4FeatInfos.xml
    1. Moved all Feats out of the DLL and into the XML. This is done with a file in the Assets/BasicInfos folder. Current fields are just the type of Feat and a Description. Descriptions are intended to be used when a Feat is made a Prereq Item for a Promotion.
  8. Added Religious HUDs as a GameOption. Also includes new Non-Religion HUD courtesy of seZereth
  9. Added a Gameoption to disable Unit Building/Upgrading Level Requirements for the AI
  10. Added a Gameoption to enable Broader Alignments
  11. New Widget Type defined for Tooltips on Armageddon Counter and for Tooltips+Action on Slave/Master buttons

Modifications Borrowed from Other Users:

Spoiler Incorporated Mods :
  1. Dom Pedro's Food from Animals
    • New Fields to allow Yields and Commerces to be gained by Combat
      • Basic MODCOMP provided fields in Traits so that all your units can gain when they win, and fields in Units so that when the unit loses the victor gains.
      • My Revisions make Promotions able to allow for either one, though Traits are still the only place where you can get a percentage modifier.
  2. New Default screen by seZereth
  3. Grey Fox's Broader Alignments (With modifications by Vehem) - Places Alignment on a Sliding scale setup so that more than religion can affect your standings. No graphical inclusion so far (Alignment Meter), nor any feedback on precise alignment score.
    • Includes PyPostCombat Win & Lose functions and a SpellRange Modification tag for Promotions
  4. Decimal Happiness Rates by Vehem - Feature, Improvement, and Garrison Happiness can now be non-integer increments (the XML still needs to be an integer, but the value in divided by 100 for processing in the code & Display)
  5. Growth Control by Vehem - City Gaining/Losing of Population based on Food exposed to Python
  6. Jean Elcard's FlavourMod 2 - Sets Start Locations to be flavorfully appropriate for each Civilization. Gameoption.
 
Gameplay Changes

Most of the work I have done with this MODCOMP simply adds new tags. If you were to place the DLL in your main FfH folder it would still work exactly like normal FfH, except for a few small changes. Those are listed in this post.


  1. Mouseover Tooltip for Units with a Workrate will show that Workrate
  2. Mouseover Tooltip for Units with a Chance to Enslave will show that Chance
  3. AutoRaze will pillage Improvements, yielding Gold for the Pillager, and only moving the Improvement down 1 level instead of completely clearing it. It still removes Features however.
  4. Circle of Gaelan will spread to cities with Free Mage Guilds from the Catacomb Libralus
  5. Kidnap Spell will allow a random selection of which settled Great Person is Kidnaped, rather than having a flat order of preference
  6. Guardsman Promoted Units will ALWAYS be selected to defend against Marksman Promoted Units if present in a stack (strongest Guardsman selected first)
  7. Enabled the Power Graphs (F9)
  8. Extra Gold Cost value on units can be Negative, and Support Costs for Units can provide Positive Yields.
  9. Unit "Age" is displayed on Mouseover. This value increments based on Gamespeed selected (1/3 rate on Marathon, and ~150% rate on Quick)
  10. Units will not gain FreePromotions all over again if Gifted/Dominated
  11. If a Unit is set to have a Delayed Death, it will be stated on the Unit
  12. Plots will show if a Tech is still required to connect the resource even after they have the proper improvement placed
  13. Any Immortal Unit will be set to UnitAI_Attack_City at the start of each turn to enhance aggression factors
  14. Spells which provide a Summon Perk which includes enhanced movement will also extend the range of most other spells (ie - Spell Extension)
  15. Units will not pass Limited Duration on to other Units when Capturing them
  16. Summoned Units now display who summoned them (specific Unit)
  17. Limit of 1 Permanent Summon per caster is now directly linked to the specific caster and Summon. Thus you cannot have 20 units CAPABLE of summoning skeletons, but only 1 unit who actually DID summon your 20 skeletons. But at the same time, should you get a bonus pair of skeletons by conjuring one while on a Graveyard, that doesn't mean that now 2 of your other units are unable to conjure skeletons of their own
  18. While the Master Unit is selected (Summoner) icons will be displayed for each of his Slave Units (Summons) allowing you to view their information or select them. Each Slave Unit will also have an icon for their Master for the same purpose.
  19. Nox Noctis Invisiblility is defined by the INVISIBLE_TYPE in GlobalDefinesAlt.xml, which is currently default INVISIBLE_LAND.
  20. Chance to adopt a religion is leveled out to be a flat chance to gain your state religion, and then a flat chance to gain any religion in the city, even probability for each present religion
  21. If Withdrawal Limit is exceeded, only promotions which add more withdrawal are blocked, not every promotion.
  22. Added a "non-Promotion" Promotion so that units which have no remaining available promotions may still spend XP to gain a Level and Heal themselves.
  23. Minimum Level for a Tile does not apply to a Team if the Tile is also a City belonging to that Team.

Non-Code Changes
  1. New Cursors for Recon, Rebase & Airlift (Obsidian Gate)
  2. FfH version of Recon & Rebase Buttons enabled
  3. Replaced Pearls Resource Icon with a Pearl
 
Requested Additions

This post is to track additions other people have requested from me. If you would like me to add something and it is not listed here, either I explained to you why I don't really want to do it (probably not capable of it, or it would alter the basic gameplay too much), or I missed the request (so ask again...)

  1. Magister's Dreamlist:
    Spoiler :
    1. National/World limits on Promotions
    2. Allow an Array for Bonuses provided by a Building (thus unlimited Resources allowed, and different types of each)
    3. Allow an Array for Bonuses Denied into a City by a Building (boolean deny)
    4. Allow Settlers to create cities with initial Population/Buildings, based on Level or new Promotions
    5. Expose canPromote to control by Python
    6. bTerritorial - Blocks non-Team, non-Aggressive units from moving onto the tile
    7. Array of Build Orders allowed by Promotion
    8. :strength: bonus based on Owner's Culture on Tile
    9. Decimal Affinity, and ability to alter more than :strength: with Affinity
    10. Give specialists bonus commerces/yields from buildings only in the city with the building
    11. Civic and Buildings global free xp broken down by unitcombat
    12. Civics block Resources
    13. Civic Modify Resource Happiness/Health on Fractional/Percentile base (to allow negative & 0 as well)
    14. Civics can cause Unhappiness in other Civilizations which lack Specific Resources
    15. Civics can cause penalties for not having a resource which other people DO have
    16. Allow Promotions on Move from Buildings to be granted to Team ONLY
    17. Tier requirements for spells
    18. PyOnMove for Promotions
    19. Decimal Military Happiness from Civics
    20. Health modifier for Units Garrisoned on City Tiles tied to Civics
    21. Allow Liberation of Colonies to be Single City Liberation and on the same landmass (this code might help)
    22. Allow Gifting Cities to Vassals
    23. Allow Multiple Entries to be listed in Derivative Civ
    24. Buncha stuff
    25. Make AirCombat strength be handled more like normal combat, where you can have different damage types and boost it by promotions
    26. And allow to change the cap with promotions
    27. Let ranged units get some xp from their more successful attacks
    28. CIV4FeatureInfos.xml, CIV4TerrainInfos.xml, CIV4ImprovementInfos.xml, and CIV4BonusInfos.xml all have equivalent tags for everything (to include Flammable & Temporary)
    29. Allow changes to the above items while they are in Temporary form to make them Permanent
    30. Culture from Improvements MODCOMP integration
    31. Integrate Improvement PreReqs MODCOMP
  2. Add Playable and AI Playable Tags to LeaderHeadInfos (Kasdar)
  3. Add Production/Food per City via Trait (Kasdar)
  4. Add to BuildingInfos the ability to change the yields of any type of terrain (and change multiple types seperately) (Kasdar)
  5. Alter Tile Yields as well as Health/Happy via Trait - ie: +1 :hammers: from Tundra (Ahwaric)
  6. Nomadic Tag added to TraitInfos to allow a Civilization to exist without any settled cities, but maintain Trade Relations and ability to gain research/techs. Also will enable RequireCompleteKills for the Civilization (Ingvar)
    • Might instead add a check to the kill function for a player which checks for units having a certain flag AND cities. Thus you would have to have a mobile city to still be considered "Alive." Probably this will NOT be <bFound> which Settlers already use
  7. Include Resources in CityBonuses and allow each unit to provide multiple varrying amounts of each resource (2 Cows, but 1 Pig) (Ingvar)
  8. Allow Improvements to join the "Culture War" by providing a Culture Per Turn value and having a predetermined (Max) range. Culture Borders expand from the improvement just like it would from a City (Mailbox)
  9. Add Food as a reward possible from GoodyInfos (Ahwaric)
  10. Allow UnitInStack prereq for Promotions (Tarquelne)
  11. And PromotionInStack (Magister)
  12. A new set of fields similar to invisibility which controls if a unit can attack another unit or not, rather than full visibility (so a flying unit could not be attacked unless the ground unit has specifically listed the ability to attack flying units) (Farmer Bobathan)
 
Does this have the ambassador promotion in it, or is that still in the worker mod?

EDIT: I see that the tag is. Just out of interest, would it be too much to change it so that disciples can get the ambassador promotion?

EDIT2: Whoops. I thought this was the promotions, not the fields.
 
Well, the promotions do exist in there, but the majority of them are not setup to be available to any Unitcombats. However it is quite simple to modify the XML so that it is avilable to those whom you want it to be available for. I reccomend Notepad++ personally (for the ability to collapse/fold tabbed sections).

You just have to search for <Type>PROMOTION_AMBASSADR</Type>, look down a couple lines and you should see <PreReqPromotion>PROMOTION_MOBILITY2</PreReqPromotion>. You'll have to change that since Disciples cannot get Mobility 2 (or if they can then they are already able to get this promotion). Then search for <Unitcombats> and add Disciple to the list (right now it only lists the same Unitcombats that Mobility 2 is available for).



Disciples is actually the perfect Unitcombat to gain Ambassador now that you mention it. Then you can spread religions without open borders. You could even set it up so that Spiritual automatically grants all Disciples Ambassador.

Actually, thinking about the Promotion now... it'd be an excellent Racial Promotion for the Elohim...



PS - Ambassador was removed from WorkerMod since people complained about it causing some random glitch which I wasn't able to reproduce, and thus couldn't fix.
 
Great stuff!

So many questions!

Is this the project with which you intend to make everything in the UnitInfos available for modification via Promotions?

Can you make the development code-word for released Projects public? :)

Requests? I wish I could remember all the "Can I do this via a Promotion? No? Well, dang." moments I've had...

Is "Minimum level required" the sort of "i" request you're accepting? (And would you be adding that anyway since it's part of UnitInfos?)

How about a tag that will "Add population" or "Reduce population" if a unit is disbanded in a city or created in a city, respectively.

Could a boolean tag switch between two ART_DEFs?

Could you explain more about bGetCasterXP?
 
Is this the project with which you intend to make everything in the UnitInfos available for modification via Promotions?

Yes, this is where I am adding things from UnitInfos to PromotionInfos. But I don't think I am going to be stopping at that. Should good ideas come up for other areas of the XML to have added values I will happily add to them. For instance (and no, I am not capable of this quite yet), you could add a PyPerTurn to Improvements. This would allow you to do the scanning of the improvements on the map using C++ instead of using Python, which is supposedly faster... Not sure if it is a better method, but seems to me like it is.

Even if I do not add fields to other areas of the XML, I do plan to condense the XML all as much as possible by setting fields to be optional.

Can you make the development code-word for released Projects public?

Yeah... I got no idea what you just asked me :) If you mean "Can you allow Search Keys so I can see what you did?" then they are included, and I try to remember to check that each one is unique so that you ONLY see what I have done. Plus they have information from me on precisely what is going on in the code at that point.

Requests? I wish I could remember all the "Can I do this via a Promotion? No? Well, dang." moments I've had...

Well, bookmark the thread or something then :p

Is "Minimum level required" the sort of "i" request you're accepting? (And would you be adding that anyway since it's part of UnitInfos?)

As a copy of the field in the UnitInfos, this one would make no sense. Seeing as a Unit cannot exist to modify at all until they have already satisfied this flag. As a requirement just to attain the Promotion... I hadn't thought of that, but I like it. Thus far I hadn't planned on doing any Pre-Req type fields, and I wasn't moving anything which is a Pre-Req type over from the UnitInfos (again, because those moves are to simulate the UnitInfo flag, and simulating Pre-Reqs doesn't work, since you can't get a Promotion till you have met Pre-Reqs :p)

Pretty sure I know precisely how to add a Level Pre-Req to Promotions, and it's really a fun idea.

How about a tag that will "Add population" or "Reduce population" if a unit is disbanded in a city or created in a city, respectively.

Reduce Pop on creation would have to go in UnitInfos. Nice idea though, so also noted for later (though might already be there. Can't remember if Beast of Agares uses XML or Python for that). I could allow a promotion field to increase City population, but I'll file that as an INT value, since for 1 you could just use the Add To City spell.

Could a boolean tag switch between two ART_DEFs?

Don't think you need it, any promotion can control the ART_DEF... Am I mistranslating?

Could you explain more about bGetCasterXP?

The field <iCasterXP> is used on Channeling promotions to allow the casters to have a chance per turn of gaining XP. Give this same promotion to a warrior & he gains no XP at all. This is because the warrior doesn"t have <bFreeXP>1 in Unitinfos.

This new field fixes that by acting like the warrior DOES have that flag set.



Uploaded new version that is now ONLY a Modcomp. No new promotions are available outside of Worldbuilder, and WorkerMod is removed from the code.

XML is now commented as well. Including the Schema. And the fields are now in alphabetic order.
 
A minimum level requirement would be quite good. There are some promotions that I'd like to see only for very experienced units, but not requiring a specific promotion path be followed for prereqs.

<bAlwaysHostile> is a must. The same goes for <bTerritorial>


Ok, so these aren't boolean or integers, but I'd really like to see promotions with a prerequisite civilization (so, for instance, Hippus mounted units not built in a city with a hippus stable, or upgraded from a different unitcombat, could get horselord) and also prerequisite unit religion (state religion prereqs were added in BtS).

It might be a better idea to (instead or additionally) expose "bool CvUnit::canPromote(PromotionTypes ePromotion, int iLeaderUnitId) const" to python.



Could you go ahead and include the changes from Broader Alignments? I mostly mean the things that don't directly have to do with alignments (pyPerTurn for units, <PythonPostCombatWon> and <PythonPostCombatLost for promotions, <iSpellExtraRange>1</iSpellExtraRange> for promotions), although it could be nice if to you just went ahead and merged them entirely too (probably releasing an alternate version with the alignment tags)

I'm still thinking mostly of promotions that you probably won't be able to add for a while. I think that spells should have prerequisite resource, prerequisite improvement, and prerequisite building (only used together with <bInCityOnly>1, of course) tags.

There are lots of places I'd like to change to allow an arbitrary number of things (promotions of resources for example), and to allow "or" requirements, but that may be a ways off. In the mean time, adding more promotion prereq tags to spells and more free resources from buildings could be useful.

Not exactly relevant, but it might be good to make the promotions granted by buildings with <bApplyFreePromotionOnMove>1 only apply to units of your team. That way Hippus horsemen could always get the promotion later, and could share the bonus with a permanent ally (but not just any rival with open borders).
 
Yeah... I got no idea what you just asked me :) If you mean "Can you allow Search Keys so I can see what you did?" then they are included, and I try to remember to check that each one is unique so that you ONLY see what I have done.

No I mean, like, this is "Project Omega". Or "Project Poof Bunny." ;)

Pretty sure I know precisely how to add a Level Pre-Req to Promotions, and it's really a fun idea.

Yep, that's what I meant. A few times I've wanted something sort-of in between a unit upgrade and a promotion.

Reduce Pop on creation would have to go in UnitInfos.

Ah, right. That'd make a lot more sense. :)

Hmm... OTOH, I can see an nasty Promotion requiring a sacrifice, too. A unit given full suits of armor made from human bone, for example.

Don't think you need it, any promotion can control the ART_DEF... Am I mistranslating?

No, I was just ignorant. :)

This new field fixes that by acting like the warrior DOES have that flag set.

Ah, ok. Thanks.

Can a promotion be turned on/off upon city entrance within the XML? Or is that a tag request? :)

Hmm... thinking about the min. level thing, too, I guess a nice thing about promotions is that you can take them away again.

And the fields are now in alphabetic order.

Thats very handy!
 
Turning a Promotion On/Off in a city is best done with a building that grants the promotion for free, and then have the promotion wear off 100% of the time. Though that is pretty dependant on the order in which things are done in the processing of a turn.

Hmm... thinking about the min. level thing, too, I guess a nice thing about promotions is that you can take them away again.

Sounds like you have an idea, but I don't have a clue what you mean :)
 
Having the building grant an expiring promotion would not work that well for turning promotions on/off, imho. It could grant promotions to the units, but they would not be removed as soon as the unit leaves. It would probably last until the end of the turn or the start of the next. Also, how could it temporarily remove promotions? You might have to add some other promotion with a pyPerTurn effect of giving the promotion when not in a city. (The same method could be used for granting the promotion, but it would be awkward.)

That was one reason why I was requesting a pyOnMove function for promotions and maybe also units. However, I think I can just use mtagge's "opp fire and unit promotion giving" python modmod for now.




Currently the <iTier> tag in CIV4UnitInfos.xml doesn't do anything. I'm thinking you should either remove it or add <iPrerequisiteTier> tag to both promotions and spells (requiring the unit's iTier tag be equal to or higher than iPrerequisiteTier in order to promote it or cast the spell)


Are you planning on borrowing any code/tags from/merging this with Broader Alignments? If not, I guess I'll have to do this my self. I'm also thinking of including UnitStats and maybe FfH BUG, in case someone feels like doing that work for me too :D
 
True, it wouldn't really be possible to remove a promotion with a building, just possible to apply the exact opposite of it, if the fields exist to cancel them.

Uploaded a new version with 10 more fields added. I changed how HN units are treated with Cities. They can no longer be attacked in them, nor can they conduct attacks against them.

At present I don't plan to integrate any other people's DLL changes, since they already exist for people to use and the primary goal of this project is just to provide material for use. Eventually I will be using this as a base for my own Mod most likely, so at that point I would probably integrate other people's changes if I find them useful.

I also don't intend to remove anything from the code. Uses can be found for them, like using the iTier as a pre-req for various things.
 
I just downloaded the modmod and glanced through the promotions and unit schema. I noticed that my requested <bTeritorial> is not listed among the new additions, but it does seem to be implemented. I'm too busy to play because of finals, but may I assume that this is working too? Are there actually 27 new fields working, instead of 26?

Edit: I just reread the first post. May I assume it is in, but not functional?

I really preferred making iTier a promotions prereq rather than removing it anyway.


It may be a while before you get to implementing this type of thing, but I think a <BlockAlignment> tag (like in the civic infos) would be good for units and buildings. In my modmod, I plan to make priests need their religion for their spells, not for building them, but letting Good Civs build AV priests seems wrong. Alignment restrictions for spells would be good too. I can easily block these in python, but then it wouldn't be as well documented.

Oh, wait, I'll probably be using Broader Alignments anyway, so I should already be able to provide alignment cutoffs. Never mind :D Alignment requirements for promotions and build orders could still be nice though. Religious prereqs too. For now though, I just that canPromote really needs to be exposed to python.


Any chance you could implement the mechanics I'd plan to use for Homeland? That is, allowing promotion to provide combat bonuses based on the percent of the owner's culture.

Bonuses based on the plot counter could be good too.
 
Actually if you had looked in the previous releases there have been 24 fields ever since the upload after RivalTerritory was added (2 of which got dropped just before I posted because they were not acting quite right, and were VERY rare use fields. One to block <bImmortal> and another to block <bIgnoreBuildingDefense>). They are in the DLL as allowed variables and fully declared to have text keys, but they are not integrated into the programming to actually do anything.


Doing the entries this way allows me to do one really big compile and ensure that I have a bunch of repetitive functions set up properly, then allows me to go in later and make the promotions actually accomplish something with much quicker Compiles (the trick is the *.h files. Change one of those and you have to recompile every file. Change only the .cpp files and you only recompile that single file. The difference on my laptop is ~50 Minutes as opposed to ~2.

However, since your field is implemented, and I am exposing all new fields to Python, you could start working with it through Python. In fact if you figure out how to make it work with Python that might point me in the right direction for making it work in the DLL.



That reminds me: I would also like people to request fields which need to be Documented in the Pedia. It is really easy for me to make something display in the Unit & Promotion Help (Mouseovers), and I imagine just as easy in all other areas. So let me know what you want added to the automatic displays and I'll work them in.


Not quite sure how to expose an entire address section to Python yet. From what I have run into I think that I just have to call Python from within the section and allow it to provide feedback, but I think that I have to know the section of Python which is going to be used. I suppose that means I can create a new canPromote section in Python... but I'll have to keep my eyes open on that one.


I haven't attempted to play with combat odds quite yet. It is something which I want to do eventually, and I think the first goal will be to ensure that all combat odds adjustments are displayed properly in the Right-Click menu (mainly so I can then evaluate anything which I add). Combat calls a rather huge and complicated function which I will be slowly documenting as I borrow things from it and realize what precisely they do :) I just now realized that I ought to open it up in Notepad instead of Codeblocks for a little while so that I can collapse layers as I figure them out.

Also, I have to remember precisely how to use CASE arguements. They are basically a rapid-fire way to do a ton of IF statements as I recall, but of course only if all of the IF statements are an IF of the same thing, which these ones fairly rarely are. But in some sections there are a couple dozen IF statements in a row which can easily be brought into a CASE.
 
Is it possible for you to make it so that all the new promotion fields are able to not be in the xml without errors?
 
Every promotion I have added is optional for inclusion in the XML (read: You only have to have that field exist on the Promotions which have non-zero values. All other Promotions will continue to work without re-writing them). I am about to go through and make a lot of the already existing fields optional as well.

While I do test each promotion field as I make it have an actual function, it is entirely possible for something to slip through the cracks (like that wierd report of Hunters without Ambassador ignoring Closed Broders). Anything you notice please feel free to report.
 
It is not only possible, thats the way it is it now. They all have minOccurs="0"

However, I think that there are some types of tags that may be added in the future which must occur every time.

I'm thinking it is probably a good idea to make most of the normal promotions also have minOccurs="0", to reduce the file size and make them easier to read/edit.

Edit: xienwolf beat me to it.
 
I'm sorry (and feel stupid :lol:) but I didn't completely understand the explanation in the first post and just wanted to know before I downloaded. You probably would have gotten this question eventually just I was the first to ask :D.
 
Will there be a new version coming out soon, or should I go ahead and start merging this one to get ready for my modmod?

I had thought that I'd have to get everything I planned to use downloaded tonight and work on it at home (where I'm stuck with dial-up), but it looks like I may be staying at school with nothing else to do until Sunday. I just finished my last Final, but it seems my family is too busy to move me out tomorrow afternoon (and I'm too lazy to move in the morning), and would rather be wait until they can just move my stuff into my summer room (although I would then go home for the week before classes start).
 
There will not be a new version for a little while. My first final is tomorrow and my last one is in a week. I have a lot of plans for adding to this after that point though. I would say that overall I am possibly 3% done with all changes I intend for the DLL.
 
Top Bottom