AdvCiv Manual
AdvCiv Manual
by Georg W. (firpo)
User Manual
AdvCiv is a mod for advanced players, building on karadoc's “K-Mod: Far Beyond the
Sword.” AdvCiv does not add content, and makes only few notable balance changes apart
from changes to the AI. Multiplayer (except PitBoss) is supported but not thoroughly
tested. For questions, comments and current activities, please visit the development
thread on CivFanatics.
Installation
To install AdvCiv, copy the unzipped AdvCiv folder into Beyond the Sword\Mods under
Program Files. When the mod is loaded for the first time, it creates a folder My Games\
Beyond the Sword\AdvCiv for the BUG settings. You'll have to remove this folder manually
to fully uninstall AdvCiv.
The above assumes a BtS installation from optical disc on Windows 8 or earlier, though I
understand that it works the same way with the GOG.com edition and on Windows 10.
Steam users may have to revert to the Game Spy version in order to run any mods, and
the Mods folder should be in Steamapps\Common\Sid Meier's Civilization IV Beyond the
Sword\Beyond the Sword. On Unix-based systems, the mod can only be played through a
virtual machine or Wine. (These guides might help, but I haven't tried either of them:
MacOS, Linux. This CFC post also looks pertinent.)
To start the mod through a Windows shortcut, create a shortcut to Civ4BeyondSword.exe,
open the shortcut's file properties, and add a space and mod=\AdvCiv to the Target field.
(In Steam, the mod name can supposedly be set through the launch options.)
1
Contents
To start playing, it should suffice to read this overview of the mod's original content and
included third-party components. The subsequent chapters describe the major changes in
more detail. Most of the AI and UI changes are low-key though and only covered by the
(extensive) appendix. I've assigned a numeric id to each batch of changes; when an id is
mentioned, there's always a link to further details and rationales in the appendix.
• UWAI: Utility-Based War AI. Rewrite of the AI parts dealing with decisions on war and
peace. The new AI is better at anticipating the course of a war. Conditions that rule out
war categorically in BtS (e.g. attitude or being occupied with another war) are factored
into an overall utility value and can be outweighed by factors that favor war. UWAI can
be disabled through the "Aggressive AI" game option.
• Dynamic Diplomacy: Makes several relations bonuses harder to get, particularly
"mutual struggle," "open borders" and "supplied resources." All AI memory decays,
including "You declared war on us." Two new modifiers: "We oppose your ruthless
expansionism" and "You agreed to come to our aid in wartime". +4 relations is required
for "pleased" attitude and -1 for "cautious," but this is evened out by a change to the
"first impression" modifier. The AI will (sometimes) offer and accept cities in trade.
• Revised Barbarians: Barbarian activity increases more gradually; fewer Barbarians on
low-yield tiles; creation rate adjusted to game speed; fogbusting nerfed (units can
appear on all fogged tiles); land units can spawn aboard Galleys; Great Wall reworked;
goodies from Tribal Villages adjusted to game progress.
• Immortal Culture: Culture of defeated civs stays in the game and can cause anger and
revolts. Revolts can occur in any cities, not just near a border. Shortened o ccupation
countdown in conquered cities, but the countdown decreases only probabilistically
based on the strength of the occupying force.
• K-Mod v1.46 by karadoc: substantial AI improvements (incl. BBAI); usability improve-
ments (incl. BUG, which in turn includes Civ4lerts, reminder, Sevopedia and several
optional advisor screens); bugfixes (incl. the unofficial patches); performance tweaks;
game balance tweaks (several from PIG, Lead From Behind); practically no flavor
changes other than Actual Quotes. The main author of BBAI is jdog5000. For BUG
credits, see the BUG help file (Alt+Ctrl+F1 in a running game).
• Kek-Mod v0.26, a K-Mod fork by DarkLunaPhantom: partly included (mostly bugfixes).
• Show Hidden Attitude Mod by DaveMcW
• Various bugfixes, performance optimizations and UI and AI tweaks adopted from:
We the People, BULL, More Naval AI, Caveman2Cosmos, Rise of Mankind, Dawn of Civilization
• Various changes, especially to rules and AI behaviors that are easy to take advantage
of in BtS; e.g. can't capture workers right after declaring war.
• R&F: Rise and Fall. Game option that divides the game into chapters; you take control
of a different civ in each chapter. A score is awarded after each chapter based on how
the standing of your civ has changed.
• True Starts: Game option that chooses a civ based on the geography of the starting
location for every player whose civ was set to “Random” during game setup.
• SPaH: Start Points as Handicap. Game option that gives an Advanced Start to the AI
civs but not to the human civs.
2
• PerfectMongoose map script (v3.3; main authors: Cephalo and LunarMongoose)
• Mixed Continents map script based on jam3's Islands and Continents v1.1.
• savemap function by tywiggins and xyx
• Blue Marble "light": Altered terrain textures that are easier on the eyes; based on Kai
Fiebach's Blue Marble, but closer to the original textures. (How to disable: see appendix.)
Utility-Based War AI
UWAI is enabled by default, but players who prefer the K-Mod AI, can use the "Aggressive
AI (Legacy)" option on the Custom Game screen to disable UWAI; that option also enables
the Aggressive AI mode. There aren't separate options for UWAI and Aggressive AI
because UWAI doesn't have an aggressive or non-aggressive mode (see also change
019; K-Mod without Aggressive AI can still be configured in GlobalDefines_advc.xml).
The major differences between UWAI, BtS and K-Mod:
UWAI BtS/K-Mod
Military analysis: UWAI predicts how ongoing The BtS military analysis simply com-
and hypothetical wars might develop in the pares present power ratings. Each civ
medium-term, i.e. over the next 25 to 50 turns. has a single power rating, i.e. land and
The projection is based on power ratings for sea units aren't distinguished. K-Mod
various military branches, namely the army adds a projection of military build-up.
(land and air units available for offensives),
home guard (only available for defense), fleet
(sea units), logistics (cargo ships) and nukes.
Simulates military build-up (based on estimated
per-turn production), clashes of army stacks,
naval landings and attempted conquests of
specific cities. The outcomes include cities lost
and conquered by the various war parties,
invested production and lost military power.
These predictions aren't intended to be accu-
rate; they only need to be plausible enough to
result in plausible AI behavior.
Power: Power ratings are based on per-unit The power value of a unit normally
military power values that are, essentially, equals its combat strength; e.g. two
computed as combat strength raised to the Swordsmen count as much as one
power of 1.66. E.g. Swordsman has about 20 Cuirassier. That is, BtS underestimates
power and Cuirassier 75; that value also the power of technologically advanced
accounts for the faster movement and other units.
useful abilities of Cuirassiers.
Caveat: Many other AI decisions and the power
graph on the Info screen are still based on BtS
power ratings.
3
The evaluation of the expected military out- The AI considers attitude, military power,
comes is broken down into 28 aspects, each geographical proximity and victory stra-
dealing with one specific reason for war (e.g. tegies. These factors are combined in an
gaining more cities or animus for a war oppo- arcane manner by a function named
nent) or against (e.g. diplomatic ill will or startWarVal.
invested production). The result of the evalua-
Peace is evaluated separately by the
tion is a utility value indicating how worthwhile
endWarVal function, which is based on
the war (plan) in question is.
war successes, finances and the tactical
situation.
K-Mod has expanded startWarVal, but
it's still inconsistent with endWarVal,
leading to war-peace oscillation, and too
ad hoc for this important part of the AI.
War plans are fully re-evaluated each turn War plans in preparation are only can-
while in preparation, and canceled if they no celed in rare circumstances.
longer appear worthwhile.
The only necessary condition for beginning Thresholds for attitude and power ratio
(and continuing) war preparations is a positive serve as necessary conditions for war; in
war utility value. Attitude and power are co- particular, many AI leaders never start
vered by the war utility calculation and no war preparations against civs they're
longer work as hard requirements. That said, pleased with. (Exceptions: Aggressive AI
attitude has a particularly strong impact on war option and – in BBAI/ K-Mod – AI leaders
utility, so that a relatively peaceful leader like close to a military victory.)
Saladin doesn't go to war against a civ that he
is pleased with unless there are unusually
strong reasons for the war. Once preparations
are concluded and war is imminent, it's too late
for a change in attitude to stop the war.
If war utility is positive, the AI begins war pre- The per-turn probability is based only on
parations with a per-turn probability based on personality and attitude.
personality and the utility value. As a result, the
AI can be quick to declare war in response to
another declaration of war or some rapid shift
in power (e.g. after upgrading to Riflemen).
The AI makes peace if and only if war utility is Apart from an endWarVal check, there are
negative or outweighed by reparations. some special conditions for peace, such
as having fought to a long draw or being
alone in what had started as a dogpile
war.
4
After a declaration of war, the AI refuses to The refuse-to-talk duration is based on AI
talk for just one turn. After that, the AI can be personality and war success. Possible
contacted unless the price for peace is greater reparations don't play a role.
than what the other side is able to pay.
Exception: If war was declared at the request
of a third party or through a defensive pact or a
vote, the attacked AI civ refuses to talk to its
war enemies for the same duration as in BtS.
The AI can start a war while already in an- The AI doesn't consider war preparations
other war. It's possible, in principle, to hire an when it's already in a war; K-Mod relaxes
AI civ for war even if that AI civ is already this restriction in the endgame. In both
preparing or fighting a war, but the price is usu- BtS and K-Mod, the AI can't be hired
ally prohibitive. while already conducting or planning war.
The AI refuses requests for starting a war Same: "We couldn't betray close friends"
regardless of war utility if either its attitude or "We don't like you enough." The AI
toward the proposed target is too high, or its also refuses categorically if the power
attitude toward the sponsor is too low. ratio is too unfavorable or when already
Otherwise, the necessary payment is com- preparing or fighting a war.
puted based on war utility. If the result exceeds
a threshold, the AI refuses to declare war,
stating "We are afraid of their military might" if
the power ratio is highly unfavorable, and "We In BtS, if the trade screen says "enough
have enough on our hands right now" on our hands," then the AI is definitely
otherwise. Thus, "enough on our hands" preparing a war. In K-Mod, other reasons
doesn't imply that the AI is already preparing for not wanting to start a war can block
another war. the enough-on-hands tell.
When an AI leader becomes willing to discuss For the player's convenience, the BUG
a sponsored war, the player is notified through mod shows a fist icon on the scoreboard
an alert message (change 210a) and the next to any AI civ that will give the
Glance tab of the Foreign Advisor screen "enough on our hand" response. (UWAI
shows a fist icon (152). disables this.)
While the utility of a war plan against a human Tribute demands are made randomly
player is positive but small, and the AI hasn't against any disliked and militarily weaker
begun war preparations yet, there's an in- human civ. Whether the AI is currently
creased chance of demands for tribute or a gift. ready to start a war doesn't play a role.
UWAI continues to use almost all of the AI Each AI leader has some 20 personality
personality values from BtS. Many work diffe- values affecting war and peace, set in
rently but, in most cases, to a similar effect. Civ4LeaderHeadInfos.xml.
For example, a high MaxWarNearbyPower MaxWarNearbyPowerRatio is a threshold
Ratio leads to an optimistically biased military that rules out war if the military power
analysis, which can make AI leaders willing to ratio is too unfavorable.
start wars that they may well lose.
5
Hiring war allies, granting or denying tribute, Separate heuristics for these decisions,
UN peacekeeping and some other decisions based on some combination of power
that imply war or peace are made based on ratio and attitude.
war utility.
Decisions about vassal agreements are still
largely made by the K-Mod AI (with many ad-
justments; change 112), and defensive pacts
are still mainly a matter of attitude values.
Unless a city is clearly about to fall, the AI is The AI is more willing to make peace
less inclined to make peace when there are when there are hostile units near its cities
enemy units near its cities. – but can't evaluate if those units actually
This does not apply to capitulation; the AI pose a threat. This can be exploited for
capitulates only when faced with a threatening better peace deals.
number of hostile units inside its borders or Positions of units have no bearing on
after multiple nuclear attacks (change 112b). whether the AI is willing to capitulate.
This is the only part of UWAI that cares about
positions of units on the map. UWAI does not
control how war is conducted, only if.
Dynamic Diplomacy
One easily noticeable change is in the mapping from relations values to AI attitude:
Relations ≥9 ≥4 ≤3 ≤ -2 ≤ -9
AI attitude Friendly Pleased Cautious Annoyed Furious
For comparison, in BtS, Cautious begins at -2, Pleased at +3 and Friendly at +10.
However, AdvCiv also removes the (hidden) -1 relations penalty on Noble difficulty and
above, meaning that, in effect, the thresholds for Pleased and Cautious stay the same and
the threshold for Friendly is two lower than in BtS. Change id: 148.
The following changes to relations modifiers should make them more sensible, more
dynamic and less exploitable. Changes to vassal agreements are described at the end of
this chapter.
‒ "Our mutual military struggle ...": A bonus of more than 1 now requires getting involved
in the war, that is, to inflict or incur losses. The bonus decays over time and is reduced
when there is a non-mutual war. (In BtS, it's sufficient to be formally at war, and, once
accumulated, the bonus stays for the rest of the game.) Fighting inside an ally's borders
is especially effective at increasing the diplo bonus. 130m
‒ "You agreed to come to our aid in wartime": Joining a war at the request of an AI civ
results in a +1 relations bonus that is remembered for 100 turns on average. 130s
‒ When a war ally is brought in, the two allies automatically sign a 10-turn peace treaty. 146
‒ "Years of peace" only start to count once a civ is met. 130a
‒ "You stopped trading with us": One cannot propose an embargo against one's own
trade partner; will first have to cancel those trades. The target of the embargo refuses to
talk for (on average) 18 turns (BtS: 30) with both the civ that proposed the embargo and
6
the one that agreed to it. (Exception: when a master asks its vassal to stop trading.) The
embargo terminates even recent deals that couldn't otherwise be canceled. 130f
‒ "You made an arrogant demand" now only applies when a tribute demand is granted; no
diplo penalty if the AI refuses to pay. However, if a player declares war on an AI civ that
remembers having paid tribute, that civ and all AI civs it has met refuse tribute and help
requests by the player for (on average) 80 turns. When an AI civ declares war, it forgets
all tribute demands, i.e. it can be attacked without repercussions. 130o
‒ "You press us too hard": There is always a chance that the AI refuses a request for a gift
for no particular reason. A refused request is therefore not a reliable way to determine if
the AI is preparing war against the player who makes the request. The AI is willing to
grant a gift about every 30 turns (20 in BtS). 144
‒ "You're getting ahead of us": AI civs dislike civs that are ranked slightly higher on the
scoreboard but not those ranked much higher. These rank-based modifiers work
differently in BtS (and BtS hides them from the player). 130c
‒ "A first impression is a lasting one": Another hidden BtS modifier; this one remains
constant for the entire game. It is based on leader personalities and affects mostly
relations between AI civs. AdvCiv reduces the modifier a bit, specifically the impact of
"peace weight," to make diplomacy less preordained. 130b
‒ "We oppose your ruthless expansionism": Having a high number of cities with foreign
majority culture results in relations penalties from everyone. These penalties com-
plement the ones for having vassals ("our rivals being vassals to your empire"). 130w
‒ "We would have nothing to gain": AI leaders are reluctant to sign Open Borders with
civs whom they haven't located yet (not a single revealed land tile) or can't reach. When
pleased, most AI leaders sign Open Borders regardless of accessibility. 124
‒ "Our Open Borders have brought our peoples together": The time that it takes to attain
and increase this bonus depends on the distances and trade routes between the two
peoples' cities. 130i
‒ "All the years you have supplied us with resources": This can take many, many years if
the recipient already has many resources. 149
‒ All AI memory decays. For example, memory about how "you razed our cities" decays
by one city every 75 turns on average (130r). The other decay times (no decay in BtS):
Memory type Turns Memory type Turns
"You razed our cities" 75 "You nuked us" 120
"You razed a holy city" 150 "You nuked our friends" 80
"Your spy was caught" 40 "You negotiated a trade embargo" 60
"You made an arrogant demand" 30 "You declared war on our friends" 120
"You liberated our cities" 150 "You brought in a war ally" 75
"You granted us independence" 300 "You declared war on us" 150
‒ "You declared war on us" penalty reduced to -2 if the declaration of war is triggered by a
defensive pact. 130y
‒ "We are upset that you have signed Defensive Pacts with our rivals": Not if we like
these rivals, or have our own defensive pacts with them, or if we're too weak to attack
7
them anyway. Also no penalty for voluntary vassals ("our rivals being vassals to your
empire") if we like those vassals. 130t
‒ The AI refuses to sign a Defensive Pact if it was recently canceled (same mechanism as
for canceled Open Borders). Defensive Pacts aren't automatically canceled when
triggered, i.e. when a third party declares war on one of the signatories. 130p/ kekm.3
‒ "We care for our brothers and sisters of the faith"/ "You have wisely chosen your civics":
Reduced the upper limit of those modifiers by 1 for about half of the AI leaders (those
with the highest limits). If many civs share a religion or civic (e.g. Hereditary Rule), the
relations bonuses are reduced. Conversely, the AI is more tolerant toward another
religion if either religion is shared by few other civs. 130n
‒ "You accepted our state religion/ favorite civic": The bonus decays faster when the
player switches out of that religion or civic. 145
‒ "Our trade relations have been fair and forthright": No longer based (primarily) on how
recently a civ was met; more difficult to max out; and trades that are indeed "fair"
contribute to the bonus. (In BtS, only what the AI gets on top of a fair deal counts.) 130p
‒ "You have traded with our worst enemy": The penalty is reduced when the worst enemy
changes. Trade with a war enemy counts (partially) even if that enemy is not the worst
enemy. Open Borders contribute to the enemy trade penalty. 130p
To become a worst enemy at peacetime, the relations value needs to be -3 or worse,
i.e. Annoyed attitude isn't necessarily low enough. 148
‒ “Perhaps it is time for all this bloodshed to end”: The AI sometimes contacts human
players with peace offers that can be more generous than those resulting from “what is
the price for peace/ stop this fighting”. Rejecting such an offer makes the AI slightly less
willing to accept human peace offers. (In BtS, a bug prevents AI peace offers.) 134a
‒ The AI forgets actions of other civs, like "You gave us help", a little less randomly,
whereas the tracking of e.g. "years of peace" or supplied resources is now a bit random-
ized. (In BtS, e.g. "years of peace" pay off after exactly 60 turns.) 130k/ 130j
AdvCiv eliminates most of the diplomatic drawbacks associated with capitulated vassals
(change 130v). They have Friendly attitude toward the master, share the master's attitude
toward rivals (but no better than Cautious), can't be anyone's worst enemy and are
ineligible as war targets and for elections (014). The master civ is held responsible for
grievances caused by its capitulated vassals – penalties for razed cities, border troubles
and trades with a worst enemy are partially added to the master's relations modifiers –, but
the master is not blamed for things that the vassal civ did prior to the vassal agreement,
nor for the vassal's religion.
Peacefully acquired vassals still work as in BtS, i.e. as largely independent. The
conditions under which the AI agrees to a vassal agreement have been tweaked: Civs only
look for a master when feeling threatened – having fallen behind is not reason enough
(112). If a master civ fails to protect its voluntary vassal (substantial loss of territory or
nuked repeatedly), the vassal cancels the agreement (143). A vassal that gets close to a
victory condition also cancels the vassal agreement (112).
The following changes (130h) should make it easier to have productive relations with
former vassals after helping them break free: Civs in a vassal-master relationship don't
consider each other "friends" as far as the "you declared war on our friends" penalty is
8
concerned. When a vassal makes peace or breaks free, its memory about past
declarations of war is decreased. When a capitulated vassal is freed because its master
capitulates, the freed vassal gives +2 "You granted us independence" to the master of its
former master. Freed vassals and their liberator automatically cease fire. 130y
Happiness from vassals ("We influence other civilizations") is now only gained from volun -
tary vassals, and it's capped at +1. 142
City trades with the AI are possible under the following conditions:
• The recipient needs to have at least 10% nationality (city tile culture) and at least half as
much as the current owner. Exceptions:
− When negotiating peace, 10% nationality of the recipient is always sufficient.
− Liberation to a colonial vassal is allowed regardless of nationality.
− Master to vassal: The vassal needs to have higher nationality than its master.
− Vassals can never trade or liberate cities to rivals.
• War with the previous owner or nearby enemy units prevent (non-liberation) city trades.
• As in K-Mod, unrevealed cities are treated as secret and thus cannot be traded.
• AI attitude threshold for giving away cities in (non-liberation) trade: Personality-based.
For many AI leaders (much) less strict if the owner has less than 20% nationality.
• The AI doesn't give away cities of major economic importance.
• After a (non-liberation) city trade, a peace treaty is signed automatically. Rarely, the AI
may reject a city (“we have our reasons”) in order to avoid a peace treaty.
• The AI accepts liberated cities only for free, as payment for making peace or in
exchange for another liberated city. As in BtS, liberation to the AI improves relations,
and only former owners and colonial vassals can receive a city through liberation.
The above doesn't cover all AI trade denial conditions. Full documentation: rules | AI | UI
User interface: The Foreign Advisor screen lists possible city trades on a new tab “Cities”,
and there is an alert for new city trades (can be disabled on the BUG menu).
Revised Barbarians
(For details, see change id 300 when no other id is stated below.)
‒ The Barbarian creation rate increases gradually, reaching its peak when slightly more
than half of the land is claimed by cultural borders, i.e. typically in the last millennium
BC. The rate is adjusted to the game speed setting.
‒ Fewer Barbarians on low-yield tiles: Barbarian units can only be created on habitable
tiles (positive food yield when ignoring hills). They're less likely to appear on jungle and
tundra without resources, and more likely on all other tiles. The maximal number of
Barbarians to be placed per continent takes into account the length of the coastline and
disregards nonhabitable tiles; i.e. fewer Barbarians on continents with large (polar)
deserts, more on snaky continents. The aim of these changes is to help civs that are
surrounded by poor land, and to disadvantage civs that have much good land to settle.
‒ Barbarian land units can be created aboard Galleys in the fog of war. Once a Barbarian
Galley has cargo, it moves toward a nearby city for a naval assault. The units can also
be dropped along the way, randomly, or to attack an unprotected non-combat unit. The
intention is to make Barbarian Galleys harder to ignore, especially for civs without
seafood at stake. (change 306)
‒ “Fogbusting” weakened: So long as a tile is not visible to any civ, Barbarian units can
9
be created there, i.e. the mod disables a BtS rule that had blocked Barbarian placement
in a 5x5 square around each civ unit. There are also several changes that make it more
appealing to fight Barbarians (rather than ensure that none are created); see below.
‒ On Monarch, Emperor and Immortal difficulty, human units receive a +5% combat
modifier against Barbarian units (none in BtS above Prince difficulty). 313
‒ Barbarian Spearmen no longer appear earlier than Axemen. This makes Chariot more
useful as an anti-Barbarian unit. 301
‒ Half of the XP gained from non-Animal Barbarians, rounded down, counts as Great
General points. 25% less XP than in BtS is gained from attacks against Barbarians. As
in BtS, units with 10 or more XP gain no XP from fighting Barbarians. 312
‒ The Great Wall (TGW) has two out of the three following effects depending on the
Raging Barbarians (RB) and No Barbarians (NB) game options: 310
∘ +1 trade route in cities on the same continent except when playing with RB;
∘ prevents Barbarians from entering your borders on this continent except with NB;
∘ +100% emergence of Great Generals inside your cultural borders if RB or NB.
To match the flavor of the new trade route effect, TGW switches its Great Person type
with Versailles, i.e. TGW generates Great Merchant points and Versailles generates
Great Spy points. TGW costs 300 production instead of 150, and requires two Walls
(in arbitrary cities). It goes obsolete with Corporation. As for the increased cost, bear
in mind that Barbarian in AdvCiv.
‒ Effects from Tribal Villages are based on the game turn number. In particular, they will
often only yield progress toward a tech rather than the whole tech. Tribal Villages that
aren't reached until the midgame may yield several hundred gold or research points
(toward any pre-Industrial tech). The other outcomes also become somewhat more
potent over the course of a game, may e.g. yield a Worker instead of a Scout. 314
‒ Explorers get the ability to attack Barbarians, which allows them to enter guarded Tribal
Villages, but they can't capture cities and no longer receive any free promotions. 315b
‒ Scouts may attack animals (315c) and Scouts get a combat bonus against all
Barbarians (315a), not just against animals. On Emperor difficulty and Immortal, the AI
starts with one free Scout instead of two and, on Immortal and Deity, with one fewer
Archer than in BtS; this leaves more Tribal Villages for human Scouts (250e).
‒ On continents without any civs, Barbarian cities begin to appear earlier than they do in
BtS. This way, a patchy network of Barbarian cities tends to be cover the New World by
the time it is discovered, reminiscent of Sid Meier's Colonization. So long as these cities
outnumber those of all civs taken together, Barbarian units act relatively peacefully.
Immortal Culture
‒ Eliminating a civ no longer removes that civ's tile culture. The remaining culture can
cause anger, now listed as "We resent being ruled by a foreign culture" instead of "We
yearn to join our motherland." 099
‒ Revolts can occur in any cities, not just those close to foreign borders, and culture of
dead civs can cause revolts. However, only border cities can flip. Cities can never flip
from a master to its vassal. If a city can't flip, it loses one population on the third revolt
10
and on subsequent revolts. 099c
‒ The occupation timer after conquest or revolt decreases only with a per-turn probability
that depends on the same factors as the revolt probability, in particular the strength of
the occupying force. The timer starts at no more than 3 turns.
Damage makes units less effective at suppressing revolts, and occupying units heal
only as fast as in a friendly non-city tile.
Revolts can happen during occupation unless the city owner is at war with the owner of
the foreign culture. 023
‒ "Cruel oppression" anger in a city makes revolts considerably harder to suppress.
(Otherwise, Slavery would be a too obvious answer for anger from foreign culture.) 101
‒ The flipping-after-conquest game option is now called "No City Flipping after Conquest",
i.e. its effect has been inverted. 101
‒ Tile culture is subject to a small exponential decay rate. The rate is increased for
“stolen” tiles, i.e. tiles that no city can work but that could be worked if they flipped to a
different owner. 099b
‒ The Creative trait grants 10 free culture upfront and only +1 culture per turn. Moreover,
Colosseum is no longer sped up by that trait, and the happiness-from-culture abilities of
Colosseum and Theater have been swapped. 908b
‒ K-Mod also makes changes to culture and revolts. AdvCiv keeps some of these – see
the first few bullets in the next chapter –, and reverses others:
• Foreign culture strength no longer goes toward infinity when the current owner has
close to 0% culture. 101
• Culture from trade routes disabled (still optional via XML). 125
• Reverted most of the K-Mod changes to building culture rates. 201
To balance out the remaining changes (especially to Free Speech), the threshold for
Legendary city culture gets reduced on the low and medium difficulty levels. (On
Monarch, the threshold begins to increase, matching the increasing tech costs
relevant for Space victory.) 251
K-Mod
See also the K-Mod thread on CFC.
BUG (BtS Unaltered Gameplay): Many BUG options are disabled by default in K-Mod and
AdvCiv in favor of a lean interface that provides essential time savers but doesn't look too
different from unmodified BtS. Please use the BUG menu (Ctrl+Alt+O) to adjust the
settings to your own preferences. To import settings from another BUG installation, it
should suffice to copy the respective .ini files to My Games\Beyond the Sword\AdvCiv\Settings
– perhaps minus Advanced Scoreboard.ini because the column order string isn't fully
portable between BUG, K-Mod and AdvCiv (cf. 085). Like all BUG-based mods, AdvCiv will
restore its default settings if an .ini file or the whole Settings folder is removed.
BULL is included only partly in K-Mod. I've merged the Show Hidden Attitude Mod (change
advc.sha), city bar help (change 186), added Sentry behavior to Fortify-Heal (004l) and
replaced BULL's pre-chop option with a more general pre-build command (011) that is
triggered by holding down the Ctrl key while clicking on a worker command. There are still
11
several conveniences in BULL and other UI mods that are, so far, missing in AdvCiv; that
said, AdvCiv also includes numerous usability tweaks beyond those in other mods (see
004 for a list). A few of those are – on a side note – also included in the Taurus fork of BULL.
For players who aren't familiar with K-Mod, I'm listing the major gameplay changes. For
players who are familiar with K-Mod, I'm also listing the K-Mod changes that I've reverted
(end of this chapter).
‒ Culture system: Culture levels (e.g. "Influential") matter less in culture wars, and specific
city culture values matter more. Moreover, the range at which the culture of a city affects
borders has been increased, meaning that the number of border cities and their culture
are less decisive. The output of some culture sources has been reduced:
• Free Speech increases culture by 50% instead of 100%.
• The Sistine Chapel adds only 3 culture to religious buildings, not 5, and the added
culture isn't doubled after 1000 years.
• Culture from Great Work depends on the game era [progression adjusted in AdvCiv].
• The Spread Culture mission only affects tile culture, i.e. it can no longer be exploited
for an "espionage victory."
• Regarding culture victory, note that tech costs in the late game have also been
increased, i.e. both culture and space victory take longer than in BtS.
‒ City flipping: Revolts happen faster, but cities don't flip until the third revolt. "The net
effect of these changes is that [...] it's a bit more predictable and less dependent on
luck." (from the K-Mod changelog)
The revolt probability is halved if a unit with the Leadership promotion is present.
‒ Vassal agreements: Can instruct vassals to start war preparations via "Let's discuss
something else." The impact of vassals on number-of-cities maintenance is more
noticeable than in BtS.
‒ The number-of-cities maintenance cost is no longer capped at 8 cities, meaning that
very large empires can incur very high city maintenance. [Cap is 25 in AdvCiv; cf. 570.]
‒ Expendable units are chosen as defenders when no defender has favorable odds.
(Lead From Behind mod component)
‒ When a religion spreads, one of the older religions is sometimes (randomly) removed.
‒ The AI never agrees to Cease Fire.
‒ Trades offered by the AI can come with a discount. The discount is forgone if the player
makes a counter-proposal. [In AdvCiv, the offer can also include more gold than the AI
would normally consider; change 026.]
‒ Espionage points accumulated by rivals against the player are treated as secret. Rival
war weariness is only displayed when demographics are visible.
‒ The AI uses a greater variety of espionage missions.
‒ Strengthened considerably:
• Serfdom +1 commerce on farms and plantations; -1 on towns
• All cargo ships +1 capacity
12
• XP from Great Warlord increased based on the number of units in the tile
‒ Weakened slightly:
• War Elephant +10 cost
• The Colossus +100 cost
‒ Strengthened slightly (incomplete list):
• Vassalage -25% number-of-cities maintenance
• Mercantilism upkeep Low
• Grenadier +10% city attack
• Watermill +1 commerce initially but only another +1 from Electricity
• Drill I takes -15% collateral damage
• Protective trait boosts production of Security Bureau
• Aggressive trait boosts production of Jail; Jail gets -2 espionage (regardless of trait)
• Industrial Park +1 free Engineer (i.e. 2 in total), +50 cost
• Guided Missile +1 range
• Hippodrome grants 2 Artist slots (like Theater)
• Space Elevator another +50% production for spaceship parts
• Forest Preserve +1 commerce
• Environmentalism doesn't penalize corporations, yields +1 happiness from Public
Transportation but has High upkeep. Environmentalism and Public Transportation
both reduce bad health from population instead of granting good health.
Some that I couldn't put better, quoted from the K-Mod database page:
‒ "Barbarian Galleys get -10% strength"
‒ "Tech requirements for corporations changed: Civ Jewelers: Corporation, Sushi Co:
Refrigeration, Cereal Mills: Medicine, Creative Constr.: Steel, Std. Ethanol: Combustion"
‒ "Mining Inc now uses Aluminium and Uranium instead of Gold and Silver (this should
make Mining Inc slightly weaker, and Civ Jewelers more viable)"
‒ "Cereal Mills also has +0.25 food output" [also: Aluminum Co. +0.5 research]
‒ "In the diplomacy screen, pressing 'Lets stop this fighting...' will now bring up the trade
screen with the AI's suggested peace terms. (Originally, it just made peace instantly
without any trades – it was a horrible button.)"
‒ "Tech trades in which the receiving player is more than 2/3 of the way through
researching the tech or when the tech is two eras behind the 'game era' [the recipient's
era in AdvCiv; 550e] no longer count toward tech trade memory; i.e. they don't
contribute to causing 'We fear you are becoming too advanced'."
‒ "Global warming has less of an impact on the map, but (in long games) causes
unhappiness to those civs contributing to pollution. There's a new advisor screen
[Environment tab on the Economics Advisor] about this."
Revised by AdvCiv:
13
‒ Changes made in order to smoothen or reinforce K-Mod balance changes:
• Forest Preserve at Biology instead of Scientific Method. 901
• Watermill takes 4 turns to build, and Lumbermill 5 (instead of 8 both). 902
• Serfdom has Medium upkeep instead of Low. 912a
• Pacifism costs 1 gold per military unit, not 0.5. 912b
• Vassalage disables colony maintenance, State Property (as in K-Mod) doesn't. 912g
• Colossus is obsolete with Chemistry. 310
• Great Lighthouse obsolete with Astronomy; cost 250 (300 in K-Mod, 200 in BtS). 310
• Quechua has no bonus against Archers; cost is 15 (was 20 in K-Mod). 907b
• Panzer 2 first strikes instead of 1.5; no free Flanking promotion. 907f
• Ship of the Line strength 10 (as in K-Mod), +25% against Frigate (K-Mod 20, BtS 50),
req. Iron (as in BtS), +1 move, increased bombard rate, cost -10. 905b
• Ironclad +1 move (as in K-Mod), at Steam Power (no Steel required), +25% defense
on Coast. 905b
• Machine Gun +25% vs. Mounted units, not 10%. 909a
• Meltdowns slightly more likely but, as in K-Mod, far less disastrous than in BtS. 652
‒ Changes kept from K-Mod versions prior to 1.45:
• Scientific Method +1 research per specialist (1.45 moves this to Computers and has
Scientific Method provide +10% commerce)
• Lumbermill at Guilds with +1 commerce (902: regardless of river) but no production
bonus until Replaceable Parts (1.45 gives them +1 production already at Guilds)
‒ Notable adjustments to K-Mod AI behavior:
• AI razes fewer cities and less randomly; 116
• uses Slavery and Drafting less aggressively, though still frequently; 121b, 017
• uses malicious espionage only against civs it dislikes. 120
Reverted by AdvCiv:
‒ See Immortal Culture about reverted changes to culture and revolts.
‒ Production overflow is never invested into an additional unit as this had lead to balance
problems with AI civs training multiple Archers per turn. Instead, excess overflow is
converted into gold as in the Unofficial Patch, though with some tweaks to make this
conversion more difficult to abuse. 064b
‒ Gifting Great People to the AI does not provide a relations bonus. 141
‒ No impact of global research on inflation; instead, adjusted tech costs based on
difficulty for a more historically accurate tech pace, and Immortal and Deity games now
start on turn 10. 251
‒ Some minor balance changes undone that weren't pulling their weight in terms of added
complexity (change 200):
14
• Eiffel Tower back at Radio
• No +2 production for Assembly Plant; no withdrawal chance for Musketeer; no free
XP for Dun
• Drill does not lead to additional promotions – except Blitz (see next chapter)
• All corporations have the same maintenance multiplier (i.e. mostly as in BtS)
15
of Galley and Trireme reduced from 50 to 45. Cost of Transport reduced from 125 to
100 and can't attack. Trireme has strength 3, but gets no bonus vs. Galley. 905(b)
‒ Attack Submarine and Submarine (now called "Nuclear Submarine") switch places in
the tech tree. Both units get 6 first strikes, which should make them more dangerous for
Battleship, but Destroyer gets to ignore first strikes. Battleship costs 250 instead of 225.
Stealth Destroyer receives the same anti-air and anti-submarine abilities as Destroyer
and 1 cargo space for missiles but also a cost increase from 220 to 270. 906
‒ Drill I enables the Blitz promotion for ships, but Blitz only allows one extra attack. 164
‒ Metal Casting tech cost reduced by 1/6, Calendar by 1/7, Divine Right by 40%. 174, 306
‒ Tweaks to tech costs across the board for better alignment with the game year. 910
‒ The Spy unit can investigate rival cities, but (unlike in Warlords) with a mission cost. 103
‒ Research progress toward a tech makes that tech cheaper to steal. 120i
‒ No espionage slider until Alphabet. 120g
‒ Get to choose from more civics and religions when using the "Change civics/religion"
Spy mission, or when negotiating peace or trading with a vassal. 132
‒ When a citizen starves, the Granary is emptied to delay further starvation. 160
‒ Courthouse allows two Spy specialists, Jail only one. 911a
‒ Grocer and Market (and Forum) cost 130 production instead of 150. 911b
‒ Aqueduct (and Baray, but not Hammam) costs 90 production instead of 100. 911c
‒ The Apostolic Palace grants only +1 production to religious buildings, costs 350
production (instead of 400) and allows 2 Priest specialists (instead of 0). The Shrines
also allow 2 Priest specialists each (instead of 3). 179
The Apostolic Palace can propose war against (non-full) voting members, but only full
members are compelled to declare war. kekm.25
‒ Can no longer bypass the Theocracy restriction by gifting missionaries. 123a/ kekm.4
‒ Damage from nuclear weapons to units made less predictable; SDI interception chance
reduced from 75% to 60% and cost increased from 1000 to 1500 production. 650
‒ Wonders that have been removed from the production queue generate no "fail gold."
Also no gold from national units. 123f
‒ Trade routes can only come from revealed cities, and the paths to those cities need to
be revealed as well. Cities are temporarily unavailable for trade when in disorder. Trade
along rivers doesn't require any tech (as in Warlords; BtS demands Sailing). When
borders of a war enemy block trade, a naval blockade can override this. Connecting a
resource on an island workable by a mainland city requires only a road, not a fort. 124
‒ When mountain peaks block off part of a landmass, the parts are treated as separate
continents. This is relevant for the placement of Barbarians, colony maintenance and
wonders that affect only one continent – though the main point is to make things easier
for the AI. 030
‒ On Emperor difficulty and above, some of the AI discounts have been reduced, but
16
human civs face increased production costs, research costs, city growth thresholds and
Great Person thresholds. The AI also starts with fewer freebies, in particular, without
Agriculture on Immortal and Deity and without a second free Settler on Deity. Pro -
gressive AI bonuses are now based on the game turn instead of the AI era. 251/ 250e
‒ Marathon speed is only 2.5 times slower than Normal speed, not 3 times. 252
‒ The default player count is 8 for the Standard map size. 137
‒ Map generation: Clusters of Gold, Gems made less common. Silver may occur on
Grassland Forest. No Flood Plains on river corners. Jungle may occur on Plains. 129
‒ New algorithm for assigning starting locations. Should partition the available land more
evenly than in BtS. Not enabled for all map scripts (list). 027, 108
‒ Switched the no-war-probability of Roosevelt and Darius, meaning that Darius can start
wars when pleased, and Roosevelt – normally – cannot. 005a
‒ Suryavarman's favorite religion is Hinduism and his favorite civic Caste System. 005a
17
TS can be used with all map scripts, climate settings and scenarios without preplaced
cities or units. Players for whom a civ has been selected on the game setup screen
receive that civ regardless of geography. Exception (due to a technical limitation): In
network games, TS picks civs for everyone. TS does not disable the difficulty-based
assignment of starting locations to players, i.e. a human player on a high difficulty level
receives one of the weakest starting locations, and then TS picks the most fitting civ for
that location.
TS is similar to the less sophisticated starting biases in Civ 6; however, Civ 6 first chooses
one civ per player uniformly at random and then makes a choice for each starting tile only
from this limited subset of civs.
Screenshots of one set of starting locations assigned by TS can be found attached to this
CFC post. See the appendix for further details.
18
and Warrior or Scout. Humans receive starting locations based on the difficulty setting, i.e.
the best ones on Settler and the (almost) worst ones on Deity. Then, if an unequal point
distribution is used, the AI civs with the fewest points (top AI slots) are placed in the
locations closest to the human civs, and the AI civs with the most points (bottom AI slots)
are placed the farthest away.
Once the game has started, the start point distribution is shown on the Settings tab of the
Victory screen. You'll also notice that the game doesn't start on turn 0. This is done to
reinforce the notion that the human civs are late arrivals, and to have the game year match
the overall development of the world.
An AI civ with a small number of points may have difficulties repelling a human Warrior
rush, so I'd recommend against going far below 300. Unequal distributions are
incompatible with team games, which is to say, they should technically work, but the
assignment algorithm makes no effort to balance the teams' start points and locations. See
250b about how to enable Advanced Start and SPaH in scenarios.
General changes to Advanced Start (250c):
BtS allows start points to be converted 1:1 into production, which is usually far better than
a 1:1 conversion into research. In order to make technologies a bit more attractive in
Advanced Start, I've changed the conversion rate to 1:1.5 for production, meaning that
cities, units and buildings now cost 50% more. Improvements, visibility and culture still
seemed overcosted in comparison, so I've lowered the costs of these a bit.
Advanced Start costs are no longer adjusted to the game speed setting. This makes it
unnecessary to manually adjust the start points entered on the Custom Game screen to
match the game speed. When playing without SPaH and on a difficulty higher than Noble,
the AI receives more start points than entered. This was apparently intended by the BtS
developers but not correctly implemented. Conversely, human start points are no longer
adjusted based on difficulty (this was working in BtS); humans get exactly as many points
as entered.
For reference, the AI freebies for each difficulty setting, and the number of start points that
would be needed in order to buy those freebies given the above changes to Advanced
Start costs and assuming Standard map size (tech is more expensive on larger maps):
Difficulty Prince Monarch Emperor Immortal Deity
Free 1 Settler 1 Settler 1 Settler 1 Settler 1 Settler250e
initial items 1 Worker 1 Worker
per AI civ 1 Archer 2 Archers 2 Archers250e 3 Archers
1 Warrior 1 Warrior 1 Scoutsee 250e 1 Scout250e 2 Scout
19
into several chapters (of history). During the first chapter, you play as the leader and civ
set on the Custom Game screen (random also works). Once a chapter ends, you're asked
to select one of the other civs in the game. During the next chapter, you control the
selected civ, while your previous civ is controlled by the AI. After each chapter, a score is
awarded that measures how much your civ has improved since the start of the chapter. If
you manage to fulfill a victory condition, the game ends, and you score a premium, which
is, again, based on the standing of your civ at the start of the chapter. To maximize the
total score, you need to pick civs that are doing badly but have the potential for
improvement. If you play well, civs will "rise" under you control, and begin to decline after
AI control resumes – this is the "fall" part. That is, unlike in the Rhye's and Fall mod, there
is no special collapse mechanism. There is no connection with the "Rise & Fall" expansion
for Civ 6. The High to Low challenge in Kael's Assimilation mod has been an inspiration.
Supported and recommended game settings: Single-player only, no teams or Perma-
nent Alliances. The number of chapters is 6 on Quick speed, 7 on Normal, 8 on Epic and 9
on Marathon, provided that there are enough civs in the game. Since a different civ is
supposed to be played in each chapter and some are usually eliminated before the final
chapter, it's advisable to configure at least 1.5 times as many civs as chapters. If you
dislike playing on Huge maps, you can fit enough civs on a Large map (up to 16 I'd say) or
even a Normal map (up to 12) if you set the sea level to Low (assuming a standard map
script like Fractal or Continents). You may want to take a look at the "Score" tab of the
Victory screen at game start in order to verify that the number and length of chapters is as
intended.
I haven't tested unusual settings much, but R&F should, in principle, work with any map
script and any scenario where the civs start without cities. Advanced Start should be fine
too, but not SPaH. Starting in a later era than Ancient results in fewer chapters.
R&F is intended to be played at a difficulty that makes it challenging to take a civ from a
rank near the bottom to a rank near the top over the course of a chapter. That's going to be
about three difficulty levels lower than what would normally pose a challenge. When it
comes to expenses for units and cities (of human and AI civs alike), R&F will apply
difficulty levels one higher than those configured on the Custom Game screen (i.e. Prince
for the AI civs); see 708 for details. This is done because expenses can feel quite
insignificant when playing several levels below one's usual difficulty level.
Objective: The objective is to
maximize what I'm calling the
Rise score. When the game
ends, that score is computed
as the sum of the chapter
scores plus a premium for
victory. What the scoreboard
on the main screen shows are
scores based on population,
technology etc.; this score is
computed as in BtS, and I'm
calling it CIV score to dis-
tinguish it from the chapter The CIV score from the scoreboard on the lower right feeds into the
score. Chapter score is based chapter score on the left of the Score tab, which feeds into the Rise
on the change(!) in CIV score score on the right of the Score tab.
and rank since the beginning of a chapter. Once the game ends, the final rank between
20
"Dan Quayle" and "Augustus Caesar" is computed from the Rise score. (In non-R&F
games, the rank is computed from the CIV score and game end turn.)
Delayed scoring, AI changes: A chapter isn't scored right after it ends but during the
subsequent chapter. This is done to disincentivize shortsighted plays toward the end of a
chapter, e.g. conquering cities that aren't tenable in the medium term. The first chapter is
scored in the middle of the second chapter. With each chapter, the scoring delay
decreases a little; the penultimate chapter is scored one quarter into the final chapter. The
exact turns on which scoring happens are shown on the upper half of the Score tab. On
those turns, a popup with a breakdown of the chapter score appears.
A side-effect of delayed scoring is that you have a stake in two civs during the first portion
of each chapter: the one you're currently playing and the one from the previous chapter.
This creates an awkward incentive for helping the civ from the previous chapter. Similarly,
toward the end of a chapter, there can be an incentive for helping whichever civ you're
going to take control of in the next chapter. In order to limit such collusive help, I've made
the following changes to the AI:
‒ Doesn't accept unsolicited gifts, and asks for gifts less frequently than normal. No units
can be gifted.
‒ Rejects offers that are heavily lopsided in favor of the AI. This can also mean that the AI
refuses to make peace in exchange for a valuable technology.
‒ Is reluctant to get paid for things of questionable value to the player: civics and religion
changes, embargoes, sponsored war and brokered peace.
These restrictions don't apply: to civs that have already been scored; to vassals of the
player; nor to any civs that outrank the player on the scoreboard. During the final chapter,
the restrictions only apply to the civ from the penultimate chapter (until that civ is scored).
Intermediate periods: In between every two consecutive chapters, there is an "inter-
mediate" period of 5 to 10 turns (depending on game speed) during which you control no
civ. During an intermediate period, most elements of the user interface aren't updated,
meaning that you have practically no vision and agency. A countdown on the upper right
shows how many turns remain until the start of the next chapter. The main purpose of the
intermediate periods is to hinder military cooperation between the civs played in two
consecutive chapters.
Civ selection: When an intermediate
period ends, you're prompted to select a
civ for the upcoming chapter. Each civ
should be played for at most one chapter.
Sometimes, this is impossible because
too many civs have been eliminated
already; therefore, it's allowed to play the
same civ repeatedly, but the chapter
score is halved then. Playing the same
civ for two chapters in a row is not
possible, and any vassals of the most
recently played civ are off-limits too.
The selection popup lists civs in order of
recommendation: First, non-vassals not
previously played, inversely ordered by
Popup for civ selection
21
rank, then, vassals not previously played and, last, civs previously played. Civs known to
any previously played civ are listed by name, the others as "unknown." Hovering over an
entry shows the civ's current CIV score, whether it's a vassal, and if so, if capitulated or
voluntary and the identity of the master, and lists any war enemies. A victory stage is
shown if the civ is close (at least stage 3 out of 4) to fulfilling a victory condition. All this
information is provided even if the name of the civ is unknown. It's often unwise to take
over a civ that is at war with a stronger opponent. If you select a voluntary vassal, you'll be
able to cancel the vassal agreement at any time. As a capitulated vassal, you'll have to
acquire enough land and population in order to break free.
Chapter scoring function: The computation of the chapter score isn't entirely simple, but
it may suffice to know that the more the CIV score has increased between the start of the
chapter and scoring, the higher the chapter score.
• When a chapter is scored, 0 to 100 points are
awarded based on the rank r of the scored civ on
the CIV scoreboard at the time of scoring:
100 * (worst rank – r) / (worst rank – 1)
That's 100 when ranked first (r=1) and 0 when
ranked last (worst). In this context, the civ currently
controlled is always considered to be ranked behind Chapter score breakdown (Score tab)
the civ that is being scored; this way, success in the
current chapter can't hurt the score for the previous one. A score for the initial rank, i.e.
the rank at the time that the scored civ came under human control, is computed in the
same way, and subtracted from the score for the current rank. Thus, the total score from
rank is maximized (100 points) by starting in the last place and climbing all the way to
first. A civ that starts in rank 1 can at best gain 0 points from rank by staying in rank 1,
and otherwise loses points.
• Points are also awarded directly for CIV score; otherwise, it
would be pointless to continue a chapter when it's clear that
the current civ can't climb another rank. The CIV score of the
next best rank is used as a point of reference. In the
example on the right, Rome is currently fourth, so its score
of 929 is divided by that of the fifth rank (Ethiopia, 922), and
the resulting percentage (101) is added to the chapter score.
At the start of the chapter, Rome's score of 352 was 65% of
the fifth rank (Charlemagne, 541), and that percentage is
subtracted, resulting in a net gain of 36 points from CIV
score.
• If the chapter was ended prematurely through retirement Example: Current scoreboard
(see "End of chapter" below), the chapter score from rank (left) and scoreboard at the
and CIV score is increased by half the percentage of the start of the current chapter
turns remaining at the time of retirement. For example, if 14
out of 65 turns remain, the portion of unspent time is 22%, so the chapter score is
increased by 11%.
If the bottom line is -10 or worse, a square root is applied in order to reduce the loss of
points. This is done so that a single failed chapter can't ruin the total Rise score.
End of chapter: All chapters have the same length except for the last one, which can be a
bit longer or shorter than the others. The chapter length depends on the number of
22
chapters and the game speed. To see how many turns remain, hover the mouse over your
civ's flag on the main screen. During the last three turns of a chapter, a countdown is
shown directly on the main screen, and, at the beginning of the final turn, there is a popup
reminder.
As the end of a chapter approaches, you may want to try putting your civ in a state that its
AI leader can work with because the civ will be under AI control for some time before
scoring happens. E.g. Gandhi might not continue your war of conquest. Don't rely on pre-
programming decisions for the AI: When the AI takes over, the mod clears your slider
positions, governor settings and the queues for city production, research and unit
missions.
You can end a chapter early by selecting "Retire" from the opening menu. This button,
which normally concedes the entire game, works very differently with R&F. By retiring
early, you earn a bonus to your chapter score (see "Chapter scoring function" above) and
the chapter continues on AI Auto Play until its regular end turn. One situation in which
retiring makes sense is when your civ is getting so far ahead of the others that the AI might
run away with the game once the chapter ends.
List of chapters on the Score tab, showing start and end turn (with end year), chapter score
and scoring turn for past chapters, the current chapter and future chapters. The chapters with
score values in bold have already been scored; score values not shown in bold indicate the
score that would be awarded if the chapter were scored right now.
Game end: The game ends immediately when one of the BtS victory conditions is fulfilled
by any civ. If the previous chapter hasn't been scored yet, it is scored now. If an AI civ
wins, then the current chapter is scored as well and the Rise score is simply the sum of the
chapter scores. If the human civ wins, then the current chapter is not scored, i.e. rank and
CIV score don't matter. Instead, a victory premium is added to the total score of the earlier
chapters. This is, once again, a bit complicated; in short, the incentive is to win as early as
possible if it can be done from a poor position, but not to win a quick victory by picking a
civ that is already about to win.
• Premium P: 150 points plus 150 for each chapter
that hasn't started yet.
• The premium above is reduced based on the rank
r0 at the start of the current chapter (initial rank)
by subtracting
(P/1.5) * (worst rank – r0) / (worst rank – 1).
However, even when the initial rank is 1, the
premium is never reduced below a lower bound Rise score breakdown (Score tab)
of P/3.
• In the endgame, score isn't a good measure of a civ's standing. Therefore, whenever
R&F considers ranks, those civs close to a victory condition (stage 3 or 4) are con-
sidered to be ranked higher than those not close to any victory, and civs at stage 4
23
outrank those at stage 3.
• Regardless of the initial rank, the percentage of turns remaining in the chapter in which
victory has been achieved is added.
• Finally, the Rise score is multiplied by a factor based on the difficulty setting.
On the Hall of Fame screen, the Rise score is shown in the "final score" column. Use the
"score victory" filter in order to display only results of R&F games.
A defeat of the human civ does not cause the game to end unless it happens in the final
chapter. Instead, human defeat causes the game to continue on Auto Play until the chapter
ends, and then a new civ is selected as normal. A defeated civ is scored immediately and
is treated as having 0 CIV points.
PerfectMongoose (PM)
The PM map script is based cephalo's PerfectWorld3 (PW3), which employs models of
plate tectonics, wind patterns and hydrology. The basic ideas are best described in the old
CFC thread for PerfectWorld2 (PW2). LunarMongoose ported PW2's successor PW3 from
Civ 5 to Civ 4, incorporated changes by AIAndy and Fuyu, and made changes of his own,
which are listed in the PM thread on CFC.
• PM vs. Tectonics: LDiCesare's Tectonics script, which is included in BtS, also models
plate tectonics and wind but, as far as I can tell, in simpler ways. PM has about three
times as many lines of code as Tectonics does if that's any indication. That said,
Tectonics offers some unique options like “Mediterranean”. An updated version of
Tectonics is also included with AdvCiv (change id 021a).
• PM vs. Totestra: Totestra is a PW2 fork by vktj. Totestra offers more custom map options
than PM, but PM has a more sophisticated noise generator. (Totestra should be
compatible with AdvCiv but isn't included in the mod.)
I've customized PM (change 021b) because I felt that the starting locations were too un-
balanced and it played too differently from the standard map scripts. In particular, there
was little arable land. In many ways, PM can supersede the Fractal map script, but, since
PM tends to generate more continents and more chokepoints than Fractal, the space
available for expansion tends to be distributed less evenly.
Mixed Continents
A variant of jam3's Continents and Islands, which, in turn, is based on the BtS script "Big
and Small" by Sirian. I've called my version "Mixed Continents" because it doesn't
necessarily involve islands – by default, the two landmass types are normal continents and
small ("snaky") continents. It's possible to place the two landmass types in two separate
regions of the map, but, by default, they're mixed together. (For separate regions, K-Mod's
“Not Too Big or Small” script may be the better choice.) I've disabled jam3's terrain options
because I found them a bit arbitrary, and, instead of the "Add Water" option, the sea level
setting is now used. (“Big and Small” ignores the sea level.) I've also added a world-wrap
option and tweaked the land/ sea ratio and map dimensions so that the same player
counts can be used as on e.g. Fractal. For some more details, see change id mxc.
24
All-AI games
An all-AI game can be a quick way to to get an impression of the AI behavior in AdvCiv or
to check how well the mod handles certain game settings. The procedure is as follows:
1. Make sure that cheats are enabled ( CheatCode = chipotle in My Games\Beyond the
Sword\CivilizationIV.ini). This is a prerequisite for Debug mode and AI Auto Play.
2. On turn 0, press Ctrl + Z to switch into Debug mode. This makes the entire map visible.
3. Unless the game is set to Noble or Prince difficulty, if you want your own civ to have the
same starting conditions as the other AI civs, you'll have to use the WorldBuilder to give
additional techs and units to your civ (if the difficulty is higher than Prince; see the table
above the Rise & Fall chapter), or to all other civs (if the difficulty is lower than Noble).
4. Press Ctrl + Shift + X to have the AI take control of your civ. A popup lets you choose
the number of turns to be spent on AI Auto Play. (A mnemonic for the shortcut: control is
shifted to the AI for x turns.) AI Auto Play can also be interrupted through Ctrl + Shift +
X, though you may have to press these keys repeatedly because key presses are not
received reliably during AI Auto Play.
AdvCiv makes a few improvements to the AI Auto Play mod component (change id 127):
• The player's civ plays by the same rules as the AI civs; in particular it plays on the same
difficulty level.
• While both AI Auto Play and Debug mode are enabled, messages about major game
events such as declarations of war and conquered cities are shown as if the player's civ
had perfect knowledge of the game state.
• Unless interrupted, AI Auto Play ends at the start of a human turn. This means that no
diplo popups can occur on that turn. (That said, it can still happen that the player is
prompted to vote on a UN resolution right after AI Auto Play ends.)
Performance
Although the UWAI component is computationally expensive in large games, as of version
0.99, the mod appears to be faster than K-Mod even when the number of civs is increased
beyond 18. In a test with 31 civs (i.e. 32=2 8 players when counting the Barbarians; this
number has some computational advantages) on a map with 160 x 100 tiles, the first 300
turns on AI Auto Play (see All-AI games) took fewer than 30 minutes with AdvCiv and more
than 50 minutes with K-Mod. K-Mod, in turn, is significantly faster than BtS. Note that
changes to the civ limit (normally 18) require the DLL to be recompiled; see under For
developers. For benchmarking, the shortcut Ctrl+Shift+B can be used (cf. BM in the
appendix). The performance gains in AdvCiv have been achieved through various low-
level optimizations across the Game Core DLL (cf. advc.opt).
Known limitations
‒ PBEM (play by e-mail) has barely been tested, PitBoss games not at all. For all types of
network games, note that, to stay in sync, all players need to use the exact same
version of AdvCiv. Player options (Ctrl+O) and BUG options (Ctrl+Alt+O) may differ.
‒ Some of the Custom Game settings have been tested only superficially through AI Auto
Play, and of course I haven't been able to test every combination of settings.
25
‒ If the mod folder "AdvCiv" is renamed, the name also has to be changed in Assets\
XML\Art\CIV4ArtDefines_Misc.xml and (twice) in Resource\Civ4.thm. Otherwise, the
mod will crash while loading: "Failed to initialize the primary control theme." This is a
side effect of change 002b (enlarged fonts). That change also makes it impossible to
install AdvCiv into My Games\Beyond the Sword\Mods.
‒ The current version of the mod should be able to load savegames from all earlier
versions but no savegames from other mods nor from unmodified BtS.
‒ The mod has only been tested with the international (MULTI5/ EFIGS) version of BtS.
German translations are almost complete, though hardly tested. I don't recommend
using one of the Romance languages as I've only translated parts of the new game text.
Localized editions of BtS (e.g. Russian) could have issues with displaying city names (if
so, this CFC thread should help) or might not be compatible with MULTI5 mods at all.
‒ One player has reported a potential issue with AdvCiv and Windows 7 user account
control, so I've listed some steps that might help here on CFC. The dated but detailed
instructions here could also be helpful. (Addendum: If a compatibility mode is needed,
some say that it's best to use Vista SP2, others say Win 7.)
‒ The Work in progress section at the end of this manual lists non-critical open issues.
(Most of them are not really work in progress anymore because v1.0 is supposed to be
the last major release of this mod.)
For developers
The modified Game Core source code files are available on GitHub. In all modified files,
changes and additions are labeled in-line with “ advc.id” or enclosed in XML style:
<advc.id> ... </advc.id>, where id is one of several three-digit numbers that I've (pretty
arbitrarily) assigned to sets of related changes. Lately, I've started to replace some of the
numerical ids with letters, e.g. “advc.opt” for miscellaneous performance optimizations.
Nonfunctional changes (cf. 003) are marked with just “advc” (no id number).
Changes from K-Mod-Extended are instead marked with kmodx (these are also in K-Mod
1.45, but I had merged them into AdvCiv before 1.45 was released), those adopted from
Kek-Mod with kekm. and contributions by Erik (devolution on CFC) with Erik. AI changes
from the LoR SDK ModMod are tagged with cdtw. Nightinggale's GameFont Display is
tagged with gfd.
I've gathered bugfixes and tweaks that other mods could easily adopt from AdvCiv in this
Git branch based on K-Mod 1.46. I've committed DLLs, so the branch is playable too.
UWAI is documented mostly through comments in code (more verbose documentation
exists but is out of date); the appendix (id 104) only describes the integration of UWAI into
BtS. Parts of UWAI are adjustable through AI_Variables_GlobalDefines.xml. If you've
enabled logging (LoggingEnabled=1 in My Games\Beyond The Sword\CivilizationIV.ini),
you can change REPORT_INTERVAL in GlobalDefines_devel.xml in order to have UWAI write
AI internals to My Games\Beyond The Sword\Logs\uwai.log. The logs are formatted in
Textile. I've been using Borgar Þorsteinsson's Textile-JS to parse it (free web interface). In
Debug mode (Ctrl + Z), AI war plans can be checked in-game by holding down the Alt key
and hovering over the AI leaders on the scoreboard; same as in the BBAI mod. If
UWAI_SPECTATOR_ENABLED is set to 1 in GlobalDefines_devel.xml and Debug mode is
enabled, then announcements about AI war preparations are shown during AI Auto Play.
26
Debug mode, WorldBuilder and AI Auto Play can be enabled for network games through
XML; see 135c for details. See 007 for a crib sheet about all available logfiles.
Unlike most mods, AdvCiv sets the maximal number of civs ( MAX_CIV_PLAYERS) not in
CvDefines.h but in CvEnums.h. The standard version of the mod uses MAX_CIV_PLAYERS=18
(like BtS) because unused player slots negatively affect performance. Due to various code
optimizations, that overhead should be almost insignificant at this point, e.g. less than 10%
(perhaps less than 5%) when increasing MAX_CIV_PLAYERS to 31 while using only 18 civs.
Still, increasing MAX_CIV_PLAYERS in AdvCiv would break savegame compatibility with
earlier versions of the mod. For mods derived from AdvCiv, going to 31 (i.e. 32 players
when counting the Barbarians, a computationally advantageous number) would seem like
a good idea, seeing that 18 aren't really enough to fill a Huge map at Low sea level and
that some spare civs are desirable for colonial vassals.
Rebuilding CvGameCoreDLL.dll: If you've done this before for other mods, then it's just
a matter of setting the usual file paths in CvGameCoreDLL\Project\Makefile.settings.
Otherwise, see step 5 in this old guide by Asaf about the paths; CIV4_PATH corresponds to
CIVINSTALL. You may want to use Service Pack 1 of the MSVC 2003 toolkit and version
6.0 of the Windows Platform SDK, both available here (GitHub; 20 MB archive), rather
than the files linked in Asaf's or Leoreth's guide. The readme file here explains potential
issues with the libraries from the guides. Step 2 of “Setup from Scratch” in Leoreth's guide
describes how to install Visual Studio (VS) 2010 Express, which is what I've been using;
newer versions of VS can be used as well (at least up to VS 2019), though VS 2010 may
have to be installed in addition. Make sure to select VS for C++ in the 2010 installer. To
build the DLL, open CvGameCoreDLL\Project\AdvCiv.sln in VS and select “Build” from the
“Debug” menu (or press F7). The build configuration can be changed in the “Configuration
Manager”. Nightinggale's guide contains some information about the available
configurations. See “advc.make” in the appendix about configurations added by AdvCiv.
To attach the VS debugger, I recommend creating a copy of My Games\Beyond the Sword\
CivilizationIV.ini, e.g. named AdvCivDebug.ini. It's easiest to place it in the same
directory as Civ4BeyondSword.exe (CIV4_PATH directory). In the copy, set FullScreen = 0
and Mod = Mods\AdvCiv. You may also want to reduce ScreenHeight a little (rationale) and
make some other debug-friendly settings: CheatCode = chipotle, LoggingEnabled = 1,
AutoSaveInterval = 1. Then select the “Debug” configuration in VS 2010 and under
“Configuration Properties” - “Debugging,” enter Civ4BeyondSword.exe with its full path(!)
into the “Command” field and ini=AdvCivDebug.ini into “Command Arguments”. (VS will
write that information into CvGameCoreDLL\Project\AdvCiv.vcxproj.user; that file can also
be edited manually.) You can then “Start Debugging” via the “Debug” menu.
Steam users need to install Steamless for debugging.
A note about the GNU Public License: A copy of that license is included in the BUG Doc
folder only for the sake of the AI Auto Play mod. AdvCiv as a whole is not (at this time)
distributed under that license and I don't believe the BUG mod is, either.
27
Appendix
Most of the change ids are assigned pretty arbitrarily. Changes since version 0.8 are also
tracked through Git: commit history.
Obsolete; Barbarians don't have a target city at all now through change 300.
Only cities whose location the AI knows or is able to deduce can be per-continent target cities. The
corresponding visibility checks were missing in various places, but mainly in
CvPlayerAI::AI_findTargetCity.
Through CvPlayer::handleDiploEvent: An AI vassal will now target no city in particular when
asked by its human master to attack a city that is not revealed to the vassal. (Don't want to filter
those cities out in the menu because a player isn't necessarily supposed to know which cities are
revealed to its vassals.)
Reduced the chance for building a "priority fort" from 80% to 20%, which, I suspect, was intended.
(No clue if it's wise.)
Since K-Mod 1.44, Gunship had been able to capture cities if they contained a visible non-combat
unit. Reported by Zholef here. Also fixed in K-Mod 1.45, but I've kept my own fix instead.
Eliminated AI civs can no longer do diplomacy. In BtS, there is a slim chance for this to happen
right after an AI is eliminated by another AI.
AI no longer trades for resources needed only for obsolete units (merged from Better BUG AI).
Integer overflow in K-Mod code when a large amount of culture is added through WorldBuilder.
Thanks to xaster for pointing out the issue on CFC. Also fixed in K-Mod 1.46.
BBAI attitude cache updated when the ranks on the scoreboard are updated.
The dot map overlay shows up correctly after loading. Bugfix by EmperorFool: source
And the overlay gets updated upon taking control of another player, i.e. will show the city dots that
had been placed by the new active player and hide those placed by the old active player. BUG had
already supported this behavior, but it had only been triggered by player cycling in Hot Seat
games. Now also works for debug tools and the R&F option.
Tbd.: Overlay isn't cleared when regenerating the map. And stays disabled after AI Auto Play. And
doesn't store the most recently selected color in savegames. And appears to be cleared when
Python scripts are reloaded (if this doesn't crash BUG entirely; see 009b).
The Civ4lerts module no longer crashes when the player takes control of a colonial vassal that
hadn't existed when the game was last saved and reloaded.
28
When enemy units and neutral units are together in a tile, the unit model shown on the map
(“center unit”) is guaranteed to be an enemy unit. (K-Mod bug in CvPlot::updateCenterUnit)
karadoc had meant to disable a preference for units with available moves. I've done that in change
– but only during AI turns. Until AdvCiv 1.06, had fully implemented the intended K-Mod behavior,
then, this CFC post made me aware that the center unit is not just shown on the map but is also
the unit that gets selected when the tile is clicked. During the active (human) player's turn, it's
helpful to prefer selecting units with available moves.
A resolution for mutual defensive pacts can't be signed if all non-vassal members already have
signed defensive pacts. (CvGame::isValidVoteSelection)
In CvFractal::tectonicAction, a variable was unused, and this looked like a bug. I'm not sure
though; the maps look as before. It seems that only the Continents script calls that function. (I'll
probably also use it for the “True Starts” script; see advc.tsl.)
Two bugs fixed in the calculateTradeRoutes function (TradeUtil.py, CvExoticForeign
Advisor.py). I don't think either of these had any impact in AdvCiv, but they were still bugs.
Credits: Leoreth (Dawn of Civilization mod) Git commit 1 2
autologEventManager.py (Autlog mod) had assumed the active player slot to be 0 in a few
places. There might be other issues with scenarios (which don't usually give slot 0 to the active
player) – I haven't tested it; these are just errors I came across when browsing through the code.
K-Mod shows cities as Barbarian if the true owner hasn't been met (city revealed through map
trade). Now showing the true color. In CvCity::getCityBillboardSizeIconColors.
If the AI starts the game with a free Worker, then the starting Settler is moved before the Worker.
(In K-Mod, the first Worker turn is always wasted.) Implemented through CvPlayerAI::
AI_movementPriority and CvUnitAI::AI_handleStranded.
When a unit that is selected by the active player dies (in combat or disbanded), the per-turn
income shown on the upper left is immediately updated to reflect possible changes in expenses
(unit cost and supply). In CvUnit::kill.
Corrected the id of K-Mod's “Simple Unit Selection” option in the DLL (CvGame::selectUnit); the
option had no effect previously.
From Mongoose Mod changelog
12-14 Dec 2012: “bug in CvUnitAI::AI_betterPlotBuild [...] it was thinking every plot bridged two
plotgroups”
15 Feb 2013: “vanilla bug with the AI evaluation of […] worldsize-scaling -1 quantity value on
Broadway, Rock 'N Roll, and Hollywood's free resources” (in CvCityAI::AI_buildingValue)
On the city screen, use the art style of the city owner even if another player is inspecting the city.
Based on this bugfix by Leoreth (Dawn of Civilization mod). I've fixed it entirely through
CvPlayer::getUnitArtInfo.
Set “time played” back to 0 when regenerating the map. (CvGame::regenerateMap)
Call beforeInit on map scripts when regenerating the map after having saved and reloaded
(which may have caused Python data stored by beforeInit to be lost). Relevant for Highlands,
PerfectMongoose (advc.021b) and some third-party scripts.
canParadrop and canParadropAt had not been correctly exposed to Python (Credit: Roamty; link)
In CvCityAI::AI_getPlotMagicValue, the YieldWithBuild value needs to be taken times 100
to match the scale of AI_getYieldMagicValue.
This bug was introduced with the BtS expansion and probably mattered only for the iPopToGrow
computation in CvCityAI::AI_yieldValue. Even there, the impact seems to have been minor
because happiness is normally the dominant limiting factor for (planned) AI population growth. See
also: The bugfix is important for 113.
29
Fixed a potential issue with the BtS limits on withdrawal, evasion and interception chance in
CvUnit::isPromotionValid: Once a unit exceeded a limit, it was unable to receive any
promotion. That would be a problem when a mod increases the respective chance value in
Civ4UnitInfo.xml. Now only promotions that increase the chance value are blocked.
The pyAssert function in CvUtil.py now actually raises an assertion error. Somewhat important
to let findInfoTypeNum (same module) tolerate empty strings then; will otherwise render
scenarios unplayable that cause no problems in BtS, specifically the Accurate Earth Maps by
Laskaris.
Credits: More Naval AI (lfgr), CFC user wfeiger for reporting the problem with Laskaris's maps
(CFC post).
(Also adopted – not really a bugfix: Git commit)
The AI doesn't cheat with visibility when selecting a target city for a Trade mission (Great
Merchant) in CvUnitAI::AI_tradeMissionValue.
Credits: More Naval AI (Tholal)
Wrong type of AI strategy bitmask in AI_getImprovementValue,
AI_updateSpecialYieldMultiplier (both CvCityAI, having to do with AI yield adjustments).
Logical operators used with bitmask in CvPlayerAI::CvPlayerAI::AI_espionageVal; something
about the counterespionage mission.
All three in K-Mod code.
See also: Found after turning the bitmasks into enumerators (advc.enum).
CvPlayerAI::AI_unitValue: Wrong parameter for the isCarrierUnitAIType call (BtS bug).
This probably meant that the AI was able to recognize special cargo units only through the AI types
stated in Civ4UnitInfos.xml. So only a problem for mod-mods, maybe.
In the BBAI code for (automated) air recon, a visibility check had been flipped in
CvUnitAI::AI_exploreAirPlotValue, and, in CvUnitAI::AI_exploreAir2 (renamed by AdvCiv
to AI_exploreAirRange), the tiles around the airbase had been evaluated instead of the tiles
around the candidate recon tile. On the bottom line, the recon target tile was chosen randomly with
a bias only for maximal distance from the airbase.
See also: 650 uses that function also for AI air recon. 029 makes some AI tweaks.
In CvUnitAI::AI_handleStranded, units had been moving toward any coastal tiles including
lakeshores. Now only seashores are targeted.
CvPlayerAI::AI_doDiplo failed to check for a trade connection before demanding resources
from a vassal.
Fixed a perhaps inconsequential copy-paste error in CvDeal::isUncancelableVassalDeal.
K-Mod's ROUND_DIVIDE function was incorrect for fractions between 0 and 1.
(CvGameCoreUtils.h)
The Partisans event had used tile culture to determine the previous city owner's culture level
instead of city culture. Also (not a bugfix I suppose), I'm subtracting 1 from the culture level so that
e.g. cities with “poor” culture don't spawn any partisan units.
Credits: Reported on CFC by SmokeyTheBear – who also suggested subtracting 1 and found
another bug in the Partisans event that AdvCiv fixes through 003y.
Flipped sign in the AI evaluation of specialist experience (CvCityAI::AI_jobChangeValue). That
ability is unused for (non-super) specialists, so this only matters for mod-mods (possibly).
Clear popups of non-human players before saving in CvPlayer::write.
Tbd.: Find out under which circumstances the EXE adds popups to non-humans. (Update a couple
of years later: Looks like the EXE no longer does that. Probably a problem I had introduced and
fixed without noticing.)
30
When a city gets destroyed and replaced due to a change in ownership (CvPlayer::acquireCity),
don't check if the city tile is valid for local units until the new city is in place. Because the tile may
flip to a third party for an instant.
A K-Mod 1.45 change in CvCity::getProductionDifference had (accidentally) caused angry
citizens to consume food even during the production of a Settler or Worker. I've also added a
loading screen hint about the underlying Vanilla/BtS rule.
Credits: Bug reported by CFC user carp.
See also: K-Mod Git commit introducing the bug. CFC thread where a Firaxis developer explains
why angry citizens don't consume food. Post by karadoc, half a year before the Git commit,
explaining that he's aware of the BtS rule and wants to keep it (reluctantly).
Tbd.: Maybe treat the population as 1 less while producing a settler or worker. That would seem
more consistent. Still doesn't exactly make sense. (It would if workers and settlers consumed
population as in Civ 3.)
K-Mod 1.44+ (through this Git commit) had chosen the “Big Espionage” strategy
(CvPlayerAI::AI_updateStrategyHash) based on the AI espionage commerce weight and the AI
espionage weight (in part) based on “Big Espionage”, creating a feedback loop. The problem was
probably introduced when CvPlayerAI::m_iEspionageWeight was repurposed as a cache for the
(final) espionage commerce weight.
Credits: CFC user SuperXANA made me aware that the AI uses “Big Espionage” very often.
See also: Might fix this issue raised in the “Dawn of the Overlord” thread.
Tbd.: Similar problem with “Espionage Economy” and CvPlayerAI::AI_updateCommerce; not
sure if it has adverse consequences.
In AI_techUnitValue, BtS/BBAI/K-Mod code for incentivizing oceangoing ships had had no effect.
CvGame::onGraphicsInitialized: When loading a savegame in which the active player owns no
units, the camera had centered on some (seemingly?) arbitrary tile, not necessarily a revealed tile.
Now it centers on the active player's starting location in that case. See also: Based on a
workaround (004j) that moves the camera after regenerating the map.
When a city was selected without opening the city screen, CvGame::shouldDisplayUnitModel
had shown a 3D model next to the production queue only if a unit was selected before selecting
the city. Now the model gets shown regardless of selected units.
The unused AdvancedStartCostIncrease XML tags for improvements and routes had increased
the cost based on improvements or routes owned by any player – only those placed by the current
player should count.
For random events involving two civs, it looks like CvPlayer::applyEvent hadn't properly
checked whether both civs have been met before notifying the human player.
Looks like BtS and the unofficial patch didn't take the Random personalities option into account in
CvGame::addPlayer and CvPlayer::getSplitEmpireLeaders. I haven't tested it, but, hopefully,
colonial vassals will now receive a random AI personality that (usually) differs from the leader
appearance.
Added code to CvPlot::changeVisibilityCount that works around a problem with the
interaction of nuke visibility and Fallout replacing a sight-blocking feature (Forest or Jungle). Tbd.:
A proper bugfix.
The price charged by the AI for an embargo (CvPlayerAI::AI_stopTradingTradeVal) had been
counting all deals of the AI, not just those with the embargo target. (bug in vanilla Civ 4)
“No Action Recommendations” player option had been ignored at game start. Fixed by setting the
dirty-bit for colored plots in CvPlayer::setOption.
See also 127: Automation options had been applied during AI Auto Play.
Flipped fraction in K-Mod's CvCityAI::AI_getImprovementValue had caused the AI to be less
31
interested in Cottages when in Emancipation.
Fixed Civilopedia links to the Spy specialist article that had lead to the Spy unit instead. Similarly,
links to coporations had lead to the HQ building instead of the coporation articles. Through helper
functions CvGameTextMgr::setSpecialistLink, setCorporationLink and changes to some
game text keys. Credits: Bug reported by crullerdonut (middle of the post)
Disregard non-rival units in CvPlayerAI::AI_doEnemyUnitData. (Because that data is used by AI
governors for picking units that counter potential enemy units, e.g. Pikeman vs. Knight.) Seems like
an oversight (but not a bug, strictly speaking).
When the game decides whether a starting site needs extra food (CvGame::
normalizeAddFoodBonuses), Whale is no longer counted as an available food source (unless
starting in Renaissance or later). BtS had failed to check the tech requirements of the necessary
terrain improvement (Whaling Boats).
AI resource evaluation had not counted projects (e.g. Manhattan Project when evaluating Uranium)
in production queues as currently relevant uses of the resource. Same bug with world units (which
are not used by AdvCiv). These issue were introduced by the BtS expansion.
Fix counterintuitive rounding of hurry production costs that get reduced by a non-generic modifier,
e.g. the settler modifier from the Imperialistic trait. Credits: Based on this CloseToHome Git commit
Call updateDiplomacyAttitude in the EXE after each update of the AI attitude cache that occurs
while the Diplo screen is up. I think this aligns the leaderhead animations with the AI attitude
level(?). Was previously only called after a civics or religion change (before updating the attitude
cache), but there are several other interactions that can change relations values while the Diplo
screen is up.
A K-Mod check in CvPlayerAI::AI_espionageVal had assigned 0 value to the Spread Culture
mission unless the spy owner had at least 8% city culture in the target city. City culture is 0 unless
a city has been previously owned, so probably tile culture was intended.
Worked around an issue with Debug mode (and WorldBuilder) that had caused Tribal Villages that
a rival had already entered to appear briefly upon being (eventually) revealed to the active (human)
player. As far as I can tell, this only occurred when the active player had at an earlier point revealed
the whole map and then hid it again. Perhaps the worst problem with that is that I or another
developer might not be aware that only developer “cheats” can cause those ghost goody huts.
Implemented in CvPlot::removeGoody.
Fixed an issue with XML comments in CvXMLLoadUtility::GetChildXmlValByName. K-Mod had
already fixed such issues in several other places. (An XML parser unable to handle comments in
certain places is a bug in my book.)
In CvPlayer::setCombatExperience, pick a civ-specific Great General unit – so that mod-mods
can implement unique Great Generals. Credits: edead, Leoreth (CFC post)
Coastal AI cities had been producing transports while preparing war against a land target that the
city owner did not have Open Borders with. Due to the BBAI function CvPlot::
isHasPathToEnemyCity (replaced by CvTeamAI::AI_isHasPathToEnemyCity in AdvCiv) not
passing a war target to the pathfinder. Credits: Found by spqkfk (AdvCiv Plus mod)
The K-Mod 1.46 evaluation of AI tech paths had gotten the ordering of the techs wrong, picking the
worst rather than the best option for the last (third) tech in a path. This had only affected paths
consisting entirely of techs that the AI was able to research immediately, i.e. paths that didn't bee-
line anywhere.
32
WorldBuilder. (I haven't fixed those; see comment in CvPlot::setPlotType.)
001b (Not actually a bugfix.)
Can't train air units in cities already filled with air units. (BtS allows them to be trained
and rebases them upon completion, destroys them if that's not possible.)
Gifting air units is only possible if the recipient has enough air unit capacity.
Support added for iAirUnitCap (Civ4UnitInfos.xml) greater than 1; not tested.
When a newly completed unit exceeds a city's air It's impossible to move air units into a tile whose
unit capacity, the unit is moved to the city's rally capacity will be exceeded, but cities without
point. If no rally point is set, the unit is moved (as available air capacity are allowed to produce air
in BtS) to the nearest city or fort with sufficient air units. Upon completion, an excess air unit is
unit capacity. The unit has its movement points moved to the nearest legal city or fort or
spent at the start of the next turn. If there is no destroyed if there is none. The forced move
city or fort with available capacity, the unit is doesn't cost any movement points. The city
scrapped. When moving to the nearest city (no owner isn't notified about the move (nor of the
rally point) or scrapping, an on-screen message destruction of a unit).
is shown. Clicking on the message centers the
camera on the unit's new location.
Config Previously, I had made it impossible to produce air units in cities without available air
unit capacity (in part, through change 064d). That rule change can be a bit tedious
when mass-producing air units in the late game, but it can still be enabled through
CAN_TRAIN_CHECKS_AIR_UNIT_CAP in GlobalDefines_advc.xml.
Credits Elkad made me aware that my old rule wasn't ideal with regard to usability. (CFC post)
See also 163 always spends the movement points of teleported units. That doesn't help in this
case because units are produced at the end of a turn, just before movement points are
restored.
Help text for the gift-unit button based on 093
001c Display and calculation of GP birth probabilities
AdvCiv BtS
GP birth probabilities are affected by the timing of GP birth probabilities are proportional to progress
GPP modifiers; e.g. specialists during a Golden values counted per GP type (no change in
Age contribute more to the probability of their GP AdvCiv). GPP modifiers do not apply to those
type than specialists at other times do. progress values.
Rationale I wouldn't call it a bug, but it looks like an oversight to me. At any rate, it's
counterintuitive when the per-unit progress values don't add up to the total progress
value.
See also Bug report, brief discussion on CFC: link
Corrected the birth probabilities shown on the GP Birth probabilities are based on the GPP
bar (city screen and BUG GP progress bar). Now collected so far; no projection. The probabilities
project the city's current per-turn GPP into the adjust only gradually when a specialist is
future. reassigned.
Tbd. Should perhaps take into account a foreseeable increase of the GP threshold due to
other cities finishing their GP earlier. And Golden Age length if currently in a Golden
Age. That said, I might at some point change the way the threshold increases; better to
leave the UI-side alone for now.
See also 078: Changes to BUG's GP bar options.
001d In Debug mode, the Top 5 Cities and Wonders tab and Religion, Civics and Espionage
screens were not properly switching to the perspective of another civ because of some
33
errors in the Vanilla Civ 4 and BtS Python code. And the Top-5/ Wonders didn't reveal
all information when the Info screen pops up at game end.
See also 007 deals with other changes to the Wonders tab in Debug mode.
Tbd. Tech tree doesn't show the tech progress of the civ selected from the Debug menu;
only shows which techs are known to that civ.
The active player should be added to to the Debug drop-down menus first so that the
active player is the initial selection. Currently, whoever is in player slot 0 is on top. (It's
apparently not possible to make a selection programmatically.)
Credits crullerdonut reported the issue with Top-5 cities at game end here (penultimate quote
box).
Unrevealed cities are shown as "Unknown" on Top 5 cities (K-Mod: "Unknown" only if owner not
met). Only revealed cities are considered for the list of high-culture cities on the Victory screen.
Rationale Not really a bugfix on second thought but consistent with the K-Mod rule that
unrevealed cities are secret.
001e No more stop-trading requests about a civ that has just stopped being worst enemy;
and no offers for Defensive Pact from a civ that has just been attacked.
Rationale Because the AI can't immediately contact human players, the conditions for AI
requests need to be checked again at the start of the human turn. This is handled
outside the SDK and mostly works, but, apparently, some checks had been missing.
See also 134a deals with AI peace offers getting discarded by the EXE.
Tbd. It would be good to check reasonable preconditions for all AI requests at the start of
the human turn inside the DLL. Perhaps by moving the conditions that are checked
before making each request (mostly in CvPlayerAI::AI_doDiplo) into subroutines.
Rationale: (a) There could be further conditions that the EXE fails to check, and (b) the
DLL could then reset the appropriate AI contact timer (since no contact was made); I
don't think the EXE does this. The timer for embargo requests and DP offers are
already reset by the DLL but only in the narrow circumstances described above (in the
blue box). But what if the resolution of one diplo popup invalidates a subsequent one?
At that point, the EXE has already fetched the entire contents of the diplo queue.
(Update: There might currently also be problems in simultaneous-turns multiplayer with
AI civs offering the same deal to multiple human players at the same time.)
Preferable approach, probably less work too: Move AI-to-human diplomacy entirely to
the start of the human turn and thus remove the need to double check the
preconditions (and this would improve the quality of the offers too). I've written and
archived (not published on GitHub) a draft for implementing this. And I've briefly posted
about it here (second paragraph). Along with this change, an open issue with the
timing of on-screen messages (see Tbd. under 106b) should be addressed.
Problem: Peace proposals are currently made during the team AI turn as part of
AI_doWar. I guess CvPlayerAI::AI_negotiatePeace and AI_offerCapitulation
should be delayed until the diplomacy turn of the team leader. The parameters that
CvTeamAI (or rather UWAIAgent) passes to those functions during the team turn are
good; shouldn't have to be recomputed later on.
Related “We the People” Git issue: link
001f Foreign cities no longer become unrevealed upon conquest by a third party
When a city is conquered, it remains revealed to When a city is conquered, it is treated as a new
all civs that knew the city prior to conquest. city, revealed only to the new and former owner,
and any third parties that happen to have visibility
34
of the city at the time that it is conquered.
Rationale Hard to say if this is really unintentional. The BtS code explicitly sets the city to be
revealed to the former owner. Were third parties not considered?
Doesn't make sense to me that third parties learn about the conquest but not about the
aftermath.
See also I think, in BtS, the culture layer gives away the new city owner and the status of the
surrounding tiles. 004z changes that.
001g Deleted duplicate MemoryAttitude entries about Suleiman and all leaders after him in
Civ4LeaderHeadInfos.xml (it's ordered alphabetically); used the mean when two
values contradicted each other. Those before Suleiman didn't have duplicates.
35
The fog of war hides tile ownership, units, cities,
improvements and routes.
The pathfinder ignores unrevealed routes on The pathfinder treats all routes on revealed tiles
revealed tiles, meaning that the waypoints shown as revealed. By plotting a path through fogged
on the UI can't give away fogged routes and that tiles, a player can learn whether routes have
the AI does not count on using such routes. been built in those tiles.
AI plot danger calculations disregard unrevealed
routes on revealed tiles.
See also 124 prevents the Trade layer from giving away routes in the fog of war.
181 prevents unit action recommandation from giving away unrevealed landmasses.
182 prevents tile yields from giving away unrevealed resources on foreign tiles.
183 addresses some issues with cities and forts in the fog of war.
128 sometimes prevents the plot danger functions from cheating with visibility.
advc.pf fixes other pathfinder issues.
004c fixes some minor issues with air missions leaking fogged info.
031 prevents recommended city sites from giving away foreign cities in the fog of war
(by making the AI city site evaluation care about revealed tile owners rather than
actual owners).
See also 017 fixes a bug that also has to do with confusing these two function.
Added a couple of isFriendlyTerritory calls – had apparently been overlooked when BtS
introduced vassal agreements (which allow passage even without an OB agreement). AI evaluation
of Missionaries should be improved now.
Replaced ALWAYS_PEACE option checks in AI code with calls to CvTeamAI::AI_isWarPossible.
Rationale When both ALWAYS_PEACE and ALWAYS_WAR are enabled, war wins out. The (Vanilla
Civ 4) AI_isWarPossible function sorts that out and also handles
NO_CHANGING_WAR_PEACE.
See also 105 replaces getAnyWarPlanCount with AI_isFocusWar; that's a vaguely similar
change.
36
(Using the canBeEntered function from change 030 since v0.90.) No longer the case
since v0.95.
“More Naval AI” fixed this a few years earlier (though my latest fix is better): Git
commit
001n Some potential OOS bugs fixed. (I've introduced my fair share of these bugs, but only
bugfixes in non-AdvCiv code are tagged with “001n”. I'm also using that tag for some
misc. code that I added for OOS debugging.)
37
The usual causes of out-of-sync errors in networked multiplayer are these:
(a) Local code (invoked by user input) modifies the game state. All uses of the sync'd PRNG
(SorenRandNum) modify the game state. Some AI functions have a bAsync parameter that
causes them to use the asynchronous PRNG (ASyncRand) instead. Also tricky: Functions that
cache their return value, in particular AI_baseBonusVal, AI_localDefenceStrength,
AI_techBuildingValue and AI_obsoleteBuildingPenalty, all at CvPlayerAI;
CvPlot::getFoundValue, CvCityAI::AI_buildingValue, CvCity::AI_neededFloating
Defenders, and the AI plot danger and closeness functions. Most have a bConstCache
parameter to prevent the cache write. I think the cache writes wouldn't actually be a problem if
the caches were reliably invalidated, but the formulas depend on so many variables that this is
impossible to do.
(b) Access to uninitialized or non-allocated memory (e.g. out of array bounds)
(c) Use of getActivePlayer in global code (not invoked by user input)
(a) and (b) are also problematic in singleplayer. Rare, but something to reckon with: Sorting by
memory address can cause OOS errors (K-Mod Git commit) and other errors (C2C Git issue).
Comprehensive guide by Gerikes about avoiding and debugging OOS errors: CFC thread
Overview by Afforess: link
CFC post by karadoc on the subject of OOS errors: link
Some posts by EmperorFool: link
By Nightinggale: link
See also See 007 (logging), 135c (Debug mode) and 127 (AI Auto Play) about multiplayer
debugging.
kekm.27 adds a OOSLogger component
See 003g about potential issues with floating point arithmetic.
Open K-Mod issue concerning (a): link (related forum post). I think 036 addresses this.
repro: Test for identifying non-deterministic code, addressing mainly error type (b).
Tbd. CvPlot::m_abBorderDangerCache isn't stored in savegames and that seems a bit
risky, though it might be fine.
The AI plot danger functions cache some data. They're only called in synchronized
code currently (except in Debug mode, and I've disabled these dangerous calls in
networked games) as far as I can tell, but it would be nicer not having to worry about
that, so a const-cache parameter or accessor should be added.
Config I've left some code for debugging OOS problems commented out in
CvSelectionGroupAI::AI_update. If an error is caused by the move of an AI unit,
this will make it easier to identify the responsible unit. The checkInSync function
could also be called from other (synchronized) parts of the code. The bFullOOSCheck
flag in CvGame::calculateSyncChecksum should be set in addition.
38
commit, in the EXE – or maybe the K-Mod lookAt call was indeed erroneous, hard to say without
knowing the exact semantics of that function. I write all this down (in Dec 2020) because I'm not
sure if the problem is really fixed now. I've been experiencing rare, non-reproducible main map
blackouts during AI Auto Play since at least Sep 2020, usually while I had the window minimized
(but, then, I often minimize during AI Auto Play). In September, I had tried out a faster version of
Python24.dll (see under advc.make). Reverting to the old version of that DLL later did not fix the
problem, but it appeared to be more common with the faster DLL. Upd. (June 2021): I haven't
experienced these random blackouts anymore.
If such problems persist, my best bet is to investigate lookAt calls. I've already tried calling lookAt
with negative x, y and z coordinates. That (by itself) does not cause the main map to black out.
Credits CFC user crullerdonut made me aware of the conscription issue: bug report
001p Crash when loading a smaller game from inside a larger game
AdvCiv BtS
Kill all cities early in the loading process. (Upd.: The logic for loading savegames is partly outside
Resetting some other CvInitCore members too the SDK, but the issue appears to be this:
now, and this bugfix has become intertwined with
Cities remain untouched during the first stages of
changes to CvInitCore data structures – change
the loading process. As general game data and
id advc.enum – that require a cleaner reset
civs are being reset, the UI keeps getting
before deserialization of the saved data.)
updated, based on data about cities that are no
Check for valid leader type in longer consistent with the other data. This can
CvPlayer::getNameKey. result in a crash when the camera is near a city
of a civ with an id greater than the highest civ id
in the game that is being loaded
(CvCity::getMusicScriptId) but apparently
also in other circumstances
(CvCity::isVisible).
(Not sure what's going on with getNameKey.)
See also This CFC thread seems to describe the bug. (No one posted a fix.)
39
to have two sets of definitions and I don't see any benefit. Note that
std::numeric_limits is not a good alternative because those functions can't be
used in template arguments (not in C++03 anyway).
001s Some code that uses canDefend doesn't seem to take into account that all non-land
units are defenseless against land units (yet canDefend returns true for all ships
except Work Boat). One such oversight (in K-Mod code) causes the AI to ignore
hostile units when stationing idle ships.
See also 139 further improves the AI code for keeping ships safe from land units.
001t Preliminary fix for the following issue in K-Mod: After declaring war, an AI stack may
decide to use a different path, even one for which no DoW would've been necessary.
If this occurs, the AI now sticks to the original path (if it's legal) for at least one more
turn so that a stack that triggers a DoW will immediately enter an enemy tile.
Rationale The fix is more about concealing the problem than making the AI smarter; a DoW
without crossing a border is an obvious mistake, sticking to a suboptimal path isn't.
Tbd. I don't see how the DoW affects the best path; perhaps something in the pathCost
function.Whatever it is, the pathfinder should anticipate that effect.
And a fix for a related bug: K-Mod sometimes lets stacks of non-city attackers move to an enemy
city when war is imminent. Since these stacks aren't supposed to start the war, this doesn't
normally make sense.
001u Fixed: K-Mod code had failed to recognize units as obsolete when evaluating a
strategic resource that it didn't have access to yet. This had sometimes led the AI to
cancel and renew trades for strategic resources (especially Horse) every 10 turns.
40
that unit's production cost was paid.
See also Thread with the bug report.
Obsoleted by 064b, which removes that part of the K-Mod code entirely.
41
001x No extra Golden Age turn when finishing Taj Mahal during a Golden Age
AdvCiv BtS
When a building that grants a Golden Age is Buildings that grant a Golden Age immediately
finished during the end of a player turn, the increase the Golden Age turn counter with one
Golden Age turn counter is increased by the turn added to the duration. As a consequence, if
Golden Age duration at the beginning of the city the building gets finished at the end of a turn, the
owner's next turn. When the building is finished added turn gets subtracted later in the end-of-
before the end-of-player-turn sequence, the player-turn sequence, but, first, the end-of-turn
Golden Age turn counter is increased sequences of all cities are completed, i.e. some
immediately. For the Taj Mahal, this can only of the player's cities benefit from the extra
happen through a cheat command ([+] key), but, Golden Age turn.
in a mod-mod, a special building like Academy
Moreover, when the Taj Mahal is finished during
might start a Golden Age.
a Golden Age, then a turn gets subtracted only
from the ongoing Golden Age at the end of the
player turn, i.e. a full turn is added to the total
Golden Age duration.
Rationale The full extra turn from Taj Mahal during a Golden Age is a widely known bug; see e.g.
this CFC post. The other issues are also bugs in my book.
001y Fixed an issue with AI Work Boats being unable to find an order. BtS uses a
“temporary hack” (in CvSelectionGroupAI::AI_update) to let such units skip their
turn after 100 attempts to find an order. That hack is still in place as a fallback, and I
intend to keep it permanently. I've reduced the number of attempts.
Added a another counter for the detection of and recovery from infinite loops in
CvGame::updateMoves.
Rationale The code in AI_update can't handle infinite loops that involve units joining a different
selection group.
42
and slightly more opaque colors on land tiles. No units are shown on the minimap.
Rationale CFC forum post (also with screenshots).
When Desert and Forest shine through too much, player colors can become hard to
distinguish.
Units: Can't make them out properly anyway, and can't tell how many there are
because each stack is shown as a single blip.
Config Options on the BUG menu (Map tab). Can also remove player colors from water tiles
like in Civ 3.
Until AdvCiv 0.99, these options were in XML.
See also kekm.21 shows Barbarian territory on the minimap.
002b Increased font sizes.
Shortened some leader names, e.g. "Augustus Caesar"→"Augustus" when used
outside of Civilopedia.
Shortened "Native American Empire" to "Amerindian Empire".
Added/ removed some tabs in Sevopedia's shortcut categories (004y) in order to
repair the text alignment.
Increased the total width of the civics screen (if the screen resolution allows it) and of
the panels that describe the effects of the individual civics.
Positioned game font icons at a slight offset on the tabular scoreboard since they're
not affected by the font size change. (I think that was the problem; not sure.)
Rationale People play on rather high resolutions nowadays, and the fonts don't scale properly.
Long leader names take up (even) more room with the larger fonts. This is a problem
for Native America because the text covers up the civics icons during diplo. Would be
better to use only short descriptions there, but that seems to be programmed outside
the SDK.
Config The font-size change can be reverted by removing the Resource folder and Assets\
XML\Art\CIV4ArtDefines_Misc.xml. This will also allow the mod to use any theme
installed in CustomAssets (e.g. Blue Marble Gold). When a theme other than the
AdvCiv theme is used, the FONT_SIZE_FACTOR in GlobalDefines_advc.xml should
be adjusted so that the DLL knows how much text fits on the screen.
The civics screen changes are all in CvCivicsScreen.py. It's easy to make the panels
in the upper half wider as well; I went out of my way to avoid that because I don't think
it looks good.
See also 061 (improved help text for listing the units in a tile) is the only DLL code so far that
adjusts the amount of displayed text to the font size.
005 also shortens some leader names (but not for lack of space).
History Rewritten sets a relative_resource path in Civ4.thm: "..\Resource"
This avoids most of the path changes in the other .thm files – but not all I think, or
some graphics from BtS need to be copied. I probably would've gone with this
approach if I had been aware of it at the time, but I don't think anything is gained by
adopting it now.
Short CFC post about the issue with icons midpositioned on the scoreboard.
Credits Inspired by VIP mod and I also took a look at vincentz's setup. This tutorial was
helpful, although neither the downloadable package nor the code in the tutorial actually
worked for me.
43
This post by CFC user hagnat helped me fix some Vanilla Civ 4 and BtS errors in the
theme files, though I don't think these errors were actually causing any problems. They
did lead to confusing log output. See also this conversation on CFC. (In the thread, I
conjecture that the log only gets created upon encountering a critical error. Not true; I
just wasn't aware that it gets created in the BtS install directory.)
Tbd. Can't seem to change font sizes without defining a custom theme, which appears to mandate copying 25
thm text files. I was at least able to avoid copying all the tga files, which make up 15-30 MB – this
would've been prohibitive for distribution.
I think there may be a way to make this work by copying just one or two files, but I can't figure it out (and I
don't think other modders have).
Had to hardcode the mod folder name in Assets\XML\Art\CIV4ArtDefines_Misc.xml in order to plug in
the custom theme.
Could I verify before the mod tries loading the theme whether the game is installed in
the correct location and display a more meaningful error message than “failed to
initialize primary control theme”? perhaps helpful for this: C2C Git issue
To allow users to rename the mod folder, I could probably create a file with the
contents of Civ4.thm (but using the current mod folder name, whatever it is) in the
Windows temp folder and change the path of DEFAULT_THEME_NAME (Misc. ArtDefine)
to that temp file before the theme gets loaded.
Allowing the mod to be loaded from My Games\Beyond the Sword\Mods seems
tougher. Somehow, the .thm files would have to acquire the paths to the Vanilla and
BtS folder dynamically (replacing the \..\ path prefixes that blindly navigate two or
three folders up).
AdvCiv BtS
Tile help text shows aggregated information (e.g. The threshold is 15.
"Archer (2)") about units if there are more than
12.
When info is aggregated, each unit type gets a Sometimes tries to put them all in one line, which
separate line. leads to chaotic linebreaks.
Rationale Larger font means there is space for fewer lines and less space per line.
See also 061 overhauls the unit list in tile help text and also takes into account the font size; the
above only applies if those changes are disabled.
Unfortunately, there is no easy way to increase the width of the help text area. See
Tbd. under 092 for further info about this problem.
002c Added a couple of translations for K-Mod game text entries.
Credits Also merged translations by Zholef. I haven't marked these changes in the XML files.
002d Changed the icon of the specialist-commerce ability introduced by K-Mod 1.45 to show
a Scientist; was Citizen. (Depending on which commerce type gets increased, the icon
could also show a different specialist, e.g. Engineer for production.)
Changed the icon of the Ocean trade effect (Astronomy) to the one that had been used in
Warlords.
Credits crullerdonut made me aware here (under the penultimate quote box) that the Coast
trade and Ocean trade effects use the same icon, and that the proper icon is available
among the art assets.
002e Disabled glow effect on units ready for promotion except for the currently selected unit
and foreign units.
Config “Unit Icons” tab of the BUG menu. (The “Promotion Available” option was not added by
44
me; that's part of BUG's “PLE” component. While I don't want to enable it by default,
that option seems sensible to me.)
Rationale Too obtrusive. Players don't select units just to assign promotions; they select them in
order to move or heal, and assign promotions at that opportunity. No need to
constantly indicate unassigned promotions on the world map.
The glow is needed on foreign units because there is no other way of telling that a
foreign unit has unassigned promotions. Shouldn't be a secret either. (Rarely relevant
in singleplayer as the AI always assigns promotions right away.)
002f Changes to city icons: Defense icon moved behind the defense modifier; city network
icon removed. Airport icon merged from BULL and enabled by default.
Rationale Should be easier to guess now that the tower icon isn't some status indicator but just
stands for the word "defense".
The city network icon is at best helpful in the early game, though probably not at all for
experienced players (and inexperienced players may be unaware of the icon). Can
always look at the list of trade routes on the city screen or consult the Trade layer.
I haven't played with the airport icon yet, but it sounds quite useful.
Config Option for the city icons on the “Map” tab of the BUG menu. The airport icon is in the
GameFont.tga I copied from BULL. (BULL does not have a custom GameFont75.tga,
but BUG and K-Mod do. Looks like that one's needed for the smiley option of the
Glance tab.)
See also CFC thread with a BULL GameFont file for some localized edition of BtS (Russian, I'm
guessing, perhaps with support for other languages too). Misses the Airport icon, and I
don't know how it could be added.
076 disables the icons placed by the “Detailed City Info” option.
101 adds, optionally, an icon for cities with positive revolt probability.
187 adds the airport icon to the 75% game font file so that it can be used in hover text.
Option on the “Map” tab of the BUG menu for re-enabling the “Detailed City Info” icons along with a
new icon for highest espionage rate and highest free XP. And another, similar BUG option: icon at
the city with the next projected Great Person birth. All disabled by default. See the hover text for
documentation. The icons are shown when the active (human) player has at least 2 cities; BtS had
required 3.
Config Originally, I had implemented a separate option for each icon. Those individual options
are still functional on the DLL-side, but commented out in XML and Python. Also left
commented out: Options for icons at the Globe Theater and National Park city.
Credits Brief discussion with crullerdonut on CFC:
1 (middle of the post) 2 (start of the post)
Rationale It was easy to do and someone will always miss any established UI feature. As for the
new icons, it remains to be seen if anyone will find them useful. The only I could see
myself using (when playing without the GP progress bar) is the GP icon at the city
where the next GP will be born.
I've though about tying the icons to national wonders. That might be a bit more useful,
but would be pretty haphazard as there isn't an appropriate icon for every wonder,
some of them don't need an icon at all, and Scotland Yard isn't a national wonder (but
a good place for showing an espionage icon). Would also not work well in mod-mods
with different national wonders.
There are still some unused icons left that could possibly make sense: The combat
strength icon (perhaps for the highest military production rate – if it's not the same city
as the one with the highest generic production rate), the negative gold icon (for cities
45
with very high maintenance), the culture icon (for cities that somehow look relevant for
a culture victory?). All a bit too complicated …
The combat strength icon could also replace the Great General icon for the city with
the most free XP. The GG icon is difficult to see – but the combat strength icon also
isn't easy to see and is less fitting.
Another city bar icon: Spoiled food icon shown The tiny button on the city screen being
when a city is set to “Avoid Growth” (AG). And highlighted is the only reminder about AG. The
some other UI reminders about that setting: food bar on the city screen and on the main map
When a city has a food surplus despite “Avoid looks completely normal, as if the city were
Growth”, print “Avoiding Growth” on the city growing (if there is a surplus).
screen's food bar and show the turns-to-grow
When citizen automation is enabled, AG will
(i.e. turns until food gets discarded) in red. On
usually cause the governor to reduce the food
the main map, show the gray status indicator
surplus to 0; the governor may even shrink the
(behind the population count) in that case. Show
food store.
a red indicator when the city will discard food at
the end of the current turn. Mention AG in the city
bar hover text when enabled.
Added a loding-screen hint about the city bar
icon, along with a reminder about turning on
citizen automation during AG.
Rationale AG is so easy to forget that it's almost not usable. The uses of AG without citizen
automation are pretty limited in any case: A player who doesn't want a city to grow will
normally manage to reduce the food surplus to 0 through citizen reassignment, and
then there is no need for AG. That said, it can happen that the assignment with optimal
non-food output will still have a small food surplus.
Important to make the city bar icon optional because players may use AG to
permanently keep a city from growing (i.e. with citizen automation enabled and
resulting in 0 food surplus), and, in that case, the icon can be more annoying than
helpful.
AdvCiv BtS
The last of the three icons contained in BULL's The population column heading says “POP”. All
GameFont.tga, the Citizen icon, is used as the other columns are headed by icons. I guess
heading of the “population” column of the (non- BULL uses the Citizen icon only for city bar hover
customizable) Domestic Advisor screen. text.
See also 004 uses the strength icon for the stationed-units column.
002g Changes to Opening Menu (the one that opens right after launching BtS)
AdvCiv BtS
Shown grayed out: "BtS Content", "Check for "BtS Content" leads to an empty screen. The
Updates" (in the "Advanced" submenu); “Internet Update site – apparently hardcoded as
Games” (in the Multiplayer submenu). http://motd.gamespy.com/motd/vercheck.asp
in the EXE –
has long been disabled; hangs for some
seconds, then reports that the game is up to
date.
The GameSpy platform for finding opponents on
the Internet has been shut down in 2014.
Rationale Can't remove the dead items (handled by the EXE), so it seems that the best I can do
is show the text in gray.
I had "Play Now! and "Play Scenario" grayed out at first, but "Play Now" shows
46
descriptions of map scripts that aren't visible elsewhere and there's a preview screen
for some map types and scenarios (though a pretty bad one).
Could rename "Custom Game" to "New Game (Randomized Map)", "Play Now" to
something like "World Picker" and "Custom Scenario" to "New Game (Scenario)", but I
think players are so used to selecting "Custom Game" that this would be an
inconvenience.
Tbd. Could contact Zulan's server instead of GameSpy by modiying the EXE (cf. 092b).
Can do a diff (WinMerge seems to handle the native code well enough) between the
modified EXE hosted here with the original EXE, then locate those lines in a hex editor
to find the addresses that need to be changed. Not so easy to do this at runtime in this
instance because the replaced strings don't have the same length as the old ones.
Would be easier if the code that accesses those strings could be redirected to strings
in the data segment of the DLL.
See also Kek-Mod has an in-game update function (inherited from PBMod I think):
CvModUpdaterScreen.py
Game text doesn't refer to the Opening Menu as "Main menu" can refer to either the in-game
the “main menu”. Exception: The in-game main menu (Esc key) or to the Opening Menu.
menu still says “Return to Main Menu”.
(Identifiers in code also still use “main menu”
ambiguously.)
Rationale Better to have different names for those two menus. I've not changed “Return to Main
Menu” because players are so used to looking for that phrase on the menu.
47
banks.
No changes to the texture detail, More detailed texture reliefs.
though reliefs might be more Makes Grassland in the fog of
visible due to the lower color war and non-fogged Jungle a bit
saturation. hard to distinguish.
When zooming out far, passing
Clouds disabled. No shadows; denser, more
clouds are shown; these clouds
realistic clouds.
also cast shadows.
Some textures resembling those
No change to textures outside Adjusts these textures to match
on the map are shown in
the map. the BM style. (Compressed size:
Civilopedia and the "Play Now!"
6 MB)
World Picker screens for
Adopted the BM resource
illustration. Less garish textures for Banana,
textures, and also toned down
Rice, Gems and Uranium.
Corn, Wheat and Silk.
Roads dark beige, Railroads
Roads light brown. Railroads Darker Railroads, no change to
light gray, difficult to tell apart.
from BM but with increased Roads. If BUG is used in
contrast for a dotted look. addition, the I Love Asphalt
component (not included in K-
Mod/AdvCiv) colors roads black.
Rationale I mostly wanted something that's easier on the eyes. Blue Marble is pretty good in that
regard, but has some other issues (see above) and looks more different from BtS than
it has to. I've also gotten the (compressed) file size down to 5 MB from 15 MB. The
BM reliefs look kind of nice but more crayon-like grainy than detailed.
All three versions let Coast bleed far into adjacent Ocean, which can make it hard to
tell where the Coast ends. Probably can't be helped because the player is –
apparently – supposed to be able to tell when there is an unrevealed Coast next to a
revealed Ocean.
See also CFC post with screenshots comparing the AdvCiv, BM and BtS textures.
Water textures by CFC user MightyToad (who I think is very capable at what he does).
Those look good when zooming in, but, at the normal playing distance, the waves are
too big; not what the seas look like from the stratosphere. I've made a version with a
2x2 mosaic of one of MightyToad's textures (and also with some color adjustments)
and that does result in smaller waves, but I guess they're still too big; anyway, it still
looks too detailed overall, perhaps especially since the land textures aren't similarly
detailed.
Tbd. In the fog of war, the deciduous forests in the subtropics are too difficult to distinguish
from tropical jungle. Making the forests darker or less reddish doesn't help. Brighter
jungle would help, but would look too unnatural. (That's what BtS did.) Sparser
forests? Don't really like that either. May have to apply to all forest varieties and also
to routed forest, which already looks too sparse. Related CFC post (near the middle)
Update: I've made jungle a bit brighter again; not sure how much it helps. Natural
jungle can look pretty bright; see e.g. this photo on Wikipedia.
48
Made a few colors like the Aztec's green (upper left) and the Persian's blue (top center) less
saturated and thus hopefully less painful to look at.
Most colors shifted a little bit to make them easier to distinguish.
49
leader in a game will receive England's colors
because the secondary color of America and the
primary color of England are both white – that is,
unless England is also in the game. For the third
player, a civ with a primary color resembling a
mix of the original civ's primary and secondary
color is chosen; e.g. Roosevelt as the third
American leader will receive a primary color
between middle blue and white (the Viking colors
in a test, but perhaps that was because the
Greek colors were already taken). Leaders
beyond the third (only possible in a mod-mod)
receive the color scheme of an unused civ
chosen at random.
See also Screenshot posted on CFC that show clashing colors.
Rationale There are a few color definitions that are unused or used only as a secondary color. To
improve on the BtS approach, those available colors, perhaps along with some novel
color definitions, could've been used for a reserve of colors that can't clash with other
primary colors. However, I think it's nicer to have unique replacement colors, i.e.
chosen based on the unique (well, mostly) secondary color. For some civs, that
secondary color is even quite fitting as the primary color, e.g. red for England. Using
the color scheme of another civ was easier to implement than to create a color
scheme around the secondary color dynamically. Choosing a color in between the
primary and secondary color (for the third player of a civ) results in a color that is fairly
easy to distinguish from the other two and establishes a color range that ties the three
players together.
50
Very slightly decreased the size of unit models when playing with the “Single Unit” graphics option.
(But they're still larger than when playing without that option.)
Config There's a parameter SINGLE_UNIT_GFX_EXTRA_SCALE for this in GlobalDefines,
changed through GlobalDefines_advc.xml.
Rationale I thought that a single model per unit would have to be at most slightly bigger than
multiple models to be easily recognizable, but I guess the original developers mostly
got it right – a single model does seem quite a bit harder to recognize. I still think that
the size can be decreased a little bit. The multiple models are already unpleasantly
big.
002k Put "AD" (Anno Domini) before the year number in all game text. And removed the
colon after “Turn” on the time display.
Rationale I understand that "1500 AD" is acceptable, but "AD 1500" is more proper.
Config Option on the “Time” tab of the BUG menu. Can also pick CE/BCE there. Or edit the
text keys in CIV4GameText_advc.xml.
51
Rationale If the final attack fails, then the defeat sound is appropriate even if the majority of the
earlier attacks succeeded – because the attacker lost at least one unit and hasn't
managed to eliminate all defenders. If the final attack succeeds, then the victory sound
is not necessarily appropriate, but there isn't a familiar neutral sound, and at least the
current behavior is simple and somewhat intuitive.
Tbd. There might be a couple more cases of stacking sounds to take care of. Looks like the
“your units are under attack” sound could be a problem.
Would be nice to have a general safeguard against loud sounds. I think all sounds get
played through either CvDLLInterfaceIFaceBase::playGeneralSound (one version
of that function is unused; can simply be set to protected visibility) or addMessage
with bForce=true. Could insert a call to a safeguard function at CvPlayer (or at a new
component of CvPlayer) into those two functions. The safeguard function would keep
track of which sound has started playing when and how long it is expected to last, and
would return false when too many sounds overall or multiple instances of the same
sound are about to get played.
See also CFC post by me about promotions and Stack Attack.
The war-horns sound is only played for primary The multiple (pairwise) DoW at the start of a war
declarations of war. involving vassals or defensive pacts result in a
single loud war-horns sound. Sounds at the end
of a war can also stack when vassals are
involved.
Play the deal cancellation sound only once when Declaring war cancels all deals. A sound is
declaring war. played for each canceled deal at the same time.
See also 106o combines announcements of declarations of war and peace deals that involve
vassals into a single message – for which a single sound gets played. (Before AdvCiv
1.04, change 002l had suppressed the sounds for war/ peace changes of vassals; that
approach might be easier to merge into other mods.)
106j plays no deal cancellation sound when the AI decides to cancel (and renegotiate)
a resource trade deal.
When multiple Global Warming events are One sound per event.
reported at the start of a turn, a sound is played
only for the first one.
Credits crullerdonut made me aware (2nd quote box): CFC post
Rationale I don't think the sounds had stacked up, but it's still annoying to hear the same sound
six times in a row.
When a sea unit withdraws from combat, one of The marching-boots sound is played for all
the water movement sounds is played (at a withdrawals. (Sea units can withdraw through
slightly increased volume). promotions.)
Credits From the Dawn of Civilization mod: Git commit, related post
(But I use a slightly different – less harsh – sound.)
52
The base number of animated combat rounds From the K-Mod changelog (v1.29b):
decreases slightly with each era. As a result, the
"Combat animations are now orchestrated to
animated units die after fewer hits in the late roughly correspond to the events from the actual
game than in the early game, and combat combat mechanics. (It still isn't a blow-for-blow
animations per battle take about 30-50% less representation of the actual battle, but events in
time in the late game. the animation will at least occur in the same
order as the events in the combat log.)"
Moreover, on the defense, starting in the
That is, the number of animated combat rounds
Renaissance era, combat animations are cut
is based on the number of entries in the combat
short, meaning that they usually stop before one
log. In addition, it's multiplied by an XML-
side has been defeated.
configurable base value.
In addition to the above, when playing with the
Looks like SUG doesn't affect the number of
"Single Unit Graphics" option (SUG) in single-
rounds, meaning that the two men are shown
player mode, the base number of combat rounds
hitting each other for about 10 seconds.
is halved.
Config GlobalDefinesAlt.xml (because that's where K-Mod's
STANDARD_BATTLE_ANIMATION_ROUNDS is defined)
Rationale For attacks by the player, there's the "Quick Combat (Offense)" option, but "Quick
Combat (Defense)" makes attacks against the player difficult to follow, and animating
them takes too long in the late game.
Sadly, the speed at which the animations are played can, apparently, not be modified. I
think the EXE consults functions like getSecsPerTurn in CvDLLUtilityIFaceBase.h
for this. (CvUnit::getAnimationMaxSpeed is called during combat but doesn't make
any appreciable difference.) Can only speed animations up by making units die after
fewer hits or by ending animations before one side has been defeated. The latter
doesn't look nice, but the former just isn't enough when large AI stacks attack in the
late game. And players still have the option to see fully animated combat on the attack.
Fewer hits per kill as the game progresses could be interpreted as weapons becoming
deadlier.
SUG: It looks goofy when a single Rifleman takes bullet after bullet without going
down. I'm applying my change only to singleplayer mode because I'm not sure if
basing the combat rounds on player options could lead to synchronization problems in
(Pitboss) multiplayer games.
Update: The disassembly for getSecsPerTurn shows that it merely pushes the
floating point number 0.25f from the (hardcoded) memory location
dword ptr ds:[0B167C4h]
onto the floating-point stack. The EXE does not seem to access that number through
this function, but probably gets it from the same memory location through other
functions. Attempting to write 0.05f to that memory location through inline-assembly
__asm { mov dword ptr ds:[0B167C4h], 0x3D4CCCCD }
results in an access violation at runtime. Might be possible to get around that through
VirtualProtect; however, I suspect that this change would end up speeding up all
animations until the original value is restored (like when running some 90s game on
modern hardware). Not sure to what extent the engine even supports playing a
particular sequence of animations at an increased speed.
See also Similar arguments in this CFC thread. Two users claim that SUG speeds up combat –
perhaps it does in BtS; not in K-Mod though.
53
Tbd. Could I just show the eventual victor knocking down all opposing figures that remain
with one strike a piece when combat is cut short? Or approximate the combat rounds
more coarsely, e.g. if the sequence of per-round wins in a fight A vs. B is
ABBABBAAABA, show animations for ABABA instead. The algorithm could be to
choose a target number of successes for the victor (at least as many as there are
figures on the losing side) and, based on that, a smaller target number of successes
for the loser. Then somehow pick a sequence that resembles the original sequence;
perhaps start by preserving the true first and last hit ...
AdvCiv BtS
Shorten the air mission animation for recon, 5 seconds each
strike and bombing to 4 seconds, i.e. play them
faster.
Rationale The long animation times aren't really a problem as the missions take effect
immediately and don't block the UI. (And the air strike animation isn't shown at all
when playing with Quick Attack.) Still a bit distracting to see the aircraft hover for so
long. Faster aircraft look also more realistic. Perhaps a bit easy to miss for a first-time
player, so it's understandable that Firaxis made the animations so slow.
Config Civ4MissionInfos.xml. The iTime value gets taken times 250 ms
(CvDLLUtilityIFaceBase::getSecsPerTurn).
Shorten the nuke animation to 8 seconds. 10 seconds
Rationale Still very long, but, if players actually want to see it, – it's not going to look good when
played much faster.
See also 650 deals with other changes to nuclear war.
A 2-second nuke animation, i.e. mostly a camera Always 10 seconds, but, without Particle Effects,
rumble plus explosion sound (if zoomed in close no explosion is actually shown and, on enemy
enough), is shown when Particle Effects are turns, the camera doesn't focus on nukes. With
disabled. 1 second when playing with simultaneous turns, it looks like the animation will
simultaneous turns and for enemy nukes. play for all human players regardless of whether
they can see it; but I haven't tested it. In contrast,
the “Show … Moves” options are treated as
disabled when playing with simultaneous turns.
When the full animation plays, the UI will still While the nuke animation plays, automatic unit
(mostly) be locked. cycling is disabled and only units in the same tile
as the nuke unit can be manually selected.
Credits crullerdonut made me aware that the nuke animation requires Particle Effects here
(end of the post).
See also The end of my previous post (link above).
54
Rationale The best solution might be to stop the animation from interfering with unit cycling.
More specifically, it seems to be the “delayed death” status of the nuke unit that
inteferes. It's easy enough to kill the unit immediately, but that also cuts the animation
off. There's probably a way to allow cycling while the selected unit is dying (and the
animation playing), but it's too much effort for me to figure this out.
2 seconds is still kind of long when there is no animation to see, but nukes have a
recon effect during their animation, and player may want to use that opportunity to
scout out enemy unit positions. As much as that illogical recon effect stinks, – wouldn't
want players to enable the full animation just so that they don't lose that benefit. I don't
think an animation can be shown without active visibility.
Simultaneous turns: Tedious to test, so I want to keep it simple. Apparently, playing an
animation that blocks the UI on only one machine would be quite a handicap (not sure
about synchronization).
Config BUG option for showing the short rumble or no animation at all regardless of the “No
Particle Effects” option.
Tbd. Would be nice if “Show Enemy Moves” could move the camera to the impact sites of
enemy nukes. But, even then, I don't think the full animation should be shown; should
suffice to show that when the active (human) player detonates a nuke.
Perhaps OK to remove the recon effect, i.e. never to play the animation when dropping
a nuke in the fog of war. Players could still marvel at the animation when they nuke a
visible tile (not so uncommon – how else can they target enemy unit stacks).
Show the main screen message (“... launches a The message is shown immediately only for
nuke ...”) immediately (bForce=true) when using nukes fired by the active (human) player.
the shortened animation. Otherwise at the start of the next turn.
Rationale Easier to follow enemy launches this way.
See also 004g shows bombardment messages immediately.
55
Tbd. In games with simultaneous turns, the “waiting for you” message seems to get shown
as soon as all other players have ended their turns. That's a bit annoying, though I
guess some indication is necessary (one time announcement?). Also the end-turn
button turns red at that point – that should never happen when there are still units that
need orders (CvPlayer::hasReadyUnit). This stuff is in part handled by
CvGameInterface.cpp, e.g. CvGame::shouldDisplayWaitingYou.
56
Tbd. Could try changing the default camera distance while the city screen is open in order
to avoid a change in music volume as the camera zooms in or out upon opening the
city screen. Would at least be nice to have this as an option. A large change in volume
is pretty clearly undesirable. As it is, players may feel compelled to set a lower camera
default distance than they'd otherwise use.
003 Style changes and other refactoring, utility functions, comments about unused or
otherwise dubious code; in particular:
Minor refactoring changes to improve readability in large parts of the C++ code base:
Variable declarations moved to the point where the variable is initialized; continue, break and
return statements to reduce indentation; variables named bIsSomething renamed to just
bSomething; removed (obviously) unnecessary parentheses; made comments more compact, in
particular those by jdog5000; removed blank lines and curly braces around one-liners unless the
braces are needed to separate the one-liner from a multi-line condition; switched conditions like 0!
=x around to x!=0; array initialization loops replaced with single-line initialization; INT_MAX and
INT_MIN replaced with Civ's MAX_INT and MIN_INT, breaks in long lines (ca. 85 to 100 characters).
removed the xmlKey parameters from getBUGOption... calls because the callee doesn't use them;
const qualifiers added. For what it's worth, the last few Firaxis programmers working on the
codebase (patch 3.19, Colonization) had been making changes (mostly localized) in a similar vein.
Those changed aren't marked with comments. Structural changes are sometimes tagged with an
“advc” comment, but I've started deleting those comments again. In particular, continue
statements without a comment can be assumed to come from AdvCiv.
Macros TEAMID added, and GET_TEAM can now also take a PlayerTypes parameter. For example,
GET_TEAM(GET_PLAYER(ePlayer).getTeam())
becomes
GET_TEAM(ePlayer)
(akin to the functions in BUG's PlayerUtil.py).
Macro PLAYER_TEXT_COLOR added to complement TEXT_COLOR; mainly used in
CvGameTextMgr.cpp.
Shortened gDLL->getInterfaceIFace() to gDLL->UI().
Added some free getActivePlayer functions (local to implementation files) in order to abbreviate
GC.getGame().getActivePlayer() in implementation files that need to access the active player
(or team a lot). Also added boolean member functions isActive to CvPlayer and CvTeam and
isActiveOwned, isActiveTeam to all classes that can be owned by a player or team.
Moved a lot of code out of CvGameCoreUtils.h/cpp – to more specific places, in part to new
translation units.
Rationale It's often faster for me to rewrite the code a bit than to make sense of it as it is –
though fastidiousness has also played a role, I'm sure.
I've stuck to the (Systems) Hungarian notation, mainly for consistency with the BtS
code, but I also think that it has some merit in this software design. Since objects are
usually passed around through integer ids (instead of pointers), it's typical to work with
an object pointer and its id side by side, and then eTeam is shorter than teamId.
See also 003g, advc.fract: Fractional arithmetic
003e (private copy-constructors) makes the cast to CvCityAI safer to use.
advc.pf: Refactoring of pathfinding code.
advc.700, advc.250b: The R&F and SPaH code uses a bit of a different coding style. It
took me a while to figure out which windmills (not) to fight. Eventually I settled on a
middle ground and most of the codebase is consistent with that, but I haven't bothered
57
to update the R&F and SPaH code because it isn't really subject to change by me and
especially not by other modders.
Removed all trailing whitespaces in the C++ files, converted spaces used for indentation to tabs
(also in the K-Mod Python scripts) and removed most of the spaces before closing parentheses.
Rationale Shortly before releasing v0.96, I decided that it's better to make these changes once
and for all instead of making them piecemeal along with functional changes. Irregular
whitespaces are distracting to me when reviewing Git commits. For indentation, tabs
were already used almost exclusively. It's especially important to stick to one way of
indenting in Python. I haven't made further style changes in Python and none in XML
because those files aren't frequently changed (by me).
Tbd. Seach an replace (case-sensitive!):
“if(“ → “if (“
“for(“ → “for (“
“while(“ → “while (“
“switch(“ → “switch (“
CvDeal: Added a more convenient interface for iterating over trade items. When a CvDeal object
and the two trading civs A and B are given, then the BtS interface with functions like
getFirstTrades and getSecondTrades forces the caller to check whether A is either the “first” or
“second” civ, resulting in redundant code to deal with both cases. The function names also give no
indication who gives an item away and who receives it.
I've adapted all or almost all the client code for which it makes sense to the new interface.
AdvCiv BtS
New class CvDLLLogger to encapsulate the The “message (control) log” is used mainly for
“message log”. logging combat outcomes and random numbers
(if “RandLog” is enabled in addition to
“MessageLog”). And some misc. logging, e.g. in
CvPlayer::setTurnActive:
if (GC.getLogging())
{
if (gDLL->getChtLvl() > 0)
{
TCHAR szOut[1024];
sprintf(szOut,
"Player %d Turn ON\n", getID());
gDLL->messageControlLog(szOut);
}
}
Rationale To make the logging code less distracting.
See also There's a short guide about the various logs under 007.
Renamed the getBugOption... functions to “isEnabled” and “getValue” and put them in a
namespace “BUGOption”.
Merged a few non-functional changes from Roamty's Unofficial Patch 1.7 (link). Not marked in-line
because the changes are too minor. He uploaded further changes here, but those are really just
whitespace changes; nothing merged except for a bugfix (see “Roamty” under 001).
AdvCiv BtS
“GC” is now a CvGlobals const&, and most “GC” (global context) is a reference to the
CvGlobals member functions have const singleton instance of CvGlobals. It doesn't have a
qualifiers. const qualifier. Most of the CvGlobals member
functions don't have const qualifiers either,
58
although they don't change the state of
CvGlobals.
The main class that changes (initializes) the state
CvXMLLoadUtilitySet.cpp redefines GC as a
of CvGlobals is CvXMLLoadUtility.
(non-const) CvGlobals& for convenient access.
GC provides access to other frequently used
Functions that provide references to other singleton instances – CvGame, CvMap,
singleton objects, in particular getGame, CvInitCore – and to the non-synchronized PRNG
getInitCore and getMap, still return non-const and various pathfinders. Some of those instances
references. This works because CvGlobals only are owned (allocated and deallocated) by
stores pointers to those sub-objects. CvGlobals.
In the rare cases, when the state of CvGlobals
needs to be changed by classes other than
CvXMLLoadUtility, the instance is accessed
through CvGlobals::getInstance().
Rationale Most classes have no business changing CvGlobals, so the const restriction on GC
should serve as a warning. I'm not sure if any performance gains are possible; making
GC const certainly can't hurt with regard to performance.
Removed functions from CvGlobals that had For each of the 100 or so “info” vectors that store
returned references to the info vectors. Instead, data loaded from XML, there are three accessor
CvXMLLoadUtility accesses the vectors directly. functions: One that returns the size of the vector,
one that returns an element at a given index and
one that returns the whole vector by reference.
The last function type is only called by CvXML
LoadUtility, which is a friend of CvGlobals.
Rationale Shouldn't expose those vectors to the entire game core when only one class needs to
access them is already declared as a friend.
See also advc.enum lets the preprocessor generate the remaining info accessor functions.
Cavemen2Cosmos did the same thing (a little later than I): Git commit
Line endings: The DLL only uses line feeds (LF); I've run it through unix2dos (on devolution's
suggestion). I think the original DLL also used LF exclusively, as did karadoc's code. XML line
endings are mixed. Looks like BtS always used LFCR and so did I, but BUG uses LF. Well, at least
line endings within individual files seem to be consistent. Haven't checked the Python code.
Turned K-Mod's CvFoundSettings and AI_foundValue_bulk (CvPlayerAI) into a new class
CitySiteEvaluator.
Rationale AI_foundValue_bulk was one of the most complex functions in the code base and it
was located in the longest and most complex implementation file (CvPlayerAI.cpp).
Moving it to a separate class has allowed me to store the data that gets computed
prior to the city radius evaluation loop in member variables. This was a prerequisite for
moving code into subroutines.
Tbd. It's easy to see that the code still isn't well structured (for one thing, several functions
return multiple values through reference parameters) and that the order of the
evaluation steps is fairly arbitrary.
See also 031 deals with functional changes to the found value computation.
When I moved the code, I also added log output; see 031c about that.
Converted most of the CvArea* function parameters to CvArea const&. Those changes aren't
marked with comments. Repurposed the getArea functions (CvPlot, CvCity, CvUnit) to return a
CvArea& instead of an int id. Same-area checks are now usually performed by functions
sameArea, e.g. CvCity::sameArea(CvCity const&), or isArea(CvArea const&). The area
59
functions returning a CvArea* (CvPlot, CvCity, CvUnit, CvSelectionGroup) aren't used much
anymore. All functions mentioned above are inlined except CvSelectionGroup::area. Previously,
most of them weren't inlined because CvPlot and CvArea objects had to be looked up in CvMap.
Now CvPlot, CvCity and CvUnit each store a CvArea*, and CvPlot no longer stores an area id.
Rationale constness is preferable and so are references and inlining. None of this is important on
its own, but all three combined gave me enough impetus for this rather expansive
refactoring change.
I've kept the area functions mostly for compatibility when merging with other DLL
mods. The change to the getArea functions will hurt compatibility, but there really
shouldn't be three different area accessors I think and accessing them by id is easily
the worst method.
See also The CvMap::getPlot function introduced by advc.opt also returns a reference,
whereas CvMap::plot returns a pointer.
Refactored the “plot unit functions” in CvGameCoreUtils, mainly through more descriptive variable
names, more assertions.
Tbd. Replace this with functors taken as template parameter? For better compile-time type
safety.
Moved the getCombatOdds and LFBgetCombatOdds functions from CvGameCoreUtils.cpp into a
separate file CombatOdds.cpp, split them up so that they can share some code with each other
and so that the Advanced Combat Odds mod (ACO) can also reuse some of it. Moved some of the
ACO code from CvGameTextMgr.cpp into CombatOdds.cpp, the rest into ACOText.cpp. Refactored
all the odds-related code a bit, mostly the variable names (ACO had used some obscure one-letter
abbreviations).
Rationale Should make it more feasible for mod-mods to change the combat rules. Updating the
odds calculations is a real obstacle to that, especially when it has to be done in five(!)
different places.
See also advc.test: Code for verifying calculated odds through simulations.
Deleted all copies of English game text that were standing in as placeholder translations in BUG,
BULL, K-Mod game text files. This concerns mostly French translations. Until v0.99, AdvCiv game
text for the BUG menu and the R&F option had also used copies of English text as placeholders for
French, Italian and Spanish; those have also been deleted now.
See also This Git commit has enabled K-Mod to fall back on English text when a translation is
missing.
Rationale Makes the game text files a bit easier to scroll through and makes it more apparent
where translations are missing. The downside is that any kind person who wants to
add translations will have to copy the opening and closing tags, which is arguably a bit
more work than deleting a placeholder text. On the other hand, the missing tags make
it easy to search the text folder for all missing translations (e.g. the closing English tag
being followed by a linebreak and then the opening German tag implies that the
French translation is missing).
Tbd. The game text could generally be organized better – I guess; not sure how.
Civ4GameText_advc.xml is too big, and it's generally difficult to identify redefines that
might clash when merging another mod into AdvCiv. At the least, a uniform comment
should be placed at every text element that redefines a BtS key.
Deleted the copy of Civ4GameText_Events_BTS.xml (half a megabyte) that was included in the
BUG mod and replaced it with a file EventText_CorrectedTranslations.xml that includes only
the few texts that the BUG mod had actually changed.
Rationale As a rule, modders should be free to assume that a BtS text key that they wish to
60
change isn't already included in the mod. Therefore, wholesale copying like that is bad.
Tbd. Would be very nice to let the DLL check whether a text key gets loaded more than
once. For GlobalDefines, this is already implemented through the
CHECK_FOR_REDEFINES preprocessor flag (tagged with “advc.test”); harder to do for
text I think.
003b Misc. performance tweaks (tagged in the source code with “advc.opt”)
See also 003d: Faster Quick Load
advc.inl: Function inlining
advc.pf: Pathfinder optimizations
advc.enum: More efficient data structures for data stored for every value of an enum
type.
003s: Cache tile adjacency lists
003h: Cache MaxVisibilityRange
003m: Cache CvTeam::isMinorCiv and getAtWarCount
003o: Profiling code
003p: Improve performance of layer updates.
003v: Don't load unused XML data
045: Rival buildings hidden on main interface.
106i clear Hall of Fame data from memory when a game is started or loaded.
004s uses a more efficient data structure for player statistics.
Brief chapter about performance in the main portion of the manual.
Tbd. Test if this flat_set implementation by alberts2 is more efficient than std::set in the
UWAI component (UWAISet.h). Not easy to do because his flat_set doesn't have
quite the same interface as std::set. The implementation in Boost 1.35 seems to
have the same interface, but it can't be easily isolated from the rest of that library and I
don't want to switch from Boost 1.32 to 1.35. If I do upgrade Boost, then I should follow
billw2015's example (C2C Git issue, branch) and upgrade to Boost 1.55.
I've tweaked various BtS functions that the Unit AI uses to quickly dismiss tiles when deciding
where to move: CvUnitAI::AI_plotValid, CvUnit::isEnemy, CvUnit::isPotentialEnemy and
related functions at other classes. The “potential enemy” functions check for imminent war plans,
so I've moved them to AI classes. Some are used by the AI to avoid danger – I've kept the name
“potentialEnemy” for those –, others are used for planning attacks – I've renamed those to
“mayAttack”. It's still a bit of a mess.
A few of my changes to calls of isEnemy are minor functional changes, bugfixes arguably, that only
matter when a mod-mod makes additional units AlwaysHostile and when such a unit is near a
friendly city or fort. I haven't marked those changes with any comment.
See also Often, Unit AI code, especially BBAI code, checks whether a tile is in the same area as
the unit. Change 030 (peaks and ice can separate areas) complicates some of those
checks because submarines can now sometimes enter a different area. I've added
functions CvUnit::canEnterArea, CvArea::canBeEntered and
CvUnitAI::AI_canEnterByLand for dealing with that.
Revised access to GlobalDefines. Integer Two different ways:
GlobalDefines are now accessed in four different
ways:
• Access through CvGlobals:: • CvGlobals::getDefineINT(char const*),
getDefineINT(char const*). This is still the which looks up the string argument in a
default method for code that is clearly not stdext::hash_map (FVariableSystem::
61
going to affect the overall performance. In a m_mapVariableMap) that contains all the
few cases (e.g. in MapGenerator.cpp), I've at GlobalDefines tag names.
least moved getDefineINT calls out of loops
and assigned their results to local consts
instead.
• Assign the result of CvGlobals::
getDefineINT(char const*) to a local static
variable. This is done when the value should
only be used locally, i.e. when it's not really
intended to be a "global" define.
• Enum value (enum GlobalDefines) in
CvGlobals.h for fast access through
CvGlobals::getDefineINT(GlobalDefines).
For values used in multiple places or that may
well be used in additional places in the future.
The mapping between XML element strings
and enum values is handled by a macro.
• Access through a dedicated function without • For more than 50 frequently accessed tag
parameters; e.g. getEVENT_MESSAGE_TIME(). names, there are individual variables cached
For pre-AdvCiv functions that can't be easily at CvGlobals with a getter function, e.g.
removed because of DllExport or because of m_iRIVER_ATTACK_MODIFIER and
a high number of call locations. Most of these getRIVER_ATTACK_MODIFIER.
I did remove.
Rationale String retrieval from a map is fine in contexts where performance isn't a concern, but
GlobalDefines are needed pretty commonly in contexts where it's at least not obvious
that performance doesn't matter, and, then, adding a data member with a getter to
CvGlobals is tedious and clutters that class up. The GlobalDefines enum solves that
problem. The only reason I like to use local static variables sometimes is that it
conveys that the GlobalDefine is only accessed in a single place. Caveat about local
static variables: They're not updated if CvGlobals::setDefineINT is called. Another
thing to be aware of: static local variables result in a branch instruction.
Credits The local static idea came from Nightinggale. CFC post
See also I posted about the GlobalDefines enum here in the C2C subforum, and a variant of
that idea was later included in C2C (Git commit).
Tbd. CvBugOptions could use a cache as well.
Added a parameter for default values (to be used when a tag isn't found in the hash map) and int-
to-boolean conversion (getDefineBOOL) to the GlobalDefines getters in CvGlobals. This has
rendered the getDefine... functions in CvBugOptions.h obsolete, so I commented those out.
Rationale Treating integer defines as boolean is frequently needed and error-prone.
Faster functions for mapping CvMap coordinates There are two functions for this mapping, both
to CvPlot objects: force-inlined, both returning a CvPlot*:
CvMap::getPlot returns a CvPlot& without CvMap::plot: Applies world-wrap and checks if
performing any checks outside of assertions. either coordinate equals -1.
Force-inlined.
CvMap::plotSoren: Doesn't apply world-wrap,
CvMap::plotValidXY returns a CvPlot*. only checks for -1.
Applies world-wrap, but doesn't check whether
CvPlot isn't generally used for data members;
coordinates are -1. The compiler may or may not
usually coordinates are used instead, and when
inline it.
those coordinates aren't supposed to represent
62
Throughout the game core code, getPlot is now any tile, they're set to -1 (e.g. CvUnit::m_iReconX).
used when coordinates are guaranteed to be
valid. plotValidXY is used when the coordinates
have been computed as an offset from valid
coordinates. plotSoren is only used in a few
locations where the coordinates may indeed
represent no valid tile (and a few where I wasn't
sure). plot is still used pretty widely, mainly in
functions that receive coordinates through their
call parameters.
Based on benchmark tests, I've kept plotSoren
inlined and removed the (force-)inline keyword
from plot.
getPlotByIndex (returning a CvPlot&) mostly For looking up a CvPlot by its index in
replaces plotByIndex. getPlotByIndex only CvMap::m_pMapPlots, plotByIndex is used.
asserts that the index is within the array's That function performs an out-of-bounds check
bounds. and returns a CvPlot*.
Rationale Speed and code clarity. plotSoren is a terrible function name. Now that fucntion is at
least not used much anymore.
Tbd. Functions shouldn't, for the most part, take coordinates as parameters; instead the
should take a CvPlot reference if the tile is guaranteed to be valid and a CvPlot pointer
otherwise. That should get rid of most of the remaining plot calls and superfluous
NULL checks. Could then perhaps rename plot to “plotSafe”.
003c Added an assertion that checks if XML data loaded through GC.getDefineINT actually
exists. Found just one (unimportant) error this way and corrected it. Had to change
some calls that happened before XML was even loaded; no functional change.
For values that CvGlobals caches, there is still no check if XML has been loaded. I've
added an isCachingDone check to every getter function and found only one issue
(TechPrefs.py; fixed). Then I removed the checks again because they were a bit
unwieldy.
63
probably all I can do. Workarounds:
a) manually exit to the opening menu before loading; or
b) play in windowed mode; or
c) press Alt+Tab two times when the delay begins. This seems to finish the "Initializing"
stage immediately.
Could easily replace the "Initializing" text with a recommendation to minimize the game
if loading is taking long. I've tested this and found it quite helpful because I keep
forgetting about this. But the recommendation would also show up when generating a
map, and this is misleading because Alt+Tab does not speed up the map script. The
replacement text also needs to be very short; no room to explain that it only applies
when loading a savegame. Had to leave it at a regular loading screen hint (008d) that
shows up randomly.
See also 009 is a prerequisite because it repairs BUG code for finding the My Games directory
where savegames are located.
004m is a prerequisite because it makes sure that returning to the opening menu
doesn't affect the layers that are enabled after loading.
advc.inl Function inlining [the change id was “advc.003f” until AdvCiv 0.97]
I haven't exhaustively checked every header for functions that may benefit from inlining (though I
did scour some of them), but I think I've taken care of the bulk of the functions that are very short,
are at least somewhat frequently called and don't contain any conditionals. In most cases, I've
merely moved the definitions into the header file.
− I use the “inline” keyword only where the linker requires it for the one-definition rule. MSVC03
(contrary to the C++ standard I think) never requires the “inline” keyword for function templates
and member functions of templates, regardless of whether they're defined in-class or out of
64
class; I guess they're implicitly treated as inline.
− I use the MSVC “__inline” keyword almost exclusively to free functions in implementation files;
it seems that the Ob1 compiler option can't inline-expand such functions otherwise.
− I use “__forceinline” in only a couple of places where performance measurements have
suggested that it's probably benefitial.
I've also removed most of the (rather few) “inline” and some “__forceinline” keywords from Firaxis
code.
See also Official documentation for the MSVC03 compiler: VS2003_CPP_en-us.pdf
• “The __inline keyword is equivalent to inline”
• “__forceinline […] tells the compiler to go beyond the current inlining heuristics and
to absolutely inline [...] except in cases in which inlining would be impossible.”
• “/Ob1 expands only functions marked as inline or __inline or, in a C++ member
function, defined within a class declaration.”
•”/GL allows the compiler to perform optimizations with information on all modules in
the program [i.e.] optimize the use of registers across function boundaries [and] inline
a function in a module even when the function is defined in another module.”
advc.make: Use of compiler options by the AdvCiv game core DLL.
“We the People” Git issue about function inlining.
003u partially solves problems with dependencies between abstract non-AI classes
and AI classes derived from them. This has allowed me to inline additional functions
without undesirable header inclusions.
Rationale Based on measurements before and after moving groups of frequently used function
definitions into header files and with and without whole-program optimization (/GL
compiler option), I estimate that the lack (by and large) of inline expansion in the BtS
DLL adds somewhere between 10% and 35% to AI turn times; a significant overhead.
The use of /GL completely gets rid of this overhead in final-release builds; however, I
don't use final-release builds during development (nor for profiling), so inline definitions
still make sense for performance, and, in my opinion, have no drawbacks with respect
to readability.
I use “inline” and “__inline” side by side in order to differentiate between cases where
an inline keyword is required and cases where I only want to nudge the compiler
toward inlining. This is only my personal convention though; the two keywords are
equivalent.
Prior to AdvCiv 1.0 I had used inline keywords copiously, especially on wrapper
functions, in order to reassure the reader that performance won't suffer (at all) or to
point out functions that get very frequently called – as a warning against expanding
those functions. I still think this latter rationale has some merit, but, on the bottom line,
I've concluded that it's better to get rid of the inline clutter. In a test, the old code with
all the inline keywords ran 5 permille faster than the newer code without them; since
such measurements are affected by some noise, there may in fact be no difference in
performance at all. That is, although the MSVC03 compiler is old and is by Microsoft, it
does seem to have a solid, reliable logic for inlining.
In my tests, force-inlining functions that branch at runtime and have multiple call
locations has usually hurt performance. I'm guessing that this is mainly due to branch
misprediction. Hence, there is generally no point in defining functions with branching in
header files (such functions are also complex enough to affect readability).
Tbd. As a matter of uniform style, all one-line const accessors should be defined in header
files – but this is pretty unimportant.
AdvCiv BtS
65
Removed the “INLINE” suffix from all function The original developers have inlined only a few
names and deleted the non-inline versions of very frequently called functions. They've done so
those functions except for a few functions with by defining them in-line and adding the inline
const-correctness issues; those few functions keyword. No exported functions have been
I've renamed by appending the suffix “External” inlined – supposedly, in order to avoid inline-
and then exported them under their original nameexpansion at the call locations in the EXE;
through a module definition (.def) file. instead, separate non-exported functions with
“INLINE” appended to their names (e.g.
CvGlobals::getGameINLINE, CvPlot::
getX_INLINE) were created for (all) DLL-internal
calls, while the non-inline versions are only called
externally. This convention has not been strictly
followed, at least not in code added by the BtS
expansion, and especially not by modders.
Rationale To unclutter the DLL code and to make sure that only one version of each function is
used in the DLL. (Now the inline versions are both faster and more readable than the
exported versions, there is no reason for anyone to use the exported versions
anymore.)
The problem of avoiding inline-expansion in the EXE is academic now that the EXE
isn't going to get recompiled. So, far what it's worth: The “inline” keywords were
probably superfluous. Inline-expansion of exported functions works just fine in the DLL
without “inline”, just so long as the function is defined in a header file. It might make a
difference for inline-expansion at external call locations, but I doubt it. Firaxis could've
used a .def file to avoid awkward function names in either the DLL or EXE.
Returning to the present, it would be kind of nice to add a ...External version for all
external functions and to export exclusively through the .def file. That would minimize
the risk of breaking a DllExport, would make it easy to make minor changes to the
signatures of exported functions and could avoid problems with inlining if the source of
the EXE is ever released. However, this is, for starters, a big effort, and I also don't
think it's going to be all the helpful on the inlining front: If the source of the EXE
becomes available, one will want to use a more recent compiler, which may use
different name mangling and thereby break the .def file. Moreover, allowing the EXE
to inline DLL calls would improve performance a bit.
See also The Firaxis developers were probably right to be concerned about function definitions
in headers getting inline-expanded in the EXE. E.g. in the case of CvGlobals::
getGameINLINE, I think that would've made it dangerous to change the memory layout
of CvGlobals in the DLL. See 003k about such obscure constraints imposed through
other part of the DLL code having been compiled into the EXE.
CFC post explaining how to add a .def file to a mod
Credits I learned about .def files from posts by alberts2 and Anq in the Caveman2Cosmos
forum (thread). Until then, I thought that it was impossible to rename functions that the
EXE calls.
Config The .def file is enabled through Makefile.project. Danny's/ Nightinggale's makefile
had already supported .def files; only a linker argument had to be added. For
obtaining mangled names, Dependency Walker is probably the easiest means.
Removed most of the _USRDLL preprocessor When disabled, the _USRDLL flag hides functions,
checks. preprocessor defines and enums that the EXE
isn't supposed to access. That includes all
“INLINE” functions.
Rationale Hiding the “INLINE” functions was, as far as I can tell, pointless because they weren't
66
exported. (As CvInitCore demonstrates, defining exported functions in the header will
indeed get functions inline-expanded in the EXE, resulting in an undesirable
dependency on the memory layout of the DLL.) Hiding enums and defines was
prudent at the time, but may not be necessary if the source of the EXE is released
(see above) and is, in any case, not going to be crucial. And currently, to be clear,
_USRDLL is always enabled – as it needs to be when compiling the DLL without the
EXE.
See also Two posts by EmperorFool about the _USRDLL flag.
CvPlot: Some frequently called functions have a (mandatory) bDebug parameter that allows
ignoring the fog of war (for Debug mode), e.g. CvPlot::isRevealed(TeamTypes,bool). I've kept
the bodies of those functions in CvPlot.cpp, but overloaded them with functions that don't take a
bDebug parameter and inlined the bodies of those new functions. (This way, the inline versions
don't perform any conditional branching.) Then I've removed bDebug=false from all call locations
so that all non-UI code uses the inline functions.
See also advc.enum simplifies many getter and setter functions, making them candidates for
inlining.
67
advc.make: The AdvCiv makefile enables SSE2 instructions (but I haven't verified that
they're actually being generated).
Posts by AIAndy arguing that floating-point math, fundamentally, isn't a problem.
Post by Nightinggale arguing that it's difficult to be certain.
Tbd. If it turns out that libraries mess with the floating-point settings, I could try to repair that
through _controlfp:
"At app startup time we call: _controlfp(_PC_24, _MCW_PC) _controlfp(_RC_NEAR, _MCW_RC) Also, every tick we
assert that these fpu settings are still set: gpAssert( (_controlfp(0, 0) & _MCW_PC) == _PC_24 );
gpAssert( (_controlfp(0, 0) & _MCW_RC) == _RC_NEAR ); There are some MS API functions that can change the fpu
model on you so you need to manually enforce the fpu mode after those calls to ensure the fpu stays the same across
machines. The assert is there to catch if anyone has buggered the fpu mode. FYI We have the compiler floating point
model set to Fast /fp:fast ( but its not a requirement )" source, similar advice, cf. MS library
68
I've removed DLLExport from structs and instead DLLExport. This means (apparently) that all
added it to the individual functions that the EXE functions of the class, including implicit ones, can
calls except for cases where every (explicit) be called by the EXE.
function was called by the EXE.
Patch 3.19 removed a lot of unused DLLExports,
For functions that do require DLLExport, if I have but not nearly all of them.
to add a parameter, I'm employing this pattern (in
the header file):
DLLExport ReturnType functionName(Parameter1
param1) {
return functionName(param1, defaultVal);
}
ReturnType functionName(Parameter1 param1,
Parameter2 param2);
69
cache read, but doesn't prevent the cache write.
DisableFileCaching probably refers to the
catalogCiv4Beyond Sword....dat files in the
cache, but doesn't prevent them from being
written. DisableCaching probably disables both
the XML and the file cache from being read;
difficult to verify.
When loading a mod: Regardless of the INI
settings, in my experience, the XML cache is
never written. Whether the EXE attempts to read
the dat files written during an earlier (unmodded)
launch is unclear. This would result in erroneous
behavior (probably an immediate crash). Clearing
the cache is a very common recommendation on
CFC and other websites for players who have
trouble loading a mod. It's conceivable though
that these problems have been resolved by one
of the official patches, perhaps by simply
disabling cache accesses when loading a mod.
It might be that only modular loading had been
causing problems, as is suggested by item 14.10
of Kael's Modder's Guide.
Another hypothesis: The XML cache has always
been disabled for mods, and only the file cache
(catalog files) has been causing crashes at
launch.
It's also not clear what the effect is of holding
down Shift during launch. I don't see any cache
files getting deleted; perhaps it merely
suppresses the cache read.
Credits Nightinggale; CFC (same thread as above)
See also alberts2 has also removed the read/write functions from Caveman2Cosmos: SVN
revision
The DLL can disable INI settings as shown here by Nightinggale. However, the (non-
XML) file cache probably can't be disabled that way because the EXE either doesn't
call the DLL in between reading the INI and dealing with the file cache, or because
CvDLLUtilityIFaceBase doesn't get instantiated in time. Also, the DLL can't find out the
original INI settings, so all it can do is change them blindly without ever restoring the
original settings. That's poor form because the changed settings get stored on disk,
typically in the global INI file, affecting the behavior of all mods and the unmodified
game.
Large mods can take longer to load when they are launched for the first time. This is
probably caused by caching in the HDD (post by Nightinggale); the XML cache is only
a minor factor and the file cache seems to have no noticeable benefit.
I've been trying to get a hold of the contents of some user's cache that will cause a
crash at launch (don't really care with which mod). keldath posted some files here, but
I can't reproduce the problem and he can't rule out that his user profile was
responsible for the crash. Related post in the Dawn of the Overlords thread
As for backwards compatibility with old cache data: That would only matter if someone
gets the cache to work for AdvCiv. And, then, there ought to be a better way, i.e. some
70
way to disregard the whole cache on the first read after a version change.
Rationale The slight speedup when launching would be worth something to me, but since it
doesn't seem to work at all and might even lead to errors, it's clearly best to make sure
that the cache is entirely disabled. Removing the read/write functions shaves 100 KB
off the DLL file size.
Config/ The preprocessor flag is set in CvInfo_Base.h, and it's named
Tbd. ENABLE_XML_FILE_CACHE. Fixing the XML cache doesn't seem like an impossible task,
and the read/write functions would be needed then. Perhaps those functions could
also be used for other purposes.
Regarding a rewrite of the XML cache code (I certainly won't do that): One would have
to replace cacheWrite (declared in CvDLLUtilityIFaceBase), possibly cacheRead,
and CvCacheObject, and write a new checksum test. String data in the EXE suggest
that MD5 is used:
NOT Using XML cache, failed to find crc.dat file ... NOT Using XML
cache, cur md5=%s, cached md5=%s ... Using XML cache
That part appears to be disabled (or broken) in the EXE. Update: Now that change
092b has introduced a framework for modifying the EXE at runtime, one could
probably (fairly easily?) get the cache to work.
71
Config Cppcheck is quite easy to use for a project like this. One basically just has to load the
.sln file in the GUI. External headers aren't needed; I guess Cppcheck just ignores
unrecognized symbols. Providing the std and boost headers, specifically, isn't even
recommended. A checkmark can be placed for Windows libraries in the GUI; I guess
that's prudent. I've also selected Win32-unicode as the target platform. “All build
configurations” should probably be unchecked because, otherwise, the analysis will
take several hours. The ART_INFO_DECL macro in CvArtFileMgr.h , ART_INFO_DEFN
in CvArtFileMgr.cpp and K-Mod's trait_info macro had originally aborted the
Cppcheck analysis. They had used the ## operator in questionable ways; easy to fix,
no need for some special VS build configuration disabling problematic code.
When reviewing the results, “suppress selected id” can be used to ignore a particular
type of warning throughout the project. These suppressions get stored in the
.cppcheck file, along with the target platform. I've committed my .cppcheck file to the
Git repository.
003k Workaround for adding data members to classes with exported constructor for which a
certain size is mandated by the EXE: CvSelectionGroup(AI), CvSelectionGroupAI,
CvReplayInfo, CvXMLLoadUtility and CvRandom. In the first case, there were already
comments about the issue in CvSelectionGroup.h, but, for CvReplayInfo, I had to
guess based on otherwise inexplicable exceptions in the destructor, and
CvXMLLoadUtility had, to my knowledge, only caused issues with Wine under Unix
(crash at startup due to corrupted data in CvGlobals; cf. advc.wine), though adding
further data members might've become a problem on any system.
My understanding is that this can be an issue for any class whose constructor or
destructor gets called by the EXE. (But I'm not too worried about virtual destructors –
which the EXE can in theory call, when the constructor isn't exported.)
I've verified that other classes whose size mustn't change (or at least not by much) are
CvFractal, CvDiploParameters, FVariable, CvPopupInfo, CvPopupReturn and
CvTalkingHeadMessage. I've put static assertions in the header files. For
CvDiploParameters and FVariable, the order of the members must also remain intact.
Looks like the EXE is making raw copies of instances.
CvInitCore is a special case. It doesn't get allocated externally, but the EXE accesses
certain data members directly at fixed memory offsets. It seems that some of the
exported getter functions (e.g. getAdminPassword) have been inlined in the EXE.
Warnings added, and an assertions for the class size – even though the class size isn't
decisive.
Nested class (akin to Pimpl idiom) added to All these classes have exported constructors
CvSelectionGroup, CvSelectionGroupAI, (CvSelectionGroup only via CvSelectionGroupAI)
CvReplayInfo and CvXMLLoadUtility. Also added or assignment operators and virtual or exported
copy constructors (C++ rule of three) and static destructors, and the EXE calls some of those
assertions that ensure that the object size stays functions.
as in BtS.
For CvFractal, CvDiploParameters, CvPopupInfo,In CvSelectionGroup, there was already a
CvPopupReturn and CvTalkingHeadMessage, warning in the BtS code against adding data
I've only added assertions. members.
Rationale I've added the nested classes as a workaround for those classes to which I wanted to
add data members. It's prudent to at least warn about the issue because the potential
memory errors can go unnoticed for a long time and then become very difficult to
debug.
72
Not sure if it's perfectly safe to replace one int or pointer member with a pointer to an
instance of the nested class, but storing the additional data in some completely
unrelated place would be really awkward.
Tbd. My pointer-to-nested-class approach doesn't allow for const correctness. The
accepted answer (class template PrivatePtr) to this Stack Overflow question sounds
like a promising remedy.
See also The Visual Studio debug heap (disabled by default; see advc.make) can help discover
memory corruption caused by exported constructors and destructors. Pinpointing the
cause – not so much. E.g. after adding two booleans to CvXMLLoadUtility, I got a
message
“Heap block at 036262B8 modified at 036262D0 past requested size of 10”
upon exiting from the opening menu (probably originating from the CvXMLLoadUtility
destructor) and a breakpoint somewhere in ntdll.dll. Without the debug heap, there
was no overt adverse effect under Windows, but under Unix (cf. advc.wine), the mod
crashed reliably at startup.
On a related note, Visual Leak Detector is also fairly easy to integrate with Visual
Studio. Only need to install it and include <vld.h> in some implementation file (I've put
it in CvMemoryManager.cpp). That said, neither the VS debug heap nor VLD find free
calls on uninitialized memory (well, that wouldn't be a leak either). Dr. Memory might
be a better alternative, but it keeps crashing at startup (both versions 2.3.0-1 and
1.11.0-2) unless I use the -no_track_allocs, -leaks_only, -no_count_leaks and
-no_replace_malloc options – which render the whole thing moot. Using the /Zi
compiler option (and the non-parallel “Debug” build config) instead of /Z7 may also be
necessary (but hasn't helped me). Relevant documentation: installation, compiler flags,
and the chapter “Running Dr. Memory” in the documentation included in the download.
As command arguments in Visual Studio, the full path to the EXE in quotation marks
needs to be used, followed by (not in quotation marks) the arguments for the EXE.
This CFC post about data loaded by the EXE from WBSave files might help explain
how some CvInitCore data get initialized. Note that the previous post says that e.g.
CvInitCore::setGameTurn is not used for this. So it might be that some function akin
to CvDLLPythonIFaceBase::putSeqInArray is used to write a Python list into a blank
CvInitCore instance. (But some setter functions may also have been inlined; so that
could be an alternative explanation.)
Somewhat unrelated to the above: Added an assertion to CvInitCore that warns when the total
length of leader names and civ descriptions in a scenario file will (probably) crash the civ selection
screen.
See also CFC thread explaining the issue in some detail
Rationale Should another modder ever experiment with AdvCiv and a scenario with more than
50 civs – and also knows how to use an Assert or Debug DLL (lotta ifs …) –, then this
assertion could be a big help.
003l Support added for ArtStyle-specific unit button graphics. This had mostly already been
supported, except in the plot list (icons shown for units in a selected tile) and the
Sevopedia.
Rationale See these posts. Only relevant for mod-mods.
Tbd. The list of units shown by Sevopedia when clicking on the category “Units” still shows
the generic button graphic. Can be fixed (in SevopediaMain.py), but would take a bit
of time. The “More Naval AI” mod may have some useful code fragement. (Git commit)
73
Also added (untested) UI support for unit and building classes without a default unit type, i.e.
classes that only exist for unique units.
Rationale Seems easy enough to do; only relevant for mod-mods.
Credits CFC users Toffer90 and Inthegrave: Git commit 1 2
003m Variables added to CvTeam for keeping track of minor civ status and at-war counts.
Rationale Speeds up the frequently used functions isMinorCiv and getAtWarCount.
Note: Minor civs were probably introduced for the Vanilla Earth1000AD scenario. The
BtS version of that scenario doesn't use minor civs, and I don't think official or bundled
content does. However, mod-mods might want to use them, so minor civs should
arguably remain supported,
See also 033 could have a performance problem without this.
003n Make sure that AI attitude and memory of and toward Barbarians and minor civs are
never used nor updated.
Rationale The updates waste time and require the code that computes attitude to handle non-
major civs gracefully.
Code that uses the (memory) attitude of/toward non-majors is dubious; it's helpful for
future testing to disallow this. Doing so has already revealed some potential issues,
e.g. Barbarian cities assigning fewer defenders in “Always Peace” games.
74
called very frequently: CvPlot::isTradeNetworkConnected, CvPlot::isTradeNetwork,
CvPlot::getPlotGroup, CvCity::canTrain
Rationale As a rule, I'd posit that any function called more than half a million times during one
late-game turn shouldn't be routinely profiled. It seems that at least part of the profiling
overhead of a function gets added to the times measured for its callers, so profiling
very frequently called functions may lead to misleading results. Also don't want to
make profile builds needlessly slow. It's better to use an external profiler (e.g. Very
Sleepy) for identifying code that gets executed extremely often.
Tbd. I've done what I could (mostly through inlining; see advc.inl) to speed the “hot”
functions up. They still take up a considerable portion of the overall runtime. Will have
to call them less frequently – by making the pathfinding code more efficient or by
relying less on pathfinding.
AdvCiv WtP
Profiler for counting CPU cycles based on the Time Stamp Counter register adopted from the “We
the People” mod. For profiling functions that are fast but get called very frequently.
Config /DUSE_TSC_PROFILER in Makefile.project. The target configuration needs to be
“Profile” in addition.
Credits Code by Nightinggale. Adopted from this Git commit.
Tbd. Crash in the EXE upon exit (when TSC profiler enabled). Don't know if that also
happens with Nightinggale's code; could be that the singleton pattern I implemented
for the TSCProfiler class is causing this somehow. CvGlobals::uninit terminates
correctly; the crash happens before the TSCProfiler instance is destroyed. Not a big
problem; without a debug build, the crash isn't even noticeable.
Added a compiler flag PROFILE_AI_AUTO_PLAY to disable code fragments that may randomly skew
results when profiling on AI Auto Play. So far used only to prevent the active player from receiving
a map in trade.
75
setting the dirty-bit. For example, I don't think the unit layer needs to be updated when
the owner of a tile changes.
76
FOR_EACH_CITYAI_VAR. (FOR_EACH_CITY with a FLTA is a “non-packed array” (Firaxis
non-AI const pointer is supposed to be the comment), iLoop is not equivalent to a loop
standard macro and the one most commonly counter.
used.) Same for CvUnit, CvSelectionGroup,
CvArea and CvDeal.
I've replaced BtS-style loops with my macros
everywhere in the game core code base.
A hints file (cpp.hint) is used to get Visual
Studio to recognize the scope of the macros.
Auto-completion (Ctrl+Space) still doesn't
(reliably) suggest the name of the element
variable (e.g. pCity), at least not in VS2010.
See also Comments in FreeListTraversal.h
advc.enum defines a FOR_EACH_ENUM macro.
Rationale The BtS loops are very clunky and the iLoop variable is a bit dangerous as it can be
misinterpreted as a loop counter (I've been there once). A proper iterator like
for (CityIter it = kOwner.firstCity(); it != kOwner.lastCity(); ++it) {
CvCity const& kCity = *it;
might be more idiomatic, but would've been more work to implement and the macros
are rather more convenient to use. (Although I'd prefer to work with references.) Also,
using iterators everywhere would lead to a lot of nested iterator loops with awkwardly-
named iterator variables (or bugs resulting from name clashes).
The auto-complete issue is only a little bit annoying and may be a nonissue with more
recent versions of VS.
When iterating through CLinkList objects, const CLinkLists are used, primarily, for storing the
CLLNode pointers (and for IDInfo nodes also units in a tile or AI group, the cities or units
const CvUnit and CvCity pointers) are used selected by a human player and the trade items
when possible. When it was obvious that a loop in a deal. A typical loop looked like this:
doesn't modify the current node through some CLLNode<IDInfo>* pNode =
side-effect, while loops have been replaced with kPlot.headUnitNode();
for loops. while (pNode != NULL)
{
Typical form: CvUnit* pUnit = ::getUnit(pNode->m_data);
pNode = kPlot.nextUnitNode(pNode);
for (CLLNode<TradeData> const* pNode = // …
pFirstList->head(); pNode != NULL; pNode = }
pFirstList->next(pNode))
{
TradeData data = pNode->m_data;
// …
}
77
be removed in the body of the loop.
Specifically for traversing the unit lists
CvPlot::m_units and CvSelectionGroup::
m_units, a macro FOR_EACH_UNIT_IN (with AI/
non-AI and const/ non-const variants) have
been added. CvPlot and CvSelectionGroup have
the same interface for accessing their m_units
member; therefore the same macro names can
be used for both.
For traversing the trade items in a deal, a macro
FOR_EACH_TRADE_ITEM (again, with variants) has
been added.
The macros that iterate over const units and
nodes, come with an assertion that checks after
each iteration whether the list length has
changed. I've disabled those assertions after
doing some tests. It seems pretty unlikely that
accidental changes during traversal will go
unnoticed even without the assertion.
Rationale The while loops are error-prone; in particular, it's easy to mix up the order of the
getUnit and nextUnitNode calls or to insert a statement in between them that causes
the nextUnitNode call to be skipped. Such errors can be difficult to debug. The for
loops are also dangerous; deleting pNode in the body will cause a crash. const
qualifiers make these loops a bit safer. That said, the current node could still be
deleted as a side-effect. For example, telling a unit to join a different selection group
while iterating over its current selection group will delete the unit from the current
CLinkList., leaving pNode as a dangling pointer. Killing a unit will immediately remove it
from the unit list of its current tile; mustn't do that in a for loop over the units in that
tile. const qualifiers on the CvUnit pointers should mostly prevent such mishaps.
while loops aren't entirely safe in that regard either. In the example on the upper right,
it's OK to kill pUnit, but, once nextUnitNode has been called, pNode mustn't be
deleted, and the unit contained in that node (which could be any unit except pUnit)
mustn't be killed.
It's preferable to wrap these details into macros, but it depends on the type parameter
of the CLinkList what the macro needs to do exactly, and some frequently used lists
are encapsulated by other classes and therefore not directly accessible to macros. The
macros I've written cover a large portion of the CLinkList traversals in the codebase.
Nota bene: Whether a unit or city in a CLinkList can be NULL before the first iteration
depends on the circumstances. AI groups and plot lists should be updated immediately
when a unit is killed – I think (that should be assumed). I'm even less certain about
human selection lists (handled by the EXE).
Tbd. Should arguably add macros for dealing with CvDLLInterfaceIFaceBase::
nextSelectionListNode (used mainly in CvDLLWidgetData.cpp) and
CvPlotGroup::nextPlotsNode.
See also CFC thread about the dangers of CLinkList loops. Also suggests that dangling node
pointers won't necessarily lead to visible errors and that, for better or worse, such
errors could be more likely to result in crashes under Windows 10 due to more
aggressive memory management.
billw2015 has written iterator classes for the Caveman2Cosmos mod (CFC post;
78
GitHub links 1 2 3 4 5 6).
C2C also has some special assertions for identifying indirect changes to CLinkList
nodes during traversal.
Each CvPlot stores a list of its up to 8 adjacent Adjacent plots get computed on the fly by going
plots. The lists aren't guaranteed to be in a through all 8 directions and calling the
particular order except that orthogonal neighbors plotDirection function (CvGameCoreUtils;
always have an even index in the adjacency list moved to CvMap in AdvCiv) for each. Example
and diagonal neighbors an odd index. An (already edited a bit for readability):
adjacency list can be traversed through the bool CvPlot::isAdjacentToLand() const
FOR_EACH_ADJ_PLOT macro. Example: {
for (int i = 0; i < NUM_DIRECTION_TYPES; i++)
bool CvPlot::isAdjacentToLand() const {
{ CvPlot* pAdjacentPlot = plotDirection(
getX(),getY(), (DirectionTypes)i);
FOR_EACH_ADJ_PLOT(*this) if (pAdjacentPlot != NULL)
{ {
if (!pAdj->isWater()) if (!pAdjacentPlot->isWater())
return true; return true;
}
} }
return false; return false;
} }
Rationale/ Even with the FOR_EACH_ENUM macro (see advc.enum), it's obviously clunky to get the
See also neighbors via the DirectionTypes. The SquareIterator (advc.plotr) isn't as efficient as
the BtS loops (not for range 1, that is). The BtS loops aren't all that efficient either.
Even after some optimization on my part, plotDirection requires several
conditionals in order to deal with the map's world-wrap settings (and, as a result, can't
be efficiently inlined) and one multiplication and one (modulo) division. The adjacency
lists increase the size of CvPlot by only 4 byte. Adjacency lists constantly need to be
traversed during pathfinding. Thanks to K-Mod, all the pathfinding of AI units happens
within the DLL and can therefore take advantage of the adjacency lists. I think the
speed-up of AI turns I got from the adjacency lists was around 10%. That said, AdvCiv
performs (far) more pathfinding than K-Mod does (see 104b).
79
with one integer entry for each unit class to store
the flanking strike ability. If the list of pairs is
empty (e.g. no flanking strike ability), all entries
are 0.
See also This technique has been superseded by enum map classes and glue that makes
them easy to use for XML loading, however, it's still used in some places, so I'm
leaving the documentation in place until all of the code has been converted.
Rationale To store the data more compactly. In total, I estimate that only a few MB (5 maybe) will
be saved, but, especially for CvUnitInfo, I'm hoping that saving a few KB per object will
improve the performance of the CPU cache.
Credits Inspired by Caveman2Cosmos (specifically this thread).
Added isAny... functions for some of the tag- For example, this loop in CvCityAI::
pair-list arrays loaded from XML. The isAny... AI_buildingValue
functions test if an array is allocated. Went for (int i = 0;
through the call locations of the respective array i < GC.getNumBuildingClassInfos(); i++)
accessor functions and inserted isAny... checks {
if (kBuilding.
to avoid costly loops. In particular the checks getBuildingHappinessChanges(i) != 0)
avoid a loop over … iValue += kBuilding.
getBuildingHappinessChanges(i) * …
• BuildingClassTypes in CvCity::canConstruct
• BonusTypes in the CvCity::getProductionModifier goes through all ca. 125 building classes to
functions
• BonusTypes in the
check if any of them has the building-happiness-
CvCity::CvCity::getAdditional...ByBuilding from-other-building ability – which is actually
functions unused.
• BuildingClassTypes in
CvCityAI::AI_bestBuildingThreshold
• BuildingClassTypes, ImprovementTypes in
CvCityAI::AI_buildingValue
• PromotionTypes in CvPlayerAI::AI_unitValue
80
be impossible to construct.
Credits The Caveman2Cosmos modders noticed that the tag is wasteful and unnecessary.
Rationale With the tag pair list changes above, the unused tag was actually no longer wasteful,
but I can't think of a reasonable way to ever use this tag for anything.
AdvCiv BtS
Use enum maps to store nested data loaded The nested data consists mostly of lists of pairs
from XML, along with macros that make all the that map some element of play (represented by
necessary declarations in the Cv_...Info.h files an enum type in the DLL) to an integer value or
(also enabling fast iteration over non-default to a tuple of yield or commerce values or
values) and CvXMLLoadUtility functions that modifiers. The DLL stores that data in two- and
insert the XML data into the maps. The choice three-dimensional arrays, filling in a default value
between the available map types needs to be (normally 0) for all enumerators not listed in XML.
made at compile time – by calling the appropriate (See above for an example.)
DEF_... macro in the Cv_...Info header.
See also advc.enum: The available enum map classes (which are also widely used outside the
CvInfo class).
The “We the People” mod uses a datastructure specialized for dealing with three-
dimensional XML data. CFC thread (By encoding yield and commerce tuples in
primitive data types, I'm mostly dealing with mappings from keys to primitive values,
but the dozens of yield types in WtP rule that approach out.)
Rationale I don't think much speed is being gained here over the my previous makeshift solution
of collapsing empty arrays – which was already not a very significant improvement.
The greater benefit is that the DEF_... macros unclutter the CvInfo classes and make it
easier to add new two-dimensional XML data without worrying about performance.
Letting the XML loading code choose an enum map type at runtime based on the
number of non-default values would have added overhead for virtual function calls –
which might well have neutralized any performance gains.
Tbd. So far, I've converted only CvBuildingInfo from raw arrays to enum maps.
81
classes derived from CvHotkeyInfo are also member needs to be initialized by the constructor
derived from CvXMLInfo. However, so far (not strictly necessary if the element is
CvBuildingInfo is the only CvHotkeyInfo class mandatory), the accessor function needs to be
that I've added an addElements function to. implemented (unless an inline definition is used)
and, in read(CvXMLLoadUtility*), a few lines
of code need to be added that do the actual
loading through CvXMLLoadUtility. If the XML file
is cached by BtS (many of the frequently
changed XML files are), then any new element
should arguably also be added to the
read/write(FDataStreamBase*) functions.
Elements added in this way can be accessed Example for an element access:
through an overloaded get function; e.g. kImprovement.getDefenseModifier()
kImprovement.get(CvImprovementInfo::
DefenseModifier) XML elements can contain integers (ids and
if kImprovement is a reference to a scalar values), booleans, floating point numbers,
strings and mappings, typically mapping integers
CvImprovementInfo object.
or pairs of integers to other integers (e.g.
Only integer and boolean elements are TerrainMakesValid, RouteYieldChanges in
supported so far. CvImprovementInfo).
Rationale Ideally, to add a new XML element tag, the name of the tag would have to be specified
only once in the DLL. This is possible through macro definitions and that works pretty
well for GlobalDefines (see advc.opt) but requires too much error-prone code to be
added to each info class in the case of non-global XML elements. Still, having to make
changes in 2 places (that are just a few lines apart) is better than the 4-7 places in
BtS.
As for the new "CvXMLInfo" class: It represents XML element tags as enum values.
That's probably not clear from the class name; don't want a long class name though
because derived classes need to refer to some base members explicitly. At least one
class (CvActionInfo) that doesn't get loaded (directly) from XML is derived from
CvInfoBase, so one could argue that representing only XML data is a specialty of
CvXMLInfo.
I've tried implementing the enum handling directly at CvInfoBase, but that resulted in a
crash in the EXE. My guess is that there is some class derived from CvInfoBase
(probably a small one) whose size mustn't change (cf. 003k).
Tbd. By now I've typedef'd all references to CvInfo base classes, so “CvXMLInfo” could be
changed to a somewhat longer and more informative name.
See also The HealthPercent tag added to CvImprovementInfo for 901 serves as an example.
003i disables the XML cache, but I'd still like to keep the code for storing XML data on
disk up to date. Through the CvXMLInfo class, this doesn't have to be done manually
for every new XML element.
003t allows cached GlobalDefines to be accessed through enum values.
xmldefault introduces a new system for default values, but I've only implemented that
for Civ4LeaderHeadInfos.xml so far
Nightinggale has written a Perl script that generates enum values from the type
elements in XML. By parsing the schema files, essentially all code in the CvInfo
classes could be generated by such a script. (Without an external code generator, one
could only end up with something inefficient like the CvGlobals::getDefineINT(char
const*) function.)
Only rudimentary support for exposing XML Most of the CvInfo accessor functions are
82
elements to Python; a macro call needs to be exposed to Python. The CyInfoPythonInterface
added for every element to be exposed, and a files contain pointers to the accessor functions.
definition pointing to the function declared by the
macro needs to be added to one of the
CyInfoPythonInterface files.
See also Comment above the macro PY_GET_ELEMENT in CvInfo_Base.h.
Rationale I haven't found a way to expose my generic get functions to Python. That's a pity
because it would be nice to make new XML elements available to Python scripts, and
doing so manually is tedious.
When converting BtS elements to CvXMLInfo, all Python exports should be kept intact.
Exposing the generic get functions wouldn't help here; but the macro solution also
isn't great as it requires a macro call for each tag exposed.
Tbd. To allow elements to be added as enum values to a CvInfo class not derived from
CvHotkeyInfo, its base class will have to be changed from CvInfoBase to CvXMLInfo
and all explicit calls to base class functions will have to be updated to call the new
base class instead (this last part is no longer necessary, I've already taken care of that
through typedefs). Also, even if derived from CvHotkeyInfo, an enum for each data
type (int, bool) needs to be added to the header file and the addElements function
needs to be overridden.
xmldefault Default values for optional XML elements set through a special <...Info> element
AdvCiv BtS
When an <...Info> element of type ..._DEFAULTS Subelements of <...Info> are optional when the
is present in an Civ4...Infos.xml file, then all schema file sets minOccurs=”0” for them. XML
subsequent <...Info> elements use the values of schema definitions – in principle – support default
the DEFAULTS element as default values for values, however, BtS (specifically the EXE) only
optional elements. On the DLL side, this behavior uses the schema file for syntax validation.
is only implemented for Civ4LeaderHead Loading XML data and setting defaults is up to
Infos.xml so far. the DLL, which has no access to the schema
parsed by the EXE. Through the Cv...Info
All LeaderHead data that is the same for all or constructors, the DLL sets default values of 0,
almost all leaders is optional and has a default false, an empty string or (for enum types) -1 for
value set through LEADER_DEFAULTS. all elements (regardless of whether they're
I've deleted all optional data that equaled the optional in the schema). For Civ4LeaderHead
default value, reducing the file size of Infos.xml, the BtS schema makes all data
Civ4LeaderHeadInfos.xml by more than 50%. mandatory although many elements are the
same for all leaders, in particular the contact
LeaderHead XML files without a DEFAULTS
delay values.
element can still be loaded, so XML mod-mods
shouldn't have to change anything.
Modular loading (not used by AdvCiv): The
defaults set in Civ4LeaderHeadInfos.xml also
In BtS, modules can only contain full definitions
apply to any LeaderHeadInfos loaded from a of <...Info> elements. Those elements are then
module. Modules should not define their own
added to those loaded from the main module or,
LEADER_DEFAULTS.
if an element of the same type had already been
For behavior similar to MRGENIE's “TrueModular loaded, the old element gets replaced. The
XMLCOPY” mod, I've left a few lines commented XMLCOPY mod (included e.g. in Rise of
out in Mankind) allows modules to alter individual
CvXMLLoadUtility::SetGlobalClassInfo. Not subelements of a previously loaded <...Info>
83
really useful for LeaderHeadInfos I think. element instead of replacing the whole element.
Rationale Mainly to make the behavior shared by all leaders easier to adjust, i.e. through a
change in one place as opposed to 52. Uncluttering Civ4LeaderHeadInfos.xml is a
nice bonus.
An alternative (more laborious) approach would have been to parse the schema file in
the DLL and get default values from there.
See also 006b warns about all optional elements not found by the DLL unless a default value is
explicitly set in the GetChildXmlValByName call (overriding the initial value set by the
Cv...Info constructor).
If the DEFAULTS were kept around past XML loading, they could be used for 004q (see
Tbd. there).
advc.rh also deals with modular loading.
Tbd. Add DEFAULTS for other large Civ4...Infos.xml files, e.g. UnitInfos. This will require
(non-trivial) DLL changes akin to those I've made in CvInfos_Civilization.xml.
84
function. Non-AI functions return pointers and
references to base-class instances. Containers of
units and cities usually have two sets of accessor
functions – those from BtS, returning a pointer or
reference to a base-class instance, and copies of
those functions with “AI_” prepended to their
name that return a pointer or reference to an AI
instance. Example (CvPlayerAI):
inline CvUnitAI* AI_firstUnit(int *pIterIdx)
const {
return m_units->beginIter(pIterIdx);
}
– alongside the BtS function CvPlayer::
firstUnit that returns a CvUnit* from that
same m_units list.
(All the above mostly also applies to
CvSelectionGroup/ CvSelectionGroupAI.)
Rationale So that AI functions can call other AI functions (BtS ensures that through virtual
function declarations; see below) and so that non-AI functions can't easily call AI
functions. The code duplication around containers is unfortunate, but it really isn't
much code all in all and it's not code that is likely to be modified. As an alternative, the
containers could always return (pointers/references to) AI instances and leave it up to
the caller to store the return value in either an AI or non-AI variable, but upcasting
would require the caller to include the header file that defines the relation between
base class and derived AI class (i.e. CvUnitAI.h or CvCityAI.h). I want to avoid
including AI headers in non-AI code.
(no change) All AI functions have an “AI_” prefix attached to
their name.
Rationale I guess this is the Firaxis approach for making programmers aware when they mix AI
and game rule code.
Tbd. If my approach for separating AI/ non-AI code were fully implement (it isn't; see players
and teams below), then there wouldn't be much of an argument in favor of the name
prefixes anymore. Removing them wouldn't necessarily be a big task; mostly
automated search and replace.
Added inline wrappers named simply “AI” for Downcasts are (almost?) entirely avoided
converting (downcasting) pointers and referencesthrough virtual function declarations (see below).
to non-AI instances into references to AI
instances. E.g. CvCityAI& CvCity::AI()
Rationale While there should be a bit of a barrier against non-AI code calling AI functions, such
function calls have to happen sometimes due to the basic (Firaxis) design. An explicit
downcast would be too unidiomatic and cumbersome (maybe even unsafe – it's a
reinterpret_cast if the respective AI header file isn't included). Hence the wrappers.
Example: When CvCity::alterWorkingPlot needs to update the AI citizen
assignment, it does so by calling AI().AI_addBestCitizen(...).
Credits Nightinggale suggested the wrappers here.
Any AI functions added by AdvCiv are non-virtual All AI functions are declared as pure virtual
functions, and I've turned any virtual functions functions at the abstract base class. All virtual
added by K-Mod into non-virtual functions. Same functions can, in theory, be called by the EXE
for all the virtual AI functions in CvCity and through the vtable, and the EXE indeed calls
CvUnit (the EXE, apparently, calls none of some of the virtual functions in CvPlayer,
CvTeam, CvGame and CvSelectionGroup. (One
85
those). can't be absolutely certain that the EXE does not
call some particular virtual function, but if a such
The remaining virtual AI functions from the
a call is never observed in any game mode or
original code I've turned into mere wrappers that
menu, then it's a pretty safe bet.)
call non-virtual functions. I've moved the
declarations of the wrappers into the private
section of the base classes and appended
“External” to the function names. For the wrapper
implementations, I've created a new file
CvVirtualWrappers.cpp.
Rationale I don't need to call AI functions through a base class pointer or reference. Having to
declare each AI function in two places and keeping the declarations consistent is
tedious and error-prone. So I'd like to just get rid of the pure virtual declarations, but
the vtable position of those functions that the EXE calls mustn't be changed. This
means that most of the virtual functions need to be preserved. For a call through the
vtable to succeed, it seems that, apart from the table position, only the data types of
the parameters must be compatible with the data that the EXE provides. So, changing
the accessibility and function names is fine. I've done that to make sure that the
wrappers aren't called within the DLL.
With the wrappers in place, the non-virtual functions can safely be modified; the
compiler will then point out that the call in the wrapper function also needs to be
modified. (The wrapper then acts as an adapter.) It's not generally safe to add any
virtual functions. There should also be no need; but if need be, then any of the
wrappers that the EXE doesn't call can be replaced with a new virtual function.
See also About deleting some of the virtual wrappers, see comments in
CvVirtualWrappers.cpp.
About adding data members to CvSelectionGroup (kind of related): 003k
CvGlobals::getGame returns a CvGame&. A new The singleton CvGameAI instance is accessed
function CvGlobals::AI_getGame returns a (only) through CvGlobals::getGame, which
CvGameAI&. returns a CvGameAI&.
Regrettably, players and teams are still usually Players and teams are usually passed to
passed as ids. I've renamed the static functions functions as enum type ids and the macros
to AI_getPlayer and AI_getTeam and created GET_PLAYER and GET_TEAM map those ids to
counterparts getPlayer and getTeam at CvPlayerAI and CvTeamAI references. The
CvPlayer and CvTeam that return non-AI macros are shorthands for static functions
references. I have not created separate wrapper CvPlayerAI::getPlayer and CvTeamAI::
macros for AI and non-AI references. Instead, getTeam.
CvGamePlay.h defines GET_PLAYER and
GET_TEAM as wrappers of CvPlayer::getPlayer
and CvTeam::getTeam and CoreAI.h redefines
the macros (with precedence over
CvGamePlay.h) as wrappers of CvPlayerAI::
AI_getPlayer and CvTeamAI::AI_getTeam.
This means that access to AI references requires
the inclusion of CoreAI.h.
In functions that make more than two function References to player, team and game instances
calls on the same player or team instance, I are rarely stored in variables; instead,
usually store a reference in a variable. If I don't GET_PLAYER, GET_TEAM and getGame are called
call any AI functions, I give that variable a non-AI over and over.
type.
Rationale Returning only AI types forces client code to include the respective AI headers; don't
86
want that when the client function isn't an AI function.
I was tempted to introduce new macros “PLAYERAI” and “TEAMAI” for AI references,
but figured that it's just too much work to change all those call locations. The redefined
macro provides only minimal separation between AI code and non-AI code.
See also See advc.make about the CvGamePlay, AICore headers.
003 allows the GET_TEAM macro to take a PlayerTypes parameter and adds a TEAMID
macro. And passes CvArea instances always as references or pointers and never by
id.
Tbd. I see no good reason to pass and return players and teams by id. Type information is
lost that way (AI/non-AI, const) and the macro calls make the code harder to read. It's
a good thing that most classes have getID functions because ids are needed for
several purposes (serialization, Python interface, std::sort), but it's much more
common that member functions need to be called. So all function signatures should be
changed from PlayerTypes and TeamTypes to CvPlayer const& and CvTeam
const& (or a less strict type when necessary). This can be done little by little.
Afterwards, if PlayerTypes and TeamTypes are still commonplace, one could consider
adding pairs of const/non-const functions
CvPlayer::team returning a CvTeam reference; and
CvPlayerAI::AI_team returning a CvTeamAI reference – to shorten code like
GET_TEAM(kPlayer.getTeam()).
Similar situation, by the way, with CvInfo ids in function signatures. That said, the
CvInfo classes lack getID functions, which aren't necessarily easy to add.
The life cycle of CvPlayer and All serializable classes are also reusable, i.e. they have reset
CvTeam can't really be changed functions that return the instance to a blank state. For CvPlayer
because the EXE is involved. I'll and CvTeam, the life cycle of an instance plays out as follows:
just document how it works on the
19 instances (MAX_PLAYERS) are created as soon as the mod
right.
starts loading: The EXE calls CvGlobals::init, which calls the
initStatics functions, which allocate the player and team
arrays, call the CvPlayer and CvTeam constructors and assign
the array index as the player or team id between 0 and 18.
The constructors allocate memory for array data members. (Not
for all of them; I won't bother to describe that in detail because
advc.enum implements lazy allocation for all member arrays.)
reset and AI_reset are called from the base constructors and
call uninit and AI_uninit – which get mostly obsoleted by
advc.enum. The reset functions then initialize most data
members to some blank value, usually 0 or -1.
While setting up a new game (e.g. Custom Game screen),
CvInitCore may call some player and team functions, e.g.
CvPlayer::updateHuman.
When a new game is started, init gets called from the EXE,
which calls reset once more, properly initializes the data
members, in particular sets the alive status (and e.g.
CvPlayer::init processes leader traits) and calls AI_init.
The final initialization steps only happen for players and teams
alive – once the EXE calls CvGame::setInitialItems.
When the game is saved, the EXE calls the virtual and
overridden write function of the derived class, which calls the
87
write function of the base class. Likewise, when loading a
game, the EXE calls the read functions. Before reading from
the byte stream provided by the EXE, reset and AI_reset are
called.
When returning to the opening menu, all 19 instances are
reset.
Only when exiting to the desktop, destructors are called, which
free any dynamic memory, either through the uninit function or
directly. (advc.enum takes over most of the memory
managment.)
Rationale My best guess as to why the player and team instances are created upfront and
reused is that the original developers wanted to store information about slot and team
assignment in those instances during the setup of a new game. Not a good reason I
think, but there's no changing it now.
Tbd. Perhaps at least the interaction between base class and derived class could be
straightened out a bit. Also, the reset call from init is mostly unnecessary (only the
!bConstructorCall branch needs to be executed).
See also 003q refactors CvPlayer::init and its subroutines.
Cities, units and groups are still CvCity, CvUnit and CvSelectionGroup have the same functions
managed by FFreeListTrashArray as CvPlayer and CvTeam for initialization and cleanup, but their
as described on the right. (I'm life cycle is quite different. In particular, they exist only during a
describing it in some detail running game. All instances are stored as elements of
because that design pattern is FFreeListThrashArray (short: FLTA) instances owned by
alien to me.) I've merged the CvPlayer instances. (A comment in that class says “Firaxis
reset functions of CvCity(AI) and Game Engine”, so I suppose that's what the initial “F” stands
CvUnit(AI) into the init functions for.) The FLTA class is responsible for allocating, deallocating
and made init a virtual function and serializing its elements.
overridden by the derived AI The creation of a city, unit or group is always initiated from within
classes. the DLL. CvPlayer provides factory functions initUnit,
initCity and addSelectionGroup, which in turn call
FLTA::add. add calls the respective default constructor, which
calls reset functions for a blank state.
add also stores a pointer to the element and stores an id at the
element by calling its setID function. FLTA::getAt can map
that id very effiently to the element pointer. The id is only
guaranteed to be unique within the given FLTA. As a globally
unique id, the IDInfo struct is used (most importantly in
serialized CLLinkLists), which couples the FLTA-internal id with
the id of the player that owns the FLTA. Lookup of an IDInfo
happens through e.g. getCity (CvGameCoreUtils) via
CvPlayer::getCity.
Once add returns, the factory function (or, in the case of
CvSelectionGroup: CvUnit::joinGroup) calls init on the
blank instance, providing some crucial data such as plot
coordinates.
The destruction of a unit, city or group gets initiated through a
kill call on that instance. kill calls a delete... helper function
on CvPlayer (deleteSelectionGroup, deleteUnit,
deleteCity), which calls removeAt on the FLTA. The FLTA calls
88
the element's destructors, which call uninit and AI_uninit.
Finally, the FLTA removes the element pointer from its internal
array.
When saving or loading, CvPlayer calls the write or read
functions of its FLTAs, and those functions call the write and
read functions of the elements stored in the FLTA. The element
functions call reset/ AI_reset before reading data from the
byte stream.
When exiting to the opening menu or desktop,
CvPlayer::uninit calls FLTA::uninit, removing all elements.
Rationale Cities, units and groups don't need to be reusable, so there is no need for reset
functions. I would've liked to also merge the init functions into the constructors, but
FLTA requires a default constructor. A virtual init function is consistent with the virtual
read and write functions and avoids calling the init function of the derived class
from the base class (which isn't how inheritance is supposed to work). I haven't made
the same changes for CvSelectionGroup because CvSelectionGroup::reset is
called from the EXE (DLL export) and I don't know under which circumstances that
happens.
See also See advc.agent about the player and team count being hardcoded (and how that could
be changed).
billw2015 has experimented with replacing the FLTA with a hash map and reported
inconclusive results when it came to performance. Git issue
Removed the unused sibling class and merged The FLTA (see above) is implemented as a
FLTA with its base class. Moved all code that header-only class derived from an abstract base
calls functions of the template argument into an class. The code base includes an unused class
implementation file with explicit instantiations for FFreeListArray derived from the same base class
all template arguments used in the game core as FLTA. All those classes take a type parameter,
code. Added an optional second template which has to be a concrete serializable class with
parameter so that the first parameter can be getID and setID functions. For the three FLTA
instantiated with an abstract base class (CvUnit, data members of CvPlayer, the type parameters
CvCity, CvSelectionGroup) and the second with a are CvUnitAI, CvCityAI and CvSelectionGroupAI.
concrete derived class (CvUnitAI, CvCityAI,
CvSelectionGroupAI). The FLTA functions for
iteration (beginIter, nextIter, getAt) then
return a pointer to an abstract (non-AI) instance
and counterparts AI_beginIter, AI_nextIter
and AI_getAt return a pointer to an AI instance.
See also Comments in FFreeListTrashArray.h
Caveman2Cosmos also merges FLTA with its base class: Git commit
Rationale The problem with the Firaxis design is that all files that iterate over an FLTA need to
include the header file that defines the template argument, e.g. CvCityAI.h, –
because FLTA::getAt calls getID on the template argument and the implementation
of getAt gets included as part of the FLTA header. More abstractly speaking, I think
the root of the problem is that FLTA is more closely coupled with its elements than
container classes normally are. That doesn't necessarily make it a bad design; the
problem with header inclusions can be solved by moving the getAt implementation
(which is too complex to be inlined anyway) out of the FLTA header. (Which requires
explicit instantiations, but writing those really doesn't bother me.)
The remaining dependency problem is the result of FLTA working only with types that it
89
can instantiate and the AI classes being derived from abstract base classes. In BtS,
FLTA<CvUnitAI>::getAt returns a CvUnitAI*. Non-AI code can't implicitly cast that
to a CvUnit* without including CvUnitAI.h. Adding a second type parameter to FLTA
is a somewhat clumsy solution (that also involves explicit casts in the FLTA header),
but at least it encapsulates the problem and allows for clean client code.
I've merged FLTA with its base class mostly to make the changes above easier to
implement. The virtual functions weren't suitable for inlining anyway, so performance
wasn't a rationale. That said, removing the FLTA header dependencies has allowed me
to inline all the iteration wrapper functions at CvPlayer, CvGame (FLTA<CvDeal>) and
CvMap (FLTA<CvArea>), e.g. CvPlayer::nextUnit.
Tbd. I feel that it should be possible to implement the getAt function without any
conditionals; or perhaps a more narrow function that can replace most of the getAt
calls. Could the nextIter function be inlined?
If CvUnitAI is going to have derived classes (see Tbd. higher up), then a class
CvUnitList should be derived from FLTA<CvUnit,CvUnitAI> with a factory function
add(DomainTypes) that calls a protected function FLTA::add(AITypes*) to insert
the newly created element. And CvUnitList::add(void) should FAssert(false).
That way, FLTA can maintain full ownership of its elements despite both template
parameters being abstract classes.
In CvUnit.cpp, I've replaced any getUnitInfo m_pUnitInfo gets accessed quite frequently and
calls with direct accesses to it's usually done without a getUnitInfo call.
CvUnit::m_pUnitInfo.
But in CvUnitAI.cpp, I've replaced all direct
m_pUnitInfo accesses with getUnitInfo calls.
Rationale This way, it'll be easier to move CvUnitAI code into component classes that aren't
derived from CvUnit. (No concrete plans for that.)
90
causes problems.
or simply (CvPlayerAI::AI_bonusTrade):
for (iI = 0; iI < GC.getNumUnitInfos(); iI++)
91
BtS, then e.g. leader traits would be “civ effects” and wonder abilities like Notre
Dame's +2 happiness in the owner's cities would also be “civ effects”.
92
“We the People” Git issue that proposes to use enum types in signatures where
possible (not specifically in the CvInfo classes – anywhere). Should take care of that
through macros that define enum maps and their (typesafe) accessor functions, see
advc.003t.
Rationale Mainly to make the Python calls – many of them callbacks that are unused on the
Python side – less visible. They really clutter the DLL code in BtS.
See also 003 similarly moves some logging code into a separate class (CvDLLLogger).
Caveman2Cosmos instead takes the approach of making the generic DLL-to-Python
interface more compact. Git commit (perhaps not the only one)
C2C also has started to get rid of the isNone functions by letting C++ functions return
NULL instead of dummy objects. This removes a lot of clutter on the C++ side, but also
requires some changes to Python code (replacing all isNone calls with built in is
93
None). Git commit (again, there may be more)
And it seems that C2C handles the int-enum casts between DLL and Python more
intelligently: Git pull request
By default, CvPythonCaller asserts that the A Python call fails if the target function doesn't
Python function was successfully called. exist in Python or if the call parameters don't
match the Python signature. This can be normal
Found out about two (unused) missing Python
in the case of map scripts. Normally, it's a bug
functions this way; removed the one
and the BtS DLL code checks for such bugs only
(doHeadquarters) on the DLL side, added the
sometimes.
other (cannotSpreadReligion) on the Python
side. Copied CvGameInterface.py into the mod CvGameInterface.py is mostly (but not entirely)
in order to add cannotSpreadReligion. obsoleted by BUG.
Instead of CvGlobals, CvPythonCaller handles The callback guards are defined in
the caching of the callback guards. This is now PythonCallbackDefines.xml and all set to 0,
done through an array of enum values. meaning that the DLL should always skip the
The guards for Python events are now handled respective Python call in order to save time.
by the CvDllPythonEvents class. Example: USE_CAN_TRAIN_CALLBACK=0 disables
the Python call to CvGameInterface.canTrain
Added some more callback guards – though the in CvCity::canTrain.
gains in performance are negligible (1% or so).
Python modders that want a guarded Python call
to happen (despite a slight performance penalty),
can disable the guard through the XML file.
On the DLL side, each guard is stored as an
individual boolean data member of CvGlobals.
K-Mod has added several more callback guards.
See also 003b uses the same technique for GlobalDefines cached by CvGlobals.
Rationale Part of the effort to move the Python stuff out of sight. I don't think I'll ever want one of
those guarded functions to be called – they're for modders who want to change the
game rules and aren't able to recompile the DLL.
AdvCiv K-Mod
Moved the computation of game score and K-Mod had already moved the pillage gold and
capture gold from CvGameUtils.py to the DLL level-up threshold computation from Python to
(CvPlayer::doCaptureGold). CvUnit::pillage and CvUnit::experienceNeeded.
94
advc.enum Enum map classes, traits for global enum types and related code
Rationale Memory optimization (for improved CPU cache performance); improved code
readability, extensibility. Well, the enum map and traits code is highly reliant on
templates and as such far from being easy to read; but the code that employs enum
maps replaces a great volume of error-prone boilerplate dealing with naked arrays.
In a perfect (object-oriented) world, much of the two-dimensional data would be
handled by component classes. For example, a class that represents all knowledge
that one (AI) team has about another team instead of a bunch of data structures that
map a team id to one particular statistic about that team.
Credits The enum map classes were originally based on Nightinggale's EnumMap class in the
“We the People” mod (WtP). By now (Jan 2022), both WtP and AdvCiv have largely
rewritten their enum map classes, and the results don't have very much in common.
See also 003t integrates enum maps with XML loading code.
AdvCiv BtS
Use enum maps for storing mappings from one Uses two- and three-dimensional arrays. Memory
or two enum types to some other – usually for those arrays is, in most cases, allocated in
integral – type. This concerns multi-dimensional constructors or functions called from there.
data loaded from XML, class members that store (Notable exception: CvPlayer and CvTeam
the (serializable) game state and, at times, local allocate their arrays upon being set to “alive”
variables and function arguments. status.) Most of the arrays have serialization
code in one of the read/ write functions, and
One type of enum map, ListEnumMap, keeps a
are accessed in get, set and change functions
list (implemented as a resizable array) of only
those key-value pairs whose value differs from a with assertions that check the array bounds.
default value. The default value is set at compile
time through a template parameter (as in WtP).
This data structure allows for fast iteration over
the non-default data, and, to this end, there are
macros FOR_EACH_NON_DEFAULT_PAIR and
FOR_EACH_NON_DEFAULT_KEY. Finding the value
for a (single) given key involves traversing the list
of pairs, so that operation is not super fast.
Clarification: ListEnumMap is generally allowed to
store default-valued pairs as well, but (since
AdvCiv 1.06) most instances use a MONOTE=true
compile-time parameter that promises not to
change any key from a non-default value to the
default value. Those instances will indeed not
contain any default-valued pairs.
The other essential type of enum map is ArrayEnumMap, which stores a value for every possible
key in a non-resizable array. Lookup (random access) is fast, but large arrays can negatively affect
the performance of the CPU cache. Two optimizations to reduce memory use (both from WtP)
allocate the array lazily upon setting a non-default value, and store boolean values in a bit array.
AdvCiv allows these optimizations to be disabled through template parameters. (Lazy allocation is
counterproductive when non-default values are guaranteed to be stored.) Another WtP optimization
supported by ArrayEnumMap is the use of automatically allocated memory when the array requires
only a few byte. This avoids overhead for dynamic allocation (especially helpful for local variables)
and improves memory locality.
For the list-based approach, I've implemented bit arrays only for the special case of mappings to
95
bool loaded from XML. Mappings to bool can be interpreted as (mathematical) sets, so I've
named the respective enum map type OfflineListEnumSet.
Another WtP optimization, the use of two-byte or single-byte types for storing values of an enum
type, is implemented for all enum map types. Moreover, any (sensible) data type can be specified
for the internal storage of the value type. For example, a map storing the yield rates of a tile can
use int in its public interface and use char internally. Assertions to ensure that the limits of the
internal type aren't exceeded can be enabled through a preprocessor switch.
For three-dimensional data, i.e. mappings from pairs of enum keys to (single) values, there's an
EnumMap2D class that maps the first (outer) key type to (a pointer to) an inner enum map, which in
turn maps the second (inner) key type to the (inner) value type. This is similar to the pre-2022
EnumMap2D class in WtP – but more flexible insofar as ListEnumMap and ArrayEnumMap can be
freely combined for the outer and inner map type.
Often, one of the key types is a yield or commerce type and the value represents a yield or
commerce rate, rate change or percent modifier. In that case, the mapping can be interpreted as
associating an outer key type with a 3- or 4-tuple of yield or commerce statistics small enough to
be encoded in a single (unsigned) int or long long int value. The Enum2IntEncMap class uses
a simple (non-nested) enum map internally (avoiding dynamic allocation of inner enum map
instances) and provides the same interface as EnumMap2D externally.
The subscript operator has been overridden – but only for ArrayEnumMap, so it's generally better to
stick to the get, set and arithmetic functions so that an ArrayEnumMap can be easily replaced with a
ListEnumMap.
See also Comments in EnumMap.h.
(cont.)
C2C has a class IDValueMap that fulfills a similar role as my ListEnumMap.
IDValueMap uses std::pair internally. I use two separate arrays for keys and values
(but had used a single array of std::pair in an earlier version of my code; I don't
think there's a significant difference in performance).
C2C also stores some boolean arrays as simple lists (vectors); SVN revision.
Replacing CvArea member arrays with EnumMaps has resulted in a speed-up of
almost 5%, in part, because change 030 tends to increase the number of separate
water areas on the map.
For CvPlot, WtP uses an additional data structure called “RevealedPlotData”. The
premise is that the route and improvement revealed to a team are “usually used
together.” I think that's not really true for the AdvCiv code. Routes are important for
movement, improvements for tile yields; there isn't much code that deals with both.
karadoc had started (slowly) to replace some arrays with vectors: Git commit
advc.fract: The ScaledNum class is fully supported as a value type for enum maps.
(This CFC post by Nightinggale advising me on how to integrate ScaledNum with his
EnumMap class is outdated.)
CFC thread with a question about ListEnumMap
Tbd. CvPlayerAI, CvCityAI and essentially all CvInfo classes except those defined in
CvInfo_Building.h still use arrays instead of enum maps. Just haven't gotten around
to refactoring them. Searching the code base for all occurrences of “new int” or “new
bool” should identify all classes that still need work.
I had implemented a ListAndArrayEnumMap class storing data redundantly in order to
maximize the speed of both random access and iteration, but I haven't bothered to
reimplement it after merging my CvInfoEnumMap hierarchy (aimed only at data from
XML) with the “We the People” EnumMap class. Could still bring this class back if a
use arises – but I doubt that it will. The latest source code is here: GitHub
96
Rationale Apart from sparse data loaded from XML, list-based enum maps are important for per-
(cont. – civ data stored at CvPlot. Some of that data, e.g. data about nearby cities, gets
list-based allocated for a large portion of plots, but is used only for a small number of players.
maps) When the civ count is increased beyond 18, the unused memory allocated by the
(array-based) WtP enum map (or the BtS arrays) seemed to have a significant impact
on cache performance. In a test with the Earth18 scenario, a DLL allowing 31 civs (i.e.
32 players including the Barbarians) had about 28% longer turn times than one
allowing 18 civs if only WtP enum maps were used for the CvPlot member data. After
converting some of the enum maps to ListEnumMap (to a precursor named
“SparseEnumMap” – to be exact), this performance penalty for allowing (but not using)
thirteen additional civs decreased to 9.5%. Earlier tests suggest that the performance
penalty is smaller on Huge random maps (which have smaller dimensions than
Earth18); it was 8% the last time I tested it and might be as low as 5% now, which
would mean that AdvCiv can switch to a 31-civ DLL whenever (or if ever) I'm
comfortable with breaking savegame compatibility.
See also 056 facilitates tests like the one with Earth18: scenarios no longer need to contain data
(cont.) about every civ id that the DLL recognizes.
advc.agent has also helped reduce the performance penalty for unused civs.
Tbd. (cont.) Experiment with some other per-civ data. That said, no class looks particularly
promising for this. CvArea has a lot of per-civ data, but most of it doesn't get allocated
for uninhabited areas. Perhaps some more CvPlot data – through the preprocessor,
we can use an array-based enum map when the civ limit is 18 and a list-based one
when it's (considerably) higher.
The enum map classes are based on a type traits system that associates most of the global enum
types (CvEnums.h) with information about its (maximal) length and with the smallest (signed)
integer type that can safely store all values of the enum type.
The enum traits are mostly generated by the preprocessor based on type lists in a new header
CvEnumMacros.h. That header also provides increment operators for most enum types and several
macros described below.
A header for arithmetic type traits treats (global) enum types and ScaledNum as arithmetic and
thus allows the enum map classes to apply simple arithmetic operations on enum and ScaledNum
values.
AdvCiv WtP (in the year 2021)
For enum types whose length is only known at To determine the internal array size (and the
runtime, the integer type is hardcoded, but number of bytes to store per value when
assertions after XML loading verify that those mapping to an enum type), the WtP EnumMap
integer types are indeed sufficiently large. obtains the number of enum values from a
NUM_..._TYPES enumerator at the end of every
supported enum type. Those enumerators are
generated by an external Perl script that parses
the “info” XML files. As a result, adding any type
elements to an XML file requires the game core
DLL to be recompiled. For enum types with a
dynamic range, the length needs to be
hardcoded by defining an ArrayLength function
and a byte size (1 or 2 bytes).
Rationale I don't want to adopt the Perl code generator. It adds another dependency to the build
environment (could port the script to Python to avoid that I guess) and requires a
special DLL to be deployed for XML modders who are unable to recompile the DLL.
My approach is more portable insofar – although not as powerful: the preprocessor
97
isn't as flexible as an external script and length information known at compile time
allows for better code optimization.
My enum map classes serialize data in (mostly) Savegame writer class that uses a compact
the same compact (binary) format that they use annotated format – for persistent enum maps and
internally. They can read data in various (less all other persistent data.
compact) formats that BtS uses for serializing
arrays.
See also Nightinggale on the WtP savegame format: CFC link
WtP wiki: Savegame format
Rationale Getting the deserialization functions for the BtS format right was a lot of work. If I ever
change my serialization functions, it'll again be a lot of work to maintain compatibility
with my current format. An annotated format really is the saner approach, but adopting
the WtP format is too big a task for now – seeing that it concerns not just enum maps
but all persistent data.
Tbd. If AdvCiv moves beyond version 1.0x, then I'll want to break savegame compatibility
eventually, and, at that point, adopting the WtP format should be more feasible.
Macro FOR_EACH_ENUM added for iterating over Macro FOREACH that gets used mostly in
an enum type. Takes an XML type name as its conjunction with EnumMap. (I don't think it's
only parameter and defines a loop counter supposed to replace all loops over enum types in
variable eLoop{Name}. the WtP DLL code base.) Those loops have the
following form in BtS:
For cases where “eLoop{Name}” is too long
because the loop variable gets referenced for (int i = 0; i < GC.getNumBuildingInfos();
i++)
numerous times, I've added a variant {
FOR_EACH_ENUM2 that takes a variable name as a BuildingTypes eBuilding = (BuildingTypes)i;
second parameter.
Added FOR_EACH_ENUM_REV for cases when
reversing the order will speed up the search for a
particular element.
Credits It's mostly Nightinggale's work; see this WtP Git issue.
Tbd. Parts of CvGame, CvGameTextMgr, CvPlayerAI, CvUnitAI don't use the macro yet.
Rationale/ As for the lengthy variable name:
Tbd.
A nondescript name like “eBuilding” has a good chance of clashing with a variable
name in an enclosing scope (no Zc:forScope option in MSVC03). Enclosing the loop
in curly braces would be possible through a pair of macros (as Nightinggale had
contemplated), and that would also allow the macro to define a reference to an info
object; e.g.
FOR_EACH_INFO_START(Building, LoopBuilding)
if (eLoopBuilding == ...
kLoopBuilding.get...
END_FOR_EACH
Or, optionally with braces. VS IntelliSense can handle such macros, but they're still
cumbersome, and always fetching the CvInfo instance can lead to unnecessary cache
misses when only the enum IDs are needed in the body of loop.
Note that it's impossible to define a CvInfo reference before the body of a loop
because a reference can't be reassigned. Even exposing the vectors stored at
CvGlobals wouldn't change that.
Would've been nicer to name the macro “ENUM_EACH” perhaps, i.e. using “enum” as
a verb, and then the enum map macro “ENUM_EACH_NON_DEFAULT_PAIR” – but
98
I'm not going to change that now.
See also 003s defines macros for iterating over lists. All those macros are listed in cpp.hint to
fix problems with IntelliSense.
advc.agent: The AgentIterator classes should usually be preferred over
FOR_EACH_ENUM when looping over players and teams.
Defined macros LOOP_INFO(TypeName), SET_LOOP_INFO(TypeName) for obtaining or defining a
reference to an XML info object in the body of a FOR_EACH_ENUM loop. These macros call
preprocessor-generated functions CvGlobal::getLoopInfo that don't check array bounds (not
even in assert builds). Examples:
• SET_LOOP_INFO(Building); instead of:
CvBuildingInfo const& kLoopBuilding = GC.getInfo(eLoopBuilding);
• LOOP_INFO(Building).getBuildingClassType(); instead of:
GC.getInfo(eLoopBuilding).getBuildingClassType();
Commented out for now.
Rationale The array-bounds assertions are unnecessary when looping over all instances with
FOR_EACH_ENUM, and they get in the way of /Ob1-inlining in assert builds (which isn't a
big concern, but still). Perhaps more importantly, the SET_LOOP_INFO macro saves the
user from having to type the enum name three times.
Most FOR_EACH_ENUM loops in the codebase don't define a CvInfo reference, but many
of those loops obtain such a reference from CvGlobals in one or two places. So it
wouldn't be much trouble to deploy the SET_LOOP_INFO macro everywhere it makes
sense, but doing the same for LOOP_INFO seems like too much work. I feel it would be
a bit inconsistent to remove the array-bounds checks only from loops where a CvInfo
reference is explicitly stored in a variable. Therefore, I'm not using either macro.
FOR_EACH_ENUM_RAND macro that goes through the enum types in a random order.
Rationale Rarely done in the BtS code, but should perhaps be done more often. I'm pretty sure
that there are some loops in the AI code where the fixed order causes a bias toward
low enum values. With this macro, shuffling takes practically no extra implementation
effort. (Though shuffling isn't free in terms of computing time of course.)
See also advc.agent: For players and teams, AgentIterator has a randomization parameter.
FAssertEnumBounds macro that takes a single enum value as parameter and asserts that it is
nonnegative and less than the enum length. FAssertInfoEnum is the same except that it also
allows -1. Both based on enum type traits.
Rationale One step beyond the FAssertBounds macro (see 006f). I don't use it very widely
because the CvInfo classes mostly use integer indices (they shouldn't; see Tbd. under
003x) and because many bounds assertions have been made unnecessary by enum
maps. And for player and team arrays, it's not clear enough whether the upper bound
should include the Barbarians.
See also 006j applies FAssertInfoEnum to simple (non-nested) enum elements loaded from
XML. (But not when the DLL stores those elements as int; again, see 003x.)
AdvCiv BtS/WtP
New (header-only) class CityPlotIterator. Usage WtP uses the FOR_EACH macro for those loops;
example: BtS:
for (CityPlotIter it(kCity); it.hasNext(); for (int iI = 0; iI < NUM_CITY_PLOTS; iI++)
++it) {
{ CvPlot* pPlot = plotCity(kCity.getX(),
CvPlot const& kPlot = *it; kCity.getY(), iPlot);
CityPlotTypes const ePlot = it.currID(); if (pPlot != NULL)
99
// ... {
} // ...
}
Can also take a CvPlot parameter and }
bIncludeCenter=false to exclude the center
To exclude the center, iI==CITY_HOME_PLOT is
tile. And there are derived classes for excluding
unworked or unworkable tiles and randomizing checked. The efficient way to do that is in the
the order of traversal. initialization of iI (as CITY_HOME_PLOT is 0); BtS
usually checks it in the body of the loop instead.
The enum type “CityPlotTypes” is also new.
Replaced all the BtS-style loops with
CityPlotIterators and a few with FOR_EACH_ENUM
(when NULL plots aren't supposed to be skipped).
See also The syntax is consistent with advc.agent; see rationales there.
Fairly detailed comments in CityPlotIter.h.
advc.plotr: An iterator for square areas of tiles.
Rationale Can't beat the speed of the BtS code, or even match it. The iteration overhead is about
two times worse than in BtS, and I think that's the best one can do with an iterator.
Speed matters because these loops occur very frequently, but avoiding the NULL check
(in the user's code) and not having to remember three unrelated identifiers
(NUM_CITY_PLOTS, plotCity, CITY_HOME_PLOT) is worth the very slight performance
penalty.
NearbyCityIter for iterating over all cities that Explicitly goes through the city radius of the given
have a given tile in their radius. Implemented as tile and checks for cities. This is done in about 10
a wrapper around CityPlotIter (because such places, e.g. in CvPlot::setFeature:
cities can only exist within the city radius around
for (iI = 0; iI < NUM_CITY_PLOTS; ++iI)
the given tile). {
for (NearbyCityIter itCity(*this); pLoopPlot = plotCity(getX(), getY(), iI);
itCity.hasNext(); ++itCity) if (pLoopPlot != NULL)
{ {
itCity->updateSurroundingHealthHappiness(); pLoopCity = pLoopPlot->getPlotCity();
} if (pLoopCity != NULL)
{
pLoopCity->updateFeatureHealth();
pLoopCity->updateFeatureHappiness();
}
}
}
Rationale Easier to read. Also to make it easier to implement a dynamic city radius. To that end,
it's helpful to reduce the number of city radius loops around non-city tiles (and to avoid
using the NUM_CITY_PLOTS compile-time constant). Loop around city tiles are easy to
handle for mods with a dynamic city radius – can query the CvCity instance for its
radius. Specifically, keldath was interested in implementing dynamic city radii in his
Dawn of the Overlords mod.
The “nearby” in the name is not as precise as I'd like, but more specific terms like
“encompassing” or “reaching” are too cumbersome or puzzling.
Enum type PlotNumTypes added for the CvPlot CvMap::plotNum returns an int and
ids computed by CvMap::plotNum. plotByIndex takes an int argument.
Stored as __int16 in enum maps unless I don't think WtP allows plot ids in EnumMap.
MAX_CIV_PLAYERS has been increased beyond
Players have been able to start games with
31; in that case, __int32 is used. The upper limit 200x200 tiles and probably more, but no one
of __int16 is 32 768, so that's now the map size finishes those games. Apart from unplayable
limit (e.g. 256x128 or 181x181) for DLLs allowing experiments and the C2C Ultimate Earth Map,
100
fewer than 32 civs. the biggest scenario that I'm aware of is the
Gigantic Accurate Earth Map with 232x112 plots.
Huge maps have ca. 50% more tiles than Large
maps. If that progression is continued, then two
sizes beyond Huge would still have fewer than
25000 plots. SmartMap has a 512x512 setting,
but it's reportedly not really playable.
Tbd. CvMap::plotByIndex still takes an int argument. If I change that, then all loops that
traverse the entire map will have to be revised. For loops that only deal with plot ids
(rare), FOR_EACH_ENUM(PlotNum) will be adequate; most loops need to go through the
CvPlot instances; an iterator should be written for that. “MapIter” could be
misunderstood; “MapGridIter”? Some filters (land/ water)? Should be tagged with
advc.plotr.
Rationale For now, the enum type is mainly for enum maps, specifically for their use in the
starting position calculation (027).
AdvCiv BtS
Functions There is a uniquely named CvGlobals::
CvGlobals::get{TypeName}Info(TypeName) get...Info function for every CvInfo type.
replaced with overloaded functions
CvGlobals::getInfo(TypeName). Except for
XML info types that have no associated enum
type. The old get...Info functions take an int
parameter now, i.e. can now handle a type cast
for the caller – and are largely unused.
Rationale To shorten the info accessor calls. It was easy enough to generate the getInfo
functions from the enum list macros and to change the four-digit number of call
locations through automated search and replace – using, for future reference, this
regular expression in Notepad++:
GC\.get(...|....|.....|......|.......|........|.........|..........|..
.........|............|.............|..............|...............|..
..............)Info\(
Since the function are generated by macros (see below), it's not much trouble to keep
the old ones around. Makes it easier for mod-modders to merge code from other
mods. And if I'm going to keep them around, I might as well give them a purpose as
wrappers for type casts from int.
Tbd. Should perhaps add enum types for the few info classes that are missing one so that
those can also be accessed through a getInfo function. I think C2C has done that in
early 2022 or late 2021.
The overloaded getInfo functions and other There were several hundred of lines of repetitive
parts of the CvGlobals class are generated by code.
the preprocessor based on the type lists in
CvEnumMacros.h.
Rationale I was a bit worried about debugging (can't set a breakpoint in a function generated by
the preprocessor), but I think the function definitions I removed were so simple that
there should be no need to step into them.
Global comparison operator functions are Comparisons between enum types aren't type-
declared for certain dangerous combinations of safe in C++03, and there is nothing in the BtS
enum types, in particular PlayerTypes and code to detect errors like if(kPlayer.getID()
TeamTypes. No definition is provided for these == eTeam). Modders seem to have fixed all
operators, so that it's impossible to call them (will errors of this kind over the years, i.e. my
101
result in a linker error). overloaded operators didn't reveal any errors in
BtS code (but several in AdvCiv code).
Rationale A compiler error would be more helpful, but only the linker can tell whether a global
function has any call locations.
Tbd. Should perhaps declare comparison operators for all enum types used in the DLL. I'm
not sure if those thousands of declarations would slow down the compiler though.
It would be nice to get rid of most of the enum type comparisons, e.g. by writing
if(kPlayer.isTeam(eTeam)) in the example above. Inlining such an isTeam function
(without whole-program optimization) would require CvTeam.h and CvPlayer.h to
include each other.
CvPlayer::operator==(PlayerTypes) etc. is also worth considering.
See also It's easy to get the NO_... enumerators and NULL mixed up, and such an error can go
unnoticed for quite some time. I've written code for prohibiting all equality tests
between integers and enums (commented out in CvEnums.h), but, currently, this would
require too many explicit casts. Maybe once the AgentIterator classes are used more
widely (see advc.agent) and once the CvInfo classes use enum types instead of
integers (see 003x) when possible.
The “We the People” mod makes all int and enum comparisons type-safe through
static assertions: Git commit
I don't think the static assertions can work with my approach of forbidding only
(certain) enum-enum comparisons; one of the parameters in the comparison would
have to be a template type.
Turned the bitmasks that were defined through the preprocessor in AI_Defines.h into enums with
overloaded bitwise operators and renamed the header to “AIStrategies.h”. I've named the enum
for the victory strategies “AIVictoryStage” and renamed the AI_...VictoryStrategy functions
(CvPlayerAI, CvTeamAI) accordingly. Also turned some bitmask definitions in CvDefines.h into
enums.
Rationale The two types of strategy defines were easy to confuse; type-safety was badly
needed. The name change is also intended to make the strategy types more distinct.
The old function names were also very long. C++11 has strongly typed enums, but in
MSVC03, overloading the bitwise operators seems to be the best one can do. (I think
it's fine.)
See also I've found three bugs through this change, listed somewhere under 001.
Tbd. There are some other uses of bitmasks in the codebase that could benefit from the
same treatment. Also, bitmasks could be used in additional places, in particular to
shorten parameter list, for example of the BestDefender function. C2C does that too
(Git commit).
advc.agent Iterator classes for looping over “agents” – i.e. players and teams
Tbd. Currently, the caches at CvAgents are only updated under very specific
circumstances, e.g. when a new colony is created. Will probably have to use more
generic update functions (e.g. whenever the “alive” status of an agent changes) to
make sure that the caches are up to date during game initialization. So far, I've
refrained from using agent iterators in any initialization code, erring on the side of
caution. See also comment in AgentIterator.h.
AdvCiv BtS
AgentIterator class with parameters for frequently A loop over all non-minor, non-Barbarian teams
needed sequences of agents. For example: alive looks like this (CvGame::testVictory):
102
for (TeamIter<MAJOR_CIV> it; it.hasNext(); ++it) for (int iI = 0; iI < MAX_CIV_TEAMS; iI++)
{ {
CvTeam& kLoopTeam = *it; CvTeam& kLoopTeam = GET_TEAM((TeamTypes)iI);
// … if (kLoopTeam.isAlive())
} {
if (!(kLoopTeam.isMinorCiv()))
(where “MAJOR_CIV” means non-Barbarian, {
// …
non-minor civ alive) }
}
}
Rationale The iterator syntax is shorter and less error-prone. Range-based loops would be even
shorter, but we don't have ranges in C++03. The available template parameters also
steer programmers toward sensible restrictions. E.g. excluding minor civs from a loop
but not Barbarians is suspicious, or counting a player's vassals but not its teammates.
Efficiency:
For MAX_CIV_PLAYERS=18, the BtS loops are actually very efficient, even if half of the
players aren't used. I guess CPU branch prediction works very well for isAlive and
other commonly used checks. Loops with small bodies also get partly unrolled by the
compiler (into a for i=0 to 3 loop with six repetitions in its body). However, when
MAX_CIV_PLAYERS is increased, the BtS loops become somewhat inefficient when
most players remain unused. That's one reason why 8-player games run more slowly
with a 48-civ DLL than with an 18-civ DLL (another reason is that a higher
MAX_CIV_PLAYERS value causes memory to be allocated for the unused players).
Excluding agents that have never been alive from most of the loops is a step toward
distributing only a single (31-civ) DLL. In any case, it's important that the agent
iterators are efficient as agent loops occur very frequently throughout the code base.
I use two sets of enum values to specify predicates that the agents need to satisfy. The
first says something about the status of the agent, e.g. whether it is alive, a major civ, a
vassal; the second enum requires a particular relation with a second agent, e.g. being
on the same team, not having the same master or having met. Bitmasks would be
more flexible, allowing arbitrary logical operators, but I don't think that much flexibility
is actually needed: The frequently needed predicates are mostly mutually exclusive.
Bitmasks would also make a (highly) efficient implementation more difficult, and I don't
103
want to use bitwise logic all the time in loop headers.
Not every combination of the two predicates should correspond to a cached sequence
of agents. It might be fastest to cache most of them (hard to say), but implementing
cache updates at the proper code locations is clearly not always worth the
programming effort. Therefore, there's a third enum that lists the available cached
sequences, e.g. CIVS_ALIVE (all non-Barbarians players and teams currently alive).
The task of an agent iterator is to map the given predicate(s) to a cached sequence
and to check any predicates not implied by the sequence on the fly; for example, if the
predicate is FREE_MAJOR_CIV and the cached sequence MAJOR_CIV, then isAVassal
needs to be checked for each agent in the sequence as the iterator advances. The
iterator also hides the available cache data from the user.
Syntactically, I would have preferred to take the predicates as constructor arguments.
I've implemented that too (Git commit), but it turned out to be a bit slower than I'd like.
With the predicates as template parameters, much of the logic can be resolved at
compile time. In particular, when a cached sequence matches the predicates exactly,
the optimized assembly is essentially equivalent to an iteration over a vector.
I've run some performance tests (AgentIteratorTest.cpp) using the TSC profiler
(see 003o): For example, in a game with 8 players and up to 18 allowed, a loop over
all major teams alive took 104 CPU cycles using BtS code, 106 cycles using an agent
iterator and 96 cycles (arguably the fastest possible) directly using a vector. A loop
over all players alive took 160 cycles with BtS code, 119 with an agent iterator and 102
with a (raw) vector. All members of a team: 124 (BtS), 68 (iterator), 52 (vector). For
sequences that aren't (fully) cached, the iterator still performs a bit worse than the BtS
code. Going through all free major teams alive took 384 cycles compared with 100 in
BtS. One reason for this is that the iterator code can't be inline-expanded in this case
(otherwise, header inclusions would get messed up), but that should not be a problem
in final-release builds with whole-program optimization. If there's still a significant
difference in performance, more cached sequences can be added. When up to 48 civs
are allowed and only 8 used, the iterators outperform the BtS code in most cases, e.g
167 vs. 406 cycles for players alive. I'm not sure why the maximal number of civs
affects the performance of the iterators at all; must be some side-effect.
As for the iterator interface, I've stuck to the C++ idiom of treating iterators as pointers,
which is nicely compact, but I use a Java-style hasNext function rather than a
comparison with some end-of-sequence constant.
See also 056 allows scenario files to be read that were created with a DLL allowing fewer civs
than the current DLL.
advc.enum reduces the memory allocated for unused players.
In the process of converting BtS/K-Mod loops to agent iterators, I've made minor functional
changes that aren't always marked in the code. Most of these changes concern the treatment of
Barbarians, minor civs, dead agents or unmet agents.
104
AdvCiv BtS
Example: BtS style:
for (SquareIter it(kCenter, iRange, false); for (int iDX = -iRange; iDX <= iRange; iDX++)
it.hasNext(); ++it) {
{ for (int iDY = -iRange; iDY <= iRange; iDY++)
CvPlot& kPlot = *it; {
// ... if (iDX == 0 && iDY == 0)
} continue;
CvPlot* pPlot = plotXY(kCenter.getX(),
This will traverse the non-NULL tiles in a square kCenter.getY(), iDX, iDY);
if (pPlot == NULL)
of length 2*iRange+1 centered at a given tile or continue;
unit with the exception of the center itself // …
(bIncludeCenter=false). The order of traversal
The 0-check can take different forms, e.g. pPlot
is a spiral, i.e. tiles at a step distance of i are
== &kCenter.
traversed before those at a step distance of i+1.
Since the movement radius of a unit is a square
There is also a “PlotCircleIter” that uses the
(“step distance” metric), these loops are quite
same algorithm but skips tiles at the corners of
frequent in the Unit AI code. For unit movement,
the square, returning only tiles within a plot
the center (current location of the unit) is usually
distance of at most iRange. (For iRange=2, this
disregarded.
makes PlotCircleIter a less efficient
implementation of CityPlotIter.)
Almost all the BtS-style loops over square and
(approximately) circular areas have been
replaced with SquareIter, PlotCircleIter and
CityPlotIter loops.
Rationale Readability mostly; the verbosity of the BtS code also makes it error-prone. (Other
modders had fixed a couple of errors; I didn't find any new ones.)
A more general “plot range” iterator might be neater, but there isn't much code
duplication between SquareIter and CityPlotIter (the algorithms for generating the tile
coordinates are completely different), and they were easier for me to write separately.
The spiral pattern is intended to act as a sensible tie-breaker for argmax computations.
It could, in principle, also speed those computations up, but that would require checks
that cut the evaluation of a tile short when its value can no longer exceed the current
maximum. For the most part, such checks don't exist, but perhaps they could be
added in expensive tile evaluation loops. In terms of overhead, spiral traversal should
not be appreciably slower than scanline traversal. (I haven't profiled it though; it might
be that the memory layout of the CvPlot array favors a scanline.) Starting at the center
has the advantage that the center tile can be skipped without any checks in
subsequent iterations. In any case, having the square range traversal in a single place
will make it easier to optimize if needs be.
Tbd. A parameter for skipping tiles in other areas would be nice to have.
Since the iterators return CvPlot references, it seems that CvPlot& is now more
commonly used overall than CvPlot*. So, I think it's time to change function
parameters to CvPlot const& or CvPlot& when possible.
Iterator over the whole map. See Tbd. under advc.enum.
105
004e: Leads-to info in promotion button help
004g: Misc. tweaks to game text
004h: Highlight full city radius when settler selected
004i: Announce amount of gold stolen by enemy spies
004k: Reorder unit command buttons
004l: Sentry Heal
004m: Default settings for camera distance, FoV, active map layer
004n: Faster scrolling through list of units in a (city) tile
004o: No start-revolution choice on new-civic popup
004p: No commerce breakdown on city screen if slider at 0
004q: Show sum of diplo modifiers in leader hover text
004r: Changes to the announcement of resources revealed by newly acquired tech
004s: Changes to commerce and yield curves on Graphs tab
004t: Option to disable click-on-map exit from city screen
004u: More info in announcements of Great General deaths
004w: Streamlining, omission of misc. help text that wasn't really helpful
004x cancels redundant minimized popups.
004y: Full-screen Sevopedia and other tweaks to 'Pedia
004z: Tweaks to map layers
101 adds help text about occupation and revolts to the Nationality bar (city screen).
120c allows hiding the espionage slider when it's at 0.
251 shows the start turn on the Settings tab when it isn't turn 0.
085 lets the scoreboard expand on mouse-over.
210 adds a few BUG-style alerts.
106: Various changes to on-screen announcements and the replay log
071 adds an option for notifications about first contacts (on-screen message or diplo
popup) to the “Alerts” tab.
151 shows the previous religion or civic in messages about changed civics/ religions.
152 shows currently offered war trades on the Glance tab.
153: Automatically split up human unit groups at certain convenient times
075: Automatically wake units in cargo (at certain convenient times)
047 Tweaks to resource tile help text
048: Combat odds help text (including some changes to ACO)
059 shows health/ happiness effects of features and improvements in tile hover text.
060 suppresses the add-to-spaceship popup.
061 makes the hover text for unit stacks on the main map more compact.
063 shows additional Actual Effects when Alt is held down.
064 adds BULL help text to the Whip button and allows hurry tick marks to be disabled.
064b adds overflow info to the production yield hover on the city screen.
065 removes the “Show Culture Turns” option; always shows culture turns.
106d changes BUG default settings for Civ4lerts and the scoreboard.
kekm.30 adds civ and leader icons to the scoreboard (disabled by default).
066 frees up some space on the Foreign Advisor.
067 overhauls the BUG game clock.
068 lets changes to the BUG options for tech era coloring take effect without a restart.
069: Changes to the PLE component
070 replaces BUG's “Gold Rate Warning” option.
078 allows disabling BUG's GP bars until there is some progress toward a GP.
072 extends the show-deal-turns BUG option a bit.
073 Trade denial hovers from BULL; revises the layout of the “Resources” tab.
074 excludes some “must-be-joking” items from the Trade screen.
077 revises the “Demographics” tab (Info screen).
154: Unit cycling button
088: Key combination for unselecting all units
106
090: Longer FoV slider, more sensitive toward the right end.
091: Score graph sometimes shown when unable to see demographics
092: The size of most elements of the main/ city screen HUD scale with the resolution
092b: Smaller plot indicators (“balloons” for resource and unit icons)
093: More help text when a unit can't be gifted
094: Production decay warnings from BULL
095: Option for wide city bars (not available in K-Mod, not optional in BUG)
096: Some tech tree hover text reflects the current game state
076 revises the player options menu (Ctrl+O).
002f: Changes to city bar icons
011b: Tile hover for partial worker builds
099f: Tile hover for culture on unowned tiles
190: Additions to the Settings tab (Victory screen)
910: Tech hover text shows speed-up from knowing multiple alternative requirements.
106m adjusts the dimensions of the replay screen to the screen resolution.
104m cancels expired peace treaties at the start of a round.
002l deals with sounds being played too many times at once.
172 removes culture rates from the Religion Advisor (because they no longer depend
on the current state religion)
186: Enhanced city bar hover text, mostly from BULL.
188: Tweaks to BUG anger timer on city screen
189: Starvation turns on the city bar
190: Additional info on the Settings tab (Victory screen)
mnai: Detailed civic info for civic buttons on tech tree
653: Hovering in Nuke mode shows the range of the explosion.
Tbd. BULL merge:
Widescreen for Foreign Advisor; coloring of ratios on the Espionage screen (just use
one coloring scheme; no options); some misc. city screen hovers; spaceship
countdowns on Victory tab (sort of requested here, under “Space victory”). Something
like the BULL Members tab (Foreign Advisor) to help the player tally votes. Maybe
HUD civics from BAT (requested here).
Auto Save options: DLL code (just two lines) already merged; tagged with “BULL -
AutoSave”. Will need to add gameStartSave and gameEndSave to
CvAppInterface.py. An option to make a second auto-save upon pressing “End Turn”
would be nice to have. (But the BULL code doesn't do that.)
Unit starting XP (tie that to the Alt key; no option needed); possibly tooltip for Drafting
from BUFFY. City Bar Tile Hover and/or City Tile Highlights (SVN revisions 1 2 3 4 5 6
7 8)
Platy UI merge:
Smaller leader/civ icons on Military Advisor; Platy's Religion and Corporation Advisors
(but keep the BUG Religion Advisor as an option); enhanced Statistics tab. Military
Advisor should also be enlarged; this MNAI commit along with these (updated links: 1
2 3 4 5) could be helpful; though I don't think I'll bother with the overblown BUG Military
Advisor. MNAI also refactors the Customizable Domestic Advisor. Enlarging the
BUG/Vanilla Religion Advisor isn't a priority if I'll merge Platy's version (which is
already full-screen). Perhaps the Platy Religion Advisor should sort the cities by the
selected religion (but not when only hovering over a religion button); related CFC post.
CFC post with some screenshots: link
From History Rewritten: CFC post by me
Espionage screen – beige panels, maybe reset weight button (requested here), go-to-
city, investigate city buttons; Dawn of Man screen – see 704; Victory tab – leader
icons, move Time victory to the bottom; I don't think I want to adopt anything from the
city screen (change 092 takes care of that).
107
C2C has progress bars on the tech tree: Git commit, screenshot
Probably too much work. Also, I think I'd like a wider bar across the tech name with a
higher alpha value so that it stands out less and so that the tech boxes don't need to
be enlarged.
Some mods have additional automation options. One that has been requested for
AdvCiv (I don't think any mod has this): Automated workers never replace Towns and
Villages and replace Forts only on workable tiles.
Another automation request: interface mode that allows protecting individual tiles from
automated workers. The implementation should store the protected tiles as a serialized
vector<CvPlot const*> at CvPlayer, add a function isAutomationProtected like
the CvPlayer::isAutomationSafe function I've already added (call locations should
also overlap; also check uses of PLAYEROPTION_LEAVE_FORESTS) , add a new
interface mode akin to Sign mode that can either add or remove protection from a plot.
Hotkey should be Alt+P. CvGame::updateColoredPlots should apply some light hue of
blue, red or white, not sure in which PlotStyle. The cursor should ideally use the
same style with higher opacity. A loading screen hint and entry in the Pedia shortcut list
should be enough for visibility. Don't want players to go and “look for uses” for this
feature – there probably aren't many.
Misc:
Show the turns-left countdown only when at most 30 turns away from time victory (instead of 100);
inspired by RFCEurope.
Announce when a tech that grants a free Great Person is first discovered. Credit: Civ 4
Reimagined 1.4.
The choose-production popup always includes the city name (BtS says “in this city” sometimes).
The UI never shows damaged units at full strength nor at 0.0 strength. E.g. a Warrior with 98/100
hitpoints is shown with strength 1.9/2 instead of 2.0/2 (exact value: 1.96/2).
Overhaul of the BUG menu: headings, help text, layout, color palette, default settings. Changed
some colors of the “Detailed Food Info” option through BUG_CIV4GameText.xml. Mainly this Git
commit.
Merged some misc. hover text from BULL: Code tagged with “BULL - Trade Hover”, “BULL-
Finance Advisor”, “BULL - Leaderhead Relations”, “BULL - Food Rate Hover”. 086 and 087
streamline that text a bit.
Help text for units that cause collateral damage says how many defenders can be affected.
Upon closing the Military Advisor screen, the game forgets which players were selected. (BtS:
Remembers which players were selected and selects the active human player in addition when re-
opening the screen.)
Military Advisor shows leader help in hover text.
The non-customizable Domestic Advisor screen shows the strength (bicep) icon instead of the
defense (tower) icon above the column that shows the number of military units stationed at a city.
And the maintenance column shows costs including inflation (as on the city screen).
Update the status of the city unhappiness indicator on the main map in
CvCity::changeMilitaryHappinessUnits, i.e. when unit moves into or out of a city.
Resource icons on the city screen are ordered by importance: Biggest effect (e.g. +2 happiness
from Silver with Forge) first, then highest number of available instances, then by ID (order in XML).
Show effects of routes (Railroad) in hover text of improvements.
108
(CvGameTextMgr::setImprovementHelp)
Make sure that an announcement is shown when the active player pillages an improvement (by
ensuring in CvUnit::pillage that the pillage gold is at least 1).
The “BUG Statistics” tab is no longer optional – all it does is add statistics about terrain
improvements; those are now always shown. And all the statistics are sorted alphabetically when
the screen is loaded (rather than sorting by internal IDs).
When pairing cities for trade routes (CvCity::updateTradeRoutes), count trade route profit at
times-100 precision. Rationale: Should lead to fewer ties (which are currently broken arbitrarily
based on player and city ids) and should make it more likely that foreign trade routes are chosen
over domestic ones. See also: It can be confusing when only domestic trade routes are shown
despite available foreign partner cities as in this CFC thread.
Hide help text explaining unit commands (e.g. gift-unit) when the command button is visible but
grayed out. Rationale: That text is quite verbose, don't show it if the command isn't possible
anyway.
Disabled the global-rank columns of the Customizable Domestic Advisor because they leak
information. Show “?” in the coordinate columns until the world map has been centered.
Credits: Inspired by the “Close to Home” mod (Git commit).
The citizen assignment of AI cities gets updated at the end of an AI turn, not (only) at the start. This
way, human players get to see the current assignment when inspecting an AI city. In BtS, when an
AI city had just grown, the new citizen wasn't shown at all. Note that it's important not to update the
citizen assignment already during the end-of-turn sequence because, then, the new citizen would
immediately generate production or Great Person points, and then the remaining production turns
calculated by UI and AI would no longer be reliable.
Hide gold from trade inventories when the one side has already put gold on the trade table. Disabled this
again in order to keep the amount of available gold on display; the code is commented out in
CvPlayer::updateTradeList.
004a UI support for the Discover ("bulb") ability
AdvCiv K-Mod/BUG
The help text for the bulb button of a GP unit The help text only says which tech the GP can
shows all techs that the GP will be able to discover right now.
discover if an additional tech is researched, e.g.
"next tech: Astronomy (with Printing Press)".
GP Research on the Tech Advisor disabled by BUG's "GP Research" option shows bulb paths
default. on the Tech Advisor. Enabled by default.
Rationale For players who don't plan their bulbs (long) in advance, the added help text should
usually suffice. I'd like to show only the tech tree on the Tech Advisor.
Config GP Research can be enabled on the Advisors tab of the in-game BUG menu.
If GP Research is enabled, info about techs that Shown to the left of the tech tree, overlapping
a GP could currently discover is shown in the with the first column of techs. This looks like a
footer area of the Tech Advisor. bug; the whole tech tree is probably supposed to
move to the right a bit.
Credits Idea from RFC: Dawn of Civilization;
I've also seen it in Platy's Tech Screen, so perhaps it's his work originally.
Rationale Want to give the tech tree as much room as possible. Some Advisor screens use the
footer for tabs, but, since the Tech Advisor has no tabs, it's unused space.
For each type of GP, the following info is shown if
applicable:
109
• Preference order: All techs that the GP could • (same)
possibly discover, sorted by priority.
• Current tech: Tech that the GP would • (same)
currently be able to discover.
• Missing requirements: Techs that have a • Techs with lower priority than the current tech
higher priority than the current tech and don't for which all tech requirements are met.
require the current tech. These are techs that These are techs that the GP could discover if
will replace the current tech if their prereqs the requirements for the current tech weren't
are researched. met.
• After research: The tech that the GP would • (same)
be able to discover if all techs currently
• Techs with lower priority than the current tech
queued for research were already
for which all tech requirements will be met
discovered.
after finishing all queued research.
Improved the help text a bit, though it's still not
Difficult to guess from the help text (and layout)
easy to understand I think.
how all this works. E.g. the "after research" techs
are just called "Future Technologies".
Rationale For optimal bulb paths, it can be necessary to avoid certain techs (example). I'm
guessing that's why the BUG mod shows the lower-priority techs. Or the idea was to
show which tech the GP would get if its current tech was discovered, but that's not
always true (because the current tech could unlock another high-priority tech). So the
BUG info is complicated and misleading. I don't think tech avoidance matters very
often, and players that use this tactic probably have their bulb paths memorized or
know how to figure them out from the preference order.
The missing-requirements list should make the player aware of techs that the GP will
be able to discover if one more tech is researched through other means. Example:
If the current tech for a Great Scientist (GSc) is Compass, the player can switch
his/her research to Compass to find out that the GSc will be able to discover
Aesthetics once Compass is finished. This works the same way in BUG as in AdvCiv.
But how to tell in BUG that the GSc could also discover Philosophy if Meditation was
researched? AdvCiv lists Philosophy (and Paper) under "requirements missing".
Config Implemented mostly in CvTechChooser.py.
AdvCiv BtS
No "can be researched by a (e.g.) Great Help text on a technology says whether that
Scientist" help text on technologies. technology could currently be discovered by a
particular GP.
Rationale If the player does have such a GP, then the player can consult the Discover button of
the GP to find out which techs it can discover. If the player doesn't have the GP, then,
by the time a GP is born, the information may no longer be accurate. Most of the time,
the help text is just distracting. If the player needs to know about bulb paths, he/she
should consult the BUG Tech Advisor.
004b Cost projections in action button help text
AdvCiv BtS
The help text for the found ("Build City") button No such projection. Can only quicksave and
shows how much the Total Expenses (Economics found to see how costs will increase.
Advisor) will increase if a city is founded on the
current tile. Does not project the gold income of
the new city, e.g. from trade routes.
The increase is computed as inflation times
110
+ maintenance for the new city, including State Property,
vassal cities etc.
+ increased maintenance in other cities, including those
temporarily exempt because of disorder or celebrations
+ increased civic upkeep
+ decrease in unit cost (from the +1 population)
+ decrease in unit supply and cost from the lost Settler
Tbd. Should also show free initial buildings (Palace, more with Medieval start or later) and
the number of trade routes (predicting the yield would be tough).
The help text on the found button shows health Forests provide +0.5 health, Jungles -0.25, Flood
from features, traits (Expansive) and freshwater. Plains -0.4 and Fallout -0.5.
All features revealed in the (full) city radius count.
While a Settler is selected, the help text of any
tile shows health effects.
City tile yield only shown once a city has been
Found-button help text shows the projected city founded. Usually just 2 food, 1 production, 1
tile yield. commerce but occasionally more.
See also 016 changes the effect of extra yields from random events on city tiles.
004h shows the full city radius when a Settler is selected.
059 show health and happiness effects from tiles surrounding actual cities.
Help text of the delete-unit button shows whether the deletion will decrease expenses for units:
supply, unit cost (incl. Pacifism) and (for mod-mods) extra cost. If deleting the selecting unit(s) will
not decrease expenses, but deleting additional units would, the help text says how many additional
units would have to be deleted.
Tbd. If the Finance tab (Economics Advisor) is checked before and after deleting a unit, the
difference in unit expenses doesn't always agree with the difference predicted by my
code. This is because the subtotals on the Finance tab include inflation, which isn't
how CvPlayer::doGold actually computes expenses. Cf. comment in
EconomicsAdvisor.py. Also, during anarchy, some of the expense items shown in
help text on the Finance tab are positive. Should all be zero.
004c Changes to bombardment, air bomb missions [not strictly UI changes]
See also 004g shows messages about bombardment immediately.
AdvCiv BtS
Can bombard at 0 defense in order to prevent Can't bombard cities with 0 defense. If a city isn't
city defense from recovering. bombarded for a turn, its defense begins to
recover on the next turn.
Air units and siege units with the ability to ignore The ability of Wall and Castle says "+... defense
defensive buildings have their bomb(ard) rate (except vs. Gunpowder-based units)" and those
increased to match the building defense. For Gunpowder-based units have the XML tag
example, when a city that has 100% defense IgnoreBuildingDefense. However, Siege units
from a Castle but just 60% from culture, is with the tag don't actually ignore defensive
bombarded by a Cannon (bombard rate 12), city buildings; they only ignore the bombardment
defense is reduced by 20 percentage points. reduction effect that Wall and Castle also have.
Units that ignore defensive buildings see 48% In the example on the left, the Cannon player
defense, the others 80%. would see 60% before bombardment, and 52%
after.
Rationale I wouldn't mind Walls and Castles having defensive abilities against post-Medieval
units, but the implementation is unacceptable from a UI pov. By the Modern era, stacks
often consist entirely of units that ignore building defense, and then the player only
gets to see the defense from culture, which somehow doesn't decrease as fast as it
111
should.
An alternative solution would be to show city defense including buildings when a siege
unit is selected; in the example, the player would then see defense decrease from
100% to 88%. Not trivial to implement (can't just take away IgnoreBuildingDefense
because siege units still need to ignore bombardment reduction), and my solution is
conceptually simpler: post-Medieval siege units entirely ignore defensive buildings.
When applying bombardment damage Defense damage is stored as an integer
(computed as described above), the city's percentage, meaning that the bombardment
defense damage percentage is set so that the damage needs to be converted into a percentage
city's defense modifier decreases by an amount and rounded. In BtS, the rounding can lead to a
exactly equal to the bombardment damage. counterintuitive loss of 1 bombardment damage.
In formulas: The damage percentage d1 after Example: A city with a 60% defense modifier gets
applying bombardment damage b should be bombarded by 5 Catapults. 8 bombardment
chosen such that the new defense modifier m1 is damage is taken times 100/60 and rounded down
b less than the present defense modifier m0. As in order to convert the damage into a percentage;
in BtS, m0 and m1 are computed from the that's 13% per Catapult. After 4 shots, the city
damage percentages d0 and d1 and the city's has 52% damage, i.e. is 48% undamaged. To
maximal defense t (defense modifier when compute the defense modifier, the 48% are taken
undamaged): times 60 and the result is rounded down: 28%.
m1 = floor((100 - d1) * t / 100) That's as expected: 60-4*8=28. The fifth shot,
From this, one can derive the following equation however, results in 65% damage and 35%*60%
for d1: rounds down to 21% – the defense modifier has
d1 = 100 - ceil((m0 - b) * 100 / t) only decreased by 7.
Tbd. Simply store the defense damage as the sum of the bombardment damage? This
might lead to unexpected results in some circumstances, but I can't think of any. E.g. if
a city constructs Walls during a siege, then subtracting the bombardment damage so
far from the increased maximal defense would be pretty intuitive.
Help text for Walls and Castle says that defense Says “+50% defense” for both.
is “raised to” 50% and 100% respectively.
Defense is represented by the tower icon.
Rationale “+50%” is misleading because building defense isn't cumulative with culture defense.
Config Implemented through a new XML tag “RaiseDefense”. Walls have RaiseDefense 50
and Castle 100, i.e. this new tag is non-cumulative when it comes to building defense.
The old “DefenseModifier” tag still works but is unused.
Don't count defensive abilities in AI evaluation of building obsoletion (looks like K-Mod did count
them).
Help text of Bombard button and in Air Bomb Generic help text saying that bombardment
mode says by how much the defense modifier decreases the defense modifier. No help at all
will decrease. while hovering in Air Bomb mode.
Rationale Not obvious when buildings and gunpowder units are involved (see above).
Tbd. A breakdown would be nice – showing reduction from buildings, increase from ignoring
building defense.
When hovering over an enemy improvement in The probability is shown nowhere (and isn't even
Air Bomb mode, the probability of destroying that explicitly computed). Not even the values that
improvement through an Air Bomb mission is enter into the probability (current air bomb rate,
shown. improvement's air bomb defense) are shown
anywhere.
Tbd. Should Air Bomb missions be allowed to target routes? (Only improvements currently.)
112
All missions that can be intercepted (air bomb, airNo such probability display. Can only scan the
strike, paradrop) show the best visible enemy nearby tiles for units with an intercept chance.
interceptor and the interception probability while Unit help text shows that chance, correctly
hovering for the mission target or for combat adjusted to hitpoints in the case of damaged
odds (right mouse button or Alt+hover). Except fighter aircraft.
when that probability is 0. When multiple units
are selected, also show which unit will get
intercepted (i.e. which unit will execute its
mission first).
Rationale A player generally can't be certain about the interception probability because there
could be a Fighter somewhere in the fog of war up to 6 tiles away from the target (jet
Fighter: 10 tiles). Still, showing the probability of visible units seems much better than
nothing.
Could make a case for showing combat odds in Air Strike mode, i.e. the same info as
Alt+hover (no odds really, but the air strength of the attacker and the combat strength
of the non-air defender). But I think it would be too much text if non-combat help text
(e.g. terrain info) is shown in addition. Currently, the player can choose between
detailed combat info (Alt+hover or right mouse drag) and civilian info plus interception
(Air Strike mode). Just too bad that the latter is what players intuitively use.
Tbd. The next step would be to show odds for air combat. Big task.
Maybe the first unit to execute its mission (assuming that multiple are selected) should
be shown even when there is no interceptor. I'm just not sure exactly how to phrase
the help text.
See also 128 uses the non-cheating interceptor check (written for UI purposes) in AI code.
650 shows the interception chance in Nuke Mode.
Human group missions are halted when a unit When a group is ordered to air bomb, air strike or
gets intercepted unless the Stack Attack option is paradrop at a tile, all units in the group execute
enabled. Exception: Group paradrops are only the mission if they're able to, regardless of
halted when a paradropping unit gets destroyed interceptions.
by an interceptor or the first time that an
interception occurs from the fog of war.
Rationale This seems pretty similar to group combat on land and water – the game should
assume that the player wants to reconsider his or her actions after each interception.
Air combat isn't as lethal than land and water combat, and insofar perhaps less
unpredictable, but, on the other hand, interceptors can intervene from the fog of war.
Exception for paradrops: A single enemy Fighter can intercept any number of
paradrops without taking damage. It seems too tedious to move a whole stack of
Paratroopers one by one then.
Custom icon for the Air Bomb button, The Air Bomb icon looks very similar to the Air
superimposing the Bombard icon on the original Strike icon. Even though the buttons are right
Air Bomb icon. next to each other, they look virtually the same.
Rationale The Bombard icon (red-white targeting circles) is very distinctive, and Air Bomb against
cities works almost exactly like Bombard. It's still not so clear that this is also the
button for bombarding improvements. Maybe that really should've been a separate
mission, but I'm not going to experiment with that. I also don't think that superimposing
the Pillage icon in addition to the Bombard icon would look good.
Config BtS uses an icon atlas for the Air Bomb button. Since I didn't want to include a
modified atlas in the mod, I've changed the button icon path to an individual graphic
instead. See comment in Civ4MissionInfos.xml.
113
Unit help text for air units shows the current air Civilopedia shows the maximal air bomb rate of a
bomb rate. unit; unit help text doesn't show any air bomb
info.
Rationale Most players may not even be aware that the air bomb rate (unlike the bombardment
rate) is decreased when a unit is damaged.
AdvCiv K-Mod
Closed some fog-of-war information leaks K-Mod already takes care of somemore
caused by the Air Bomb mission: Tile ownership, egregious leaks. Still guarantees that any Air
unrevealed cities, removed improvements, Bomb mission that can be ordered will also find a
depleted city defense. Ordered Air Bomb target.
missions are no longer guaranteed to find a
target; can e.g. happen that the targeted
improvement no longer exists. In that case, the
recon effect is the only result of the mission, and
a special announcement is shown.
See also 001i deals with leaked info about routes in the fog of war.
AdvCiv BtS
When a group of (human or AI) units is ordered The missions are executed in the internal order
to bombard a city, then the missions are of the group. I'm not sure what that order is, but it
executed (until city defense reaches 0) based on seems pretty unpredictable.
a priority function that takes into account
bombardment rate (the higher the rate, the higher
the priority, but avoid overshooting), city attack
odds, collateral damage (try not to bombard with
effective city attackers) and promotions (only for
human units). When the city is expected to fall
easily, then damaged units (despite having poor
attack odds) are deprioritized – so that they can
heal earlier.
Credits Requested by Leoreth (CFC post; see 3rd item), and he also provided concrete ideas
for the priority function a few posts below.
Rationale Requested as a UI feature, but I think there is a tangible benefit for the AI as well; AI
bombardment missions are generally executed by stacks, not individual units.
See also If not all selected units are needed to bombard a city down to 0 defense, then 153
splits off units that didn't get to bombard into a separate group and selects that group.
114c deals with other AI changes regarding bombardment.
After each AI bombard mission, a city attack by Seems that city-attack stacks can only either
units in the same tile (with remaining movement bombard or attack on any given turn.
points) is re-evaluated.
Rationale Attacking one turn earlier not so rarely makes the difference in avoiding a deadlock.
When a group is ordered to air bomb a city, then Executed in the internal order of the group.
the missions are executed (until city defense
reaches 0) in an order that prioritizes units with
high defense damage, tries to avoid overshooting
and (more of a tiebreaker) deprioritizes valuable
units (high production cost, XP).
Rationale I had written this simpler heuristic for both air bomb and bombardment missions. I
don't think it was quite up to snuff for bombardment (see Leoreth's criticism in the
114
thread linked above), but it may still be good enough for air bombing. At least it's
predictable. The new bombardment code isn't suitable for air bombing.
AdvCiv K-Mod
When a group of units is ordered to air bomb an The internal order of the group is used for air
improvement, then the missions are executed bomb missions, but, for pillaging, fast-moving
(until the improvement is destroyed) in an order units are preferred. (BBAI had disabled group
that prioritizes the current air bomb rate (and thuspillaging entirely; K-Mod re-enabled it.)
the chances of success). As a tiebreaker,
production cost and XP are used (prefer using
low-value units for bombing).
Likewise, when a group of units is ordered to
pillage an improvement, production cost and XP
are used as tiebreakers.
Rationale Important for the displayed chance of success (see blue box higher up). Only one
probability is displayed, and the player will probably assume that it's the best
probability. And a player will probably also assume that the best unit will carry out the
mission (just like the best attacker comes forward in a group attack) – and not some
arbitrary unit.
(Pillaging doesn't really belong under this change id, but the logic is quite similar to air
bombing.)
AdvCiv K-Mod
When cycling between units, try to avoid cycling Air units and civilians are treated as the same
between air units (or nukes) and civilian units. category of units.
Rationale Seems like an oversight. Assuming that CvUnit::canFight identifies military units is a
somewhat common mistake. (It's actually just units that can engage in regular
combat.)
Config K-Mod handles the unit cycling order through CvSelectionGroup::
groupCycleDistance
Credits CFC user MightyToad made me aware of the problem in this post (“side note” above
the 2nd quote box).
Tbd. Not sure how much I've improved the situation. I haven't implemented the suggestion
to always select all aircraft (around the world) first. Perhaps that should be a BUG
option.
004d AI says "not right now" to peace when war is recent
AdvCiv K-Mod
When a player tries to broker peace, the Trade Says "we'd love to, but you'd have to ask them"
Screen says "not right now ..." if the war is still instead. Often, both sides say this.
too recent. The AI will agree to brokered peace
(As far as I recall, peace could be brokered even
with a third civ as part of a peace treaty with the
when a war was recent in BtS.)
human even if the AI would normally still refuse
to talk to that third civ.
004e Leads-to info added to promotion buttons
AdvCiv BtS
The help text for promotion buttons lists the Can only look this up in Civilopedia.
promotions enabled by the current promotion.
E.g. "Flanking I
115
Leads to Flanking II, Navigation, Sentry"
004f Disabled celebrations
No celebrations (We-Love-The-King Day) ever. If a city has at least 8 population, no anger and
no bad health, celebrations happen with a
probability of population / 1000. The reward is 0
maintenance for 1 turn.
Rationale Celebrations grant just -3% maintenance on average in a size 30 city, which is
insignificant. I'm not even listing this as a balance change. Celebrations were potent in
Civ 2 but already irrelevant and confusing in Civ 3. Something no one will miss who
doesn't know it's disabled.
Config WE_LOVE_THE_KING_POPULATION_MIN_POPULATION in GlobalDefines_advc.xml
004g Misc. changes to confusing help text (not a complete list)
See also 062: AI diplo comment when canceling a vassal agreement
"Our shared borders spark tensions" "Our close borders spark tensions"
Too similar to "closed", and doesn't imply that
they're touching.
"We don't like you enough" "We just don't like you enough"
Sounds like this is the only obstacle – but often
isn't.
"Your x has attacked a y: 22% damage." "Your x has attacked a y: -22% damage"
Removed the minus sign.
“Reduced city defenses” message shows the Always shows the defense percentage including
defense percentage without Walls/ Castle if the buildings.
bombarding unit ignores building defense.
"Some wonders on this continent are making us "Some buildings are making us happy", listed
happy" for the Notre Dame ability. twice when there is also e.g. a Colosseum.
(Only changed in English and German)
"The anarchy is over" in white letters In red letters, like it's a bad thing.
"We are afraid of their military might" when "Surely, you must be joking."
sponsored war refused on account of nukes
Help text of Blockade missions says that only “disrupts the trade route so that no
enemy trade is affected. intercontinental trade can pass through the
blockaded tile”
List culture from Creative trait in city culture
breakdown as “from Traits”. Listed as “free city commerce”. (With translations
List health from Expansive trait as “from Traits”. in the vein of “free-flowing commerce.”)
Tbd.: “Yeah” for happiness from Charismatic trait Expansive: “from Civilization”
is too obscure (and pretty dumb). Can't use “from
Trait” there though; has to be a sound bite.
Seems that “resources” is used predominantly,
Refer to bonus resources as “Resources” in
e.g. “we enjoy our luxurious resources”, but, for
health help text.
health it says “Bonuses”. Positive modifiers are
Announce bombardment of human cities also referred to as “bonuses” sometimes.
immediately (bForce=true) and include the
name of the bombarding unit (inspired by MNAI).
Announce pillaging of human improvements
immediately as well.
Replace the (slang) term “plot” with “Tile” in some
116
game text. (Didn't bother with this for 'Pedia,
WorldBuilder, map scripts and random events.)
004h Highlight full city radius when Settler selected; no yield icons
When a Settler is selected, the full city radius is Only the inner radius, i.e. the adjacent tiles are
highlighted. highlighted.
No yield icons are shown (unless they're always Even if "Display Yields" (button above the mini-
shown through "Display Yields"). map) is disabled, yield icons are shown when a
(To implement this, CvInterface::toggleYield Settler is selected.
VisibleMode was no help. I had to replace
CvUnit::isFound so that the EXE doesn't even
know whether a Settler is selected.) The highlighting is based on whether at least one
Nothing is highlighted if any non-Settler unit is Settler is selected (CvInterface::
selected along with a Settler. canSelectionListFound).
Rationale Highlighting the adjacent tiles isn't helpful at all; it's not even a reliable projection of the
borders right after founding because some of the highlighted tiles could already be
owned by another civ.
The yield icons are useless to me personally, but I know some players always keep
them enabled, perhaps, in part, because icons on worked tiles are highlighted, making
it easier to tell which tiles are being worked. I'm not sure if anyone wants to see the
icons only when a Settler is selected – I normally choose my city sites before even
training a Settler.
Config Two options on the “Map” tab of the BUG menu
Tbd. When settling on a tile marked with a dot on the Strategy layer, it would be nice to
remove that marker automatically.
See also 004b shows info about city maintenance and health when a Settler is selected.
009c (removal of Map Finder) makes room for the options on the BUG menu.
004i Message about gold stolen by enemy spies says how much was stolen
Credits Idea from Civ 4 Reimagined 1.2
See also 120d: The Espionage screen shows the amount of gold to be stolen in advance.
004j Changes to "Regenerate Map"
AdvCiv BtS
In singleplayer games, the map can be Can only regenerate the map on turn 0 (unless
regenerated until (incl.) turn 3. Exception: Can't civs meet each other already on turn 0).
regenerate after any civ has met another civ.
Rationale More convenient for testing, but, on second thought, regeneration past turn 0 might not
be entirely clean. Regeneration does not reset the game, player and team instances;
just destroys all units and cities. Also, it's not such an inconvenience to reload the
initial autosave.
Tbd. Perhaps a full reset wouldn't be so hard to implement.
At least I should try to get rid of the have-met exception on turn 0. Resetting the has-
met flags is simple. Years-of-peace and perhaps other AI memory starts to count when
another civ is met, but that's not a problem on turn 0, and resetting memory counts is
also easy enough. A human civ could immediately declare war, so I at-war flags would
have to be reset. When starting in a later era though, various trades could be made on
turn 0 ...
After regenerating the map, the Dawn of Man The DoM screen isn't shown after regenerating,
117
(DoM) screen is shown again, and the camera and the game tries to center the camera on the
centers on the player's active unit. player's starting plot, but somehow this has no
effect; camera stays at the previous starting plot.
Config Optional through GlobalDefines_advc.xml. If disabled, the camera still centers
correctly (through change 003r).
Rationale Without the DoM screen, the player sees the old starting location slowly fade to black.
I'm not sure if that reveals parts of the new map that the player isn't supposed to see,
but, even if it doesn't, it's confusing. The DoM mostly obscures that.
See also 704: Other changes to the Dawn of Man screen.
001: Workaround for a problem with the camera position after loading a savegame in
which the active player has no units.
Extra yields added through Python are reset Only random events set extra yields. Can't occur
before regenerating the map. on the initial game turn, so no need to reset extra
yields.
Rationale For mod-mods that might set extra yields during map generation.
See also 016 makes an exception for extra yields so that peaks can be made workable through
Python.
004k Changes to unit command buttons, and misc. usability changes to Sea Patrol.
See also 004c changes the artwork of the Air Bomb button
028 changes the Sea Patrol rules for submarines, 028b makes some AI changes
concerning Sea Patrol.
162 might, in the future, increase the range of Sea Patrol and expand it to cover
enemy naval landings.
AdvCiv BtS
Options for hiding the Sea Patrol and Auto-Explore The Sea Patrol button is shown near the start of
commands. The keyboard shortcuts (P, E) are not the command list, between Skip and Sentry,
affected by this. (Implemented but commented out. Auto-Explore normally at the very end of the list.
Note: Prior to AdvCiv 1.06, the Sea Patrol option had Sea Patrol was added by the BtS expansion.
disabled that mission entirely, also for the AI.)
Sea Patrol is only allowed when there actually is
an improvement to guard in an adjacent tile. The
command button is only shown under these
narrow circumstances.
Clarified the hover text describing Sea Patrol.
Config The options have been commented out by this Git commit.
Rationale Few players seem to ever use Sea Patrol, and many may not even know what it does.
However, with Sea Patrol restricted to the few situations in which it has an effect, there
is not much of an incentive for hiding the command. See below about Auto-Explore;
that option was intended as a companion to the Sea Patrol option.
Reordered the command buttons a bit. Notably, The command buttons are shown in a single row
promotions and upgrades are shown in separate that wraps around as needed. It's not clear if
row – if there is enough space to show all most buttons were ordered in a deliberate way;
command in just two rows of buttons this way. for some, a priority value was explicitly set in
Delete is near the right end of the first row. XML (high priority means a position closer to the
Special treatment for the found-city mission: The left end). Delete is given the highest priority that
button is placed all the way to the right (as in way. Promotions and upgrades usually come
BtS). toward the end, but automation (Auto-Explore)
and ungroup buttons are even farther to the right.
118
Config Civ4MissionInfos.xml, Civ4CommandInfos.xml for priority values, but most use the
default priority, and then ties break according to the call order in CvLoadUtility::
setGlobalActionInfo in the DLL and the order of the action subtype enums. And the
ungroup buttons are added by CvMainInterface.updateBottomButtonList in
Python. Hence no BUG option for restoring the original order.
See also CFC posts raising the issue of clicking on Auto-Explore by accident.
1 (under “Unit command buttons”) | 2 (also the next post, under the 2nd quote box) | 3
Rationale Putting promotions and upgrades in a separate row should go along way toward
preventing accidental clicks on them. Unlike most of the other commands, those
buttons represent strategic decisions more than tactical, so separating them also
makes some sense to me conceptually.
The best place for rarely used and dangerous commands seems to the right of the
center of the first row. The button at the very end stands out visually, so that should at
least not be something dangerous; ungrouping and cancellation seem fine.
Moving Delete away from the first position is hopefully a less significant change than it
may sound like; I think players had mostly ignored that button and focused on Sleep/
Fortify, and now they just need to move their gaze tiny bit to the right. Not having the
found-city button all the way to the right felt quite unfamiliar – not a good thing when a
player might have just started his or her first AdvCiv game –, so I've kept found-city all
the way to the right.
Tbd. May yet want to uncomment the option for hiding Auto-Explore. Even if it's no longer
prone to accidental clicks, many players never use it, and the design of the icon stands
out, drawing attention.
When a unit on Sea Patrol is selected, the Can only tell that a unit has been set to Sea
resource tile(s) guarded by it are highlighted on Patrol from the absence of the Sea Patrol button.
the map in blue and hover text says that they're The command doesn't cost movement points
being guarded. either, so it looks just like it's been set to Sleep
(except that the Sleep button gets shown when
on Sea Patrol and not when asleep).
Rationale Mainly just to confirm to the player that the command is being carried out.
An attack triggered by pillaging causes combat Quick Attack matters if the active (human) player
animations to be shown unless both Quick Attack owns the pillager, Quick Defense when owning
and Quick Defense are enabled. the patrolling unit.
Rationale The attacker-defender role is a bit muddled and, since the triggered attack can be
unexpected, it's better to err on the side of making the player aware.
119
Fortify-Heal should result in the desired behavior in most cases. Units already have so
many rarely used buttons; don't want to add another. BAT also uses a single button
(and has a menu option for switching to the BtS behavior).
I've tried using the Sentry-Heal graphic from BUFFY (a monocular on top of a canteen)
for the Heal button when outside a city, but I think this draws too much attention to
what is supposed to be a low-key change.
Units on Sentry (and units healing in a non-city A unit on Sentry is woken up if and only if there is
tiles) are not woken up by enemy units that start an enemy unit within the Sentry unit's visibility
their move already within visibility range. range at the start of the turn. How the enemy unit
got there doesn't matter.
Rationale Sometimes, enemy units keep stalking around a Sentry unit because they're too weak
to attack it or entirely unable, e.g. a ship vs. a land unit. Now the Sentry is only woken
up once in such a case – unless the enemy keeps moving in an out of visibility range.
It wouldn't be difficult to keep track of encountered enemies indefinitely (regardless of
whether they move out of range), but the player may actually want to be alerted when
an enemy unit returns, and a player isn't really supposed to know whether a unit that
has moved out of sight has returned or whether it's a different unit with the same
characteristics.
The BUFFY mod has an optional “Sentry (Land)” mission to address problems with
land Sentries being woken up by ships. That's a much clunkier solution, and not really
suitable for AdvCiv because, in AdvCiv, Barbarian ships may well carry land units (see
300).
See also Depends on 003k (workaround for adding data to CvSelectionGroup).
075 wakes embarked units up when a ship reaches land with its last movement point.
When checking if human units are in danger, the Same treatment for human and AI: To decide
pathfinder is used for greater accuracy. This whether an enemy unit (on the same landmass)
mostly (only?) applies to Workers getting is a threat, the air distance is compared with the
interrupted. Danger from more than 3 tiles away movement points. If the unit is standing on a road
is ignored. or railroad, its movement points are treated as 1
greater. Terrain and whether the route connects
to the target isn't checked, so false positives can
easily occur.
During the first two eras, the AI also uses the Will not notice possible attacks by units with
pathfinder but only when the potential threat is a terrain movement bonuses (e.g. Woodsman II
human unit. promotion).
Credits Leoreth brought up the issue of false positives here on CFC.
Rationale See the link above. I'd like to use the pathfinder always, but, at longer distances, this
could give away information about fogged or unrevealed tiles along the way, and the
plot danger functions are called very frequently by AI code. In profiler runs, using the
pathfinder for the AI (when the air distance is 3 or less) added something like 5% to
the total runtime, which is clearly not worth it. The pinpoint change to address early
attacks by human Woodsman units on AI Workers isn't going to affect performance.
Tbd. Perhaps increase the 3-tile limit to 4.
Might be nice to only add threatened (human) workers to the unit cycle, i.e. to leave it
up to the human player to cancel their orders.
Would be nice to give the same treatment (or to just cancel orders) to human units with
a queued movement order when an enemy unit becomes visible and will, on its next
turn, be able to attack into the tile where the moving unit is planning to end its turn. Or
maybe only when the moving unit will be unable to defend against the attack (civilian
120
or ship/ aircraft vs. land). Related CFC post (under “pathfinding”)
004m Default camera distance, field of view (FoV), layer icons
AdvCiv K-Mod
Decreased the default FoV value; with an BUG introduced the FoV slider; previously, the
adjustment based on the screen height. FoV value was only adjustable through XML. K-Mod
slider still hidden by default. hides the slider by default and adjusts the default
FoV value based on the screen width.
Added a brief explanation of the field-of-view
setting to the hover text of the option on the BUG
menu.
Made the camera angle a little bit more top-down
at medium and close distance.
Config The slider can be enabled on the “Map” tab of the BUG menu. If "Remember Field of
View" is checked, the value on the slider is stored in My Games\Beyond the Sword\
AdvCiv\Settings\BUG Main Interface.ini. "Field of View" can then be unchecked
again in order to hide the slider.
The camera angle adjustment is done through CAMERA_LOWER_PITCH in
GlobalDefines_advc.xml.
Rationale The lower the value, the smaller the field of view, i.e. fewer tiles are shown on the main
interface and the city screen. If fewer tiles are shown, one has to zoom out closer to
the Globe view boundary to get an overview. This, in turn, means that the camera
angle becomes more top-down, which is what I want. The CAMERA_LOWER_PITCH
parameter isn't a great way to accomplish that because a flat angle is desirable when
zooming all the way in. My issue with the BtS camera behavior is that the angle
becomes too flat already at medium to far camera distance. A rather small FoV value
works around that problem.
While a larger screen can show a larger field of view, I also expect players to sit a bit
farther away from their large displays, especially from extra wide displays. So I think
adjusting only to the height is a reasonable compromise. (To be clear, this only affects
the default FoV value; players can set any value they like via the slider.)
See also BUG developers discussing the creation of the field-of-view slider: link
090 makes some changes to the field-of-view slider.
092b adjusts the size of plot indicators (resource, unit “bubbles”) to the FoV value
rather than to the screen resolution. With the original adjustment, increasing the FoV
on high resolutions had exacerbated problems with the plot indicators getting too large
relative to the size of a plot.
Tbd. Clean up the implementation of the starting camera distance option based on the
Taurus mod (Git commit). It's not necessary to involve CvScreensInterface.py.
The camera pitch can be set arbitrarily through CyCamera.setBasePitch; see the
BlueMod for example. It might be possible to intercept the mouse wheel input and set
a steeper pitch. (Letting players freely adjust the pitch won't work well because the
mouse wheel will zoom beyond a perpendicular angle when the base pitch is steeper
than the BtS default.)
Increased the height of the Globe view boundary a bit.
Rationale To accommodate small field-of-view values better. Will want to zoom out far then.
Config XML\Misc\Civ4DetailManager.xml
121
002h disables the passing clouds.
AdvCiv BtS
Let the DLL set the CAMERA_START_DISTANCE Set statically in GlobalDefines. Determines the
value based on the FoV value and era. default camera distance, but also affects music
volume and zoom granularity.
Rationale The default zoom is way too close and flat, especially when loading a savegame –
except, perhaps, when playing with a high FoV value; it seems that players who use a
high FoV value like playing at a flat angle.
Config Option on the Map tab of the BUG menu. By default, the camera start distance is set
automatically as described above, but players can also configure a fixed value.
Tbd. Perhaps a fixed value should be the default. Players keep running into this problem
(see links below); a fixed value might be less likely to not work well at all for some
players. On the other hand, more players could then end up with a value that works
only somewhat; perhaps better to make players aware. (I've also added a loading
screen hint.) It's also not clear what a good fixed value would be; the BtS value isn't
going to work well because, by default, the mod doesn't use the same FoV value as
BtS does.
Better to use city count instead of era (while still updating the
CAMERA_START_DISTANCE only upon entering a new era)?
See also Hover text of the BUG option.
Bug reports about music being inaudible at high FoV values in AdvCiv 0.97 and earlier
due to a high CAMERA_START_DISTANCE set in XML. 1 2
CFC posts suggesting that a camera start distance based on FoV isn't suitable for all
players. 1 2 3
002q: Option to play era and civ music while the city screen is open. A high
CAMERA_START_DISTANCE may result in a too low music volume on the city screen
with that option (because the camera distance on the city screen will be much smaller
than the start distance).
The camera distance on the city screen gets At a low FoV value, not the entire workable
adjusted (a little bit) to the FoV value. radius of tiles will fit on the city screen. At a high
FoV value, too many non-workable tiles take up
space that could instead be used for showing the
workable tiles at a closer distance.
Config The base distance can be adjusted through GlobalDefines_advc.xml.
See also 092 centers the city screen camera better.
CFC post with a screenshot demonstrating the problem. AdvCiv players have also
brought this up to me at least once in the past.
Increased the camera scroll speed (movement parallel to the ground).
Config Through GlobalDefines_advc.xml
Rationale I think the speed is defined in terms of world (“landscape”) coordinates, so scaling
based on the typical number of tiles on the screen shouldn't be necessary. (One tile
always has a length of PLOT_SIZE=180 units in terms of landscape geometry. Scrolling
(with the cursor at the edge of the screen or through the arrow keys) just generally
seems quite slow, even if I use a 1024x768 window.
Tbd. Should perhaps also increase the acceleration, as described in this CFC thread.
Although the impact appears to be small, and I'm not sure where to put that line of
122
Python code.
Enable the Resources layer (“bubbles”) at the No layer is enabled at game start.
start of a new game.
Rationale Most players seem to play with the Resource layer.
Config Can be toggled on the “Map” tab of the BUG menu.
See also Even more players will want to play with the Resource layer because change 092b
sets a more sensible size for them.
The currently active layer is stored in After loading a savegame, the same layers
savegames. If the saved layer requires Globe remain active as before loading. When loading
view, then no layer is enabled after loading a from the opening menu, no layer is enabled.
savegame.
To implement this, I've added Python code that No function in the DLL interface for checking the
tells the DLL when a layer is enabled or disabled. currently active layer.
Rationale The layer at the time that the savegame is created is more likely to be suitable for the
saved game state than the layer that is active when loading.
See also A DLL function for checking the current layer was needed anyway for 003d and 102.
004n Faster scrolling through unit icons in a (city) tile (“plot list”)
AdvCiv BtS
One normal click on the right-arrow button on the One full row of unit icons is shown when opening
city screen shows up to 100 unit icons. the city screen. If there are more units in the city
Subsequent clicks show 10 more units each tile than fit in one row, each click on the right
arrow next to the unit icons shows one additional
unit. If Ctrl is held when clicking, 10 more units
are shown.
Outside the city screen, each click shows 10 Outside the city screen, a much higher number of
more units; the Ctrl key makes no difference. icons is shown at once.
When exiting the city screen after scrolling the
Fixed this apparent display bug (through a plot list, the plot list shown on the main screen
workaround, technically). can have empty rows at the bottom.
Rationale At least at 1280x1024 resolution – and I think most players have that much –, 100
units don't really obstruct the city screen, no reason to take it slowly.
AdvCiv BUG
If the BUG display method for the plot list is The BUG display method will only ever show a
enabled, each click on an arrow button on the single row of icons on the city screen.
city screen scrolls by one full row of unit icons.
Right-clicking an arrow button scrolls to the end
of the list. This last part is also true for the PLE
(Plot List Enhancements) display method.
Rationale Not sure if the BUG behavior is intentional; seems fair enough – but can be a bit
tedious when there is a very large garrison. So let's use the highest increment that
makes sense. The right-click behavior would be nice to have for the default (BtS)
drawing method too, but I've found that difficult to implement. The plot implementation
is generally quite complex with some redundant Python code for the three display
methods and the EE and DLL being involved as well.
004o No start-revolution button on the new-civic popup
123
AdvCiv BtS
The change-civic popup only has the buttons "Let's get this revolution started" directly starts a
"No, the old ways are best" and "Let's see the big revolution.
picture." Exception: When there is only one civic
that the player can change to, the start-revolution
button is shown in addition. This usually happens
when the player discovers Bronze Working.
Rationale Players sometimes forget other civic changes that could be made along with the one
suggested by the game (especially if more than one civic becomes available at a
time). This is frustrating and happens easily.
004p No commerce breakdown on city screen if slider at 0
AdvCiv BtS
When showing help text for any of the four Raw commerce is shown even when the slider is
commerce types on the city screen, a breakdown 0. E.g.
of raw commerce is shown only when the slider "Culture: 1000
position is above 0. ====
Base commerce: 50
+50% for Capital
-------
0% of 75 = 0"
Rationale Makes the culture-bar help text harder to read, and could be confusing for new or
returning players since the culture slider isn't even available at the start of a game.
Don't show the player's total culture output on the Total culture output (sum of the culture rates in all
main interface. cities) shown next to the culture slider.
Rationale Not an important statistic; not worth being constantly on display. Even a bit confusing
as total culture doesn't have any effect of its own.
Config Option on the BUG menu (General tab). As requested here (CFC).
See also 120c hides the espionage slider when it's at 0
004q Display of relations modifiers
See also This would make less sense if some modifiers were hidden; but sha reveals them all.
AdvCiv BtS
Sum of the relations modifiers shown along with Players have to sum up the modifiers by
diplo breakdown. For example: themselves to find out the total relations value:
Pleased (+7) towards Gandhi Pleased towards Gandhi
+1: "Years of peace … +1: "Years of peace ...
If not all modifiers are revealed (randomized BUG shows the sums on the Glance tab. That's
personalities), the sum of the revealed modifiers actually based on searching the attitude string
is displayed. generated by the DLL for plus and minus signs.
Therefore also only counts revealed modifiers.
See also sha reveals all relations modifiers except when playing with randomized personalities.
When playing with randomized AI personalities, E.g. “-2: You declared war on our friends” when
unusually high memory-based relations modifiers only only one friend has been attacked
are (incorrectly) displayed as just +1 or -1. unequivocally gives away Gandhi's personality.
(Until AdvCiv 0.96d, all memory-based modifiers were –
accidentally – hidden when playing with randomized
personalities.)
124
Tbd. The types of AI memory to which this change applies are currently hardcoded in
CvGameTextMgr.cpp. Would be better to check how many personalities deviate from
the default and decide based on that whether to show the true modifier.
See also The LEADER_DEFAULTS element introduced by xmldefault could be used for this
purpose. However, currently that element is deleted once XML loading has finished.
AdvCiv BBAI/ Civ Accelerator mod
After computing an attitude breakdown, the The total relations value shown above an attitude
cached total relations value is compared with the breakdown is read from the attitude cache,
sum of the breakdown. If the two values aren't whereas the modifiers in the breakdown are
equal, an assertion message is displayed, the computed on the fly. If the cache is out of date
attitude cache is updated and the breakdown is (which should ideally never happen), this
recomputed before being displayed. becomes apparent when the displayed total
relations value doesn't match the sum of the
None of the above is done in networked games
modifiers. Actually, only with the SHA-Mod the
because it would result in an asynchronous
inconsistency is apparent – because, otherwise,
cache update.
hidden modifiers could be responsible for the
discrepancy.
Rationale Consistency problems with the attitude cache keep cropping up now and then, and
any changes to the computation of the relations modifiers can introduce new errors of
this kind. The above hides these errors from the end user and makes them easier to
spot and resolve when testing with an attached debugger.
Tbd. Check if I can make use of K-Mod's CvPlayerAI::AI_changeCachedAttitude to
avoid recomputing all relations modifiers all the time.
004r Report resources discovered on unclaimed tiles
AdvCiv BtS
When a tech reveals a resource, sources in Only resources on the player's current territory
unowned and Barbarian territory are reported as are reported.
well, and there's a special message when no
source was discovered or only on tiles owned by
rival teams.
Resources on the territory of the player's vassals
are also reported.
Rationale All sources could be interesting to the player, including those owned by other teams,
but mustn't flood the screen with messages.
The warning about no source probably matters most for Animal Husbandry; easy to
forget to check whether Horses have been revealed anywhere.
004s Economy ("GNP") curve doesn't count culture and espionage; yield curves show
moving average
See also 091: Changes to score graph
AdvCiv K-Mod
The Economy graph on the Info screen is named Called "GNP (Gold)" and shows the sum of all
"GNP (Gold+Research)" and shows the net sum commerce produced by cities, including culture
of the gold generated by all cities plus the sum of and espionage. (So far, as in BtS.) Gold is
the research generated by all cities. This sum reduced by the sum of all gold costs, including
doesn't include any costs (e.g. city maintenance inflation. Research is increased based on
or civic upkeep). It does include (no change) all modifiers that apply to the currently researched
gold and research modifiers (e.g. Bank, Library) tech: from tech diffusion and from knowing
and commerce from trade routes, buildings multiple prerequisite techs.
125
(Shrine) and specialists.
All the yield curves show moving averages based All curves show the game state at a given turn,
on three samples. not an average.
Economy and Industry ("goods produced") When a revolution turn is sampled for one of the
curves show a (very short) straight line for curves, a sharp, brief decline is shown.
revolution turns.
Rationale Culture and Espionage have their own curves. Both can reach far higher rates than
research and gold normally do; e.g. a settled Great Spy produces 12 espionage per
turn, a settled Great Scientist only 6 research. This makes it hard to tell from the
Economy curve if a civ has a strong economy or if it's merely focusing on culture or
espionage. A single curve for gold and research is OK; they're on the same scale.
By including costs, the curve would essentially become a research curve, which is
probably more useful than some commerce curve, but then it would seem like a "Gold"
curve is missing. Excluding costs is also consistent with the Agriculture curve ("crop
yield"), which doesn't include food consumption.
As for research modifiers: Any modifiers that apply only to the currently researched
tech (which can change any turn) are misleading.
Moving average: The Economy and Industry curve fluctuate a lot in BtS, to the point of
being hard to read, and removing culture and espionage (which rarely fluctuate) from
the Economy curve makes it worse. (One cause of the fluctuation is AI juggling of
citizens.) Apart from usability, the average is also supposed to obscure the changes
from one turn to the next a bit. I can't make much sense of them, but it might be
possible to derive some specific information, e.g. about AI war planning or wonder
building, that the player isn't supposed to have. The power curve has that issue too;
however, it might be confusing if the enemy power curve doesn't immediately drop
after defeating an enemy stack.
Revolution turns: The negative spikes are ugly, and confusing because revolution turns
aren't always sampled when drawing the curves.
Tbd. "GNP" is a bad name because "Goods produced" would have to be included in a GNP.
Showing yield icons instead of the words "production", "culture" etc. would be nice, but
it seems that the Python drop-down menus don't support icons in their labels.
See also 077 makes lets the “Demographics” tab use the moving averages of the “Graphs” tab.
That change also uses some of the same game text as 004s.
038 uses the GNP curve to determine which civs are "wealthy".
132 uses the GNP curve to predict the cost of anarchy.
UWAI uses the GNP curve for converting war utility into trade value and vice versa,
and the production curve for estimating military build-up.
Moved the player statistics into a separate class The mapping of turn numbers to statistical data is
and switched to a more efficient data structure. handled by an STL hash map.
As a side-effect, the graphs on the Info tab no
longer show a discontinuity when the active
player is switched through Alt+Z.
Rationale Now that the AI accesses this data, the access needs to be fast.
See also advc.opt: Other performance optimizations.
126
If the “Click Map to Exit” option is disabled (City The city screen can always be exited through
tab of the BUG menu, enabled by default), then middle-click, left-click on the mini-map, Esc,
the city screen can't be (accidentally or Enter, Space, by selecting a garrisoned unit or by
deliberately) exited through a left-click on a tile accessing an Advisor screen through a function
outside the city radius. Double clicking outside key. Left-click on a non-workable tile also exits
the city radius always exits, and all other the screen; since the BtS expansion, there is an
methods for exiting the city screen also work as XML switch to disable this.
before.
CITY_SCREEN_CLICK_WILL_EXIT in XML no
longer has any effect.
The flashing text "Press <Esc> to return" is no
longer shown on the city screen.
Rationale Happens too easily by accident. Especially annoying when the city has just been given
production orders because, then, the next popup will appear before the player gets a
chance to re-enter the proper city screen.
Apparently, the original developers wanted the game to be playable without a
keyboard and with just one or two mouse buttons, and I agree with that – fortunately,
one can still exit the city screen by clicking on the mini-map. Not very intuitive, but
neither is clicking on an unworkable tile.
Since AdvCiv 1.0, the option is enabled by default (i.e. for new installations) because
players kept getting confused by not being abloe to exit and weren't aware of the
option.
Config This change has (understandably) kept bothering players, so I've moved the option
from XML to the BUG menu (City tab).
See also One of the CFC posts inquiring about the click-to-exit behavior. I think there were two
other such posts over the years, one by keldath.
002n disables the flashing end-turn message.
Double click on the city tile no longer exits the When the city screen is up, a single click on the
city screen. Instead, right-click on the city tile (citycity tile re-enables citizen automation if it has
center) exits the city screen. A single or double been disabled. A double click does that too
click on the city tile toggles citizen automation before exiting the city screen.
once. (A slow double click toggles it twice.)
If a working city has been assigned to a tile
manually, right-click undoes this assignment.
When right-click is used for exiting, the camera After exiting the city screen, the camera always
centers on the city tile afterwards. center on the selected units (if any).
Rationale Normally, a player that isn't aware of the single click behavior will notice that citizens
are being reassigned, but if the city screen is exited in addition, the player may easily
not notice his/her accident.
Right-click on the city center didn't do anything previously because the working city of
the city tile itself can't be changed. The camera jump is usually annoying, however,
when inspecting the capital through the flag button (i.e. without moving the camera
over the capital first), then jumping back to the selected units is welcome. So I don't
want to disable that. (Ideally, perhaps, the camera would always return to its previous
locations, but I don't think that can be implemented.)
Tbd. Can I somehow tell when a city screen has been entered from the Domestic Advisor?
In that case, exit via right-click should work the same way as the other methods, i.e.
127
should not move the camera.
128
004w Removal of unnecessary help text
AdvCiv BtS
For buildings already completed, don't show Help text for buildings in a city's building list
requirements in help text, and don't show if it's a shows e.g. that the Palace requires at least 4
unique building, if it founds a corporation, if it cities and that the Trading Post is a unique
starts a Golden Age, if it centers the map, if it's building replacing Lighthouse.
required for another building, if it can be built by a
Great Person.
Help text for wonders and projects only says how Says e.g. "Wold Wonder: 1 Allowed" or "(National
many instances are allowed if more than 1 Wonder: 0 Left)".
instance is allowed, which is only the case for
some spaceship parts.
The remaining slots for National Wonders are "2 Left" would mean that two more cities can
only shown in help text on the city production build the given wonder. The number of remaining
buttons, not on the list of completed buildings, national wonders per city is only shown once it is
and e.g. "2 Left" means that two more national maxed out.
wonders can be built in the selected city.
Show "0 left" in red when a wonder is already in The reason why a building can't be constructed is
production in another city. normally shown in red but not in this case.
Civiliopedia no longer shows whether a building
appears for free when starting in a later era.
Some abilities that require a tech are not shown E.g. Work Boat: "Can Create Oil Rig" shown in
in help text when the player's era is more than 1 the Ancient era.
behind the tech era.
"Open Borders to Alexander for Open Borders"
Active dual deals (peace treaty, OB, DP) shown
as e.g. "Open Borders with Alexander".
Rationale This text is at best distracting, at worst misleading.
The number of remaining national wonders per city is especially helpful for One-City
Challenge.
See also 004a removes "can be researched by a" from technologies.
002b (larger fonts) makes it a bit more urgent to reduce the amount of help text.
History Rewritten explicitly displays the remaining slots for national wonders on the city
screen (screenshot). Shouldn't be necessary in AdvCiv (now that the help text is
improved).
Help text for obsolete buildings in the building list No indication in the building list whether a
of a city says that it's obsolete. building is obsolete.
The word “obsolete” is only shown in red when a
building is already obsolete. Otherwise e.g.
“Obsolete with Scientific Method” “Obsolete with Scientific Method”
Tech requirement of Temple is shown in hover It's a special building requirement; must've been
text. overlooked somehow.
Rationale While I was at it.
See also 097 grays out the names of obsolete buildings on the city screen.
Help text for resources overhauled – some inappropriate text removed but also a fair amount of
text added.
129
See also In part dependent on 073, which merges the trade denial hovers from BULL and
replaces one of the columns of the “Resources” tab on the Foreign Advisor screen.
036 also adds information to the resource hover text (only on the Foreign Advisor).
003p caches the help text for the Resource layer. Without that change, there would be
a noticeable delay whenever the Resource layer is enabled or updated. 003b also
improves performance a bit by caching the number of teams ever alive. (That number
is needed by CvGame::canConstruct.)
047 revises help text for resource tiles.
Help text for resources omits health and E.g. shows “+1 health from Supermarket” for Pig
happiness effects from obsolete buildings, from already at the start of the game, and lists all
buildings whose tech era is more than one era seven Cathedrals for Incense.
ahead of the player's current era and from
buildings that require religions which the player
doesn't have access to.
The tech to reveal a resource is only shown if the Will say “Revealed by Animal Husbandry” for
player doesn't have that tech yet. Horse for the entire game.
Tile yields of resources are only shown in Always shown, but K-Mod has added “on plot” to
Civilopedia text and when inspecting resources clarify that the yield can't be traded.
on the map.
On the main map and city screen, the number of “(firpo has 1)”
resources owned by the active player is stated as
e.g. “(we have 2)”, and, on the city screen, it's
only shown when the number isn't 1.
On the “Resources” tab, the help text for the
export columns (cf. 073) says how many The other player's resource counts are only
resources the other players own. shown on the Trade screen.
See also 074 excludes must-be-joking resources from the Trade screen, meaning that the AI
resource counts aren't necessarily visible there.
Tbd. For religions, it would be better to list the religious buildings under a single name, e.g.
“+1 happiness from Cathedral” with all religion icons listed in parentheses after
“Cathedral” (all in one line). Eventually, I want to move the happiness ability from the
Cathedral buildings to the Temple buildings, and then it would be better to show it from
the beginning of the game, even if no religion has been founded/ spread yet.
For a clean implementation of this, the happiness ability should be moved to
CIV4SpecialBuildingInfos.xml.
When trading (Trade screen or “Resources” tab), the surplus health and happiness of
the capital should perhaps be shown in help text. E.g. “Sheep +1 health (Rome has +5
health).” I think BULL does something similar but uses the smallest surplus among the
active player's cities.
Help text for resources shows buildings, projects Only tile yield, tech-to-reveal, active corporations,
and units that are affected by strategic resources,happiness and health effects are shown in help
so long as they're not too far in the future, text.
obsolete or in some other way irrelevant.
The names of boosted buildings that are
currently under construction are highlighted;
exception: Not in the resource “bubble” text on
the main interface because it's too difficult to
keep that up-to-date (cf. 003p).
130
Rationale After removing tile yield and tech-to-reveal info in most situations, the strategic
resources had only their names left. The new info should be helpful when deciding
whether to trade away a non-surplus strategic resource.
When the city screen is up, the effects shown in Help text for resources is not based on the
resource help text are based on which buildings selected city. Will e.g. say “Clam +1 health; +1
and units the selected city can produce. Buildingshealth with Harbor” in a landlocked city that
that the city already has are shown in green, and doesn't have a Harbor and won't ever have one.
buildings that the city doesn't have but could
have someday, in red, e.g. “Wine +1 happiness;
+1 health from Grocer”.
Shortened help text for production modifiers from resources and traits by replacing the word
“production” with the hammer icon and omitting the word “speed”.
Production modifiers from traits are shown in All production modifiers from traits are shown in
hover text for building and unit buttons (e.g. on Civilopedia (regardless of the active player's
the city screen) if they apply, i.e. if the active traits), but, on the city screen, only production
player has the proper trait. modifiers from resources are shown. The impact
of traits can only be inferred from the predicted
production turns.
Rationale The trait production boosts are difficult to remember, so highlighting them on the city
screen is very helpful I think.
Stats on unit pane:
Don't show a row for movement points for ICBM; Immobile units (ICBM) and air units are show as
for air units, replace that row with a row for air having 1 movement point. Air range isn't shown.
range.
Don't show a row for XP level when the selected A level is always shown; 1 by default.
unit has 0 XP.
See also 004y (unit stats on Sevopedia) about the movement / range info.
Rationale Level 1 generally isn't interesting; even a bit confusing when a player isn't sure if levels
start at 0 (they don't). Still, once a unit has XP toward level 2, it's probably better not to
hide the level. Moreover, the XP check is a good way to always hide the level of
missiles and civilian units. (Well, not absolutely always; if a mod-mod allows e.g. Spies
to gaher XP, then the level info will appear.)
AdvCiv BtS
When a choose-tech popup is launched or the When research finishes on a tech and no tech is
player chooses a tech, all pending choose-tech queued for research, a choose-tech popup is
popups are killed. launched and appears minimized at the start of
the next turn (if playing with the "minimize
When a change-civics popup is launched or
popups" option; otherwise there isn't a problem).
civics are changed, all pending change-civics
For each additional tech that the player receives
popups are killed.
through e.g. tech trade before choosing his/her
When a change-religion popup is launched or the next tech, another minimized popup is launched.
131
player converts to a religion, all pending change- All but the latest popup will show outdated
religion popups are killed. research options (not taking into account all the
additional techs discovered). Once the next tech
When anarchy breaks out, all choose-production
is chosen, any remaining popups disappear once
and choose-tech popups are killed. They
maximized.
reappear when order is restored.
Similarly, multiple change-civics and change-
religion popups can appear and don't disappear
when the player changes civics/ religion through
an advisor screen.
I don't think multiple choose-production popups
for the same city can appear, but the single
popup fails to disappear when the player
chooses production through the city screen.
Rationale I'd actually prefer to allow multiple change-civics and change-religion popups, but it's
difficult to do this consistently as there appears to be a mechanism in the EXE for
preventing multiple change-civics popups, it just doesn't always work. E.g. after
discovering Feudalism, BtS shows only one popup for Serfdom and none for
Vassalage (intended behavior I think, but I'd like it better to also have a popup for
Vassalage), but when trading for, say, Code of Laws while the change-to-Serfdom
popup is waiting, another change-civics popup will appear for Caste System (OK, but
inconsistent with the missing Vassalage popup).
See also
During anarchy and before the first city is The BASE_RESEARCH_RATE (set to 1 in the Vanilla
founded, civs have 0 research rate and GlobalDefines.xml) applies even during
production rate, and the research bar shows the anarchy. When no tech is chosen during anarchy,
remaining anarchy turns even if no tech is choose-tech buttons are shown on the research
currently selected. All game text that normally bar. Game text shows the remaining research
shows the remaining research or production and production turns based on a rate of 1 per
turns doesn't show that information when the rate turn during anarchy.
is 0.
When the BASE_RESEARCH_RATE is active (i.e. The research rate on the main interface shows
once a city has been founded and while not in only research from city commerce.
anarchy), the research rate shown on the main
interface includes the 1 free beaker.
Rationale During anarchy, the turns to complete can't be properly computed, therefore, research
and city production shouldn't be chosen. Setting the research rate to 0 makes it easier
to communicate this, and makes sure that there is no incentive to choose research.
Tbd. Get rid of the BASE_RESEARCH_RATE. Can instead increase the commerce from Palace
by 1 or even 2, which will make Gold, Gems and Silver less powerful. That said,
commerce modifiers in the capital would become even more powerful this way, so
perhaps give Palace 10 commerce minus 1 for every other city, or
5 + max{0, 5 - number of other cities}.
When the Pyramids or Shwedagon Paya is Buildings that unlock an entire column of civics
completed, a change-civics popup is shown don't trigger a change-civics popup.
unless the player already had access to all
Government/ Religion civics.
When a new civic becomes available (through a
technology or a wonder) at a time when no
revolution is possible, then the popup is delayed
until the player can change civics again.
132
When the game starts in an era later than No such popup. It's normally best to change
Ancient, a change-civics popup is shown on the civics on the initial turn – but easy to forget.
initial turn.
Rationale I've forgotten about switching civics after completing the Pyramids one time too many.
Tbd. Should also delay change-religion popups. Could then, as part of an overhaul of the
leader traits, restrict the fiddly ability of the Spiritual trait so that a free revolution is
allowed only on a turn on which a change-civics or change-religion popup occurs (and
perhaps once per era in addition).
When the active player enters the Civics screen, all minimized change-civics popups of that player
are canceled. Same for the Religion screen and change-religion popups.
Rationale The player probably noticed the new civic or religion when or before viewing the
respective screen, making the popup reminder unnecessary.
133
Rationale There are other empty boxes in Civilopedia too, but this one doesn't have a self-
explanatory name, so it can be confusing if empty.
On terrain improvement pages: “Improvements” The first box lists base yields and yield enabled
box renamed to “Improvement Yields” and by technologies, the second one lists special
“Bonus Yields” to “Bonus Resources”. yields from bonus resources.
Rationale The first box needs to say something with “yields” for clarity and then the second one
shouldn't also say “yields”.
Civilopedia lists (when clicking on a top-level category like "Units" or "Wonders")
AdvCiv BtS
Show production costs of units in hover text (but Only shown inside the unit articles.
not under “Special Abilities”).
When Civilopedia (or Sevopedia) is accessed The number from Civ4BuildingInfos.xml is
from the opening menu, show number of requiredshown, which corresponds to Duel map size. E.g.
buildings as e.g. "Requires University: 4-6". "Requires University (4 Total)".
Also show other numbers that depend on the
map size as a range.
See also 140: Changes to map size adjustment multipliers.
008: Changes to Civilopedia content
AdvCiv K-Mod
Sevopedia (with alphabetical sorting) enabled by Disabled by default.
default.
As a result, when entering Civilopedia from the If Sevopedia is enabled from the BUG options
opening menu without having started or loaded a menu, the BtS Civilopedia is still shown when
game first, Sevopedia is shown regardless of the entering Civilopedia directly from the opening
setting in the BUG options menu. Sevopedia thenmenu. The Sevopedia setting in the BUG options
remains enabled until Civ 4 is restarted. Added a is then permanently ignored: Sevopedia remains
warning about this to the hover text of the disabled even after restarting Civ 4; only toggling
Sevopedia option on the BUG menu. the checkmark in the BUG options menu twice
brings it back.
Sevopedia doesn't list e.g. Ruins under
"Improvements"; only improvements that civs can
actually build.
See also Enabling Sevopedia by default (which I'd want to do in any case) more or less fixes
this open K-Mod issue.
Tbd. Would be nice to use the INTERFACE_GENERAL_CIVILOPEDIA_ICON instead of the
commerce icon for the Hints and Concepts sections on the index. That would have to
happen in SevoPediaIndex.py under type == "Concept", but can I simply use
addDDSGFC there?
Don't list “Minor Nation” in the “Civilizations” category. Continue listing the Barbarian civ there.
Rationale For the Barbarians, there is sensible strategy text; they're supposed to appear there.
Not so for the Minor Nation; moreover, that civ only appears in some official scenario (I
guess?), not in regular games.
Unit stats: Don't show strength for nukes; Nukes are shown as having 0 strength;
don't show movement points for air units; air units and immobile units (ICBM) are shown as
show “immobile” for ICBM and “unlimited” range. having 1 movement point; ICBM is shown as
having 0 range.
Rationale The Sevopedia info was, in a way, technically correct – but confusing. Showing
134
meaningful ICBM stats could actually be useful for new/ returning players; not obvious
how that unit works.
See also 004w makes similar changes on the main interface.
rheinig's mod (see advc.rh) shows “immobile” as a special unit ability instead.
Show production cost as the final stat. AIr range is shown below production cost.
Rationale Cost shouldn't be mixed in with the benefits.
Put a gray panel behind the list of hints; same style as in the BtS Civilopedia.
Rationale The white text was too hard to read on the beige background.
The box with the strategy help and historical The box has the title "History" and the historical
background has the title "Background" and the background section has the heading
historical background section has the heading "Background".
"History".
Rationale Strategy advice doesn't fit under "History".
Config Through Civ4GameText_advc.xml
Sevopedia categories for keyboard shortcuts and K-Mod has disabled these; explanation.
leader traits restored. Removed mention of
There is a GameFont icon for each trait shown in
shortcuts that AdvCiv doesn't support. Removed
the list of traits (I didn't remove those icons) and
the trait button icons.
a button icon shown in the article. All the icons
are reused, e.g. the “Heal” action button for the
Still disabled: Strategy advice for the traits and Expansive trait.
the category for strategy articles.
Rationale The traits category comes with strategy advice, which is tedious to keep updated, so
I've kept that aspect disabled.
Trait buttons with hover text could be useful elsewhere in the UI, but unique icons
would be needed for that, and currently there is no hover text, so the Sevopedia trait
buttons serve no real purpose.
Config To remove these categories again, it's probably easiest to comment out one or two
lines in setPediaCommonWidgets (SevoPediaMain.py). Adding the
TraitsPedia_CIV4GameText.xml file from BUG should suffice to restore the strategy
advice on traits.
Credits The shortcut lists are originally Ekmek's work, the traits Sisiutil's. A couple of shortcuts
that I've added I got from dj_anion's BtS reference guide.
See also 002b: Had to add/remove some tabs to get the shortcut info properly aligned.
Tbd. I've only made stylistic changes to the English version. The other languages probably
include some mistakes (because their keyboard layouts are different).
The shortcuts should be ordered by effect, not by the key combination. People don't
consult Civilopedia to check what a particular key combination does, they want to
know whether there's a hotkey for a certain effect.
Would be nice to add a subcategory for cheat/ debug shortcuts (see 007b).
Added a box named “Changes” for pointing out balance changes to traits made by K-Mod and
AdvCiv. And articles about civics now include strategy help texts (previously only shown as a short
summary in change-civic popups) with notes about K-Mod and AdvCiv changes appended.
Tbd. Several other categories of articles still lack a space for balance changes: promotions,
improvements, specialists, projects, corporations, leaders (would be nice to mention
significant changes to the AI behavior of individual leaders).
135
Opening an Advisor screen no longer causes the Civilopedia button to be hidden.
Rationale Hiding the button means that an extra click is required to get from an Advisor to the
Civilopedia. Ideally, the Advisor screens should include direct Civilopedia links to all
relevant information, but that isn't currently the case.
136
giant flag button, there's still room for plenty of layer buttons. Doesn't seem trivial to
implement though.
The Resource layer also highlights goody huts Highlights only resources. Tribal Villages aren't
when the "All Resources" option is selected. The highlighted by any layer. If UAR are enabled,
unit action recommendations (UAR) option Tribal Villages are highlighted with a blue circle
causes huts to be highlighted when any nearby when a nearby Recon unit is selected.
combat unit is selected (can be a Recon unit, but
doesn't have to be).
Rationale/ Normal map scripts don't place a hut and a resource in the same tile, so the Resource
See also layer seems like a good place for highlighting huts. 315 increases the size of the
goody hut 3D model, but they're still a bit hard to see on Forest tiles.
Until AdvCiv 0.99, the Resource layer had shown huts only when UAR was disabled. A
circle and an indicator bubble is arguably too much highlighting, but let's let the player
decide that.
In any case, entering a nearby hut with a Warrior is usually a good idea, so UAR
shouldn't be restricted to Scouts.
Config Option on the “Map” tab of the BUG menu
The “normalization” step after the assignment of The only way that a resource can coexist with a
starting locations tries to avoid placing resources goody hut on a map generated by one of the
on goody huts and removes the hut if it can't be official or bundled map scripts is through the
avoided. normalization step.
Rationale Don't want resources and huts in the same place because the resource layer can't
show both.
See also 108 deals with other changes to the normalization step.
The Trade layer colors all revealed tiles The Trade layer colors only tiles owned by the
according to the trade network grouping except (human) player's team.
some very small groups like water tiles enclosed
by sea ice.
Cities that are actively visible to the player (i.e. No special marker for disconnected cities.
not fogged) and not connected to their owner's
capital are marked in black.
Rationale I think this layer is used (if ever) for getting a better understanding of the trade group
rules. Showing trade along unowned coasts (with Sailing) should be an improvement.
It would be nice if the layer could also show the trade networks of rivals – in BtS, the
coloring is entirely based on the player's civ. The problem with showing rival networks
is that it can give away information about unrevealed coastlines and routes. Therefore,
I'm only providing info about currently visible cities. The black mark should be helpful
for verifying that an enemy city has been cut off from the capital, e.g. through a naval
blockade.
See also 124 allows only revealed routes to carry trade. Without this, the Trade layer coloring of
tiles owned by other civs would give away routes on fogged tiles.
Config GlobalDefines_advc.xml
The Unit layer option for showing non-military Called "Domestics". Some commented-out code
units is called "Civilians". The indicator bubbles suggests that, in some earlier version
show a non-military unit. If multiple non-military (Warlords?), only units within the active player's
units are present, the shown unit is selected borders were shown, but BtS highlights all tiles
based on a priority list (from highest to lowest): with visible non-military units. The plot indicator
Great Person, Settler, Spy, Missionary/Executive, on a highlighted tile shows the tile's top defender.
137
Worker/ Work Boat. That's a military unit when the tiles contains both
military and non-military units. Air units aren't
Air units are considered military units.
recognized as military units.
Rationale The name "Domestics" doesn't fit anymore in BtS, and it shouldn't show bubbles with
military units – it's counterintuitive and makes it difficult to locate Spies (which are
usually in cities together with military units).
For fogged tiles, the culture layer uses only the The culture layer doesn't distinguish between
color of the last known owner at a fixed fogged and actively visible tiles. Shows the colors
brightness (alpha value). of up to four civs that have culture in the tile. The
brightness is set based on the culture values.
Outside the culture layer, culture percentages are
shown in hover text for actively visible tiles,
whereas, for fogged tiles, only the last known
owner is indicated (through cultural borders).
Rationale There's no need for letting the culture layer (partially) bypass the fog-of-war rules. In
fact, the map looks tidier with mono-colored tiles in the fog of war.
Perhaps a significant culture percentage (say, 20%) should grant visibility. Then again,
it's not too unrealistic that the ruler of a civilization wouldn't know all the places that the
civilization's culture (or ethnicity) has spread to.
See also 001f reveals the new owner of a fogged city after conquest by a third party. In that
case, BtS is quite restrictive about revealing cultural ownership in fogged tiles.
Tbd. Add indicator bubbles for (actively visible) cities with a positive revolt chance (icon
civics_popup.dds?), cities in occupation (that orange fist icon), with hover text
stating the revolt probability and occupation countdown, and cities relevant for culture
victory (how to measure that?), especially foreign cities, which aren't covered by the
Domestic Advisor. Would have to review the code that sets the globe layers dirty-bit
(see 003p).
AdvCiv K-Mod
The culture layer shows the tile owner's color Only the colors of civs with at least 20% tile
even if that civ has less than 20% tile culture, e.g.culture are shown.
right after conquering a faraway city.
Rationale Since borders aren't shown in Globe view (and can't be shown through the SDK), the
Culture layer is the only way to highlight territories in Globe view. Too easy to overlook
a recently conquered area when it is shown entirely in other civs' colors.
See also 099f shows culture on unowned tiles in tile hover.
AdvCiv BtS
When the culture of multiple civs is displayed on The colored area is split evenly among the civs,
a tile (see conditions above), the colored area of with ties broken in favor of the lower civ id. The
each civ corresponds to that civ's culture percentages are only indicated through
percentage. For example, a tile that is 75% brightness.
Egyptian and 25% Japanese is shown as 3 parts
yellow and 1 part red. 2 parts yellow, 2 parts red
Rationale The differences in brightness are very subtle, almost useless really for multi-colored
tiles. After my change, it's easy to tell which tiles are contested, and which ones have
only a significant minority culture.
Credits Prompted by this old CFC succession game. Several players complained about the
culture layer in K-Mod.
138
005 Minor flavor changes
"Sumeria" changed to "Sumer"
Rationale Seems to be much more common (also in German and Italian). Wiktionary lists
"Sumeria" only as "(archaic, poetic) Sumer." And brevity is always good.
“Pacal II” renamed to “Pacal”
Rationale According to Wikipedia, the earlier Pacal wasn't necessarily a king; the article refers to
our Pacal (the Great) simply as “Pacal.” Simpler names are better. I haven't renamed
“Montezuma” to “Montezuma II” – although he is as much a second as Ramesses II,
Mehmed II, Suryavarman II and Joao II – because it would be a complication and also
because the the proper name would really be “Moctezuma II,” which might confuse
players.
“Asoka” renamed to “Ashoka”
See also Discussion (near the middle of the post)
(I wasn't going to make this change at first, but it doesn't seem too difficult after all too
get used to the spelling change.)
“Justinian I” renamed to “Justinian”
Rationale Justinian II is also an important figure, but not as important as Justinian the Great, and
also isn't the kind of ruler that would be included in a Civ game. So players should
have no difficulty deciding which Justinian is meant, and the name looks a bit too long
with the regnal number.
About Cyrus II, it's more difficult to decide. Leaving out a regnal number other than “I”
seems problematic – though there is precedent in Montezuma, and Cyrus I is much
less significant than Cyrus the Great.
See also 002b also shortens some leader names (for lack of space)
005a Leader personality tweaks
AdvCiv BtS
MaxWarMinAdjacentLandPercent=2 for Bismarck. Was 0. It's a preference for long-distance land wars, ranging
While he eventually gave up his reluctance to off-shore between 0 and 4. 0 means Bismarck treats neighboring civs
colonies, he was never keen on distant parts of Europe (let no different from other civs on the same continent when it
alone Asia): "The Balkans are not worth the healthy bones comes to war planning.
of a single Pomeranian grenadier." The Realism Invictus
mod even sets it to 4.
Also lowered his attitude threshold for defensive pacts to Threshold is at Pleased, like most other leaders.
Cautious (realpolitik, Triple Alliance), and increased his
Victory condition weights have been added by BBAI. I don't
weight for diplomatic victory and lowered the one for
think they actually have a big impact on the game.
domination victory. Conversely, gave Brennus higher weight
for domination and lowered weight for diplo.
While I was at it (further minor changes): Shifted Catherine's
weights from conquest toward domination and science.
Added a bit of science weight to Ramesses, and reduced
his conquest weight. Increased Saladin's weight for
diplomacy a bit at the expense of conquest and space.
Was 100. A preference for naval war. Napoleon is tied for
MaxWarDistantPowerRatio=70 for Napoleon.
the highest value, while his MaxWarNearbyPowerRatio
Napoleonic France fought few off-shore wars and even (land wars) is only moderate.
ceded Louisiana to the US.
MaxWarMinAdjacentLandPercent=2 for Charlemagne Was 1 and 3 respectively.
and Cyrus. Charlemagne extended his borders gradually in
all directions; Cyrus conquered several empires that weren't
exactly at his doorstep.
139
MaxWarRand=150 for Willem, i.e. now a bit less willing to start Was 100.
"total" wars. In part, because wars of conquest seem out of
character for the small Netherlands; in part, because he's
doing a bit too well in AdvCiv games in my experience (and
more so than other Financial leaders).
Was 80, tied for the lowest value with Alexander, Louis,
Also shifted his victory weight a bit from Conquest to Culture
Mao, Montezuma, Qin, Victoria. 90 is the same as the other
and made him a little less interested in dogpile wars. And
19 leaders who attack when Pleased
increased NoWarAttitude when Pleased to 90.
Was 90 at Pleased, 50 at Cautious, 20 BuildUnitProb.
Increased Roosevelt's NoWarAttitudeProb at Pleased to
Was 70 (Brennus, Cautious) and 100 (Darius, Pleased).
100 and at Cautious to 70 but increased his BuildUnitProb
to 25. Decreased NoWarAttitudeProb for Brennus at
Cautious to 50 and for Darius at Pleased to 90.
Embargoes against Gandhi carry no penalty for either side.
Negotiating a trade embargo against Gandhi results in a -1 Voting against him carries the usual -2 penalty.
relations penalty. Agreeing to an embargo against him still
carries no penalty. Gandhi doesn't mind being voted against.
Buddhism. Primary Gold, secondary Culture. Gandhi is the
Suryvarman's favorite religion is Hinduism, primary flavor is only Hindu.
Religion and fav. civic Caste System. He was a Hindu and Fav. civic: Organized Religion; Wang Kon is the only Caste
built large temples. (Some later Khmer kings were System proponent.
Buddhists.)
Each leader (except Hatshepsut) has 100% weight bonus
Overhauled Unit AI weight modifiers and reduced their for one particular Unit AI type, namely Worker (Pacal,
impact to at most +50% per Unit AI type. And two small Frederick, Gandhi), Explorer (Mansa Musa), Attack
accompanying changes to CvPlayerAI::AI_unitValue. (Alexander, Brennus, Cyrus, Hannibal, Justinian,
Also overhauled AI improvement weight modifiers and Montezuma, Peter), Attack City (Augustus, Chalemagne,
increased their impact to up to 30% per improvement type. Kublai Khan, Louis, Suleiman), Counter (Catherine, Julius,
Napoleon, Roosevelt, Saladin, Wang Kon, Willem), City
See also: 131 makes minor changes to AI_bestUnit, and Counter (Darius, Huayna Capac, Lincoln, Tokugawa), City
AI_getImprovementValue (both in CvCityAI.cpp), the Defense (Churchill, Gilgamesh, Hammurabi, Sitting Bull,
functions that apply the weight modifiers. Zara Yaqob), Reserve (Ashoka, Ramesses, Suryavarman,
Civ 4 Reimagined has also overhauled unit and Washington), Pillage (Boudica, Genghis Khan, Mao, Shaka),
improvement weight modifiers: Git commit Collateral (Bismarck, Mehmed, Qin), Attack Sea (Isabella,
Pericles, Peter), Reserve Sea (Victoria), Assault Sea
(Ragnar), Explore Sea (Elizabeth, Joao), ICBM (De Gaulle).
31 leaders have 10% weight bonuses for one or two
improvements, namely Farm (Bismarck, De Gaulle, Shaka),
Farm & Windmill (Brennus, Boudica, Churchill, Elizabeth,
Willem, Napoleon, Peter, Pericles, Cyrus, Hammurabi,
Mehmed, Suleiman, Isabella, Joao, Pacal, Washington),
Cottage..Town (Darius, Frederick, Huayna Capac, Ragnar,
Victoria, Wang Kon), Cottage..Town & Windmill (Gandhi,
Hannibal, Lincoln, Mansa Musa), Workshop & Watermill
(Mao, Stalin).
Rationale Roosevelt change: 90/50 NoWarAttitudeProb is the same as the Mongol leaders or
Napoleon. Some peaceful leaders like Mansa Musa and Elizabeth also have it, but
along with a low BuildUnitProb. This makes for leaders that are ruthless but powerless.
This doesn't fit for Roosevelt at all. He's the leader most representative of the present-
day America that doesn't invade partners, but has a big military. Changed Brennus and
Darius to keep the overall balance. I don't know if that balance is exactly right, but, if
anything, there are too many leaders that don't normally attack at Pleased.
Suryavarman's fav. civic: Asking others to change into Organized Religion (or
Theocracy, Pacifism) generally doesn't make much sense unless the state religions
happen to match. This was especially annoying in Sury's case because his change-
civics requests apply a -2 relations penalty when rebuked.
Unit AI weights: Doubling the weight seems extreme, and, for most leaders, a
preference for a particular Unit AI type doesn't even make much sense. See
Civ4LeaderHeadInfos.xml for the new weights and some handwave rationales. I've
tried to avoid reinforcing the AI type(s) of the unique units because the AI already
trains these more frequently than the unit stats would justify. About Worker weights,
note that Workers are rarely trained through AI_bestUnit, so these have very little
140
impact. This may also apply to other unusual bonuses (e.g. Spy).
Improvement weights: I can't make much sense of the BtS weights. Looks like the AI
didn't build enough Windmills and the developers decided to amend this through
weights for all civs that have ever built windmills. This reason should be obsolete
because of K-Mod changes in the DLL, and 10% is very little (it said 20% in XML, but
the DLL halved that). I've given most leaders two 20% bonuses (no longer halved),
and some a single bonus of 30%. The impact of these bonuses still seems very small,
perhaps too small. The choice of the improvement is now vaguely based on the
leaders' historical policies. I didn't take into account whether an improvement supports
a leader's traits, favorite civics or playstyle; the DLL can handle that, and I don't want
to make the playstyles (even) more predetermined.
Tbd. Considering (low-key) changes to make certain leaders more distinct, improve
historicity and to increase the number of warlike leaders. Under consideration for
becoming more dangerous: Augustus, Brennus, Cyrus, Darius, Churchill, Frederick,
Hammurabi, Justinian, Ramesses.
Willem is still too aggressive. May need a thorough overhaul to become a small civ
interested in culture and only slightly feisty.
Increased cap for the relations penalty from 2 for Mao, Stalin and Darius, 4 for Qin, 3 for
shared borders to 3 for Mao, Stalin and Darius, Roosevelt. The cap is between 1 (only Willem
and decreased the cap to 3 for Qin and to 2 for has this value) and 4 (most of the typical
Roosevelt. warmongers).
Rationale Modern China has plenty of border problems with pretty much all its neighbors. In
Mao's time, border tensions with the Soviet Union escalated. Stalin was impossible to
get along with for his western neighbors. I'd set both caps to 4, but that change would
be a bit drastic. Both Persian kings invaded most of their neighbors, but let's keep
Cyrus somewhat peaceable for now. To counter the increased caps, I've reduced
Roosevelt (I don't see why he should be particularly sensitive about border tiles) and
Qin. The Qin dynasty secured its northern border with the Wall, but that doesn't quite
justify a cap of 4. And it's strange to give Qin a higher cap than Mao.
Partially revised the CONTACT_DEMAND_TRIBUTE A high divisor means that the AI leader is unlikely
divisors. to demand tribute.
Ragnar, Mehmed, Shaka, Kublai Khan and All five 1000.
Brennus set to 25.
Montezuma set to 50. 25
Charlemagne, Wang Kon, 1000, 1000,
Hammurabi, Gilgamesh, Suryavarman, 500, 500, 500,
Joao, Julius Caesar, 50, 50,
Napoleon and Genghis Khan set to 250. 25, 25 respectively.
Louis set to 500. 50
Catherine set to 750. 50
De Gaulle, Sitting Bull and Isabella set to 1000. 25, 25 and 50.
Rationale For change 079 (bragging about units based on the demand-tribute divisor), I'd like
early warmongers to have a low divisor so that they blab. That said, the divisors also
need to make sense historically, which, to me, wasn't the case at all in most of the
cases that I've changed. In that regard, it should matter e.g. whether the ruler or the
dynasty he or she represents had exacted tribute or similar payments (though tax-like
tribute from provinces or satrapies shouldn't count) and if tribute was customary in
their cultural area. It can make sense to let leaders that represent non-expansionistic
powers ask for tribute frequently – they prefer tribute over conquest, and vice versa.
141
However, for modern peaceful leaders (e.g. Lincoln; not changed), it makes more
sense to let them start wars (for reasons that are somehow principled) than to let them
extort payments.
Tbd. I'm also not happy with most of the 33 leaders that I haven't changed. Should address
those as part of a comprehensive leader overhaul.
See also 104m adjusts the probability for an AI tribute demand based on war utility.
Gave Gandhi the highest no-war percentage at Pleased/Cautious/Annoyed/Furious
Annoyed attitude, namely 50, the second highest Gandhi: 100/70/30/0
at Cautious (85 after Sitting Bull who has 90) and Sitting Bull: 100/90/50/0
made him the only leader with a no-war Lincoln: 100/80/40/0
percentage at Furious (20) and greater than 100 Justinian: 100/80/30/0
at Pleased (110) and Friendly (115). Decreased For reference:
Sitting Bull's percentage at Annoyed to 40 and Ashoka, Augustus, Churchill, Cyrus and
Lincoln's to 30. Also decreased Justinian's several others: 100/70/20/0
percentage at Cautious to 70.
Rationale A faithful representation of Gandhi should arguably never start a war when more
favorable than Furious. That said, Gandhi did have a pragmatic side, cf. Gandhi on
Indian involvement in WW2 (Wikipedia). More importantly, players tend to assume that
Gandhi acts very peacefully in the game. In BtS and even K-Mod, his high WarRand
values make it very unlikely for him to start wars and his military budget, the only factor
that can dynamically lower the WarRand values in BtS/K-Mod, is virtually always small.
UWAI introduces a bunch of other opportunistic factors, making the WarRand values far
less relevant in situations when starting a war is highly beneficial. That's also why I felt
the need to go above 100 for Pleased and Friendly. Currently, only UWAI distinguishes
between 100 and values greater than that.
I didn't want to increase the no-war percentages overall – if anything, I feel that they're
too high overall –, so I shuffled them around: Gandhi takes his Annoyed percentage
from Sitting Bull, Sitting Bull from Lincoln, Lincoln from Gandhi. Gandhi (more or less)
swaps his Cautious percentage with Justinian.
Sitting Bull can't be more peace-loving than Gandhi overall. I did preserve his
especially high reluctance at Cautious attitude. Justinian's unusually high no-war
percentages don't seem to have any historical basis. It's OK that he's not supposed to
fight civs that share his religion, but, given his very high SameReligionAttitude
ChangeLimit, Cautious attitude shouldn't affect that behavior. Lincoln: want the 40 for
Sitting Bull. 30 is still unusually high.
005b GP names assigned chronologically
AdvCiv BtS
GP names are assigned in the order they're listedWhen a GP is born, the name is chosen
in Civ4UnitInfo.xml, i.e. roughly ordered by uniformly at random from among the GP with
date of birth; no more Ancient Heisenberg. About matching type. Heisenberg is just as likely to be
every second (based on the number of civs in the the first Great Scientist as Socrates.
game) name is skipped at random, so that GP
names aren't the same in every game.
There is an additional offset when starting in the
Medieval era or later, i.e. early names are
skipped.
Corrected a few misspelled GP names, e.g.
"Frank" Kafka.
Replaced the two Great Generals that also
142
appear as civ leaders with two new ones
(Charlemagne→ Zizka; Boudica→ Hai Ba Trung).
Names of playtesters replaced with actual spies The last 10 names for Great Spies are the real
from the 20th century. names or nicknames of BtS playtesters.
“Malian” as the ethnonym of Mali “Malinese”
Credits The new spy names are taken from a list that etiennefd (Steb on CFC) compiled for
the RFC: Dawn of Civilization mod.
This CFC post by Phil Bowles made me aware that “Malinese” has apparently only
been popularized by the Civ series.
See also 038 picks historians that somewhat match the type of civ ranking (e.g. Machiavelli for
the "most powerful civilizations").
Tbd. Perhaps separate lists of GP names for every civ. DoC should have lists for most civs.
Though I'd like the following better for AdvCiv: Assign a list of GP names to each
technology and pick a name based on the current bulb tech when a GP is born. Use
the BtS list as a fallback (and for Great Generals). May have to add a separate list for
each GP type to each entry in Civ4TechInfo for this.
Another potential name for a Great Spy (from Realism Invictus): Thomas Edward
Lawrence
005c City ruins bear the name of the former city
Help text shows the name of the most recent city The name of the former city isn't recorded
in a tile with city ruins. Can't pillage city ruins, anywhere. Can pillage city ruins (0 gold).
meaning they can only be removed by building
an improvement on top.
Rationale For flavor. No pillaging because the name of a destroyed city could have strategic
importance (albeit very little), and I wouldn't want players to destroy ruins in order to
monopolize information (in multiplayer). Also, while Sennacherib boasted to have
"removed the dust of Babylon for presents to be sent to the most distant peoples," the
idea of pillaging ruins doesn't immediately make sense.
Tbd. Would be nice to explain that ruins can't be pillaged in hover text. Related CFC post
(at the end of “nitpick” item 2)
005d Spurious/ misattributed tech quotes corrected or marked as "ascribed to ..." (only
English and German)
Credits CFC discussion about Civ6 tech quotes: link; offshoot about BtS: link
CFC user Steb pointed out a few more in the Dawn of Civilization subforum: link
005e German text: Changed the name of Galley from "Triere" to "Galeere" and the name of
Trireme from "Trireme" to "Triere" because "Triere" and "Trireme" are synonyms.
The names are also problematic in English: A trireme is a special kind of galley. The
Warlords Civilopedia text says that the Galley unit is supposed to be a pentekonter.
Apparently, they didn't want to give Galley that rather obscure name.
005f City art style based on highest culture
The art style of a city's 3D models is that of the The city owner's art style is used.
civ with the highest tile culture in the city.
Rationale The style of the buildings shouldn't immediately change upon conquest. (It kind of did
in the New World, but in these cases much of the former population and its culture was
also gone.) It's nice to have more traces of the past on the map.
143
Disabled this change again after realizing that there is no way to make the same
change for Cottages, Hamlets etc. Looks like the code in the EXE checks the owner of
the improved tile, calls CvPlayer::getArtStyleType on the owner and uses the
returned ArtStyle. Could, no doubt, fix that through a runtime code change (cf. 092b),
but such an effort isn't quite justifiable.
Config XML switch in GlobalDefines_advc
Credits Idea from Xyth's History Rewritten v1.25
144
Added one text for a declaration of war (DoW) by Actual Quotes pretty much only replaces Vanilla
Gandhi and one by Alexander. text, and there are no leader-specific texts in
Vanilla for DoW.
Rationale I happened to come across some quotes that seemed suitable for those two leaders.
Could be an inspiration for someone to add more leader-specific DoW texts.
006 Assertions
Disabled a few assertions that are supposed to be rare and were still under investigation by earlier
modders, and are probably false positives or mostly harmless and difficult to resolve.
006b Enabled assertions in CvXMLLoadUtility that warn when an XML tag expected by the
DLL isn't found in XML – unless a default value is passed to CvXMLLoadUtility::
GetChildXmlValByName.
Rationale If the tag is defined in the schema, then the EXE will warn about it anyway, but the new
assertions should help when a tag is also missing from the schema and, in particular,
when the tag is mistyped in CvInfos::read(CvXMLLoadUtility*). And they warn
about missing default values for non-mandatory tags – although a default of 0, false
or an empty string as used by BtS is usually fine. I pass default values to
GetChildXmlValByName where they are now necessary.
See also No assertion triggers when a default value is set through xmldefault.
Tbd. Can I somehow warn about tags that are entirely unused?
006c Define assertion and profiling macros as (void)0 when disabled.
Rationale Mainly to avoid errors like this:
if(...)
FAssert(...)
foo();
If FAssert is entirely removed (as in BtS), then the foo call will move into the if
branch without any compiler error.
With my change, macro calls have to be terminated with a semicolon.
006d Warn when reading an XML element with an empty value (e.g. <iMoves></iMoves>)
Credits Adopted from More Naval AI
006e Show current XML file in error messages only if the error occurs while loading an XML
file.
Credits A couple of lines from these two MNAI commits.
See also advc.rh: Adopted a similar (redundant?) change from rheinig's mod.
006f Show the name of the enclosing function in in FAssert popups through the
__FUNCTION__ macro; remove the (now redundant) function name parameter from
FAssertBounds (formerly named FASSERT_BOUNDS).
Credits From Caveman2Cosmos (billw2015)
Tbd. Would be nice to include stack trace as well; that would arguably require some library;
C2C uses Stack Walker.
See also advc.enum introduces a macro for asserting the bounds of info enum types.
006g Show a failed assertion instead of a windows error message (ErrorMessage) when
145
XML loading fails while debugging.
Rationale The assert popup is much more helpful for debugging.
Windows error messages are still shown by the DLL-internal profiler
(CvGameCoreDLL.cpp). I haven't changed those because one doesn't normally debug
while profiling
006h When an assertion fails in a debug build, the condition is evaluated for a second time.
Rationale So that the user can immediately step through the evaluation of the condition. It's not
always obvious why it evaluates to false.
I don't think there's any downside to this. Failed assertions are rare, so performance
isn't consideration. Assertion conditions must never have side-effects. And just
pressing F10 will skip to the line after the FAssert/FAssertMsg call as before.
006i Macro FErrorMsg instead of FAssertMsg(false, ...)
Credits From Caveman2Cosmos: Git commit
006j After storing a simple integer element from XML in an enum variable, the limits of the
enum type are asserted.
See also Based on the enum traits code written for advc.enum.
006k Warn when loading a CvInfo element from XML for a second time despite modular
loading being disabled.
Rationale Not going to leak memory, but probably not intended by the XML modder.
006l Button for stopping AI Auto Play added to the assertion-failed popup.
Credits Based on this WtP commit by Erik. I've done the layout a bit more nicely, and my stop
button only ignores the current failure, not subsequent ones (can use the ignore-
always button for that if the assertion keeps triggering).
146
• Alt-text on the scoreboard shows culture info only when Alt+Ctrl is held or when a civ is close to
a culture victory.
• Don't show espionage help for rival spies; e.g. no “unit has moved/ can't conduct mission”
message in red letters.
• Some changes to the information shown by the contact-player widget on the scoreboard about
unmet players when in Debug mode. (CvDLLWidgetData::parseContactCivHelp)
• Add a bForce parameter to CvPlayerAI::AI_isDoStrategy that CvGameTextMgr and
CvDLLWidgetData can use in order to ignore CvPlayer::isHuman. So that the scoreboard in
Debug mode will show human strategies.
• No time stamps in the BBAI log. (I've never needed them for anything and they're very
annoying when comparing logs in order to debug synchronization problems.)
• The BBAI log only shows game score breakdowns only if an interval parameter is explicitly set
in BBAILog.h.
• Ctrl+Alt while hovering on a capital shows AI tech values (was Ctrl+Shift on any owned tile)
• Need to hold down Shift in order to see stack compare values along with combat odds.
See also 001d fixes some Debug mode bugs in various Advisor screens.
085 shows a score breakdown when Ctrl is held in Debug mode while hovering over a
score value on the scoreboard.
058 deals with concealed player identities – and makes sure that they're not concealed
in Debug mode.
XML switch PER_PLAYER_MESSAGE_CONTROL_LOG for creating multiple MPLog.txt when testing
multiplayer games on a single PC. These will have to be deleted manually. In networked
multiplayer games, the id of the active player always gets appended to the name of the BBAI log
(no XML switch for that one).
Procedure: Set LoggingEnabled=1, OverwriteLogs=1, and RandLog=1 in CivilizationIV.ini.
Will probably also have to set MessageLog=1 and SynchLog=1. Or rather, put these in a copy of
CivilizationIV.ini (say, MPDebug.ini), set Mod = Mods\AdvCiv and FullScreen = 0 in the
copy and place it in the same folder as Civ4BeyondSword.exe; then create a shortcut targeting
"C:\Program Files (x86)\Sid Meier's Civilization 4\Beyond the Sword\
Civ4BeyondSword.exe" ini=advcMP.ini multiple, where multiple is for allowing multiple
instances of the BtS process. Launch the game twice through that shortcut, create a Direct IP
game named chipotle (see 135c) with one process and join it with the other by connecting to
127.0.0.1.
Rationale Need an MPLog.txt from each player in order to debug OOS errors. The BBAI log can
also be helpful.
See also 001n fixes OOS errors
135c allows debug tools in multiplayer and refactors CvGameTextMgr::setPlotHelp.
Disabled some log output from CvEventManager.py. City growth, border expansion and saves are
now only logged if the respective __LOG variables in the CvEventManager constructor are set.
Rationale Probably an oversight by the (Vanilla) Civ 4 developers. Most of the other log output
was already tied to __LOG variables. (Savegames were probably being logged on
purpose, but that leads to a lot of uninteresting log output when autosaving every turn.)
147
The BUG Python logs have an extra switch on the System tab of the BUG
menu.
LoggingEnabled also enables:
- audio.log
- xml.log
- network*.txt
- app.log (mostly seems to record the Civ 4 window gaining or losing
system focus)
- resmgr.log (failures to load .dds graphics; models and animations too?)
- initmgr.log (apparently for profiling game initialization),
- LSystem.log (some type of graphics warnings)
- combat.txt (K-Mod – requires LOG_COMBAT_OUTCOMES to be defined in
CvUnit.cpp in addition).
Disabling LoggingEnabled doesn't stop all messages written to xml.log, I
guess because of the timing inside the EXE. Also probably by accident,
some messages still appear in the network-*.txt logs.
There seems to be no way to check the value of LoggingEnabled
programmatically; only the EXE knows. That said, the DLL can enable or
disable LoggingEnabled (or any other key in CivilizationIV.ini)
through gDLL->ChangeINIKeyValue. One can probably also use
CvDLLIniParserIFaceBase to re-parse CivilizationIV.ini.
PythonErr2.log Can't be disabled. Basically never of interest., and I think all the output is
also, redundantly, written to PythonDbg.log. (One could perhaps disable it by hex-
editing the string “PythonErr2.log” to zeros; not sure if the DLL could apply such a patch at runtime.
Maybe some or all of the output gets written before the DLL gets loaded.)
SynchLog Mainly seems to write “DBG: SYNCLOG: All Checked In” messages to
(CivilizationIV.ini) network-*.txt. That happens exclusively in the EXE; it doesn't look like
the DLL can write to that logfile.
To check whether SynchLog is enabled, use CvGlobals::isSynchLogging.
I think LoggingEnabled is required in addition.
MessageLog Enables the “message control log” MPLog.txt. It's mostly a combat log
(CivilizationIV.ini) (less detailed than the in-game log and combat.txt).
Use CvDLLUtilityIFaceBase::messageControlLog to write to MPLog.txt.
003 wraps a class CvDLLLogger around that function.
Use CvGlobals::isLogging to check if the log is enabled. Note that this
isn't the same as LoggingEnabled (see above), which is not a prerequisite
here.
The EXE shows a warning on the Staging Room screen if a player has the
message control log enabled.
advc.mapstat writes to the message control log if LOG_MAP_STATS is set in
GlobalDefines_devel.xml.
If PER_PLAYER_MESSAGE_CONTROL_LOG is set in GlobalDefines_devel.xml,
then multiple files MPLog*.log are created in multiplayer games. Cf. 135c.
OOS log When the game recognizes an out-of-sync error in a network game and
MessageLog is enabled, OOSLogger.py creates a file OOSLog*.txt and
writes all data that the OOS checksum is computed from to that file.
Comparing the message logs of all players can give a clue about the cause
148
of an OOS error. The log is no help, however, if only one player has
MessageLog enabled. Realistically, it's only useful for OOS debugging with
multiple program instances on a single machine. Cf. kekm.27.
RandLog Logs all pseudo-random numbers generated by an instance of CvRandom.
(CivilizationIV.ini) Writes to MPLog.txt, so MessageLog needs to be enabled in addition. (To
find the combat log messages in between the PRNG messages, one can
search for “kombat”.)
Through advc.007c, log output of the global non-synchronized RNG
CvGlobals::m_asyncRand are written to ASyncRand.log instead of
MPLog.txt. I.e. MessageLog.txt isn't required for this RNG.
Use CvGlobals::isRandLogging to check if RandLog is enabled.
LOG_AI Need to recompile to toggle this log. Pretty comprehensive AI logging (with
(BBAILog.h) some blank areas). Thus also useful for OOS debugging. Writes to
BBAI.log. Requires LoggingEnabled=1.
Use logBBAI to write to BBAI.log. Such calls should be preceded by a
g...LogLevel check (“g” for global), otherwise, the call will take up time
even if the BBAI log is disabled. (In CitySiteEvaluator.cpp, I've wrapped
that check together with the logBBAI call into a macro.)
UWAI reports Reports about AI war planning by the UWAI component; written to files
(GlobalDefines_ named UWAI*.log once per team turn if the game turn number is divisible
devel.xml) by REPORT_INTERVAL in GlobalDefines_devel.xml. Additionally requires
LoggingEnabled and – to avoid cheating – MessageLogging in multiplayer
games.
Use WarAndPeaceReport::log to write to the current game turn's
UWAI*.log.
Use WarAndPeaceReport::isSilent or isMute to check whether the
report object is enabled. If not silent, then temporary mute status can be
toggled through WarAndPeaceReport::mute(bool).
Unfortunately, re-launching Civ 4 doesn't cause old reports to be
overwritten; will append instead. The AdvCiv makefile has a YOURLOGS
variable though that will cause all .log files to be deleted after
recompilation.
StartingPos.log Requires recompilation to toggle the SPI_LOG switch in
StartingPositionIteration.cpp. LoggingEnabled=1 is also required.
The log documents the steps taken by the starting position iteration
algorithm; see 027.
Profiler log The DLL-internal profiler, if enabled, writes to IFP log.txt. See 003o and
Makefile.project about that.
ThemeParseLog.txt Gets created in the BtS install directory!
VS console When launched from within Visual Studio, debug builds write some
messages to the “Output” window of Visual Studio. The DLL can write such
messages through OutputDebugString, defined in CvGameCoreDLL.h.
Messages written by the EXE might be helpful for diagnosing program
instability; though the “first-class exceptions” are generally no cause for
concern. If the Visual Studio debug heap is enabled, then messages about
memory errors are also written to the Output window when Civ has exited.
149
mapstat Log file with statistics about a generated map
AdvCiv BtS
If LOG_MAP_STATS is set in There is a "Map Details" screen available in
GlobalDefines_devel.xml, and MessageLog Debug mode through Shift+F2.
enabled in CivilizationIV.ini, then, each
time a map is generated, some statistics like
land/ sea ratio, terrain, elevation and resource
frequencies, resources per player are written to
MPLog.txt.
Rationale The Map Details screen is difficult to read and lacks terrain info.
150
which allows Debug mode in multiplayer.
Would also like to block Ctrl+Alt+F4 (kills the process – or simply exits to desktop
without confirmation; not sure). This might be an OS thing, but the fact that it doesn't
work in the opening menu suggests to me that it's implemented in the EXE.
Enabled some debug tools that the BUG mod had (accidentally I guess) made unavailable. Now
they require Debug mode (probably only required cheat mode in BtS):
Shift+T: Award tech or gold.
Shift+Ctrl+W: View wonder movie
Shift+] on unit: Heal 10 HP
Shift+[ on unit: Damage 10 HP
Shift+F1: View replay
Shift+F2: "Debug Info" screen with various per-civ statistics
Shift+F3: View Dan Quayle screen
Shift+F4: View UN victory screen
Each cheat command is triggered only by one combination of modifier keys; e.g. Shift+Ctrl+T will
not open the tech/gold menu.
Rationale Reduce the risk of clashing shortcuts, i.e. one event handler pre-empting another.
AdvCiv BUG
Removed handlers for keyboard inputs from BUGEventManager.py handles keyboard inputs.
CvEventManager.py.
Rationale Removal of dead code.
007c Added macros for RNG calls that make the logging side less tedious – by simply
writing the current function name and line number into the log. Replaced all calls to
CvGame::m_sorenRand and CvGame::m_mapRand with those macros.
Output of the global non-synchronized RNG is written to ASyncRand.log instead of
MPLog.txt. (If RandLog is enabled in CivilizationIV.ini.)
Rationale I'm not sure if a log file for the non-synchronized RNG is helpful at all. In any case,
having synchronized and non-synchronized numbers in one place is potentially
confusing and makes it harder to debug OOS errors. The Firaxis developers had
sometimes added “ASYNC” to messages from the non-synchronized RNG, to make
them stand out I guess. This is no longer necessary, and removing those suffixes has
allowed me to simplify CvPlayerAI::AI_techValue a bit.
Tbd. Might be better not to use any random numbers in CvPlayerAI::AI_techValue when
the function is called asynchronously, i.e. when recommending techs to a human
player.
See also advc.fract: The RNG macros , apart from integer percentages and limits, also support
the ScaledNum type.
151
translations in Civilopedia are complete.
Config The modified bits are in a separate file called CIV4GameText_advc_pedia.xml. I've
also moved the one text changed by K-Mod into that file
(from Civ4GameText_K-Mod.xml).
Tbd. Not all the strategy advice is up to date. Especially the tech and building advice is a lot
of work to maintain, and much of it is redundant. The tech advice is only shown when
Sid's Tips are enabled. Would be best to somehow disable these texts completely for
anything past the Ancient era (simply check the tech's era along with each check for
the player option); the early-game texts actually do contain some advice.
See also 004y: Changes to Civilopedia formatting
033 shows the Privateer's plunder ability in Civilopedia
179 shows the production bonus of the Apostolic Palace in Civilopedia
008a Hide abilities in Civilopedia when they don't apply
Rationale To unclutter the Civilopedia
See also 004w unclutters the help texts for buildings on the city screen.
AdvCiv BtS
Showing the "Can be built on X era and earlier The restriction is shown for all buildings that have
starts" restriction only when X is smaller than the one regardless of how Civilopedia is accessed
current game's start era, i.e. when the restriction and regardless of the current game's start era.
applies to the current game. When the
Civilopedia is accessed from the opening menu, For most wonders, X equals the wonder's tech
the restriction is shown when X is not equal to era plus 1.
the wonder's tech era plus 1.
Shwedagon Paya not available on Renaissance Both wonders were added in BtS. Shwed is
start and Statue of Zeus available on Classical available on Renaissance start and earlier and
start. Zeus only on Ancient start.
Versailles not available on Industrial start. Industrial start or earlier.
Rationale Most wonders become unavailable when starting two eras after their tech era; spell out
only these exceptional cases (e.g. most Ancient wonders are available when starting in
the Classical era, but Stonehenge isn't).
The changes to individual wonders reduce the number of exceptions that the
Civilopedia needs to mention.
See also 310 changes the start era restriction of the Great Wall
Tbd. Civilopedia should list the free buildings from later-era start along with the descriptions
of the later-era start settings.
Perhaps prevent civs from constructing a wonder once they reach the threshold era –
regardless of the game's start era. This could make wonders scarcer in games with
few civs.
Show required victory condition ("such-and-such victory must be enabled") only when accessing
Civilopedia from the opening menu or when the victory condition is disabled in the current game.
008b (unassigned)
008c Updated some of the hints that are shown while loading savegames (only English and
German)
008d New hints about AdvCiv changes and a few K-Mod changes that weren't previously
covered. Gave all hints about modded content a higher probability of being shown than
the hints from Vanilla and BtS (Warlords didn't add any). Tried to mimic the tone of the
152
original hints. Only in English and German.
Config Increased the probability by duplicating entries in CIV4Hints.xml. Separate file for the
new hints: CIV4GameText_advc_hints.xml.
008e Changes to the names of wonders and projects
No wonder or project name starts with "The" or Totally inconsistent; e.g. "Angkor Wat", but "The
any other article (translations). Taj Mahal".
Rationale Makes it easier to find wonders in Civilopedia and on the Wonders tab. Just
"Pyramids" is a little strange, but most of the names work fine without an article. Could
make it "Great Pyramids" (joining Great Lighthouse, Great Wall and Great Library), but
I guess "Pyramids" is OK.
Config Separate file CIV4GameText_advc_wonders.xml. Further changes to wonder names
will have to be made there. Can delete the file to undo all name changes.
See also Caveman to Cosmos also does this (but I haven't checked how they've implemented
it). SourceForge revision
009 Setup of configuration files: BUG settings, GlobalDefines, BUG and BBAI help files
See also 002b also deals with file paths
AdvCiv K-Mod
Included the BUG 3.5 help files in three No BUG help files included; clicking on "BUG
languages (no French and Spanish translations Mod Help" in the BUG options menu results in an
exist). With one new page inserted explaining error message. Credits tab also removed from
that the help file is outdated (from Oct 2008) and the BUG menu. K-Mod is based on BUG 4.5, the
listing the contents of the BUG 4.5 Credits tab. final version that did not become an official
Recompiling the files (in HTML Help Workshop release. BUG 4.4 included the outdated help files
4.74) has also almost halves the (compressed) and the (more or less) up-to-date Credits tab.
file size.
Rationale I agree that having Credits on the menu isn't good. Don't to have to keep that up to
date as AdvCiv adds further options. AdvCiv credits should be handled in this manual.
There's also just enough space for the remaining tabs without having to show scroll
buttons. But since the BUG developers went through a lot of trouble to credit all their
contributors, I don't want that to be ripped entirely from the mod. Including the help
files is pretty painless, gets rid of the error message – and, though out of date, the help
still contains interesting background info.
Tbd. Would be nice to use the SourceForge URL that BugHelp.py tries to access for Mac
installations – as a fallback when help files aren't found locally.
See also I've put my setup for recompiling the help files in a separate repository on GitHub.
Added a text file to the Mods\AdvCiv\Settings BUG and K-Mod have this folder, containing ini
folder explaining its purpose. files of the Unit Naming and Custom Domestic
Advisor components. BULL instead has a folder
Mods\BULL\UserSettings that contains all ini
files used by the mod. The presence of these
files prevents BUG/BULL from creating them
under My Games (cf. this post by EmperorFool).
Rationale The folder is confusing in two ways:
a) The name suggests that it contains important global settings, but the settings are
actually only for two particular mod components, which are even disabled by default.
153
b) The contents of the folder are copied to My Games\Beyond The Sword\AdvCiv\
Settings when the mod is started for the first time, so it seems that the folder in
Mods\AdvCiv is redundant – which is true, but only once the copy has been created,
so the Settings folder has to be included in the download archive.
Tbd. If I'd store all ini files in Mods\AdvCiv, a copy under My Games would no longer be
created. This would also make it easier to uninstall the mod. That said, it can lead to
issues with Windows rights management (example), and fallback behaviors for that
would be too difficult to implement for me. And I wouldn't want to include all the ini files
in the download; this can perhaps be avoided by giving Mods\AdvCiv higher priority
than My Games in BugPath.findSettingsFile.
Either way, I should consider a different name for the Settings folder
(SETTINGS_FOLDER in BugPath.py). Though, ideally, the game should then continue to
check the old location so that players don't have to update manually (by moving their
ini files).
See also K-Mod Git commit that might force settings to be copied to My Games (haven't looked
into it in detail).
CvTextScreens.cpp removed from CvGameCoreDLL.
Rationale Apparently doesn't get compiled into the DLL, so it doesn't serve any purpose.
Credits alberts2 (Caveman to Cosmos mod): SourceForge revision
Removed a few DDS art files from the Art\BUG folder that appear to be unused (the file names
appear neither in the DLL nor in any of BUG's XML and Python file): Arm.dds, Foot.dds,
GreenFace.dds, RedFace.dds, YellowFace.dds, Star.dds, Trade.dds. The total compressed
size of these is only 7.3 KB.
009b BUG initialization (only relevant for developers)
AdvCiv BUG
When a Python script file is modified while the Reloading fails almost always and leads to an
game is running, Python scripts will sometimes, unresponsive UI and nonfunctional alerts until the
in part, fail to be reloaded. The likelihood (race game is restarted. So, unlike in unmodded BtS,
condition) of such an error depends on which file Python changes at runtime aren't really possible
was modified. As workaround, it usually suffices in BUG-based mods. This post by platyping
to save the file one or two more times. Or to save confirms that this is an issue with BUG and not
a different file. just K-Mod/AdvCiv.
Some of the errors are caused by the Civ4lerts
and Field-of-View slider components. But there
are probably also problems with circular
dependencies and/ or the proper order of
reinitialization.
I suspect that these problems were introduced
late in the development of the BUG mod because
developing such a complex Python mod without
the possibility of changing scripts at runtime
would've been very difficult.
Rationale I haven't been able to fix this entirely.
Tbd. Perhaps it's mainly a problem with change handler functions (“dirty”) referenced by
ChangeHandler.handle (BugOptions.py)?
154
009c Removed Map Finder, BUFFY integrity checks
AdvCiv K-Mod
The configuration files, text files and Python Map Finder is included in the BUG mod, so it
scripts of the Map Finder mod component have seems that karadoc disabled it (by commenting
been removed, and references to them out a few lines in BugMapOptionsTab.py.
commented out. One of the BUFFY game text
files has been removed, the other mostly deleted,
BUFFY code in Python kept commented out.
Rationale Generally, I don't want to remove any BUG/BULL features entirely, even if I don't think
I'll ever use them personally, but Map Finder and the BUFFY checks are really features
for competitive HoF players, which doesn't make any sense in a mod like this. I don't
think it can be used as a developer tool either, e.g. to find out how commonly some
very poor or powerful combinations of tiles occur, or only with major modifications. The
compressed size of the removed files is 12 KB (negligible), but it also reduces the
number of files to browse through when making changes to other BUG components.
Config Not terribly difficult to re-enable: Restore the removed files from BUFFY (K-Mod hadn't
made any changes), uncomment any code marked with change id 009c.
See also The space on the BUG menu is now used for 004m, 004h and 004z.
155
in the ini file that includes, again, the default and
the hover text for the option, read from the
corresponding ...Options.xml file in Assets\
XML\Text. These comments are, as far as I can
tell, never updated, so if the default or hover text
changes from one version of AdvCiv to the next,
the comments won't reflect this unless the user
clears the settings.
Rationale Ideally, BUG would read the comments in the ini at startup (along with the actual
values), check if they're outdated and update them if necessary. I don't think the
comments are read at all though, so this would be quite an effort to implement.
Updating the comments always isn't easy enough to do for me either, and might affect
performance.
I don't think the ini files should be manually edited anyway, so comments really don't
seem necessary. They also take up a little bit of disk space.
156
I've considered making the probability dependent on the distance to the nearest tile
owned by the captor, modelling, on a high level, the distance that the captives would
have to be transported and guarded in reality. In the early game, distances tend to be
long, so the capture probability would be 0 or near 0. This solution would feel more
organic than the one based on the timing of the declaration of war, but it would still
allow high-stakes gambles when civs start close together. Distance-based
probabilities are also conceptually more complex.
Disabling worker stealing entirely was nicely simple, but it's strange (perhaps
disquieting) when civilian units never survive combat. There were also rare situations
in which a Barbarian worker became “orphaned” through the sudden conquest of the
only nearby Barbarian city. In that situation, a human player had no reason to attack
the worker, so it would just sit there. More importantly, I think that (severely) restricting
worker stealing will go over better with players than disabling it entirely; psychological
thing.
Another idea was to delay worker stealing through a civic or tech requirement. Slavery
would be the obvious choice, but, in its current state, clearly can't have another
powerful effect. Moreover, I don't think worker stealing should be contingent on
running particular civic; should never be disabled entirely. As for techs, Monarchy
comes at about the right time, but doesn#t have the right flavor. Code of Laws also
seems rather farfetched.
Tbd. AI workers getting destroyed through human surprise attacks is still a problem. Could
be addressed through a rule change maybe, difficult to address through AI changes.
Keeping workers safe has an economic cost that can easily exceed the cost for letting
a Warrior patrol along the borders of an AI civ. The appropriate response to such
harassment would be to declare war and destroy the Warrior. Just guarding the
affected worker for a while would also work, but this mustn't imperil the defense of the
nearby city. This is all complex behavior with little margin for error. I've written some AI
code and archived it in this Git commit, but I think it would hurt more than help.
AI civs may delete workers (ca. 25% chance) in a No such scorched-earth behavior.
city that is all but certain to be conquered on the
next turn. They don't delete workers if the city is
the last remaining city.
Rationale I guess it doesn't hurt to reduce the number of workers captured a bit further. Not
really necessary, but it's just dumb to let the aggressor have those workers (but if it's
the final city, then it doesn't matter), and often it's very obvious that a city will fall. If
this were the only mechanism to deny workers upon city conquest, then the AI would
have to be more subtle – wouldn't want human players to send in fewer units just so
that the defenders don't lose hope and commit suicide. Older notes on that:
“When losing badly at war, too many workers overall and too many assigned to a local city, then disband
1 local worker (only in the city tile?) per turn. May disband another if evacuating. Should probably keep 1
worker assigned per city in any case.”
The AI deletes captured workers only if there is Captured workers are deleted unless there is a
no AI city nearby or if the capturing unit is badly friendly city nearby or unless there is no potential
outnumbered by nearby enemy units. attack at all against the capturing unit.
Rationale A worker getting re-captured is not actually a big deal, especially now that there's only
a 50% chance.
See also Rise of Mankind never lets the AI delete captured workers.
Combat help shows the odds of capturing a Help text doesn't tell the player about units that
worker and informs the player when the odds are might get captured.
0 due to a recent declaration of war or when war
hasn't been declared yet. No such help is shown
157
when a military unit is going to defend, i.e. when
a worker would only be captured upon defeating
that defender.
Rationale Important to make players aware of the rule changes, especially the artificial special
rule for the turn during which war is declared. Not showing capture help when there
will be fighting simply because that turned out to be complex to implement.
Show a message on the main interface when a No message. Can't happen for workers, but can
noncombat unit is destroyed through an attack. happen for ships in port and landed aircraft. For
captured workers, there's a message.
Rationale So that destroyed workers don't disappear without notice. But also very useful to
have such a message for units that can't defend because of their domain type.
158
purpose.
Tbd. One downside of my implementation is that keyboard shortcuts (e.g. Alt+C for
chopping) don't work when Ctrl is pressed. They do work in BULL when the “pre-chop”
option is enabled, but then all chop commands have to be issued twice, which is, I
think, a much bigger downside. I could make keyboard build commands work by using
a letter key, say Y, instead of (or in addition to) Ctrl. Only the modifier keys Ctrl, Shift
and Alt interfere with the build shortcuts; I suppose that's why karadoc decided to use
the X key for suppression of unit cycling. However, pressing Alt+Y+C (or even
Ctrl+Alt+C) to pre-chop really isn't convenient, so I don't think I'll bother with this.
Like BULL; I'm showing a message when a build is suspended. That's perhaps more
annoying than helpful. Also, the message would be timed better at the start of a turn.
Currently, Workers abandon their build missions right after making the move that
brings the progress to x-1 of x turns (perhaps this should happen at the start of the
next turn instead) and the message is shown; often, Workers don't move until the
player presses “end turn”, and then the message is shown only very briefly, which
looks strange.
159
of its minions. And of course a capitulated vassal shouldn't win.
AdvCiv BBAI/BtS
Capitulated vassals don't pursue victory Capitulated vassals pursue victory strategies and
strategies, don't build team projects and don't can actually win the game.
build wonders of the world except Shrines.
Rationale Internet and Manhattan are things that the master may not want the vassal to build;
SDI is covered by the master (change 143b); the other projects are for space victory.
Capitulated vassal shouldn't build wonders that the master might want to build or that
could hurt the master (UN, AP); it's simplest to block them all.
See also 130v about capitulated vassals voting along with their master and generally behaving
like zombies.
112 about voluntary vassals breaking free when approaching victory.
143b scraps nukes upon capitulation.
016 Extra tile yields from random events not added to city tile yields
AdvCiv BtS
On city center tiles, extra yields from random City tile yield is computed as the yield from
events are added to the natural tile yield before terrain, hill, unimproved bonus and river, all
raising the yields to at least 2 food, 1 production, assuming that features (incl. Flood Plains) are
1 commerce. removed. The result is raised to at least 2 food, 1
production, 1 commerce. Finally, extra yields from
random events and yield bonuses from Golden
Age are added.
Rationale Should be treated like all the other yield effects; counterintuitive in BtS.
Credit Pointed out here on CFC by traius.
Tbd. Considering to change the city tile yield formula so that bonuses are applied after the
raise step.
See also 004b shows the city tile yield before founding
Count extra yields even for impassable tiles. No natural yields on impassable tiles. Non-
natural yields (e.g. extra yields) can make
160
impassable tiles workable.
Rationale So that Python modders can make peaks workable.
Credit Post by CFC user xyx
See also 057: Changes to impassable terrain
017 AI trains fewer units when its military is already very large and drafts less in general
See also 121b: AI hurries production less, especially units.
018: Reduced impact of Crush strategy
107: Fewer AI defenders
110: Changes to AI military buildup
AdvCiv BtS
The probability of training a unit in a city is The military power of other civs affects the
reduced based on the military power of the number of trained units only indirectly through the
strongest potential enemy. Not as much when "Area AI type"; generally keeps building units so
pursuing a military victory strategy. long as the maintenance is affordable.
Rationale Better to develop the economy more than to train excessive armies. AI stacks of doom
can also get too disheartening if the human player is behind when Drafting and Rifling
become available.
Need to be careful not to throttle military production too early when aiming at a military
victory. Those often have to race against a peaceful victory of a rival and may require
overwhelming numbers to succeed in time. Moreover, the bigger an empire gets, the
more units are tied down as garrisons (while still counting toward the military power
rating).
Decreased the base probability to train a military By the midgame, the probability is effectively 3
unit by 2 percentage points overall. higher than set (per AI leader) in XML because
the experience from Barracks is added in.
Added an upper and lower bound for the city-
specific train-unit probability based on the
number of cities: The AI only gets to use very
high or low probabilities once it has about five
cities.
Rationale The average probability to train a unit was about one in three, which seems a bit
much in a situation where there is no war on the horizon.
AdvCiv K-Mod
AI unlikely to build Barracks before training a About three times more likely than in AdvCiv.
Settler for founding a second city.
Tbd. Want to give Barracks a tech requirement.
Don't draft away more than a third of a city's Draft as many units as allowed except when
population unless defenders are urgently there are angry citizens or upkeep gets too costly
needed. (K-Mod has the same condition but (that's a high ceiling). Stricter rules when drafting
doesn't apply it to Rifleman.) Don't draft at all sth. other than Riflemen.
when there is neither a war plan, nor a reason to
reduce population.
When it's not urgent, only draft with a per-turn No randomness in drafting.
probability equal to the normal buildUnitProb.
161
Reduced AI utility value for Nationhood civic Utility is only reduced when maxUnitSpending is
when already paying high unit upkeep. exceeded.
Rationale The K-Mod behavior leads to huge AI stacks once/ if the AI hits Rifling and switches to
Nationhood. If the player can stay out of harm's way through diplomacy, it becomes
too easy to overtake the AI economically. One third of the population is still a lot.
Drafting without planning war is generally a bad idea; can draft units pretty quickly
once they're needed. Probably shouldn't adopt the Nationhood civic without war plans
either. The change to civic evaluation may help with that. Don't want to make war
plans a hard requirement for Nationhood though – that would give away the AI's
intentions.
The probability should make AI drafting less abrupt, and reduce it a bit overall.
Tbd. buildUnitProb should be taken into account in a more meaningful way: currently
mostly slows AI drafting down. However, need to change the drafting rules before
putting effort into the AI; drafting is too efficient currently.
The target number of warships to escort a naval Only the number of escorted transport ships
assault is adjusted based on the number of matters, and whether they can defend
coastal cities owned by the enemy and the game themselves (Galleons).
era.
Potential bug fixed in BBAI code that may have
lead to large AI fleets when only a "minimal
attack force" had been intended.
The AI trains fewer sea explorers if the file name
of the map script is "Pangaea".
Rationale No need for an expensive escort if the enemy has very few ships. Can't be sure of
that, but the number of coastal cities should be a pretty good predictor (and don't want
to count enemy ships that the AI can't see).
Tbd. Should check if the enemy can even train any dangerous ship; no need to protect
(Industrial-era) Transports if the enemy ships are Frigates.
Once that's implemented, should probably use relativeNavyPower if UWAI is
enabled.
See also 905a buffs Trireme and stops the AI from using (and training) Caravels as escorts. Not
sure if this has lead to fewer or more AI ships.
081 is supposed to train more ships when they're needed.
AdvCiv BBAI
Reduced the number of attackers that the AI BBAI added that behavior for “building [a] city
trains when there is no war plan. hunting stack” that is also supposed to “to
produce early rushes on tight maps” (comments
in the code). May train as many as 12 attackers
for this.
162
explorers. trained for that purpose. Explorers can adopt
various other roles if exploration isn't needed
Lowered the priority of guarding seafood when in
anymore.
UNITAI_RESERVE_SEA.
163
non-aggressive AI, and really no need for two modes. Even for inexperienced players,
it would be better to tie AI aggressiveness to the difficulty setting instead of a separate
game option. (To be fair, BtS does that too: iAIDeclareWarProb is based on difficulty.)
In the original Civ 4 code, the non-AAI behavior is very passive, especially on the low
and medium difficulty settings; this has been a recurrent player complaint since the
Civ 4 release. Therefore, I haven't reduced the impact of Aggressive AI in the original
code.
See also AAI can only be disabled through XML; see chapter on UWAI. 120b: No impact of AAI
on malicious espionage.
Posts by Blake about Aggressive AI in BtS. (Note, however, that the option existed
already in Vanilla Civ 4.)
164
Reduced maintenance leads to a high science rate, which conflicts with buildings like
Market that increase gold output. Gold flavor does give some incentives for growing
wide (trade route bonuses), but I still think it's more important not to have the same
flavor on Courthouse and Market. The next best choice seems Military; militaristic
leaders tend to conquer wide empires.
Corporations aren't there for generating gold. The HQs pair well with +gold buildings,
but Gold-flavored leaders try to build Markets everywhere, not just in the HQ cities.
The missing Culture flavor on Hollywood etc. seems like an oversight. While
Cathedrals are more of a religious thing, they're so instrumental to Culture victory that
they should also have Culture flavor.
If Growth is supposed to support tall cities, it needs an even mix of health and
happiness.
Tbd. The Trade Mission ability of the Great Merchant also clashes with the plus-gold-rate
buildings.
Apply the tech flavor values multiplicatively. Additively; i.e. a flavor-based value between 0
and about 100 is added to the utility value of
each tech. The utility value tends to increase with
the economic output of a civ.
Reduced the impact of flavor on building Additive in BtS, K-Mod replaced it with a
evaluation, so that flavor typically makes about a multiplicative formula. Flavor can make up to a
20-30% difference. 100% difference, though 40-50% seems more
typical. Since the building evaluation also affects
the tech evaluation in K-Mod (not in BtS),
building flavor indirectly affects tech evaluation
too.
Rationale The BtS formula means that the impact of flavor decreases with the economic output,
so that a civ starts making more rational choices when it's doing well, and that flavor
matters more when all eligible techs have a low utility value. None of this makes
sense to me.
Tbd. The flavor values in Civ4TechInfos.xml look loopy; need an overhaul. Doesn't take
into account that the utility value counted for unlocked buildings includes the flavor
values assigned in Civ4BuildingInfos.xml. Should perhaps treat units and civics in
a similar way, i.e. assign flavor values through Civ4UnitInfos.xml (most would
simply get sth. like 5 Military flavor) and Civ4CivicInfos.xml (no flavor tag yet) and
count them only indirectly in the tech evaluation. This way, the flavor value would be
reduced along with the unit value when a tech doesn't immediately unlock a unit, and
the flavor values would not have to be changed when making changes to tech
requirements.
Should ignore first-to-discover abilities when assigning flavor values: already
addressed through custom code.
Revised flavor values will change GP "bulb" paths though; bad for players who have
them memorized.
021 Adjusted map scripts with simulated tectonics; see also chapter PerfectMongoose.
See also Since these map scripts frequently produce mountain chains and large areas of
uniform terrain, the improved AI handling of areas separated by Peaks (030) and the
reduced probability of large resource lumps (129) are especially relevant.
165
Also tend to generate oblong continents near the poles, and 027 improves the
selection of starting areas in such cases.
021a Tectonics
AdvCiv BtS
Uses the latest version 3.16 (Nov 2008) of the Uses version 3.15. (Although Dresden's Unofficial
Tectonics map script. Patch had included the update to 3.16 and was,
otherwise, mostly adopted by BtS 3.19.)
"[...] added more rivers. [...] Terra option now
has a nice looking Arabia instead of some
landbridges and islands."
source
All map scripts are allowed to place Jungle on Jungle can only be placed on Grassland. Since
Plains. The impact on most map scripts seems Tectonics maps have lots of Plains near the
very minor; most tiles at the equator are equator, these maps end up with very little Jungle.
Grassland anyway. A sample (non-Tectonics)
Pangaea map had only 8 Plains Jungles and 40
The following resources can be placed on Jungle:
Grassland Jungles. (Not sure if that means that
Oil (Grassland), Uranium (any terrain), Banana
there would have been 8 fewer Jungle tiles
(Grassland), Pig (Grassland), Rice (Grassland),
without my change.)
Dye (Grassland), Gems (Grassland), Ivory
Banana, Sugar and Ivory can be placed on (Grassland – or non-Jungle Plains), Spices
Plains Jungle (in addition to Grassland Jungle). (Grassland, Plains), Sugar (Grassland).
Credits It's LDiCesare's map script. It was included in BtS patch 3.17, and he updated it once
more after that.
Config The Jungle-on-Plains change is done in XML (Civ4FeatureInfos.xml).
Rationale I've not allowed Dye to be placed on Jungle Plains because the Jungle is almost
impossible to see then. It's also a problem with Grassland Jungle Dye, but somehow
it's not quite as bad – and players are used to it. Not important for gameplay; the map
generator normally still finds enough Grassland Jungle to place the target number of
Dye resources.
Tbd. Allow Pig and Dye on Plains, perhaps instead of Grassland. Shifting resources away
from the best terrain type (Grassland) should be healthy for game balance.
See also 165 reduces the grid size of Tectonics.
AdvCiv Tectonics 3.16
Increased the elevation thresholds for hills and Places far more hills and peaks than most map
peaks so that they occur less frequently. And scripts (although it varies quite a bit too). Since
made hill placement more random. the placement is based on (absolute) elevation
values, which are, in turn, derived from the
geological model, large regions of the map can
end up without any hills.
Rationale To make Tectonics play more like the standard map scripts. Typically, hills and peaks
are still more common on Tectonics maps – because that helps avoid regions with
very low production capacity. The randomness also helps with that.
(I think it's a better approach to place hills based (mainly) on local differences in
elevation, but I don't want to turn Tectonics into PerfectMongoose.)
Tectonics landmass type options "Earthlike" 80%, Only 70% and 60%
70% and 60% water.
Reduced the number of rivers for all landmass Was supposed to be reduced (perhaps to the
types, and a bit more for Pangaea. level of v3.15) only for Pangaea, but due to an
166
apparent bug affected (only) 60% water instead.
Rationale Corresponding to High, Medium and Low sea level. My 80% option actually does the
same as the 70% option in the original script, the new 70% corresponds to the old
60%, and the new 60% is a new setting. I've noticed that far less land is generated
than the old percentages said. My percentages are still too high. Actually, the ratios
vary a lot. The new 60% option sometimes does lead to 40% land, but at other times
just 23% ...
3.16 generally had more rivers than e.g. Fractal; I didn't like that. Not sure if Pangaea
really needs special treatment. Seems to receive fewer rivers in any case (albeit
longer ones than on maps with smaller continents).
Tbd. Make the script produce reasonable land ratios reliably. Should be the same as
Fractal.
Credits 4Dingo4 and LDiCesare have suggested formulas for the 50% setting here.
Show approximate land percentages also for the Percentages only given for the “earthlike”
other landmass choices – Pangaea, Islands ... choices.
Rationale So that players can choose an appropriate player count. E.g. Islands supports far
fewer players than the other choices.
021b PerfectMongoose (PM)
Credits I've adopted a few changes from Toffer90's C2C_World.py script
(Caveman2Cosmos). Apart from that, see chapter PerfectMongoose for credits.
Config The “Perlin Noise” option is equivalent to the “PerfectWorld 3 Landmasses” option in
PM 3.3. The “Plate Tectonics” option is equivalent to “Perfect World 2 Landmasses”.
This option affects continent sizes and shapes and the distribution of hills and peaks.
Perlin noise has more varied results, landmasses tend to be smaller and snakier and
hills and peaks more widely distributed. Since AdvCiv 1.06, Plate Tectonics is the
default.
The “Break Pangaea” option has been removed from the menu; it's now implied by
“Old World Start”.
All options that I've removed should still be fully functional; they just can't be selected
on the menu anymore. (I.e. it's easy to restore them by editing the map script.)
To make PM maps reproducible, in addition to setting fixed RNG seeds in
CivilizationIV.ini, the Python RNG needs to be disabled (self.UsePythonRandom =
False) in PM. It should not be necessary to disable the Python RNG in multiplayer
games: out-of-synch errors reported about the predecessor PW2 have been fixed by
AIAndy.
Some debug output gets written to PythonDbg.log if Python logging is enabled.
Unfortunately, this can't currently be toggled in the script.
See also The latest version of my changes that should be fully portable to other mods and
unmodified BtS: Git commit
After that, I made changes that are specific to AdvCiv. That said, I've also made some
more non-AdvCiv tweaks that could (easily) be merged into the portable version.
Maybe I'll do that at some point and post the result in the PM thread on CFC. This
version I had posted earlier is now outdated.
I've used version 3.3 as my starting point. LunarMongoose never made that version
available as a standalone script, so I took it from the latest version of MongooseMod,
version 4.2a. It's the same version that cephalo has posted here in the PM thread.
Then I've stripped away all the code specific to MongooseMod. (Realism Invictus has
taken the same approach – its version of PM is also based on v3.3.)
167
In Oct 2018, cephalo published "PerfectWorld6" as a Lua script for Civ 6 (link), which
"might be the best PerfectWorld yet." The Perlin noise generator doesn't seem to
have been altered (same as in LunarMongoose's Civ 5 port), apart from a small tweak
to the “twist frequency” that I had already arrived at independently. The rainfall
formulas are also unchanged. Most of the new code is dedicated to lakes and rivers:
“I have […] incorporated lakes into the river system, so that rivers can flow into lakes,
and lakes can flow into other lakes […].” To me, this doesn't seem worth the trouble of
attempting a back-port.
The LoR SDK ModMod makes some changes to PerfectWorld2, but these are
probably obsoleted by LunarMongoose's work. Changes by Fuyu in RevDCM are
minor and obsoleted by my own changes. Likewise those by Antmanbrooks for
Realism Invictus. Mongoose Mod makes numerous changes beyond those in the
standalone version of the script (see in particular the v4.1 release notes), but nothing
that I'd like to merge (or very little).
001 fixes issues that occur when regenerating PerfectMongoose from a turn-0 save
after having exited the game.
Tbd. My changes are getting extensive enough to justify a name change. I'd like to lose the
nonsensical “Mongoose” part. “Mundus,” in a way, means both world and perfection
and would still be a nod to LunarMongoose's user name. Or “Ad Mundum” – that
would not cover the perfection part (not what I strive for anyway …) but allude to the
AdvCiv mod; and it sounds like a motto for modders (“to the world”).
See also Unless the starting position iteration algorithm (“SPI”; 027) is disabled, the
PerfectMongoose algorithm for starting positions only designates the New World
when the Old World Start option is used.
I've used the mapstat log for measuring the relative frequencies of terrain, feature
types, elevations, rivers and resources on Fractal maps (customized by change 129).
I've tried to get PM to match those frequencies. For reference, these are the relevant
Fractal statistics under default settings:
Total tile count: 4368 (84x52); Land: 20.4%; Resources per player: 21.63
Land breakdown:
Hills: 16.7%; Peak: 5.5%; Grassland: 50%; Plains: 27%; Desert: 12%; Tundra: 4.5%; Ice: 4%; Jungle:
14%; Oasis: 0.2%; Flood Plains: 1.5%; Forest: 21.5%; River plots: 20%
Water breakdown: Ice: 20%
AdvCiv PM 3.3
Same map sizes as Fractal. I've also aimed at A larger tile grid is used for all map sizes, leading
the same terrain frequencies (see above) with to about 40% more tiles. The land-sea ratio is
some exceptions: I've set the land-sea ratio, and about 28%. On the other hand, Grassland and
frequency of hills, forests and plains a little bit Plains cover only 40% of the land area and much
higher – but still far lower than PM 3.3. My of the Grassland is covered by Jungle. Hills are
Tundra frequency is (on average) closer to PM almost twice as common as on Fractal maps,
3.3 than to Fractal – around 10% – at the making arable land even more scarce.
expense of Grassland, which lands somewhere
between 40% and 50% on average. No attenuation at the poles (though
PerfectWorld6 does use 75% attenuation). The
Toward the poles, land becomes less likely to
attenuation factor (if used) also affects altitudes
occur (59% “attenuation”). Eliminated the
above 0; altitude differences caused by
elevation artifacts resulting from attenuation.
attenuation can make peaks and hills more
common near the poles.
Rationale Apart from using different overall terrain frequencies, PM generates, locally, more
uniform terrain than Fractal, i.e. larger deserts, steppes and mountain ranges (clusters
of peaks and hills). I see that as a strength as it gives the various regions of the map
more character and a more Earth-like feel, and results in city sites of marginal value
168
that can present a third choice between stopping to expand and waging war. As
cephalo's pitch for PerfectWorld6 puts it: “a believable map that makes exploration
more fun and adds extra challenge to the game.” The balance problem posed by civs
starting near poor terrain should be much lessened by AdvCiv's starting position
algorithm.
Keeping the Tundra frequency relatively high is in line with these considerations. It's
really a matter of the amount of land generated in high latitudes; Fractal (and also e.g.
Pangaea) generate very little land anywhere near the poles. PM could easily mimic
that through a very low attenuation factor – but shouldn't in my opinion. That being
said, without attenuation, it's pretty common that large continents get connected by
some sort of elongated Antarctica. This is unrealistic (armies can't traverse a polar
desert) and doesn't play well either as it diminishes the importance of ships.
It's important to me that the same player counts can be used for PM as for the
standard map scripts. To this end, I've set a slightly higher land-sea ratio for PM than
for Fractal because city sites on PM maps tend to be spaced a bit farther apart and
there tend to be more small, initially uninhabited continents that civs can't immediately
expand onto. On the other hand, PM maps have longer coastlines than Fractal maps
and therefore more seafood and a higher number of viable coastal city sites.
It would be nice if the land-sea ratio were closer to the real-word value, which should
be around 28% if we assume that Antarctica is mostly represented by the ice sheets
shown above and below the map edges in Globe view. One could change this for PM
or all map scripts and keep the player counts as before by decreasing map sizes.
Maybe this would place continents too close together, especially when using PM's Old
World Start option. There's always the Low sea level option. Generally, the maps don't
have to be scale models of the Earth, but getting somewhat close to the terrestrial
proportions would be nice.
See also Some discussion about the terrain proportions: CFC link
Tweaked the method for placing peaks and hills Peaks and hills are placed based on altitude
so that the altitude of both the lowest orthogonal differences unless the “Absolue Height” option
and lowest diagonal neighbor is taken into (introduced in v3.3) is enabled. cephalo's scripts
account and so that water tiles are treated as use the difference between a tile's altitude (as
having higher altitude than the seafloor; removed generated by either plate tectonics or Perlin
the Absolute Height option. noise) and the mean of its neighbors' altitudes.
LunarMongoose uses the minimum of the
neighbors instead of the mean. All these methods
result in peaks and hills forming bigger clusters
than on Fractal maps. The difference-based
methods – and also absolute heights when
combined with plate tectonics – result in a bias
for peaks and hills on or adjacent to coastal tiles.
Rationale Hills really mustn't clump together too much; some terrain here and there with highly
unbalanced yields can be fun, but not large swaths of it. Clumps of peaks don't have
this problem, but similar methods need to be used for peaks and hill placement,
otherwise peaks won't have surrounding foothills. Placing hills based on absolute
altitude is pretty obviously bad for gameplay, and hills also aren't a convincing
representation of plateaus,which may well be irrigable; – so I've removed that option.
Apart from finding a good balance between representing Himalayan-size mountain
ranges and spreading hills out, there is also the issue of arranging peaks, hills and flat
tiles into natural-looking patterns. Distinguishing orthogonal and diagonal neighbors
seems helpful in that regard.
See also 030 makes coastal peaks less likely for all map scripts that use the standard terrain
169
generator. See the rationales there against peaks on coastal tiles.
Tbd. I think hills still form bigger clusters than I'd like, especially with the Plate Tectonics
option. I don't think the slightly higher overall frequency of hills (compared with
Fractal) fully compensates for the uneven distribution.
Straight, uninterrupted chains of peak also still occur too frequently. Perhaps one
should simply check for such formations explicitly and break them up probabilistically.
Would also be nice to check for tiles completely enclosed by peaks and either open
up an entrance or turn the enclosed tile(s) into peaks as well.
Hard latitude limits for Jungle. That means, on A fraction of the hottest and wettest tiles become
maps with little tropical land, Jungle can only get Jungle, meaning that the latitudes where Jungle
denser to compensate (to an extent) and sparser can occur expand when there is little land near
when there is much tropical land; generally, the the equator and shrink when there is much land
occurrence of Jungle varies a lot depending on near the equator. In v3.2, the temperature
the latitudes of the continents. requirement was still absolute, meaning that the
Jungle coverage was more dependent on the
latitudes of the continents.
Rationale A fixed frequency of Jungle tiles isn't important for game balance. Too much Jungle
can be a problem; that can be addressed well enough by making the Jungle sparser.
Jungle in higher latitudes looks very jarring (and I don't think players will interpret it as
temperate rainforest).
Especially wet plots are represented as Plains All wet plots become Grassland. Still, more plains
rather than Grassland. Jungle can occur on occur in the tropics than on other maps (that use
plains but is a bit more common on grassland. the default terrain generator). Jungle is placed
only on grassland. As a result, jungles are less
dense than on other maps.
Rationale Plains are a slightly less unrealistic representation of tropical soils than grassland (at
least in terms of food yield; the color of plains also fits for clay-rich soils). Also,
allowing jungle on both plains and grassland makes the jungles less scattered.
Avoid placing Jungle adjacent to Desert. In theory, the rainfall map should be somewhat
smooth, which would avoid Jungle next to
Desert. Perhaps it's less of a problem on larger
maps.
Rationale I like the alpine tundra idea, but snow-covered mountains (or jungles) next to desert
are jarring (even on small maps, where such contrasts may not be so unrealistic
considering the scale of the model).
Tbd. Desert next to Grassland is still quite common.
Land Ice and Tundra only appear in the polar Tundra and Ice are placed on any tiles that are
latitudes with the exception of Ice hills, which sufficiently cold and (in the case of Tundra) wet.
may occur on high-altitude tiles with at least
Tundra and Ice are used (also) to represent
moderate rainfall in temperate latitudes.
alpine tundra, i.e. in plots that have a high
elevation but aren't rugged or high enough to
make them impassable.
Credits Adopted some code from C2C_World.py that adjusts per-tile temperature values to
the tile's distance from the sea.
170
Rationale Mixing some Ice hills into clusters of Peaks seems like a nice way to represent
mountain passes. That should be intuitive enough; I don't think players will interpret it
as a polar desert randomly existing at medium altitude in a temperate zone. Apart
from this special case, Tundra and Ice at medium or low latitudes look too strange,
especially near the desert or jungle belts.
Tbd. Maybe Tundra hill would be a better choice for mountain passes; representing also
alpine tundra. I don't think both terrain types should be used – this only concerns a
handful of tiles on most maps.
Oases don't have to be surrounded by desert; a Oases only on tiles entirely surrounded by
few adjacent non-desert tiles are OK. No cold desert. Sometimes large deserts are placed right
deserts near the poles. next to tundra.
Rationale Oases that are totally surrounded by desert are rarely useful.
Attempt to turn lakes fed by a river into bays only Comment in the script (by Cephalo probably):
with a 50% probability. “It looks bad to have a lake, fed by a river, sitting
right next to the coast. This function tries to
minimize that occurrence […].”
Rationale I think those lakes are fine if they don't occur too frequently; don't want to “minimize”
their occurrence.
Lakes placed at the end of a river usually have Minimum size 3.
only size 1. If the inflow calculated from the
Such lakes are rarely placed at all on Standard-
rainfall model is high, the size can be greater
size maps with non-Low sea level. They're pretty
than 1. The specific conditions for such lakes
common on Huge maps. Not sure why this is so.
depend on the world size and sea level.
Rationale Those large lakes, combined with the frequent inlets make big maps look perforated.
And, even at Huge world size, if a scale model is assumed, the Earth would have very
few freshwater lakes with a size greater than a single tile.
And of course smaller maps should have some lakes as well. Seem to have occurred
pretty much only through “normalization” of starting sites.
The PM river generator gets to place some of the By default, v3.3 lets the DLL place all rivers.
rivers, the rest are placed by the standard river Optionally, the PM river generator (pretty much
generator in the DLL. And I've tweaked the PM unchanged since PerfecWorld 2) can be used
generator to discourage rivers in extreme instead. The PM generator is based on the
latitudes. rainfall map and tends to place most of the rivers
in extreme latitudes, especially near the equator.
This can leave few rivers for the temperate
areas, and Desert Flood Plains are also pretty
rare. The PM rivers also tend to be shorter than
the rivers placed by the DLL.
Rationale River placement should take into account how crucial a river is for human habitation.
Rivers through the rainforest have, historically, not been as important as, say, the Nile
or the Huang He. Covering the tropics with rivers also exacerbates the problem of
ahistorically high tile yields in that region.
I don't want to detach river placement entirely from the precipitation model, and some
more short rivers (placed by PM) make coastal regions more valuable, which
increases realism and may also, indirectly, help the game balance by making naval
units more relevant. Letting the DLL place some of the rivers seems like a good
compromise that should ensure a reasonable coverage with rivers across the map.
Tbd. Toffer90 has made extensive changes to the river generator in C2C_World.py, but his
code is based on a lake generator that doesn't look like it's straightforward to port.
171
The balancing ("normalization") of the tiles near In v3.2, all the standard normalization functions
starting plots is handled entirely by the DLL are disabled and replaced with custom code that
functions that most other map scripts use for seems very reluctant to make any changes: No
normalization. rivers or lakes are added, no bad terrain (tundra)
converted, jungles and peaks only removed
when they occur in large numbers. v3.3 has re-
enabled the addition of rivers and lakes through
the DLL.
Rationale The PM normalization code can lead to awful starting locations. BtS might do a bit too
much balancing (especially for a map that's supposed to look natural), but, fortunately,
I've already made changes (id 108, 027) that make the balancing less aggressive.
Added some code that encourages one starting The PM code for assigning starting sites tries to
site per continent to be placed inland. However, (after narrowing the search to a few dozen
this only matters if the Starting Position Iteration candidate sites) maximize the distances between
(SPI) algorithm is disabled through XML; when starting sites. This means civs frequently start on
SPI is enabled, the DLL takes over the the tip of some peninsula (where they may easily
assignment of starting sites. get boxed in) and virtually never on a non-coastal
tile.
Rationale The PM code also suffers from using custom functions (“potential value”) for tile
evaluation, which, I'm confident, are inferior to the ones in the DLL that have been
improved a lot through changes 031 and 027.
Tbd. The potential value functions are still used for splitting up the map inot New and Old
World for the Old World Start option. Ideally, the found value function in the DLL
should be used instead – or the DLL should handle the split entirely (Old World Start
game option usable for all map scripts).
It might also be nice to use the starting sites assigned by PM as the initial solution of
SPI. That's awkward to implement; see comment in PM's findStartingArea
function. Or, if the current initial solution (i.e. the BtS algorithm in the DLL) actually
works better, then PM should not waste time computing its own starting position.
Seems a bit difficult, though, to separate the Old/ New World split from the
computation of specific starting sites.
Resources are placed in the standard way Custom code for resource placement. Seems to
(CvMapGenerator). be largely the same as in CvMapGenerator. I
guess cephalo wanted to make some changes
Fur can only be placed on flat tiles, and only
without changing files other than the map script.
above a latitude of 35°. This applies to all map
scripts. The BtS map generator places Fur on flat and
hilly Tundra and Ice tiles at any latitude. Since
PM uses Tundra and Ice (usually as hills but not
always) to represent high elevations, Fur can
appear fairly close to the equator. Deer is
restricted to latitudes above 30°.
Rationale I want my own, more extensive, changes (129) in CvMapGenerator to apply instead of
the PM changes. (The PM BonusPlacer class also seems to be quite slow, but that's
only based on one sloppy test.)
The Fur change isn't really relevant for PM anymore now that I've restricted Tundra
and Ice based on latitude. It could matter for other map scripts.
Fur near the equator could represent savanna fauna, but, in BtS, that's clearly not the
idea. 35° is still pretty far away from the poles, but, in combination with the no-hill
restriction, it should be OK. Fur on hills doesn't make perfect sense to me anyway as
the most widely known fur-bearing animals (beaver, ermine, mink) live near water,
172
which tends to be more abundant in flatlands (mountain valleys too, I guess). Perhaps
fresh water should be required?
Option for using the PerfectWorld 2 Climate Options "PW3 Generator (Square Grid -
System removed. Also can't opt for the hex- Accurate)", "PW3 Generator (Hex Grid -
based PerfectWorld 3 landmass generator. I've Interesting)" and "PW2 Generator" for landmass
kept the Perfect World 2 landmass generator as generation; and "PW3 Climate System" and
an option (renamed to “Plate Tectonics”). "PW2 Climate System" for climate.
Rationale I want to remove experimental options in order to make the script easier to use.
I don't know how the two climate options differ exactly, but the older one tends to
produce continents that look like a fried egg with spinach (see e.g. this screenshot); I
think the newer climate option is less predictable in this respect.
The hex-based generator seems like an intermediate result of back-porting the Civ 5
code. I guess it adds some noise to the process; doesn't look particularly interesting to
me. As for the Climate Systems, it looks like cephalo ported the PW2 system to Civ 5,
made some adjustments, and then LunarMongoose copied the Civ 5 code back to
PM, keeping the older version as an option.
Tbd. Should probably just delete the PW2 climate code (so far, I've only removed the
option from the menu).
"Break Pangaea" map option removed. Enabled If the Break Pangaea option is enabled (which it
if and only if the Old World Start option is set. is by default), the script checks in the end if there
is a single group of continents (spearated only by
Reduced the maximal number of meteors and
coastal water) containing more than 70% of the
their diameter. Inside that diameter, the elevation
land tiles; if so, circular groups of land tiles are
is decreased. The decrement is maximal in the
removed (explained as meteor strikes) until all
center and becomes gradually smaller toward the
continents have at most 70% of the (remaining)
edge of the crater. This way, there are usually no
land tiles. The impact sites are chosen based on
Peaks on coastlines created by meteors.
(I think) the betweenness centrality metric. The
After each meteor, the sea level now gets number of meteors is limited to 15, the average
adjusted to restore the land-sea ratio. (Meaning diameter appears to be about 9 tiles depending
that a meteor will eliminate land tiles in one place on map size. All tiles in the diameter have their
and -indirectly- create new land tiles in other elevation set to 0. Since Peaks are placed (in a
places.) later step) based on differences in elevation,
coastlines created by meteors are (always?)
covered by Peaks. Since the total number of
Peaks to be placed is limited by a target ratio,
few or no Peaks get placed inland.
The meteors can strike only land. The meteors may strike coastal water. This
doesn't necessarily turn the coastal water into
ocean because that's a matter of distance to land
and not elevation.
Credits The sea level update is inspired by C2C_World.py. CFC posts by Toffer90 on the
subject: 1 | 2
Rationale “Meteor” works as a metaphor for explaining the Pangaea split algorithm, but the
meteor impacts shouldn't be easily indentifiable on the map – meteors don't really
alter coastlines, and the impact sites could also leak map knowledge.
It's not guaranteed that the meteors succeed in It seems that the meteors usually succeed, but
creating a New World that is significantly larger they may remove so much land that the map
than the islands that PM tends to create looks like a plucked goose and the Old World
regardless of the Break Pangaea option. At least becomes very crowded.
at Medium and High sea level, the success rate
173
seems pretty high, let's say closer to 100% than
to 50%.
Rationale Relaxing the limit on the number of meteors (i.e. moving back toward the PM limit)
could increase the success rate. Since the land-sea ratio gets restored, this wouldn't
render the map unplayable; I only worry that it'll look too peculiar.
See also I've added a recommendation about the number of players to the label of the Old
World Start option. This is consistent with change 137, which adds such
recommendation labels for Low and High sea level.
Latitude is taken into account when identifying a Only based on tile counts; so the New World or
suitable continent (or group of continents with a Old World may have far fewer habitable tiles than
shallow-water connection) to serve as the New anticipated.
World.
Rationale Latitude is a simplistic heuristic; a quick stopgap change.
Modified the Perlin noise and (more so) Plate Both map generators rarely, if ever, produce a
Tectonics landmass generator to encourage continent of Eurasian proportions. The Perlin
larger continents. Also randomized some noise (PerfectWorld 3) often yields results similar
parameters (which didn't seem to have a big to the “Snaky Continents” option of other map
impact on the size of continents) for greater scripts.
variety.
For PerfectWorld6, cephalo has made the same
tweak as I (increased twistMinFreq) to the
Perlin noise generator.
Rationale More massive continents are more Earth-like and make diplomacy more interesting.
Should occur at least sometimes.
Tbd. Still not massive enough. I don't think the Perlin noise generator has a suitable
parameter. Reducing the resolution (hmWidth, hmHeight) should, in theory(?), result
in coarser structures, but lowering the resolution quickly results in block artifacts. I
guess one would have to combine Perlin noise with a different input – e.g. the Plate
Tectonics (PerfectWorld 2) generator.
That said, I don't know how to get massive continents out of the Plate Tectonics
generator either (except by increasing the map grid size). May have to add debug
output and really look at what's going on and at the resulting height map.
When placing lakes, the map areas are now They're recomputed after every added water tile.
recomputed only once in the end. This adds a couple of seconds to the total map
generation time.
I'm not sure if this is purely a nonfunctional
change, but at least I'm not seeing any adverse
effects.
Tbd. Could probably improve the performance substantially by moving some code into the
DLL. That said, it's difficult to determine which parts are slow. So far, I've only stepped
through the DLL-to-map-script calls in the debugger to get an impression. The lake
computation stuck out a bit but was still only a small portion of the total time.
The elevation map (i.e. early in the process of Both landmass generators seem to make some
generating terrain) gets shifted sideways by an effort to avoid land at the map boundaries, but
offset in a way that minimizes elevation values at the result is not reliably optimal.
the western and eastern map boundaries.
Credits Based on code in Totestra (Git commit). Though the latest, “streamlined” version has
thrown that code out (Git commit).
Rationale Still doesn't reliably avoid land at the boundaries. It's not even possible to do when
continents overlap horizontally. And my algorithm optimizes a (weighted) sum of
174
elevation values; a more exact result could be achieved by calculating the sea level
threshold and counting the plots above the threshold. However, making use of the
target land-sea ratio this early in the map generation process might be a bit messy. In
any case, based on some limited testing, the current solution does improve things.
175
023 Occupation countdown based on revolt probability
AdvCiv BtS/ K-Mod
The occupation timer (after conquest or a revolt) The occupation timer is decreased by 1 each turn.
is decremented only with a per-turn probability
equal to the tenth power of 1 minus the revolt
probability. The revolt probability is not adjusted
to game speed in this context (normally smaller
on slower game speed, which would result in a
higher chance of decreasing the occupation
timer). I.e. the expected duration is the same on
all game speed settings.
When a city is conquered, the occupation timer Occupation after conquest last for 3 turns plus
is set to the minimum of 3 and the population 50% of the population size, e.g. 13 turns in a size-
size. 20 city.
A revolt sets the timer to 2 plus the number of Also 2 in BtS and in K-Mod 1.45 (but 3 in earlier
prior revolts. K-Mod versions).
Damaged units have their culture garrison Unlike combat strength, garrison strength is
strength reduced proportionally to the damage. unaffected by damage.
The per-turn chance to decrease the occupation
timer is shown on the main interface (city tile
help text) and on the city screen (Nationality bar
help text).
Rationale BtS occupation times get too long in Renaissance; one reason why it's difficult to
catch up at that point. 10 turns is a very long time when the game may last just 100
more turns, and the city may still have to spend some 20 turns on essential buildings
before it starts paying off.
By basing the occupation duration on the revolt probability, I hope to reward players
that conquer only one or a few cities at a time and can then afford to sit in them to
make occupation end quickly. Generally, occupation durations are still going to
increase as the game progresses – mature cities tend to have high revolt
probabilities. Now, 3 turns is often just the time that units need for healing anyway, so
this would hardly slow down conquests if it weren't for the reduced garrison strength
of damaged units.
I'm not showing a message when an occupation counter is decremented; could
become too much when occupying several conquered cities.
The pace of warfare is generally not adjusted to game speed. Not just movement, but
e.g. also healing is relatively fast on slower game speed settings. I think occupation
should be treated the same way.
Config The conversion of revolt probability into the probability of decrementing occupation
can be tweaked in GlobalDefines_advc.xml. Can also restore the BtS rules there
(longer but deterministic occupation).
See also 101 reverts the K-Mod changes to revolt probability.
099c makes revolts more common by allowing them to happen outside of foreign
culture range. 023 wouldn't really work without 099c because, in BtS, conquered cities
often have 0% revolt chance.
210b displays an alert when occupation ends.
176
Revolts can't happen in occupied cities (conquest No revolts during occupation.
or prior revolt) if the city owner is at war with the
cultural owner. If they're not at war, a revolt in
occupation is possible but mitigated by the
following special rules:
• The revolt test is only executed if the
decrement-timer test has failed.
• Revolt probability is halved while in occupation
• A revolt during occupation does not increase
the occupation timer; it does increase the
revolt counter and can flip the city.
Culture garrison strength doubled while at war.
Being at war does not increase culture garrison
strength.
Rationale If revolts were impossible during occupation, a player could withdraw all units to
deliberately prolong occupation, which makes the city worthless for the current owner
– but also for the cultural owner (can't flip).
Regular revolts during occupation would be too punishing though. The halved
probability only makes up for the loss of garrison strength when units are damaged as
part of a revolt.
I don't like having complicated special rules for revolt during occupation, but I don't
see a better solution. Or perhaps a city should flip deterministically after spending 10
consecutive turns under occupation (unless at war)? That would be a bit simpler.
It's a bit problematic that cities can remain under occupation indefinitely while at war,
but the above rules would lead to small probabilities of potentially painful revolts pretty
regularly. I guess a grace period would have to be added (there's already a timer for
cultural ownership after conquest), and maybe if foreign culture strength were halved
(quartered? martial law does make it easier to put down a rebellion) instead of halving
revolt probability, it could work, but that wouldn't work so well for peacetime
occupation – would usually drop revolt chance to 0 once a revolt occurs. (Or maybe
that's OK?) Pretty sure that allowing revolts while at war would further complicate the
rules. Revolts while at war would also have to be counted as a war success of the
revolt (AI) player.
See also Brief CFC discussion about revolts under occupation.
An occupied city heals units only as fast as a An occupied city heals as fast as an unoccupied
friendly non-city tile (15 HP per turn). one (20 HP per turn) except that Hospital doesn't
count while in occupation.
Rationale For plausibility and to slow wars of conquest down a bit more. 10 HP per turn (heal
rate in neutral territory) might be even more appropriate, but then players could heal
units faster by moving them onto some owned tile adjacent to an occupied city, which
would be counterintuitive and tedious.
177
024 Order in which AI contacts other AI randomized
AdvCiv BtS
When contacting other AI civs for trades, the AI Fixed order based on the player slot id.
goes through them in a randomized order.
Rationale Some deals aren't mutually exclusive, but the AI can e.g. give away a resource only
once, and may only have enough gold to convince one civ of a joint war. The fixed
order leads to a slight bias for trading with AI civs with low ids.
178
026 More gold offered in AI-proposed deals
See also 134a gives humans a discount when suing for peace.
AdvCiv K-Mod
When an AI civ contacts a human with a trade The AI can offer deals that are slightly more
offer, when trying to balance both sides of the favorable to the player, but the portion of the AI
deal, the AI is willing to give away more gold treasury offered for trade isn't increased.
than normally. If the player negotiates, the extra
gold is no longer offered.
Rationale The aim of the K-Mod change was to make it "worth considering the deal the AI offers
[...] rather than going straight to the renegotiate button" (from the K-Mod 1.07
changelog). But a worthwhile offer still seemed very rare, so, while worth considering,
it didn't exactly hurt to never consider AI proposals.
Config AI_OFFER_EXTRA_GOLD_PERCENT in GlobalDefines-advc.xml
Tbd. A general problem with any one-time offers: If the player can't just click "renegotiate",
then the player doesn't know what else the AI might have. Encourages the player to
routinely enter the Foreign Advisor during diplo. The only fix I can think of (other than
removing the one-time offers) is to have the AI remember its initial offer. Then, if the
deal is renegotiated, that offer remains available through "what would make this deal
work": If the player offers to give the AI what it had originally asked for (or that and sth.
in addition), or asks for what the AI had originally offered (or a subset of it), the AI
suggests the original offer unless it finds an even better one. This way, the player
would again always renegotiate, but would still take a look at the original offer in order
to possibly get back to it.
For now, I've added a loading screen hint about opening the Advisors during diplo.
Another way to make one-time offers more attractive: Increase the trade value
counted for "fair and forthright" trade if an AI offer is accepted without renegotiation
(but don't increase the trade value for trade with worst enemy). Or even decrease fair-
trade memory if an AI offer is rejected. Or, another idea: Relax trade denial checks,
e.g. by randomly treating the relations modifier as a couple of points higher when
making attitude-based checks while putting together an AI-to-human trade offer.
Another issue: AI-proposed tech trades are often worse than the trade resulting from
"care to renegotiate" → "what would make this deal work?". Should check
AI_counterPropose before offering a tech trade to the player.
027 Changes to the selection of starting sites; starting position iteration (SPI) algorithm
See also 021b: PerfectMongoose has its own algorithm for assigning starting locations, which
SPI, if enabled, supersedes.
108: “Normalization” of starting sites (based on the results of SPI).
108b may swap starting sites between players (based on the results of SPI).
031: Changes to AI city site evaluation – which is the basis for the initial selection of
starting sites. Many of those changes also factor into the evaluation of the space for
expansion performed by SPI.
CFC thread about SPI
AdvCiv BtS
If the map script doesn't override any starting There are three DLL functions concerned with
position function, then SPI treats the position starting positions that map scripts can override:
found by CvGame::assignStartingPlots as an assignStartingPlots, findStartingPlot and
179
initial solution (to the problem of finding a findStartingArea. The following official/
balanced starting position, i.e. an assignment of bundled scripts override none of them:
one starting site to every civ) that it tries to
Fractal, Continents, Balanced, Big_and_Small,
improve on iteratively. Upfront, SPI computes a
Medium_and_Small, Hemispheres, Great_Plains,
selection of alternative starting sites, typically 5 to
Tilted_Axis, Ice_Age. Likewise, K-Mod's
10 times as many as the number of civs in the
not_too_Big_or_Small doesn't override any
game. Those sites are selected in a way that
starting position functions, nor does AdvCiv's
balances maximal found-city values (evaluating
Mixed_Continents (advc.mxc).
only city radii, not surroundings) against maximal
dispersal across the map. Each iteration then Those scripts leave it to CvGame::
considers moving one or two of the current assignStartingPlots in the DLL to assign a
starting sites to alternative sites. If a (single or starting site to each player. That function greedily
double) move is found that significantly improves assigns a starting site to one player at a time by
the attributes of the position, then SPI commits to calling CvPlayer::findStartingPlot, which, in
that move. Then the next iteration starts unless turn, calls CvPlayer::findStartingArea to
the new solution is already deemed good enough select the least crowded landmass, and then
or a time limit is reached. SPI also terminates if selects the starting site with the highest found-
none of the considered moves would be an city value on that landmass. The found-city value
improvement. I'll briefly describe below how computation penalizes short air distances to any
starting positions are evaluated, i.e. what starting sites already occupied by other players
attributes are treated as desirable, and which (CvPlayer::startingPlotDistanceFactor),
moves are taken into consideration. and takes into account workable tiles on the
same landmass in a 11x11 (K-Mod: 13x13)
square centered at the prospective starting site.
If a map script overrides findStartingArea, The scripts Lakes and FantasyRealm override
then SPI considers only alternative sites on only findStartingArea. I think in a pretty
landmasses where at least one starting site is inconsequential way since those scripts create
located in the initial solution. I've modified only one major landmass anyway; so they
PerfectMongoose so that it overrides basically work as described above.
findStartingArea instead of
assignStartingPlots. when the Old World The remaining scripts (offical, bundled and also
Start option is used and otherwise leaves the all scripts from the PerfectWorld family) override
starting position entirely to the DLL. assignStartingPlots or findStartingPlot.
Most of them merely limit the set of potentially
SPI will freely change starting positions in non- valid starting sites and then let the global
team games on Pangaea. For Pangaea team findStartingPlot function defined in
games and for any other scripts that override CvMapGeneratorUtil.py greedily select the
assignStartingPlots or findStartingPlot, valid sites with the highest found values.
SPI takes no action. Effectively the same thing as CvPlayer::
findStartingPlot in the DLL except that the
crowdedness of the landmasses isn't explicitly
taken into account.
Donut and Pangaea only allow coastal starts; the
latter applies that restriction only in team games.
Highlands, Boreal and Rainforest don't restrict
starting positions but perform some cleanup
around the sites found by CvMapGeneratorUtil.py.
Tectonics, Earth2, Terra and NewWorld rule out
New World starts. Earth2 also has more than
15000 tiles at Huge size. GlobalHighlands has
nearly as many; also problematic.
The other scripts impose various non-trivial
180
restrictions.
Scenarios without fixed starting coordinates
SPI also handles players in scenarios that have
(StartingX=/ Y=) and without preplaced cities
no fixed starting coordinates, i.e. players with
(CityPopulation=) use
RandomStartLocation=true or any players that
CvGame::assignStartingPlots. If those
didn't get one of the plots designated as
StartingPlot. And I've dialed down the
scenarios have plots flagged as StartingPlot,
randomness resulting from the then those plots are randomly distributed among
RandomStartLocation flag.
the players. If there are more players than
starting plots, then CvGame::
assignStartingPlots will find additional
starting sites – as it would e.g. for Fractal.
Exception: Players set to
RandomStartLocation=true in the scenario file
can't receive one of the designated starting plots;
the WB scenario parser will instead call
CvPlayer::findStartingPlot with
bRandomize=true. That parameter adds (a lot
of) random noise to found-city values. The BtS
version of the Europe scenario is the only
scenario that uses RandomStartLocation=true.
The six starting plots from the Vanilla version of
that scenario still exist in BtS, but are no longer
used (because all players receive random starts).
Config SPI can be disabled through ENABLE_STARTING_POSITION_ITERATION in
GlobalDefines_advc.xml. For PerfectMongoose, the map's own algorithm can be
re-enabled (to take precedence over SPI) in PerfectMongoose.py (search for
“advc.027”). The exception for the Pangaea map script is hardcoded in
StartingPositionIteration.cpp.
Debug output can be enabled in StartingPositionIteration.cpp (SPI_LOG,
DEBUG_SPACE_BREAKDOWN). For debugging, MapRandSeed and SyncRandSeed should
be set to a value greater than 1 in CivilizationIV.ini; otherwise generated maps
aren't reproducible. For PerfectMongoose, self.UsePythonRandom = False has to
be set in addition in PerfectMongoose.py.
Regarding scenarios with RandomStartLocation, the randomization of found-city
values can make sense to avoid getting the same starting sites in every game. That
said, the Europe scenario has random resources anyway, and, in any case, the
randomness was overdosed.
Rationale Desirable properties of a starting position (some obviously conflicting):
• Fairness – giving every civ a realistic chance to compete with every other civ.
Some degree of unfairness is in my opinion also desirable because this magnifies
the effect of the StartingLocPercent handicap (see 108b) and thus can be a
fairly organic way to make the game more challenging.
• Tension – if sites are close together, the early game tends to be too tense, even if
the respective civs all have enough room for expansion to, in theory, coexist
peacefully. If sites are far apart, in particular, if one civ is alone its landmass, then
there is too little tension in the first half of the game.
• Plausibility – the starting sites represent the cradles of civilization; they shouldn't be
mediocre sites.
• Variation – a great variety of starting sites in terms of available yields, resources,
freshwater, terrain features, coast/ inland, latitudes, distance to other civs and room
for expansion increases replayability.
181
I think the BtS algorithm – with a fair number of tweaks by various modders – does a
pretty good job at finding the next best site. The main problem is that it's a greedy
algorithm, placing one player after another. The last site that gets placed and its
neighborhood often have too little space. On concave landmasse, the use of air
distances is another significant shortcoming. The PerfectMongoose (PM) algorithm is
less greedy and uses path distances across land, but neither BtS nor PM can deal
with shallow-water connections, which is a significant problem for PM because its
maps tend to be quite watery. The PM algorithm also tries too hard to maximize
distances between starting sites, which results in coastal starts all around.
On the bottom line, the unfair starting positions on “scraggly” maps like PM or the
Big/Small family seriously affect their playability, and also Fractal maps that are
supposed to be somewhat crowded (which is what the AdvCiv standard settings aim
at) often end up giving one or several players far too little room.
The motivation for using an iterative algorithm is that an evaluation of a given starting
position, while a complex task, is conceptually straightforward and computationally
feasible, while I'd have no clue how to devise an efficient algorithm that somehow
places all players simultaneously at their final starting sites. For centroidal Voronoi
tesselations, iterative algorithms that move one centroid at a time (Voronoi iteration)
have been used with some success. A Voronoi diagram isn't exactly what I need
because, in Civ, a) not every map tile is equally important, b) the distance metric
needs to account for obstacles, and c) tiles that are close to multiple starting sites
should not be counted for just one site. Nevertheless, the two problems have
similarities and the same type of algorithm might work for both. (That was my intuition
anyway.) It's also nice that the BtS algorithm doesn't get discarded; it's put to good
use for a strong initial solution.
Partitioning space is computationally hard. The pre-selection of alternative starting
sites goes a long way toward making the effort manageable. Typically, only a small
portion of land tiles are suitable as starting sites anyway (sufficiently high found-city
value), and dispersal, i.e. the elimination of all but one or two potential sites in a
cluster, only means that SPI isn't able to adjust starting sites by just one or two tiles;
such fine-tuning shouldn't be necessary either. Still, among dozens or, on
(super-)Huge maps, even a few hundred of alternative sites, it's infeasible to evaluate
every possible starting position. So the iterative algorithm is still needed for a heuristic
search in the solution space. I suppose that, given a function for evaluating starting
positions, one could apply genetic programming or reinforcement learning, but a
starting position evaluation is not cheap computationally and I don't think those
generic, off-the-shelf algorithms are frugal enough. Also, devising my own algorithm
was probably less work than integrating an external library.
One further desirable property – that I had taken for granted initially:
• Meaningful choice to move the starting settler
Initially, SPI made it optimal to settle in place most of the time. The first decision in the
game – arguably shouldn't be as consequential as it is – but even more importantly
shouldn't be boring. I've taken a number of small measures to improve the situation:
Increased the overall resource density a bit again (see 129); randomized the selection
of potential sites a little bit so that they're not always quite optimal locally; increased
found-city values a bit when there is a resource or other high-yield tile just out of
reach; increased the lake placement chance (normalization; see 108) a bit again;
introduced a bias for the inner ring when placing extra resources (normalization; see
108).
Tbd. Would like to use SPI for all map scripts, but will have look at them one by one to
figure out how SPI can respect the restrictions that they impose. E.g. for the New
182
World scripts, it should be possible to have them override only findStartingArea.
For others, it might be easiest to let the DLL ignore the restrictions in the script (going
by the map script name as I've done it for Pangaea) and to reimplement those
restrictions in the DLL. This way, the mod won't have to include modified copies of
unconventional scripts that I don't want to be listed near the top on the Custom game
screen.
030 treats land cordoned off by peaks as a separate continent. Does that solve the
problem with having to open up “pockets” of peaks on Highlands, Boreal and
Rainforest? Depends on how many there are; mustn't take too much land off-limits (as
SPI would probably do) when assigning starting sites. Should be OK at least for
Boreal and Rainforest; ought to have fewer peaks than Highlands. I've already
adjusted the starting site evaluation (under id 027, but regardless of whether SPI is
enabled) so as to avoid starts near a land area boundary. This is problematic on any
map because, if the normalization step ends up breaking the boundary, a starting site
that was previously isolated by a mountain chain can become unexpectedly powerful.
Some more specifics about SPI (rationales included):
When evaluating a postion, several statistics are computed that correspond to the goals of high
fairness, high plausibility and medium tension stated in the “rationale” box above. As for fairness, a
“start value” is computed for each of the current start sites, expressing how favorable the site is for
whichever civ that starts there, and the distribution of those start values (especially its outliers)
determines how fair the position is. The sum of the start values is a measure of the position's
overall plausibility. Tension is covered by a “volatility value.” All those values combine into an
overall “starting position value.”
The start value of a site is computed from its found-city value (counting only the city radius), a
“space value” for the surrounding land, or really any land that a civ starting at the site might be able
to claim, and modifiers accounting for possible trade and warfare. Those modifiers also take into
account game options, most importantly “No Tech Trading” and “Always Peace.” The “space value”
is based on path distances and tile “yield" values (perhaps a bit of a misnomer because trade
values of resources also factor in). All path distances and yield values are precomputed before the
first iteration; doing so repeatedly during the iterations would not be computationally feasible. Since
we're only interested in distances that involve potential city sites, the distance table takes up a few
megabytes of memory at worst. I use Dijkstra's algorithm with a distance metric that assigns a high
– but not necessarily prohibitive – cost to transitions from land to shallow water and from shallow
water to deep water.
The path distances still don't fully solve the problem of civs getting cut off by a rival city at a
chokepoint. Specifically, path distances fail when such a chokepoint is closer to the rival while
much of the terrain beyond the chokepoint is about equally close to both civs. I think this could only
be addressed by actually simulating how the civs will expand from a given starting position.
The order in which moves are considered is important because the algorithm commits to the first
decent move that it finds. Apart from saving time (by cutting the current iteration step short), this
isn't necessarily a worse strategy than selecting the move that offers the greatest immediate
improvement; such a move might lead into a local optimum. The algorithm considers moving
outliers (in terms of start values) first; negative outliers have especially high priority. Sites with high
volatility are also prioritized. Within the same continent, only moves to neighboring sites are
considered, the rationale/ intuition being that the initial solution can often be made to work with
minor local changes. The algorithm also considers destinations on other continents, but only a
single site per continent; this leaves it to subsequent iterations to optimize the placement within
that continent.
Moving just one site at a time doesn't seem promising, considering that every iteration step has to
improve the start position value. Often, moving one site from A to B will give some other site(s)
near A too much space or some site(s) near B too little, and the starting position value might only
183
improve if other sites are moved to compensate and then further sites to compensate for those
moves (ripple effect). The more the merrier, but I don't think moving more than two sites at a time is
computationally feasible, and it doesn't seem to be necessary either as the current algorithm works
well enough.
In team games, SPI computes starting sites as normal (see above) and then swaps sites between
players in order to let teammates start near each other and to avoid one team getting outnumbered
by another on any continent. A greedy algorithm is used. After SPI is through, the BtS algorithm
may make further swaps, but only when swapping significantly decreases distances between
teammates and never between continents.
Exception: For very large team games (high player count, high average team size), SPI isn't used
at all.
See also 108b makes some minor changes to the BtS algorithm. I've summarized the BtS
algorithm for starting site assignment in team games under that change id.
CFC post by me
Rationale The BtS algorithm doesn't take into account civ counts per continent. It's obviously
very unfair when e.g. all three members of team A start on the larger of two continents
together with a single of team B, while the remaining members of team B start on the
smaller continent. In such a case, a symmetrical starting position (two members of
each team on the larger continent) should be preferred. Fairness shouldn't always
overrule vicinity though; players of team games are used to starting near each other
most of the time, I guess it's important for the collaborative feeling. Also, having
teammates start far apart reveals more information about the map early on, which
diminishes the element of exploration.
I could've modified the BtS algorithm so that the distribution of players across
continents is taken into account, but I wanted to make use of the path distances
computed by SPI (which take into account shallow-water paths), and that was easier
to implement within the SPI class. The BtS approach of processing all possible swaps
(of starting sites between pairs of players) in an arbitrary order is also a bit suspect to
me. I've been too lazy to implement a sensible heuristic for ordering the swaps. My
greedy algorithm doesn't work great though; therefore I'm still running the BtS
algorithm afterwards with some restrictions. It seems to work especially badly for large
(or rather Huge) maps with large teams (more than 2 members). Teams can get split
up across three continents then even though the (main) continents are so large that
one team outnumbering another isn't a major concern. For now, I'm leaving such
maps completely to the BtS algorithm (i.e. no SPI at all). Perhaps there would be no
harm in letting SPI at least make the initial selection of starting sites (but on Huge
maps, SPI doesn't usually fare much better than BtS because of the time limit on the
number of iterations) ...
184
In summary, the Starting Position Iteration algorithm is, so far, used for the following map scripts:
Fractal, Pangaea (except team games), Continents, PerfectMongoose, Mixed Continents, not too
Big or Small, Big and Small, Medium and Small, Hemispheres, Balanced, Tilted Axis, Great Plains,
Lakes, Ice Age, Fantasy Realm, Savemap (New Starts option).
It also fills in missing starting sites in the following scenarios when the player count exceeds the
number of starting sites designated by the scenario:
Africa, Battle, East Asia, Eastern United States, Planet, South America, Europe
(In the BtS version of Europe, all sites get assigned by SPI.)
SPI is never used for maps with more than 12 000 tiles. Huge normally has about 10 000; Huge
PerfectMongoose and Terra are a bit larger, but still under 12000. SPI also isn't used for large team
games (specifically: if the product of player count and average team size exceeds 36).
185
Any Tribal Villages located directly at a starting Tiles with tribal villages are disregarded when
site get removed. Exception: Not in scenarios. looking for a starting site.
Rationale Finding good starting sites is more important than keeping the number and spacial
distribution of Tribal Villages intact. (Tribal Villages that were deliberately placed in a
scenario could be more important yet.)
When (re-)assigning starting sites to players, if Starting sites are selected without regard to
the sites were selected by SPI, then the start which player will start at which site. Technically,
values of the SPI final solution are used to the sites still need to be assigned to players; this
determine which site is the strongest. preliminary assignment is arbitrary. The proper
assignment is done based on StartingLocPercent
If the site that would be assigned to a human
from the difficulty level, which, apart from some
player purely based on difficulty has a high
scenarios, is going to be the same for all AI civs.
volatility value (as computed by SPI) and a
I.e. human civs are supposed to receive a better
similarly strong site (in terms of SPI start value)
or worse start than AI civs depending on the
has a significantly lower volatility, then the human
difficulty level. This is determined through found-
player is given the low-volatility site.
city values computed with the bStartingLoc
parameter (bNormalize in AdvCiv) so that tiles
surrounding the city radius (“greater range”) are
taken into account.
Rationale Found-city values aren't reliable when it comes to the space available for expansion
(see somewhere above); they also put too much emphasis on the tiles within the city
radius.
SPI tries to avoid selecting high-volatility sites, but this isn't always possible. Not
assigning those sites to human players should significantly reduce the ratio of
unplayable starts encountered by human players. That's worth compromising on
StartingLocPercent (although I like handicapping humans through their starting
site). High-volatility can just mean isolated on a somewhat small landmass or quite
close to rivals (but not necessarily boxed in). I wouldn't want to make such starts
exceedingly rare for humans, so it's good that the volatility avoidance mechanism
doesn't guarantee low volatility.
Tbd. It would be better to not to (re-)assign sites until after the normalization step. As it is
normalization can strengthen sites that looked weak, in some cases even drastically,
in particular, when a removed peak removes a barrier between two continents.
See also 108b: Other changes to the reassignment procedure.
When deciding whether a starting site needs to Based on found-city values with the
be improved during the normalization step, the bStartingLoc parameter (AdvCiv: bNormalize
game makes use of data computed by SPI (if SPI – if SPI isn't used), i.e. taking into account the
was used for computing the starting sites). Both city radius and its surroundings.
start values and found-city values (accounting
only for the city radius) are used. This mostly
applies to random extra resources and features, The food target is not affected by found-city
but can also lower the target amount of food for values.
sites where food isn't already abundant.
Rationale Use the best data available.
See also 108: Other changes to normalization
186
027b Store RNG seeds used for map generation
AdvCiv BtS
The seed set for the sync RNG and map RNG at Maps are generated based on the map RNG, but
game start are stored in savegames and the sync RNG determines the civ and leader
displayed in Debug mode when holding Ctrl selection at game start if “Random” is chosen
while hovering over the big flag button on the during game setup. The two RNGs are seeded by
main interface. When the map is regenerated, the EXE(?) with some random number (perhaps
the stored map RNG seed is updated. from the system RNG) unless MapRandSeed or
SyncRandSeed are set to a value above 0 in
CivilizationIV.ini. The game doesn't store
the seeds, so map generation is only reproducible
if the seeds come from the .ini file.
Rationale For development purposes. Reading the seeds off the flag button and entering them
into the .ini file is tedious, but at least there is now some way to reproduce the map
generation process when something unusual happens.
During the starting site normalization process, Normalization uses both RNGs, pretty
only the map RNG is used. haphazardly.
Rationale To reproduce a regenerated map, the sync RNG seed of the original map needs to be
used because only that seed will result in the same selection of civs and leaders. That
seed mustn't be used for normalizing the regenerated map though.
It's also just cleaner to commit to one of the two RNGs.
187
028 Submarines as escorts
AdvCiv BtS
When a stack with invisible and visible units is Invisible units only defend when revealed (e.g. by
attacked, the attacking player sees combat odds a Destroyer).
against the best visible defender, but an invisible
unit may replace that defender once the attack is
ordered, i.e. if the invisible unit is the better
defender (considering unit cost and combat
odds).
Invisible units don't defend if all the team's units
in the tile are invisible (same in BtS), i.e. an
attacker can't stumble upon an invisible stack,
and invisible units don't defend units of other
teams.
Rationale Not plausible for a Submarine to sit by while e.g. a fully loaded Transport gets
attacked by another Sub. The new behavior makes Subs worse in situations when the
defenders are outnumbered by modern ships, e.g. a Transport (or just a Work Boat)
and a Sub against four Battleships. That said, players can easily prevent this by not
stacking Subs with visible units. All in all, the change should make Subs (and Stealth
Destroyers) a bit more useful.
I don't think that this change poses a big danger for the AI. In theory, the AI could keep
running into the same submarine, but, typically, only individual units or small groups
hunt (seemingly) vulnerable transports. Moreover, the submarine will eventually be
overwhelmed or, if the AI is that far behind technologically, its fleet is useless anyway
and could be also be hunted down easily. It's not the same situation as with naval
mines (which Sid Meier says he's happy not to have implemented) that can take out
powerful units at a low cost.
See also Depends on changes to CvPlot::getBestDefender made for 061.
When an invisible unit on Sea Patrol gets Submarines can execute the Sea Patrol mission,
triggered, that unit may defend as if it were but if the pillaging unit can't see the submarine,
visible. no forced attack happens and the improvement
gets pillaged.
Rationale To be consistent with the change above.
188
See also under Tbd. there). Otherwise, it might have been more prudent to just disable Sea
Patrol for everyone (which had actually been the default AdvCiv behavior until v1.06).
CFC post claiming that the (BtS) AI never uses Sea Patrol. The withdrawal issue has
been fixed in BtS (3.13?).
189
Rationale For mod-mods; Dawn of Civilization uses this to represent satellites.
Credits from Dawn of Civilization (Git commit)
190
030 Peaks can separate areas
Config PASSABLE_AREAS flag in GlobalDefines_advc.
AdvCiv BtS
When one or several peaks make parts of a Only water can separate land areas.
landmass unreachable by land, that secluded
part is treated as separate land area.
Rationale Should make things easier for the AI. The AI still has to be able to handle dynamic
obstacles because of closed borders, and it can (but not that well).
Would prefer to base the rules for colonies and single-continent wonders on BtS
landmasses, but that seems like too much work. When e.g. Notre Dame is completed
in one area, would have to call changeBuildingHappiness on all areas with the
same RepresentativeArea id.
See also Without advc.enum, the additional areas would probably increase memory usage (and
thus cache performance) enough to affect performance and savegame size
negatively.
When sea ice makes part of a water area Only land can separate water areas.
unreachable, that secluded part is treated as a BBAI had tried and failed to implement separate
separate water area. Exception: In scenarios that areas for ice; see comments in ::areaValid
let the civs start with more than just a Settler and (CvGameCoreUtils).
Warrior (i.e. don't call CvGame::setInitial
Items), water areas are as in BtS.
(No change to the trade rules.) Trade cannot pass through ice (nor peaks).
Had to revise a lot of code related to unit The AI handles submarines well but builds all
movement so that the AI recognizes that sorts of ships in cities cordoned off by ice.
submarines can pass between adjacent water Barbarian ships can also spawn trapped in ice.
areas.
The amphibious canMoveAllTerrain unit ability I don't think the BtS AI supports it either. Anyway,
is not supported by my code. (Shouldn't crash, no unit actually has this ability. (Gunships can't
but the AI won't be aware of potential attacks.) enter water.)
When ice is added or removed (WorldBuilder,
global warming), the water areas are not
recalculated, i.e. the AI remains unaware if e.g.
the Northwest Passage opens up.
A city adjacent only to an ice-locked water area
of fewer than 10 tiles can't construct buildings
like Lighthouse that require an adjacent water
area of at least 10 tiles.
Rationale Shipbuilding in ice-locked cities makes the AI look very bad.
Tbd. Can't recalculate the water areas in a running game because various statistics and AI
data are stored at the CvArea objects; hence the exceptions for scenarios and global
warming. Another issue is that placing a Peak through WorldBuilder currently leads to
recalculated land areas, which should be fine when creating a scenario, but bad when
play is supposed to continue after exiting WorldBuilder. Should bite the bullet and
write code that preserves per-area data after recalculation. Starting site normalization
can also remove peaks; not sure if those recalcs are safe.
Also, plot groups (for trade network) aren't currently updated after removing ice.
(That's not an issue introduced by change 030, but still ...)
191
Or, if I can't do the above, I should at least change global warming so that Ice can only
melt when it is orthogonally surrounded by water (so that water areas are unaffected
by global warming).
Could limit the (step) diameter of water areas (by limiting the search depth of the
calculateAreas_visit function), which might help the AI when the geography
resembles the American continent (minus the Panama Canal). Then again, distances
between coastal cities are rarely long enough to make naval movement between them
impractical.
Regarding Lighthouses in ice-locked cities: Easier to implement this way. Also
plausible that a lighthouse isn't helpful in a city that is locked away from maritime
trade. Even more true for Harbor, Customs House, Great Lighthouse ...
I've cut some corners in the AI danger checks, meaning that the AI won't recognize
that an enemy submarine can attack across Ice that fully separates two water areas.
Seeing that submarines are normally invisible anyway, this will probably never be an
issue (and if 315 allows Explorers to enter Peaks, they'll still only be able to attack
Barbarians, and the Peak will probably block the Barbarians' sight anyway). If there is
a problem after all: I've left the code for handling such situations commented out in the
AI danger functions; the performance penalty is still going to be very small.
See also 003b: Lists functions introduced for dealing with submarine movement across Ice.
033: The checks for naval blockade had relied on water areas not being adjacent to
each other, so I had to change these checks.
051 is responsible for calculating areas in scenarios.
041 does allow Dry Dock and ship production in ice-locked cities.
Hover text on water tiles whose water area is adjacent to sea Ice and has a size of less than 10
says that the tile is “ice-locked”.
Rationale To give some warning to the player that cities won't be able to construct most coastal
buildings (and that ships, while allowed, may not be able to move anywhere).
While the new text is pretty low-key and players aren't going to inspect icelocked
water tiles often, I still would've preferred showing “ice-locked” only when a settler is
selected or when a city has been founded adjacent to the water area. But I think the
latter part would be confusing because water areas without a city would appear not to
be ice-locked.
Credits CFC user crullerdonut pointed the problem out to me.
Tbd. Show it only when a settler is selected?
AdvCiv BtS
Fractal-based map scripts are two times less It seems that Peaks are just as likely near water
likely to place a Peak on tiles orthogonally as inland. A Peak that is orthogonally adjacent to
adjacent to water than on other tiles. water can make part of a landmass inaccessible
via land. (Inland Peaks could do that too in theory
but would have to form a circle.) Almost(?) all
map scripts bundled with Civ 4/Warlords/BtS are
based on Fractal, but PerfectMongoose isn't.
Rationale On Earth, a drop in height from above the tree line to sea level is rarely so abrupt that
it would justify a Peak next to a water tile, though there are some examples, in
particular in the Central Andes. Still, there is (always?) a coastal strip wide enough to
be traversed even by an army, so Peaks completely denying land access to an area is
not realistic. Then again, the Darién Gap does prevent traffic by land between the
Americas. This is a case of swamps more than mountains, but Civ doesn't have a
swamp terrain type. As a compromise, I'm making Peaks that block coastal movement
192
less likely rather than impossible.
This discussion on CFC is somewhat related.
Config Implemented in Python (CvMapGeneratorUtil.py)
030b AI doesn't train cargo units for naval assault in land/ice-locked waterbodies
AdvCiv BBAI
Build cargo units for naval assault only in coastal Build cargo units for naval assault in all coastal
cities that share a water area with an enemy city. cities that don't have a land path to an enemy city.
Rationale Change 030 generally prevents cities that aren't adjacent to "relevant" water areas
from building ships, but doesn't address the specific case of building up for a naval
assault.
Tbd. The tracking of city counts per water area may not be totally reliable in scenarios. See
comment in CvPlot::processArea.
031 Changes to AI found value: Revised most of the code, rearranged it a bit and made
several additions
See also 108 makes changes to the found value of the initial city (which is important for starting
site normalization).
040 assigns a found value to unrevealed tiles.
052: changes AI found behavior in scenarios
007 makes some changes to the found values computed when the Alt key is held
down in Debug mode.
036b: changes to resource evaluation (few so far; affecting both city placement and
resource trade)
Tbd. I don't think the found value computation takes city specialization into account at all.
The computation of the culture modifier is quite primitive. The culture rates of nearby
cities should matter. There's also a K-Mod comment about that in (what's now)
AIFoundValue::calculateCultureModifier.
Perhaps introduce a personality-based factor that e.g. makes Willem (Netherlands)
want to found cities more closely together (i.e. worry less about overlap) and Genghis
Khan (Mongolia) farther apart.
AdvCiv K-Mod
AI considers settling on tiles without any bonus Tiles without a good bonus resource in the city
resource in the city radius if the city can expect radius are disregarded; resources that the AI
to work at least 3 freshwater tiles. Also considers doesn't have access to yet and food resources
tiles without any "good" resource if there are at are considered as "good".
least two (not-so-good) resources.
Reduced the impact of distance from capital Strong and uncapped impact of distance in all
based on era. No distance penalty for small-ish eras, making the AI highly reluctant to settle e.g.
landmasses near the capital. the New World on Terra.
Rationale A river (or oasis) without resources is rare, but can be worth settling on (esp. with
Flood Plains).
About the impact of distance: Need to be careful not to revive the AI habit of planting
colonies on a far edge of foreign territory. I think that used to happen in Vanilla Civ 4
193
and in Civ 3.
Fixed a likely bug in the K-Mod evaluation of Especially extra copies of strategic resources
additional copies of a resource near a city site. had been way overrated.
Utility of happiness/health/strategic resources Utility computed as if the resource could be
(i.e. not the utility from yield) halved when the connected. Unimproved copies not taken into
resource can't be connected yet. Further reduced account. This leads the AI to aggressively settle
if there is already an improved copy available. near any Oil sources when Oil isn't yet workable.
Reduced the penalty for bad tiles near a city site Sites with 10 or more bad tiles practically never
by subtracting a multiple of the number of bad settled. The bad-tiles check seems to be the
tiles rather than dividing by it. Decreased the main guard against settling land that isn't (ever)
base utility that the found value starts at. worth settling.
Utility reduced when a site has very little food; to The code that checks the available food only
the point of making the AI unwilling to settle takes into account food on resource tiles, along
completely dry areas. The penalty is not applied the lines of "the Grassland Cow will allow this city
to resource trade values though, so the AI could to work its Plains Hill Gold" but doesn't take into
e.g. settle in the middle of a desert in order to get account e.g. regular Grassland Farms, and the
access to Oil. low-food penalty is rather moderate. It applies to
the trade values of resources though (although
trading/ sharing of resources does not require the
tile to be worked).
Ice, desert and tundra hills counted as bad tiles. Hill and ocean tiles are never counted as bad
Ocean tiles count as half bad. (nor half bad).
When a resource enables units, the AI power Evaluates the unlocked units only based on how
values (from XML) of those units are factored useful they are compared with other currently
into the utility value of the resource (which, in available units. Tends to overrate Iron and
turn, factors into found value). underrate Oil and Uranium (once they can be
worked).
Increased the utility counted for yields from Utility is assigned based on the total yield from
bonus resources, especially if these yields are bonus resources (assuming they're all improved
provided from a small number of powerful and worked); the number of resources doesn't
resources. matter in this context.
The per-tile utility values are decreased by a The per-tile values are mostly based on tile
constant, then sorted in descending order and yields. The values are summed up without
multiplied by decreasing weights. The total is weights (or with uniform weights if you will). A
multiplied by a normalization factor to keep it on special penalty is applied for "bad" tiles toward
a similar scale as in BtS. The special penalty for the end of the found value computation.
bad tiles is much lower than in BtS.
Rationale The subtracted constant represents the food consumed by the citizen working the tile
and largely replaces the bad-tile penalty. The food consumption is the reason why e.g.
a yield of 2 food and 2 production is about twice as good as 2 food and 1 production.
The weights give the AI a tendency to prefer a few good tiles over a lot of mediocre
(or marginal) ones. A few powerful resources (e.g. Gold, Pig) are preferable to several
weak resources (e.g. Silk, Fur) because, in the latter case, it takes longer and costs
more food to grow the city enough to work all the resources. Also, while cities with few
worthwhile tiles aren't very profitable, they also don't cost much maintenance because
the population stays small.
Tbd. Shouldn't count bad tiles at all. The "special" yields from resources are also dubious;
should be possible to cover these through the tile weight distribution. The "taken" tiles
count also seems redundant. Try this:
Count for each tile in the city radius (and the city center) a yield vector that is the sum
194
of the nature yield and, if applicable, resource improvement yield. Subtract the 2 food
consumed per citizen. Compute from the yield vector a tile yield value that should also
include a base value to account for a run-of-the-mill improvement and (negative)
maintenance and civic upkeep paid for the extra citizen. (Predicting the improvement
type gets too far into the weeds I think.) Also compute a food surplus value for each
tile – or perhaps better two values: a natural food surplus and an improved surplus
that assumes Farm and Lighthouse if those are legal. Perhaps just assume another
+1 improved surplus in the Industrial era to account for Biology and food corporations.
From the tile yield values, culture modifiers, the sequence of decreasing weights and
the per-tile food surplus values, AIFoundValue::sumUpPlotValues needs to
compute the tile value, essentially simulating the growth of the city population,
applying penalties when the cumulative food surplus runs low or when the city relies
on food from culturally contested tiles. This should get rid of all the “special” variables
and the bad tile and taken tile counting.
When there is no easy means of generating culture, unowned tiles in the outer ring
and all foreign owned tiles should be penalized. This could be accomplished by
changing the criterion by which tile values are sorted before computing the weighted
sum. E.g. the first two positions could be reserved for tiles that can be worked without
expanding borders. Sorting should also be biased toward a high food surplus. Will
need a (private) CityPlot class for the sort criterion; should also be useful for tidying up
the main tile evaluation loop in AIFoundValue::evaluate.
Apart from the overall yield value, the weighted sum could also provide (a rough
guess at) the maximal city size and the cumulative yields upon reaching that size.
Those yields could be used to reward cities that specialize on one type of yield. The
maximal city size should also be useful for evaluating health.
Utility threshold for founding a city increases Increases only based on number-of-cities
throughout the second half of the game. maintenance, not game progress.
Threshold lowered based on the number of Threshold lowered based on total city
owned corporate HQs. maintenance (to prevent overexpansion), which
includes corporation maintenance and can lead
to very high thresholds once corporations have
spread.
Rationale Toward the end of the game, too little time remains for cities to become profitable and
amortize.
Corporations can cause high city maintenance before the Modern era, i.e. not that late
in the game. At that point, high city maintenance shouldn't worry the AI too much
because the corporations bring in high yields that can be turned into gold if necessary.
AdvCiv BBAI
Reduced the utility assigned for access to the Code added to encourage coastal cities for more
sea, especially when the site doesn't offer much AI shipbuilding but doesn't take into account how
production, when already having many coastal much production these cities would actually
cities and when playing on Pangaea. have. Also adds a clause that gives a substantial
extra boost to coastal sites when fewer than 25%
Nothing to encourage the AI to found at least
of the owned cities (rounded down) are coastal.
25% of its cities at a coast.
This can lead to coastal cities in totally awful
sites.
Rationale The current code may still encourage more AI coastal cities than would be rational,
and that's OK with me if it helps make naval units viable. But I see no reason to have
every AI civ found at least a few coastal cities – being entirely landlocked isn't a
particular disadvantage.
195
Tbd. Taking the map script name into account could help in other parts of the AI too.
AdvCiv K-Mod
Bug fixed: Tech requirement for removing Jungle The AI happily settles its second city in the
had not been taken into account. middle of Jungle.
Great reluctance to settle sites that will lose food
due to bad health during the Ancient and
Classical era. No change for other eras (except
for the bugfix).
Some extra utility for chopping opportunities, Chopping only accounted for indirectly through
utility from good health capped. good health.
See also 119 allows chopping only on owned tiles.
When computing the total potential production Count 1 production for any non-Hill land tile, even
rate at a city site, count 1 production for non-Hill a Peak and regardless of available technology.
land tiles only if a worthwhile improvement that
grants production (i.e. a Workshop with +2
production) can actually be built there.
2 production per Hill (no change).
Some utility is counted for tiles in the radii of Tiles within the radius of a city (rival or friendly)
other cities, i.e. tiles that could be stolen from are counted as "bad tiles" and otherwise
rival cities or shared with a friendly city. Such tiles disregarded. For tiles outside city radii that are
are not counted as bad tiles. within rival borders, tile utility is decreased (a bit,
say, by 25%) based on the amount of foreign tile
Stolen tiles: Tile utility is reduced through
culture.
essentially the same formula that K-Mod uses for
tiles that have a rival owner but aren't in any city The AI can place cities close to each other, it just
radius. I'm making that formula more pessimistic doesn't expect the new city to win any contested
overall and especially for tiles in a rival city radius tiles.
because the rival city owner is more likely to
focus on culture when there is a contested
workable tile. A second (new) formula accounts
for potential diplomatic (or not so diplomatic)
consequences of stealing tiles. This formula is
personality-based (Protective trait, power
threshold for limited war).
Shared tiles: I'm counting only those tiles that are
going to be assigned to the new city, and only
tiles that the old city is probably not going to need
in the medium term (i.e. not until it grows three
more times). Even then, the old city is normally
going to miss the tile at some point, and I'm
reducing the yield value counted for the new city
When the radii of two cities owned by the same
to about 40% to account for this. The tile is
AI civ overlap, the tiles are assigned based on
counted fully for deciding whether the new city is
step distance with orthogonal vs. diagonal as a
going to have sufficient food and production.
tiebreaker. K-Mod adds a routine for reassigning
I haven't changed the AI code that assigns tiles when close to a culture victory
shared tiles to cities. (CvCityAI::AI_getCityImportance).
Rationale This should mostly allow the AI to settle map regions with abundant resources (or
floodplains) more densely than regions with normal or scarce resources, in particular
in Earth scenarios (which tend to place a lot of resources in Europe). Multiple cities
can start working the good tiles faster than a single city can.
196
K-Mod comment in CvPlayerA::AI_foundValue_bulk: "it kind of sucks that no value
is counted for taken tiles. Tile sharing / stealing should be allowed."
As for counting bad tiles: Tiles in a city radius that the new city is very unlikely to win
are really bad tiles, but it's difficult to count them as such because of the structure of
the code. The bad-tile counting is a kludge anyway; I'm not sure that it's needed
anymore at all (or maybe just as a shortcut to improve performance).
karadoc on the bad-tile clause (CvPlayerA::AI_foundValue_bulk): "this final
condition is ... not something I intend to keep permanently."
Tbd. Ideally, the formula for diplomatic consequences of stolen tiles should check whether
the rival is a military threat.
See also 099b (culture decay) makes it a bit easier to steal tiles, especially those outside a city
radius.
The Financial trait is factored into the predicted Only done for river tiles, not for coastal tiles. AI
tile yield. civs with a unique naval unit or coastal building
have a preference for coastal spots, but the
Financial trait has no such effect.
See also The nerfed Financial trait (908a) still benefits coastal tiles.
AI leaders with Growth flavor are more inclined to Growth flavor biases the AI toward settling at a
settle at a plot distance of exactly 6 tiles from the plot distance of 6 or more(!) from the nearest city.
nearest city than leaders without Growth flavor. Plot distance is computed as max{deltaX,deltaY}
+ floor(0.5 * min{deltaX,deltaY}).
Rationale Growth flavor should mean that a leader likes big cities, so the city radii shouldn't
overlap much. Cities that are 6 tiles apart don't overlap; shouldn't encourage even
larger distances that may lead to unworkable tiles (or a another city getting crammed
in later on) and high distance maintenance in the early game.
When a tile connects two seas (non-Lake water The possibility of a canal does not affect found
areas), found value is increased based on the value. The AI considers canals when placing
size of the smaller of the two seas. Forts but only under narrow conditions and not
on workable tiles, meaning that the AI can't
establish a canal after settling in the city radius
around the tile that allows for a canal.
See also 121 (partly) deals with the Worker AI for Forts as canals
Tbd. This only works if the two seas are fully separated from each other by land or (through
change 030) ice. Will have to call the pathfinder to identify mere shortcuts like in
Panama or at Suez. Could do it as follows:
At the start of the game let CvGameAI compute a canal value for every land tile. It
would be better to do this e.g. once per turn and for each team independently based
on the revealed portion of the map and OB agreements, but I think this would be too
costly to compute. The canal value of a tile T should equal the number of movement
points saved by ships passing through a canal in T. Algorithm: Iterate over the tiles
adjacent to T in clockwise order (very cheap to do). Make a list of all water tiles
encountered directly after a land tile. In most cases, that list is going to be empty or a
singleton; this means the canal value is 0 or very small; set it to 0. If the length of the
list is greater than 1 (maximum: 4), i.e. if there are adjacent water tiles separated by
land, run the pathfinder on each pair of tiles in the list. Set an upper bound for the
path length somewhere between 30 and 40 (won't care if the shortcut is even greater)
for efficiency, and let the pathfinder only worry about water, land and impassable tiles.
Store the maximum of the computed path lengths as the canal value. Use the canal
value for the AI placement of cities and Forts.
197
Deleted a block of BtS code that had increased AI found values by 20% to 50% unless the city was
going to be the first colony on a landmass where a rival civ already had a city.
Rationale This was apparently supposed to discourage AI colonies on continents dominated by
rivals. Such cities are indeed difficult to hold onto. However, the checks were much
too coarse (a single city owned by a rival – perhaps even a friendly one – should not
discourage colonization) and the positive-reinforcement approach lead to a high
bottom for found values on the home continent, making the AI willing to settle
anywhere where an abundance of outright “bad” tiles didn't prevent it. Also, the code
did little to drop the found values of exposed colonies below the found threshold,
meaning that they were merely deprioritized compared with local cities. That's
something that the K-Mod evaluation for distances and empire shape will also
accomplish.
Deleted a block of K-Mod code that was trying to steer starting locations toward an even
distribution of players among landmasses.
Rationale This should be the responsibility of CvPlayer::findStartingAreas.
AdvCiv BtS
Count only major landmasses when calculating All landmasses are counted, up to a maximum of
the target distance between starting sites. the player count. This tends to lead to
unachievable target distances on Huge maps.
Rationale Looks like an oversight.
See also 137 adjusts the target distance to the greater default player counts in AdvCiv.
AdvCiv BtS/ K-Mod
Deleted the “greed” personality modifier. A BtS comment said that “Greedy founding means
getting the best possible sites - fitting maximum
resources into the fat cross.” K-Mod introduced
modifiers “easy culture” and “ambitious” that,
taken together, are based on the same leader
personality values and affect the found value
computation in similar ways.
Tbd. “Greed” in the sense of cannibalizing other potential city sites could make sense. For
situations when there is abundant space for expansion; possibly also based on leader
personality.
See also For the latest version of the deleted code (greed and the deletions mentioned above),
see this Git commit.
Lower threshold for founding cities when nearing a Domination victory.
Rationale Cities on marginal land can be a significant contribution toward meeting the target
land percentage, which is usually the tougher of the two Domination conditions.
See also 115b makes the AI more willing to grow city populations when approaching a Diplo
victory.
I've done away with all or nearly all fog-of-war Resources had been handled correctly in K-Mod
cheats in the evaluation of city sites. I think (probably not in BtS), but the fog of war
had been ignored for tile ownership. This also
meant that city sites recommended to human
players gave away AI cities in the fog of war. The
BUFFY mod (not included in K-Mod) had shown
recommendations only on actively visible tiles,
(presumably) to fix this info leak.
198
AdvCiv K-Mod
When normalizing starting sites (i.e. when Tribal Villages aren't accounted for at all.
determining whether a site needs additional
resources), some value is counted for Tribal
Villages in the starting city radius.
See also 027 will deal with Tribal Villages beyond the starting city radius. Also allows removing
Tribal Villages in order to free up a starting site.
031b AI trains Settlers only probabilistically when city sites are poor
AdvCiv BtS/BBAI(?)
AI governors compute a priority value for training When the conditions for training a Settler are met
Settlers based on the found value of the best city(nothing very urgent to do; at least one city site
site, the current found value threshold (which is, whose found value is above the threshold; OK for
among other factors, based on expenses) and city to halt growth), AI governors train Settlers
the game options Always War and Always with 100% probability regardless of the quality of
Peace. Protective leaders and voluntary vassals the city sites. Exception: In defensive wars, the
prioritize Settlers more highly. probability is only 50%.
When all necessary requirements (no change)
for training a Settler are met, the probability of
training a Settler is based on the priority value.
During the first 100 turns (Normal speed), the
probability is typically 100%; so the change
tends to matter most between turn 100 and 150.
See also CFC user keldath has pointed out to me here (and in a private conversation) that the
AI tends to expand too recklessly.
Rationale In part as a consequence of my changes to AI found value (id 031), the AI will claim
any land where a city can develop if it has relatively few cities (and no better land is
available); I think that's working as intended. However, the AI shouldn't be quick to
claim land that is barely worth settling. Delaying a Settler for some 5-10 turns can
open up new avenues, e.g. through revealing additional tiles or resources. Or perhaps
some other civ will claim the site, one whose capital is closer to it; that's also fair
enough.
AI may decide to cancel the production of a Unless in a defensive war or financial trouble,
Settler when there is no city site. Settlers are always completed once started. The
Settler is then disbanded after 20 turns unless a
city site becomes available.
199
If the DLL is compiled with the BBAI has added a global function logBBAI for AI
LOG_FOUND_VALUE flag, then a breakdown of the logging. It doesn't cover the AI found value
found value computation is written to the BBAI computation though. K-Mod added a little bit of
log whenever an AI civ founds a city. In addition, information that enters into the found value
a breakdown for the next best adjacent city site computation (e.g. about deadlocked resource
and for the next best city site is written to the log tiles) to the tile hover text in Debug mode.
file. A breakdown is also written when placing a
starting location and when “normalizing” (cf. 108)
a starting location.
Rationale It's a complex computation and, so far, my only means of testing it has been the
debugger, and that only worked with a savegame from right before the founding of the
city.
See also 003: Moved the found value computation into a separate class and refactored it. The
logging code was crucial for testing those changes.
Tbd. I've disabled the display of deadlocked resources display in hover text because I
wanted to move that computation into CitySiteEvaluator.cpp (it isn't used
elsewhere), and that has made it awkward to expose the function to CvGameTextMgr.
200
Rationale Better to be explicit about this.
See also This change also allows found values to be computed “as if normalizing” before
starting sites have been assigned. That might be helpful for 027 (though I don't think
I'll make use of it after all).
032 Signing a dual deal when there already is one causes turns-to-cancel to be reset
AdvCiv BtS
When a peace treaty, open borders or defensive Signing a peace treaty has no effect if there is
pact is signed between two civs that already already a peace treaty. Same for OB, DP.
have such a deal, then the turns-to-cancel are
reset to 10 turns. This can happen through a
diplo vote, or (peace treaty only) sponsored war
(due to change 146) or city trade (change
advc.ctr). I don't think gifts and demands are
possible when there is already a peace treaty.
OB and DP votes are nevertheless only allowed
(as in BtS) when some pair of full members
doesn't already have an OB or DP deal. I.e. the
vote can't be put forth just to reset the turns-to-
cancel of existing deals. (Nor can it be used just
to force deals with non-full voting members –
although this BtS restriction is a bit curious.)
Rationale More intuitive this way. Otherwise, e.g. the target of a UN peace proposal could get
attacked just one turn after the vote. Or Open Borders could be canceled shortly after
they've been enforced by the Apostolic Palace.
201
AdvCiv BBAI
When collecting gold from Privateers, compute BtS does it all based on air distance. BBAI uses
the plunder range based on path distance (e.g. path distance for blockaded tiles, but jdog seems
not across an isthmus). to have forgotten to change the plunder code as
well.
Rationale Or they had been worried about performance, but I'm only checking cities adjacent to
blockaded plots, which should be quick.
See also 030 (ice-locked water areas) depends on this change.
124: Can use blockade to let trade pass through hostile tiles.
AdvCiv BtS (BBAI and K-Mod made some changes to
the Privateer AI, but the basics are unchanged)
When selecting a city to plunder, the AI takes its AI Privateers behave largely like Barbarians and
leader's attitude toward the city owner and the treat all civs except the Privateer's team alike.
tech known to the city owner into account. The AI
doesn't use Privateers against ships and
improvements of partners. What a "partner" is in
this context depends on the AI personality. If the
attitude is equal to DeclareWarThemRefuse
AttitudeThreshold or worse, AI Privateers will
attack. This threshold is Pleased, Cautious or
Annoyed for all leaders except Catherine
(Friendly).
Rationale It's not smart to use Privateers against one's partners, especially not for attacks and
pillaging. An attack puts the Privateer at risk for no gain and the gold from pillaging
water improvements is negligible. Plundering a partner should be OK when there is no
one else to plunder.
Tbd. Privateer attacks on ships should have some upside for the Privateer owner. Stalking
ships is fun but just not rewarding. A ransom mechanism would be nice because it
would also curb the losses of the owner of the attacked ship but too much work to
implement at this point, and no other mod seems to have implemented this either. A
chance to steal the ship (in a damaged state, and any cargo transformed into a single
Worker)? Captured Caravels wouldn't be very useful though ...
See also 130v makes vassals Friendly toward their master.
Civs in a vassal-master relationship can't pillage Privateers can attack, pillage and plunder
each other's improvements with Privateers, can't everything not owned by the Privateer's team.
block tiles from being worked (CvUnit::
canSiege) and can't blockade each other's cities.
They can still attack each other's ships through
Privateers, and no restrictions apply to vassals of
the same master.
The AI never attacks ships of its vassals or AI Privateers attack anything that comes near
master. (That's the idea anyway. Seems difficult them.
to guarantee this ...)
202
Rationale About capitulated vassals, see below. Voluntary vassals plundering their master might
be OK, but a master plundering its vassals (voluntary or not) is jarring; the master is
supposed to protect the vassal. An AI change wouldn't stop a human master from
harassing his/her vassals, so this has to be prevented on the rules level.
I've considered changing CvUnit::isEnemy and getCombatOwner so that Privateers
of vassal/master behave as if they're on the same team, and revealing the Privateer
owners' identities between vassal and master. This would entail the following:
• can't attack each other and can coexist in the same tile
• can heal in each other's territory and enter each other's cities
• can't blockade each other
• moves shown as friendly
• Privateers not seen as a threat by the AI
This would be a pretty clean approach, but goes a bit too far I think. Implausible that
everyone on the vassal's and master's side knows a Privateer's identity, but other civs
have no clue. Submarines aren't revealed between vassal and master either.
If the owner if a vassal/master Privateer is to remain secret, then it has to remain
possible (for humans) to attack Privateers; otherwise one could tell who the owner is.
And if Privateers can be attacked, they should also be allowed to fight back, so, no
restrictions on Privateer combat. It's a little strange that combat is possible, but not
pillaging; I guess there's no perfect solution for this.
Credits Cruiser76 raised the issue here on CFC.
See also 123e makes it impossible to plunder Barbarian cities
Tbd. When using a Privateer to attack a unit that the Privateer owner is not at war with, and
hovering for combat odds, the mouse cursor shows a white circle. I think it should be
a red circle like for all other attacks. This isn't a result of my changes; it's a white circle
in BtS too.
Capitulated vassals only train Privateers if they Capitulation doesn't affect the training and
somehow have no other general purpose naval behavior of AI Privateers.
unit.
There is a unit "viability" check
All civs stop training Privateers once the game (CvPlayerAI::AI_calculateUnitAIViability) to
enters the Industrial era. prevent the production of outdated units, but
that's based only on units that the same civ can
train, not the global tech level.
See also 130v makes capitulated vassals subservient to their master in most regards.
Rationale Capitulated vassals shouldn't even indirectly interfere with their master's goals. Don't
want them to use Privateers against civs that the master might like (with a human
master, one can never tell) and don't want a blockading Privateer to affect the master
indirectly e.g. by cutting off some important sealane.
The Privateer's plunder ability is listed in Only mentioned on the BtS concept page about
Civilopedia and help text. trade blockades. For the Privateer, only the
hidden nationality ability is listed.
A feat message ("Congratulations, you have
trained your first Privateer ...") also explains
plundering, but that's a one-time notice.
203
Rationale Technically, the Privateer doesn't have a special plunder ability. Any ship can collect
plunder if it can manage to blockade a city without declaring war. This rule is very
obscure though; need to list plundering as a separate ability.
Also, when a player wonders why a Privateer can't plunder a vassal, that player may
look up the Privateer in Civilopedia, and there it'll now say that Privateers have the
ability to plunder rival cities.
AI civs don't blockade Barbarian cities. Not sure if the BtS code actually targets
Barbarian cities for blockades or only ends up
blockading them opportunistically while
bombarding.
Rationale No gain in starving Barbarian cities.
Tbd. Naval bombardments of Barbarian cities might still happen, and then the AI would
also blockade. There's no point in this because Barbarian cities normally only have
building defense, and by the time Frigates become available, most AI land units
ignore building defense.
Only Privateers can blockade at peacetime. All warships can blockade inside the Open
Borders of other civs. This only affects the trade
of the ship owner's war enemies (if any).
Rationale Confusing; makes it look like the tile owner is being blockaded. Also not realistic that a
civ that has Open Borders with both sides of a war would allow a blockade in its
waters.
Non-Privateer units can't blockade at all if not at war with any civ.
Rationale Blocking Barbarian trade doesn't make sense. The advantage is that blockading units
will be woken up (with the change below) once a war ends (well, once all wars end).
It's easy to forget about blockading units after making peace.
When the owner of a tile changes, blockading Can e.g. prevent a Privateer from collecting gold.
units in the tile are only woken up if the blockade
is no longer legal.
Blockading units are awoken at the end of a turn Will blockade (to no effect?) indefinitely unless
if the blockade is no longer legal; e.g. because manually woken up.
the owner of the current tile has capitulated, or
(see above) no longer fighting any war.
Added a function CvUnit::blockadeRange for code shared by updatePlunder,
collectBlockadeGold and CvGame::updateColoredPlots. This should also address some
minor inconsistencies between them. Also replaced some duplicate/ inconsistent code with calls to
CvUnit::canPlunder.
Now using a pathfinder function written for 104b for computing the tiles affected by a blockade
because that function has a range limit (whereas the BtS function CvMap::
calculatePathDistance is quite slow when tiles are unreachable) and can handle movement
restrictions of non-oceangoing ships.
Removed some unnecessary updates of plot groups and trade routes. This change mostly
eliminates the delay after starting/ending a blockade with a non-Privateer unit; doesn't really help
with Privateers though.
See also Without 003m (which caches atWarCount), this could be slightly slow.
034 Temporary Open Borders after war (optional through XML, disabled by default)
204
AdvCiv BtS
When a war ends, an Open Borders (OB) When a war ends, units are immediately bumped
agreement is automatically signed between the out of rival territory, teleporting to the nearest tile
former belligerents. Units aren't bumped until that they can legally occupy. The AI is not pro-
that agreement ends after a configurable grammed to anticipate this.
number of turns (recommended: 3 to 5). It's a
special OB agreement, internally called a
"disengagement" agreement, that does not
affect trade and diplomacy; only a right of
passage for units.
Details about the temporary OB agreement:
• No movement bonus from roads and railroads.
• No risk of getting caught for idle and moving
Spies.
• Canceled when a proper OB agreement is
signed, or when a Vassal Agreement or
Permanent Alliance is signed.
• Shown as "Open Borders (x turns)" on the
scoreboard and in other help text.
• The turn on which peace is made counts as
the first turn. When it says "1 turn" remains,
then the agreement is canceled at the end of
the round.
• Unaffected by embargoes.
Rationale To allow the AI to reposition its units after a war, in particular, to prevent large AI
stacks from getting stranded. This happens quite regularly when the AI conquers a
remote city, and it can be very harmful for the AI because it still counts on those units
when when deciding on war/peace against a third party and when calculating needed
floating defenders. The change also reduces unit bumping, which is a pretty strange
mechanism.
The ability to explore the territory of a former war enemy just after the war ends is
highly immersion-breaking though. It's worse than I had anticipated before imple-
menting this change.
Config Increase DISENGAGE_LENGTH in GlobalDefines_advc.xml to enable this change.
Tbd. Not properly tested.
The "You have made peace with" message (CvTeam::makePeace) should also
mention the Open Borders.
See also 035 (also disabled) would also address the problem of stranded units. 099b (tile
culture decay) addresses it a little bit.
046: AI improvements for units stranded on a different landmass and changes to the
bump algorithm.
035 While at peace, civs own all tiles that no other civ could work
205
Config Currently disabled (including the AI changes) through the OWN_EXCLUSIVE_RADIUS
switch in GlobalDefines_advc.xml.
Has been disabled for some time, but, as of v0.96, it still seems to work correctly as
reported here.
See also 099b replaces 035. If 035 is enabled, then the CITY_RADIUS_DECAY part of 099b
should arguably be disabled.
Revolt chance (101) is adjusted to 035 if it's enabled.
Tbd. Try letting civs only own those tiles in the exclusive radius where they're somewhat
close to having the majority culture; e.g. set a multiplier m := 75% and let civ A own
tile T in its city radius if culture(A,T) > m*culture(B,T) for every civ B that does not
have T in a city radius, and culture(A,T)>culture(C,T) for every civ C≠A that does have
T in a city radius. I guess inner and outer radius should be distinguished too. Perhaps
too complicated, but, other than that, it might play better than the decay in 099b.
AdvCiv BtS
A civ can only own a tile when that tile is either The civ with the highest tile culture owns a tile so
within the (workable) radius of one of the civ's long as that tile is within the culture range of one
cities, or when it's not within the radius of any of the civ's cities (up to 6 tiles depending the city's
cities that the civ is at peace with. I.e., at peace, culture level). Thus, tiles within a city's radius can
cities own all tiles that they could work and that belong to a civ that is too far away to work the tile,
no rival city could work, and the highest culture meaning that no civ can work it. War/ peace does
value only matters for tiles in overlapping city not affect tile ownership.
radii and for tiles that are in no city radius. At
war, tile culture matters on all tiles contested
between the war parties, and thus some tiles
may flip when war is declared and when peace
is made. A unit that was about to cross the
border can get bumped back upon declaring
war.
Minor AI changes (more below)
Forts: Don't build them on tiles that will flip when
at war.
Pathfinder: When moving to hostile territory and
war is not yet declared, try to avoid tiles that are
going to flip to the enemy upon DoW, and prefer
enemy tiles that are going to become friendly.
Rationale It's implausible that tiles near a city can't be worked by anyone. At least, this shouldn't
happen as commonly as it does in BtS. It's a mechanism that encourages culture, but
it does so mostly through punishment (loss of workable tiles). A civ with high culture
gains tiles, but it's not much of a reward because that civ can't work them; it only gets
bonus resources and a tactical advantage, which is somewhat neutralized by the diplo
penalty for stealing tiles. My change preserves the tactical advantage.
Border tensions: When not at war, stolen tiles in overlapping city radii count 50% more than in BtS.
Tiles that would flip when at war add to border tensions; the civ that would own them when at war
is mad about them.
Rationale The rules change result in fewer stolen tiles, but I don't want less border tension. The
diplo penalty for tiles that flip when at war works against civs with low culture (good),
whereas the diplo penalty for stolen tiles works against civs with high culture (not
good, as in BtS).
See also 147 also changes the border tensions formula.
206
AI found value: Don't worry much about foreign culture on tiles near a city site, so long as those
tiles are not within the radius of a foreign city. Take into account which tiles will flip when settling
near a rival city.
Rationale The AI should still avoid foreign culture a bit because tiles around the city will flip when
the owner of the foreign culture founds a city nearby or when war is declared (making
the city difficult to defend). Foreign culture will also add to border tensions (see
above), and can cause the city to revolt.
See also 031 makes other changes to found value.
UWAI: Reduced utility penalty from culture-pressure penalty (GreedForAssets aspect).
Tiles lost by war enemies are counted as "lost assets", making the AI more reluctant to make
peace when this will flip tiles to the enemy. Flipped tiles could also motivate the AI to start a war
that otherwise looks like a stalemate.
Rationale A peace treaty practically cedes the tiles around any lost cities to the conqueror. The
AI needs to be reluctant to do that and factor it into reparations.
207
for-resource trades with gold per turn.
The price in gold per turn that the AI charges for
a resource is computed based on the utility for Based only on the city count of the seller and the
the recipient and a "market value". The utility of recipient. Resources sold between large civs
the recipient is computed from the number of its tend to be overpriced.
cities, and the happiness and health in those
cities if a sufficient portion of the recipient's
territory is revealed to the AI. The market value is
based on the number of other potential buyers
and the number of their cities. The market value
tends to be quite a bit lower than the recipient's
utility.
Relaxed AI attitude threshold for trading away
The leader-specific threshold applies regardless
strategic resources when the recipient already
of whether the recipient already has the
has access to the respective resource and only
resource.
needs additional copies for a corporation.
Rationale The more flexible AI behavior creates a larger market for resources, allowing civs that
lack resources to grow their cities through reasonably priced imports. Should make it
more feasible to grow tall without growing wide.
The utility of the seller does not factor into the price for resources because the AI still
only trades away resources that it doesn't have much of a use for.
I've considered allowing resources in peace deals, but that's not workable. Too difficult
to predict whether there is going to be a trade connection, and the civ providing the
resources could just pillage its own roads to get out of the deal. Might also cause
problems outside the SDK.
AdvCiv BUG (Exotic Foreign Advisor)
In the list of resources that the AI is willing to BUG's Foreign Advisor screen (enabled by
import from the player (Resources tab of the default; not sure if it can be disabled) lists
Foreign Advisor), surplus bonuses are listed resources that other civs are willing to import or
before bonuses that the player has only one of. export on a tab "Resources". The lists are
ordered by the (meaningless) internal ids of the
resources.
Rationale It's preferable to trade away surplus resources, so these should be distinguished from
other resources that the AI is willing to import. This is not directly related to the AdvCiv
changes to AI trade behavior (in BtS, humans can export non-surplus resources as
well).
Tbd. I've tried to highlight the surplus resources in the import list somehow, but that's
difficult to do because the lists are shown through BUG's IconGrid class, which uses
addMultiListControlGFC, and that function treats every listed icon the same way.
Perhaps a graphic could be overlaid like it's done under the BUG comment "add the
circles behind the amounts" in CvExoticForeignAdvisor.py.
AdvCiv BtS
The AI makes up to about one third of its total The amount of gold traded per turn is capped at
commerce available for trade as gold per turn. the current per-turn income (commerce times
gold slider position minus expenses). This cap is
usually a one-digit number or a small two-digit
The current income also no longer factors into
number. Often, it's negative, meaning that the AI
the amount of cash that the AI is willing to trade.
is unwilling to trade away any gold per turn.
Instead assume an income equal to 20% of the
total commerce; this usually leads to more cash The amount of cash that the AI is willing to trade
208
for trade than in BtS. is partially based on the current income.
Rationale Now that the AI knows how to evaluate resources, there's no harm in making gold
available for resource trades. This allows small AI civs to take advantage of the
resource market. It also allows large civs to sell most of their surplus resources, but
the prices, especially those paid by small civs, are low, so this change helps small civs
more than large ones.
A low income shouldn't prevent the AI from trading; doesn't imply financial trouble.
See also 104w lets UWAI decide how much gold the AI should be willing to pay for peace.
104m allows the AI to demand gold per turn as tribute.
026 makes the AI willing to trade even more gold in an AI-initiated one-time offer.
550f determines how much gold the AI saves up (gold target).
210e extends the resource trade alert so that it triggers when the AI becomes willing
to import a resource in exchange for gold.
131 deals with avoiding strikes during anarchy; the increased trade budget makes the
AI more vulnerable to this.
The resource help text on the “Resources” tab of the Foreign Advisor screen shows how much gold
per turn the AI will offer or demand for the resource. When hovering over a resource icon in the
“Domestic Resources” box, all AI gold offers are shown; when hovering over a resource icon in the
“Will Import” column, only the offer of one civ is shown.
See also 073 changes the headings on the “Resources” tab.
Rationale Makes it easier to find the best buyer or supplier.
Tbd. Optimization of trades is still tedious. Might want to put some mechanism in place to
discourage changes, perhaps simply a counter akin to “We fear you're becoming too
advanced” that increases whenever a resource trade is signed.
The AI assigns a fixed trade value to gold (per The trade value depends on whether the AI is in
turn, cash). financial trouble.
Rationale The BtS approach means that the AI receives less gold in trade when in financial
trouble. This makes some sense (you're in a bad position to negotiate when you need
money badly) but isn't really intuitive. Finances factor into the amount of gold that the
AI makes available for trade; that's good enough to prevent broke civs from
overspending.
Tbd. Would be nice to apply a slight adjustment based on the recipient's attitude.
The gold per turn and cash that the AI is willing to The amount of gold that the AI is willing to trade
trade to another civ is adjusted based on the is not affected by attitude.
attitude toward that other civ except when the
two civs are at war or when the AI civ is a
capitulated vassal.
Rationale When e.g. an AI civ promises that it'll "never trade" with its worst enemy, that civ
shouldn't be perfectly willing to pay gold to that enemy (but shouldn't refuse to pay any
gold either).
This change should also make attitude matter more when tech trading is disabled.
Exception for capitulated vassals: Don't want the master or the master's friends to
plunder the vassal.
AI memory about cash traded to other civs The AI keeps track of how much gold it has
decays. traded to every other civ. That amount is
subtracted from the cash that the AI is willing to
trade to another civ. This subtrahend tends to
become negligible over time because the AI
209
generally becomes willing to trade larger and
larger sums of gold as the game progresses.
Rationale The amount of gold that a civ is willing to trade (prior to subtracting gold-traded
memory) can stagnate, and then the BtS AI can stay unwilling to trade any gold
indefinitely. Also, pretty much all other AI memory decays in AdvCiv (cf. 130r).
When asked to "make this deal work," the AI may Never adds non-surplus resources to the table.
add resources to the trade table that the human
civ has only one copy of if the human civ doesn't
have enough gold per turn available for trade.
If the human player is offering resources to the Tries to give surplus resources, then gold per
AI, then the AI offers to buy them with gold per turn.
turn if the current human income is negative, and
otherwise tries offering surplus resources in
return and uses gold per turn to balance the deal.
May offer non-surplus resources as a final option.
Rationale Had to adjust the counter-propose algorithm to the more flexible AI trade denial
behavior (which involved refactoring the entire function).
The human income condition leaves it up to players whether they want the AI to pay in
gold or in resources: Just change the gold slider for a moment. Resources are often
preferable because the AI doesn't pay much gold, but gold can also be preferable,
especially when the player doesn't need the resources of the AI. Players shouldn't
have to optimize the deal through trial and error then.
The AI refuses to give away more than 2 non- Capitulated vassals give any number of non-
surplus resources of the same kind (happiness or surplus resources to their masters. Other civs
health) at once, and refuses to accept more than never give away non-surplus resources.
2 resources of a kind at once.
No limit on resources accepted at once.
The precomputed resource values are updated
Resource values are precomputed (since the BtS
after starting or canceling a trade.
expansion) for efficiency and only updated once
per turn.
Rationale Now that the AI evaluates happiness and health from resources situationally, it must
be careful not to buy too many resources at once because the evaluation is done for
each resource independently. I.e. the AI knows what e.g. one more happiness is
worth, and simply triples that value when three happiness resources are offered (but
perhaps needs only one). Similarly, the AI can tell whether it can spare e.g. one non-
surplus happiness resource, but it can't tell if it can spare more than that.
Tbd. Should call AI_updateBonusValue each time that the AI connects a resource to its
city network (easier said than done). Currently, an AI civ updates its resource values
at the start of its turn, so resources connected during the AI civ's turn aren't taken into
account until the next turn of that AI civ.
Once per round, all AI-AI deals are checked for cases in which two civs A and B sell resources to
each other. If one deal is found in which A sells exactly one resource to B, and another in which B
sells exactly one resource to A, and both deals can be canceled, then they're canceled and
immediately replaced by a resource-for-resource deal in which one side may additionally have to
pay some gold.
Rational Now that AI civs are able to import resources from other AI civs for gold per turn,
resource-for-resource deals have become rather rare because often only one side
has a suitable resource available. Sales are harder to read on the Foreign Advisor
screen than barters and take up more space. Therefore try to collapse sales into
barters.
210
When trading one resource for another with a Not an issue because all health and happiness
human, the AI never asks for 1 gold per turn in resources have the same trade value.
addition.
Rationale Adding the 1 gold to the trade table is tedious, and it makes the AI look petty.
AdvCiv BtS/K-Mod
Changed AI tech evaluation to increase the value The utility counted for bonus yields is
of bonus improvements with high tile yields (such proportional to the yield. (BtS code)
as Cow Pasture or Corn Farm) and to decrease
Military units requiring unrevealed bonuses are
the value of military units whose bonuses haven't
valued at 80% (compared with units whose
yet been revealed (such as Axeman and
bonus requirements are fulfilled). (K-Mod code)
Swordsman; multiplier now 60%).
Rationale Since health in the early game is now (correctly) counted as unimportant, the AI tech
values of Agriculture and Animal Husbandry need to be adjusted. Prior to this
adjustment, the AI often went for Iron Working(!) before Animal Husbandry, even if it
had a Cow next to its capital. (Actually, I suspect that this happens in K-Mod too,
despite the overestimation of health, but I haven't checked. In unmodded BtS, it's
fine.)
K-Mod comment on the Axe and Sword evaluation (AI_techUnitValue):
"We're quite optimistic... mostly because otherwise we'd risk undervaluing axemen in
the early game! (Kludge, sorry.)"
Undervaluing Axeman isn't a problem currently.
Tbd. Animal Husbandry is still be a bit underappreciated. The strategic value counted for
Horse might be too low. The fact that Wheel enables Chariot complicates matters.
That said, the evaluation of the resource yields also needs more work. Needs to
check whether a new terrain improvement will immediately increase city yields in the
very early game.
See also k146 increases the tech value counted for chopping Forests and Jungles; I've also
reduced that effect a bit.
AdvCiv BtS
The AI values surplus resources based on the Unless consumed by a corporation, a surplus
potential for trading them away, and (as in BtS) resource is valued at 20% of the first copy. This
based on corporation yields. value is sometimes so low that the AI doesn't
connect surplus resources. (Perhaps also due to
K-Mod changes to the Worker AI and the
evaluation of the first copy; not sure if this is a
problem in unmodded BtS.)
Rationale The value of the first copy shouldn't affect the value of surplus copies; one resource
for trade is as good as another. Tradeable strategic resources might be a bit more
valuable than luxury and food resources, but not much; difficult to find buyers for
strategics. And the AI needs to connect all its (surplus) resources; it's the correct play
most of the time, and can't really hurt.
See also Prior to v0.92, this change was tagged with advc.121. Change 121 deals with AI
Worker builds.
Set all XML modifiers for the AI trade value of Some strategic resources have an
individual resource types to 0. “AITradeModifier” of 10 to 30% set in XML that
increases the trade value assigned by the AI to
those resources.
Rationale The BtS/K-Mod code for evaluating strategic resources should have this covered. (If
211
not, it should be amended.)
Config Civ4BonusInfosl.xml
AdvCiv Warlords
The demand-vassal-tribute shortcut demands all Players can demand resources from their vassals
resources that the vassal is willing to trade to the by holding down the Alt key while clicking on the
master, including those that the master only vassal's name on the scoreboard. This triggers a
needs for a corporation. confirmation popup listing all resources that the
vassal has an excess amount of and that the
master doesn't have yet. (In Warlords, this was
equivalent to all resources that the vassal was
willing to trade to the master because there were
jno corporations.) If confirmed, the resources are
demanded as if through “it's time for your tribute.”
Tbd. Perhaps replace this with a “join us in preparing war” popup. I've actually only
discovered this shortcut because I was wondering if karadoc had implemented a
shortcut for vassal war preparations.
212
they badly need themselves.
Rationale Don't want the master to starve the vassal's cities by buying the vassal's crucial
resources.
Capitulated vassals aren't a concern because players have no reason to sabotage
those (they're not going to break away without outside help). Probably no trade
discount in BtS because the master can get resources for free through "time for your
tribute"; fair enough.
Tbd. Perhaps put some limit on "time for your tribute".
213
networked multiplayer.
The name of the historian is chosen at random The historian is chosen at random from among
from the two names that I've assigned to each 11 names regardless of the type of ranking.
ranking. E.g. Machiavelli and Tacitus for the
"most powerful" civs.
Rationale Just for historical immersion.
Config I've hardcoded the assignment of historians to rankings in CvTopCivs.py.
214
040 AI improvements for settling other continents
See also 300: Barbarian placement on continents without civilizations.
905a gives ships better stats (cost, speed, cargo capacity).
031 reduces the impact of distance on AI found value.
113 comprises some improvements to Woker ferrying
Tbd. Would like a Columbian Exchange mechanism that reveals resources in the Old
World once a copy is obtained from the New World.
AdvCiv K-Mod
When an AI civ has no city on a continent, it Unrevealed tiles don't add anything to found
counts unrevealed tiles in the city radius as values. This makes the AI very reluctant to settle
average tiles when computing found values a continent that it has only explored from the sea.
(with a number of exceptions and restrictions).
The Settler may change its mind once it gets to
the spot and reveals its surroundings.
Rationale Could instead try to improve AI exploration. Not so easy; how can the AI tell that a
continent is large enough for land exploration (without circumnavigating it first)?
Should Caravels be routinely accompanied by a Scout/ Explorer?
AdvCiv BBAI
The AI moves Settlers trained in inland cities to Inland AI Settlers wait indefinitely for a ship.
coastal cities when there are no city sites on the
BBAI comment: "TODO: Go to a good city (like
continent.
one with a transport) ..."
Fixed a problem with Workers taking up all the
Update – It seems that ships not having room
space in a ship that is supposed to transport a
was the main problem, and that my new
Settler.
CvUnitAI::AI_moveSettlerToCoast function is
now largely superseded by AI_load. Though I'm
still seeing the AI use AI_moveSettlerToCoast
occasionally.
AdvCiv BtS
When a workable tile or an owned tile with a The never sends a Worker to such a landmass,
resource is on a landmass where an AI civ and tiles there remain unimproved forever.
doesn't have cities, that civ will (eventually, when
When evaluating city sites, regular yields of land
Workers don't have much else to do) transport a
tiles in the city radius that are located on a
Worker to the landmass.
landmass where the AI doesn't have cities are
AI found value computation: As in BtS, but the fully counted, but no trade value and no special
trade value of offshore resources (i.e. on a yields are counted for resources on such tiles.
landmass without cities) is partially counted. (See CvPlayerAI::AI_foundValue for the meaning
of regular yields vs. special yields; complicated.)
See also 124 allows workable resources to be connected without the need for a city or Fort on
the same landmass as the resource. This makes offshore resources a little more
attractive as the owner doesn't have to choose between connecting the resource
(through a Fort) and the full resource yields (through a non-Fort improvement).
Change 040 shares some code with 121.
Tbd. CvCityAI::AI_countNumBonuses should perhaps count resources on other
landmasses in some contexts now that the AI can hook them up.
215
041 Can train ships in any coastal cities
AdvCiv BtS
Cities adjacent to any non-lake water area can Can train ships and construct Dry Dock only in
train ships (except Work Boat – treated as in cities adjacent to a water area of at least 20 tiles.
BtS) and construct a Dry Dock. The AI ignores A Work Boat can also be trained when there is at
this change, i.e. builds ships/ Dry Dock only in least one water resource in an adjacent water
cities at a size-20 waterbody. area.
Other coastal buildings require only 10 water tiles,
which is also the threshold for a salt water lake.
Rationale Since BtS, it can make sense to train naval units in small water areas because Forts
can act as canals into larger water areas. For inland seas and ice-locked water areas,
such a Fort is pretty commonly possibe. Implausible that this should not be allowed.
Since the AI doesn't have a notion of canals, it needs to stick to the old rules though.
This change also eliminates the confusion about two different area size thresholds (10
for buildings, 20 for units). Cities are now either proper coastal cities, or only (fresh
water) lake-side cities.
Don't want to allow shipbuilding at lakes because it's confusing to see shipbuilding
options on the city screen of some inland city with a 1-tile lake. Dawn of Mankind
players have also argued that small lakes aren't deep enough for constructing and
launching oceangoing ships.
Work Boat remains unavailable when there are no resources because, even if there is
a canal, players might as well produce their Work Boats in other cities; they're cheap.
Don't want players to be confused by Work Boat as the only naval production option in
the early game when canals and warships may not be on their minds.
Tbd. By allowing Lighthouse in lake-side cities, I could remove the awkward incentive for
founding in tiles that are both coastal and lake-side.
But I'd rather treat Lake tiles as being a terrain different from Coast and Ocean, and
thus unaffected by Lighthouse (and Colossus, Moai); then give Lake +1 food, -1
commerce from the start (i.e. like Oasis but 1 less commerce).
See also 030 treats ice-locked water as a separate water area and prevents coastal buildings in
such cities.
216
of at least 100 000 is needed; the next best thresholds are 14 000, 13 000, ... Dan Quayle is
victory is at 75 000, then 50 000, 40 000 ... 1000 below 3000.
is needed to avoid the worst title (Dan Quayle).
Rationale Almost all my victories have been "Julius Caesar", so this is apparently too easy to
reach for an experienced player. More of a logarithmic scale now, covering a wider
interval of scores. It's possible that the original scale worked OK in Vanilla Civ 4;
hasn't been changed in either of the expansions.
Tbd. The score formula needs work too; increase the weight of victory date and difficulty.
The main incentive should be to win as early as possible on the highest possible
difficulty. Though the bigger issue is that yields increase too much in the Industrial era,
so a lot of points can scored by drawing the game out.
Should also move the formula into the DLL so that R&F can access it (see comment
in RFTotalScore::updateString).
See also 707: The Rise & Fall scores are normalized to match this new scale.
217
044 Changes to the timing of autosaves
See also 106l: No message when autosaving.
700: The R&F game option changes the timing a bit.
I've added some initialization steps after loading a savegame to a new function named
CvGame::onAllGameDataRead.
AdvCiv BtS
No autosave right after loading a savegame. When the initial autosave is loaded, the game
There's still an autosave after regenerating the immediately autosaves again, overwriting the
map, which replaces the initial auto-save and savegame just loaded and deleting all other auto-
deletes all other autosaves. saves.
Rationale It's unnecessary to save right after loading, and the deletion of other auto-saves is
somewhat unexpected; should only happen when a new game is started (via the
opening menu).
Per-turn autosaves are created at the start of the At the start of the game turn, i.e. right before the
active player's turn. Specifically, the savegame is start of the turn of player 0.
created before diplo popups and votes and after
displaying on-screen messages and non-diplo
popups. Therefore, after reloading, diplo popups
and votes will be shown again (as in BtS), but
messages and e.g. the new-era splash screen
won't reappear.
Exception: When playing multiplayer with
simultaneous turns, autosaves happen at the
start of a game turn as in BtS.
Rationale Not sure if the exact timing is ideal with regard to messages and popups.
Saving at the start of the active player's turn is much better in scenarios, when the
human player isn't necessarily in slot 0.
With simultaneous turns, the order of the player turns is randomized and not stored in
savegames, so saving at the start of a player turn could lead to other players missing
(parts of?) their turns.
See also 127 makes AI Auto Play end at the start of the human turn instead of the start of the
game turn. It's important for testing (reproducibility of errors) that the autosave
happens at about the same time as AI Auto Play ends; otherwise, AI Auto Play for
several consecutive turns will have a different result than AI Auto Play for one turn at a
time. (E.g. if Auto Play ends before the start of the human turn, then the AI will never
assign any promotions in AI_doTurnUnitsPost when running one turn at a time.)
218
Rationale Too much information. If a player has all cities of a rival revealed, he/she could check
every turn whether a building was completed, and infer that units or wonders are
being produced when no (ordinary) building gets completed for some time. With
detailed knowledge about the AI code, it might also be possible to deduce the AI
strategies and war plans. No one does this, but the game still shouldn't reward it.
The change could improve performance, but probably just reduces the main memory
usage, which isn't an issue in AdvCiv.
And it makes the important buildings (wonders, Walls, Castles) easier to spot.
Would be more realistic to show the buildings whenever a city is visible (i.e. not
fogged), but hiding them seems better for gameplay; I think showing them only when
a unit is inside is a good compromise.
I'm not updating city layouts when entering or exiting WorldBuilder or Debug mode
because doing so seems to (hard to say …) prolong the already quite noticeable
delay (at least with debug builds).
Config XML switch TREAT_REVEALED_BUILDINGS_AS_VISIBLE in GlobalDefines_advc.xml.
Credits From Rise of Mankind, though they don't check if the city could be investigated or if
there's a unit, and don't show Lighthouse and Levee. Link to source code (1 MB file):
Sourceforge.net
Tbd. K-Mod comment in CvUnitAI::AI_nukeValue: “It is possible to see which buildings
the city has by looking at the map. This is not secret information.” No longer true, so
AI_nukeValue should instead estimate the value of the city's buildings.
Fog of war should apply to the shown buildings, i.e. only those buildings should be
shown that were present when the city was last visible. Doesn't seem that hard to
implement. Since only a handful of buildings are ever shown in the fog of war now, the
additional memory usage should be negligible.
On a related note, fog of war for terrain features would also be desirable. Can
currently spot rival cities in the fog of war by paying attention to disappearing forests.
A Civ4lert about completed buildings. Now that the player doesn't learn about most
buildings, this wouldn't necessarily generate too many messages. See also Tbd.
under 210.
See also 120d removes the Sabotage Building cost from the Espionage screen; could
otherwise use that cost to learn about the cheapest building in a city.
219
the enemy cities – iterating through all areas is often costlier because of islands and
sea ice.
Credits CFC user vedg reported units not getting picked up in K-Mod 1.46 and provided
savegames.
See also 040 and 082 also deal with the transportation AI.
When deciding where to place a bumped land When a unit needs to be removed from the
unit, landmasses where the unit owner has a city territory of a rival because of an ended war or
are preferred. canceled Open Borders agreement, that unit gets
"bumped" to the nearest tile it can legally occupy.
Tiles on the unit's current landmass are preferred
(tiles on a different landmass are effectively
considered to be 1.5 times more distant than
their air-line distance).
Rationale Might make stranded units a bit less common, especially on tiny islands. I don't want
to enforce teleportation to a friendly city because this could be exploited for moving
units quickly between theaters of war. At least for now, distance should remain the
primary criterion.
See also 034 (disabled) was an attempt to avoid bumping altogether.
163 spends the movement points of bumped units.
Added a clause to discourage teleportation of ships into lakes.
Rationale If the lake isn't connected to a sea, the ships could be irretrievably lost. I've never had
this problem, but this bug report for the “We the People” mod suggests to me that it
could happen.
220
048 Changes to combat odds text
AdvCiv K-Mod
When more than one unit is selected by the When more than one unit is selected, the next
attacker, the combat odds help text shows which attacking unit is chosen for the human player by
of the selected units is about to attack. the AI. Which unit is chosen can only be inferred
from the strength value and odds breakdown. In
Combat modifiers that get applied to the
BtS, the same goes for the defending unit. K-Mod
attacking unit (i.e. generic combat modifiers) are
indicates the defending unit through the 3D model
shown under the name of that unit along with the
shown on the map, but, on the attacker's tile, 3D
attcker's first strikes. Then info about the
models of multiple units are shown when multiple
defending unit is shown, then the combat
units are selected.
modifiers that get applied to the defender (i.e. all
non-generic combat modifiers) and the When ACO is disabled, combat modifiers that are
defender's first strikes. tied to an ability of the defender are shown first
and always in red; then modifiers for river
(The shown unit info is a one-line short
crossing and attack from cargo (which are tied to
description with promotion icons.)
the attacker insofar that the attacker could
The sign of the combat modifier indicates eliminate those modifiers through the Amphibious
whether it gets subtracted or added and the promotion) are shown in red; then the remaining
color (red or green) whether it benefits the modifiers tied to the attacker are shown in green.
attacker. This applies regardless of the ACO The signs are as stated in the unit abilities. ACO
option. instead shows the sign that gets applied in the
firepower calculation, i.e. it flips the sign for non-
generic modifiers of the attacker because they
actually get applied to the defender.
If ACO is enabled, both the attacking and By default, ACO shows the defending unit as a
defending unit are shown by default. ACO is still one-line short description with promotions. The
disabled by default (as in K-Mod). attacking unit is not shown by default.
No separate info about hitpoints. If either of the two combatants is damaged, the
current hitpoints are shown after the combat
odds.
Various changes to the arrangement of the ACO The settings "always", "never", "normal" and
menu, the menu text, default settings and in- "alternate" are a bit difficult to understand in the
game text are also tagged with id 048. original menu.
Tbd. When a stack attacks, the map should show only the 3D model of the unit that is
about to attack. It's easy enough to set the "center unit" of the attackers' tile
accordingly in CvGameTextMgr::setCombatPlotHelp, but the game ignores the
center unit and shows a mix of 3D models instead. Not sure if and how this can be
changed. Temporarily setting UNIT_MULTISELECT_MAX to 1 (CvGlobals::
setDefineINT) might do the trick. In any case, the one-line descriptions are still going
to be helpful: can't tell from the 3D model which promotions a unit has.
Moreover, the 3D model on the info pane should show the unit that is about to attack.
Currently CvMainInterface.py shows the HeadSelectedUnit.
Rationale The UI needs to make clear which units are about to fight. ACO already had an option
for this, but I don't want to use ACO because I find it too bulky.
Hitpoints: The one-line descriptions already include the current strength and the total
strength, which is how the UI usually represents hitpoints.
Color-coding and signs: Both BtS and ACO assume that each combat modifier can
only have one sign. K-Mod's Disorganized promotion breaks this assumption and
mod-mods based on AdvCiv may want to break it in additional places. I'm not sure if
221
the BtS approach of showing the sign as stated in the ability (thereby hiding the
somewhat countintuitive combat rule about non-generic modifiers always applying to
the defender) could be salvaged. I think it's better to tell it as it is and maintaining two
modes of displaying the modifiers is extra work.
See also I've implemented most of these changes also in a mod-mod of Rise of Mankind – A
New Dawn 2: Git commit
Tbd. This Git commit could be ported to AdvCiv. Might be nice for mod-mods that use
negative modifiers a lot; not sure. Complicates the program logic a bit (and slows it
down, but that probably doesn't matter at all).
AdvCiv BtS
An addendum to the group attack display When an attack is ordered with multiple units
changes above: Can hold down the Alt key to selected, the game always makes a “smart”
view the unit with the highest survival odds or, if choice that also takes into account a) how
held while ordering the attack, to force that unit to valuable the potential attackers are and b)
attack. If the Alt key is not held, the game is free whether they inflict collateral damage. a) was
to make a smarter attack. Either way, the odds added by the BtS expansion and it seems that
display shows which unit is about to attack. they forgot to update the odds display, which is
only based on b), meaning that the displayed
odds often don't match what happens when an
attack is ordered.
Config If the smart choice does not have the highest survival odds, a hint about pressing Alt
is shown. This can be disabled through GlobalDefines_advc.xml. If ACO is enabled
(“Odds” tab of the BUG menu), then disabling the “Instructions” option will also disable
the hint about the Alt key.
Rationale At first I just wanted to fix the inconsistency in BtS by showing only the smart choice,
but then I figured that there also needs to be a way to just see the best odds.
Tbd. If I can manage to show the proper 3D models (see Tbd. above), there will also be the
issue of updating the shown model whenever the Alt key is pressed and released. Not
sure if that's doable.
Perhaps the smart choice should prioritize high survival odds a bit more; currently it's
the exact same procedure as for AI group attacks. See iOddsThresh in
CvSelectionGroupAI::AI_getBestGroupAttacker.
See also The Alt key functionality depends on 011b (Ctrl key for pre-building).
048b Replaced a few uses of the word "retreat" with "withdraw" in help text.
Rationale Game terms should be used consistently. Plus I may want to use the term "retreat" in
the context of a combat round limit in the future.
222
for such a unit. It's cleaner to use AdvCiv's TeamPathFinder, but this doesn't cover all
special movement rules that may apply to individual units, so the C2C functionality
could be useful for the AdvCiv AI. This “We the People” commit should make it easy to
adopt the C2C code.
“We the People” has parallelized a part of the A* calculation that corresponds to the
processChild function in AdvCiv (Git commit). Adopting the WtP framework for
parallelization would be a lot of work. It's also not obvious to me that parallelizing
processChild is really correct and efficient; might be too small a task.
Refactoring changes, performance optimization:
Moved pathfinding code that cares about (specific) selection groups and units into a separate class
GroupPathFinder, derived from the KmodPathFinder class.
Derived a class TeamPathFinder from KmodPathFinder for computing paths for “typical”
(hypothetical) units of a team. BBAI had implemented largely the same functionality on top of the
FAStar pathfinder in the EXE (e.g. in CvPlot::calculatePathDistanceToPlot). TeamPathFinder
replaces that (much slower) BBAI code entirely. CvMap::calculatePathDistance remains in use.
That BtS function treats only land/ water and impassable tiles as obstacles, whereas
TeamPathFinder also takes into account foreign borders and can distinguish between shallow
water (Coast) and deep water (Ocean) movement. TeamPathFinder can replace calculate
PathDistance, but the latter is more convenient to use, so I'm keeping it in places where
performance isn't a concern.
Simplified the logic of karadoc's A* implementation a bit. The original implementation (for unit
groups) is still in the codebase for testing purposes. Also changed the public interface a bit (mostly
in pedantic ways, e.g. capitalization).
Some tweaks to memory allocation in KmodPathFinder and CvSelectionGroup (function
getClearPathFinder).
Use a more compact data structure for the nodes in KmodPathFinder. K-Mod had used the same
data structure as the FAStar pathfinder.
Created an enum type for the group movement flags in CvDefines.h.
Moved the BtS pathfinding functions that don't deal with unit movement from CvGameCoreUtils
into a new header FAStarFunc.h.
Cached the presence of isthmuses on the map. The check for isthmuses blocking sea movement
is the only check that the pathfinders have to make on a per-edge basis (as opposed to per node).
I've included a guess at that memory layout of the FAStar class in CvDLLFAStarIFaceBase.h. In
the future, this could perhaps be used to replace the results of the FAStar instance that the EXE
uses for displaying waypoints with paths computed by GroupPathFinder. Currently, to keep the
waypoints consistent with the actual paths taken, GroupPathFinder has to compute the exact same
paths as FAStar for human units. This isn't really a problem because we simply want a minimal-
cost path, and that's what FAStar computes. Paths of equal cost can be a problem, but aren't
currently. Related CFC discussion
AdvCiv BtS/ K-Mod
Made sure(?) that, when selecting between paths For human player, straight moves are preferred
of equal movement costs for a human player, a over diagonal moves for aethetic reasons. Taken
path that enters a smaller number of tiles is together with a K-Mod tie-breaker that is
preferred over a path that enters an extra tile and supposed to prevent two paths from having the
has a smaller ratio of diagonal moves. exact same cost, the preference for entering
fewer tiles can be outweighed. This results in
paths with counterintuitive detours.
Credits carp provided a savegame (CFC post).
223
See also Earlier version of the K-Mod symmetry-breaking code: Git commit
Tbd. I've had to scale some of the decision weights up. Hopefully this has no unforeseen
consequences.
As another tiebreaker for paths of equal Routes (greatly) affect movement costs, but only
movement cost, paths that end on a route are when the move starts and ends on a route.
slightly preferred.
Rationale Regardless of whether the current path can take advantage of a route, landing on a
route has a potential of speeding up future moves. Moreover, a preference for routes
should make a rare pathfinder bug involving danger avoidance even more rare (might
even fix it, indirectly).
See also Detailed Git commit message; comments above
GroupStepMetric::canStepThrough and in KmodPathFinder::processChild
(regarding “dead end” nodes)
AdvCiv BtS
The AI doesn't build roads in human territory. If the shortest path between two AI cities passes
(But may upgrade human roads to railroads.) through human territory and the human and AI
player have an Open Borders agreement, the AI
may build roads through the human territory.
Rationale If the human pillages those roads, the AI keeps rebuilding them, which can
permanently occupy several AI Workers. Also, ultimately, humans should be in control
over the roads in their territory.
Tbd. Implemented through a new pathfinder flag. I'm not sure that I'm using that flag in all
the right places; should take another look some time to make sure I'm not preventing
pathfinder instances from being reused, which could hurt performance.
224
locations (if not all) to make sense. If I do it, I'd let the Java program that I use for
generating scenario file also generate the game text file.
See also ALT key shows combat odds instead of plot help when hovering over a unit. 089
disables this when the unit is owned by the player – one can't attack one's own units.
225
1.5%, and when deciding which site to settle next choices, e.g. research, scouting, city production
(Settler Unit AI), the respective found values are and Worker builds, can affect AI found behavior,
randomly increased or decreased by up to 4%. but the placement of the first couple of cities is
(These random adjustments do not change from often perfectly predictable.
turn to turn, but stay the same for each tile for the
entire game.) Only applies to scenarios.
Rationale Should improve replayability of scenarios. Not much randomness in the site selection
because this could move a city from a locally optimal position into one that is
obviously inferior, which makes the AI look bad.
The AI considers training a Settler in a size-2 The AI normally lets its capital grow to size 3
capital when that capital is slow to grow. But not before training a Settler. Exception: When the
until the capital has a sufficient number of capital isn't growing at all or has no decent
defenders (typically 2). So long as an AI civ unworked tiles left.
hasn't met any human civs, it may leave a single Typically, the AI has enough defenders when it
defender in its capital and use the other to reaches size 3. I'm not sure if it also usually has
accompany the Settler that founds the second an extra combat unit ready to accompany a
city. Settler.
Rationale Capitals with low food but high production shouldn't wait for size 3. (On random maps,
such capitals don't really occur.)
This change is also relevant for non-scenario maps, but especially for the EuroWorld
scenario which has unusually dry terrain around some capitals.
226
visible on the Custom Scenario screen regardless of the XML setting.
Tbd. Would be nicer to add a field to Civ4GameOptionInfos.xml that determines whether
an option shows up on Custom Scenario.
"Lock Modified Assets" is never shown on the Shown both in singleplayer and multiplayer but
(multiplayer) Staging Room screen. has no effect in multiplayer. (CvGame::init
disables the option, ignoring the setting on the
Staging Room screen.)
Rationale Not sure why the original developers disabled this (it's already that way in the Vanilla
Civ 4 code). Perhaps modified assets will result in OOS errors anyway.
Tbd. Should temporarily disable the code in CvGame::init and give this a try. If the option
actually works, it could be nice to have for some players.
“New Random Seed” on reload is never shown The option is ignored in multiplayer. No new seed
on the Staging Room screen. is generated (confirmed here by Afforess). That
said, with simultaneous turns, CvGame::
updateMoves constantly uses numbers from the
synchronized RNG for randomizing the turn
order, and this makes random outcomes non-
reproducible.
Tbd. If the EXE reports the Staging Room setting to the DLL (I haven't checked), it will be
easy enough to the isNetworkMultiPlayer check from CvGame::read. Could then
re-enable the option (though it'll still be meaningless with simultaneous turns).
Can something be done to make randomness reproducible with simultaneous turns?
Can't really debug with this option currently. Mongoose Mod might fix it, but is closed-
source (change log, 20 Dec 2010: “devised a simple, effective way to lock random
seeds in Network Multiplayer games when the NewRandomSeedOnReload option is
not enabled”).
227
order to allow GW to remove vegetation from Grassland as well. That should probably
be done when giving Forest Preserve the ability to protect vegetation (see below).
See also CFC post where I weigh the change described above against the alternative change
described below.
(Disabled again in favor of the change described GW doesn't directly destroy Forests, but it can
above.) turn them into Jungles and can destroy Jungles.
If that happens to a Preserved Jungle, then the
Preserved Forests and Jungles can't be removed
improvement is destroyed (as it requires
by GW. The terrain type can change, but not to
vegetation).
Desert. If a Plains Forest Preserve is randomly
selected for a GW event (which normally
removes the Forest and, failing that, turns the
terrain to Desert), then no GW event takes place
instead – i.e. the target tile isn't re-rolled.
Credits Proposed by Cruiser76 (post)
Rationale Since the goal is to buff Forest Preserves (or at least not to hurt them with the Forest
removal change), I didn't want to block terrain changes – those will often change
Tundra to Grassland. Protecting the Forest Preserve improvement itself (which
requires a feature) might be more elegant, but it's difficult to ensure that a GW event
won't destroy an improvement (in general; not for the Forest Preserve in particular).
Config New optional XML tag for improvements: GWFeatureProtection
If a (positive) value less than 100 is used, then the feature is protected only
probabilistically.
Reduced the per-turn probability of GW events to 3/5 of its value in K-Mod.
Upd.: Reduced it again in AdvCiv 1.03, this time to 1/2 of the K-Mod value. And, in AdvCiv 1.04,
introduced a multiplier based on the initial team count to decrease the value (further) on maps with
fewer than 8 initial teams and to increase it on maps with more than 8 initial teams.
Config Through GlobalDefinesAlt.xml (but the team count adjustment is hardcoded in the
DLL).
Rationale Player feedback suggests that GW was starting unexpectedly early. The warning
about the sustainability threshold still comes as early as before, but isn't as much of a
concern as the GW events, which alert the player turn after turn. crullerdonut's play
reports also say that GW anger wasn't much of an issue. So, as a stopgap measure,
let's deal with the event probability.
I suspect that the issue is mainly that tech costs are higher in AdvCiv than in K-Mod –
at least on the higher difficulty levels – leading to longer games and (far) more GW
events overall.
Upd. (v1.03): Game length still appears to the main factor. Sometimes, games will
descend into near-permanent warfare when Riflemen become available; those games
can approach the time limit. Don't want such games to desertify much of the land area
most of the time.
Upd. (v1.04): All-AI games on Huge maps with about 18 civs seem to be considerably
less likely to be severely affected by GW than games on smaller maps with 8 and
fewer civs. I'm guessing that this is because games with a higher number of factions
tend to produce more heterogeneous tech progress. When some civs don't manage to
fully industrialize before the game ends (and don't get conquered by more advanced
civs either), then there is a lot less GW.
See also Posts linked in WIP section.
K-Mod Git commit that tweaks the same variable that I have tweaked. The commit
228
message suggests that karadoc had also concluded that the probability needs to be
adjusted to the typical game length.
251, 910: Tech cost adjustments.
Tweaked a parameter to increase the GW “severity” rating shown on the Environment tab. The
rating is a visual clue about the overall impact of GW, but also affects anger from GW.
Rationale Not sure if the anger needs to be higher. I mainly felt that – despite the decreased
event chance in AdvCiv (which does not enter into the severity rating) – the rating
tended to understate the severity as I perceived it. E.g. one event per turn hitting a
land tile owned by the human player is already pretty severe in my book.
AdvCiv K-Mod
GW turns Tundra into Plains. Plains near cold Into Grassland, referred to as “temperate” terrain
terrain (coldness score based on adjacent in the code, whereas Plains is referred to as “dry”
Tundra, sea/land Ice) can't be turned into Desert. terrain.
(But the cold Terrain could eventually turn into
Plains, so everything can still get desertified
eventually.)
Rationale Grassland is too big an upgrade. I don't agree that Grassland should be interpreted as
(always) being wetter than Plains (which is apparently the idea in BtS too – so I don't
blame K-Mod). It's more helpful to interpret the terrain types in terms of their yields –
because the yields matter for gameplay.
Don't want Tundra to turn into Desert in two steps though; hence the special treatment
for Plains near cold terrain.
A somewhat undesirable side-effect of this change is that Tundra Forest can lose its
Forest after two GW events instead of 3. Well, I don't think double events are all that
relevant for the overall deforestation rate (not until GW becomes really bad) and it's
not unrealistic for taiga (Tundra Forest) to be vulnerable to forest fires as global
temperatures increase.
AdvCiv BtS
Announcements of GW events that happen near The announcement only says that “Global
a city of the active player's team say how the tile Warming strikes near” the city; clicking on the
has changed (terrain, feature, improvement). announcement fouces the camera on the tile.
Rationale Players can figure out how the tile has changed, but if the message already says that
e.g. Grassland has changed to Plains (a common event), then players don't even
need to look at the tile – probably doesn't require any attention.
A GW event near a rival city is announced as Only events near cities of the active player are
described above if only one rival city is affected announced. (With K-Mod, the expected total
by GW on the current turn; otherwise, a single number of events per turn is shown on the
announcement lists all affected rival cities Environment tab of the Economic Advisor; so a
(without saying which specific tiles were affected player can guess how many unannounced
and how). events are happening.)
Melted water Ice on unowned tiles that aren't
within or adjacent to a city cross are announced
in a single message that only says how many
tiles were affected on the current turn.
Rationale Not terribly relevant, but players don't like missing out on changes to the known game
state, and the announcements give the player a better impression of how much GW is
affecting the world and that rivals are equally (proportional to their land area) affected.
See also Screenshot attached to this CFC post (1st attachment).
229
056 WBSave format
AdvCiv BtS
Can read scenarios so long as the player ids in If MAX_CIV_PLAYERS is changed in the DLL, then
the WorldBuilder save are less than the maximal WorldBuilder saves created with a different
number of civs (MAX_CIV_PLAYERS) allowed by MAX_CIV_PLAYERS value become unreadable. In
the current GameCore DLL. particular, mods that allow 48 civs can't load any
of the official scenarios. (The scenario files can
be converted fairly easily though by inserting 30
team and player sections for 30 dummy civs into
the scenario file.)
Config The WB reader/ writer is implemented in Python\pyWB\CvWBDesc.py.
The maximal number of civs can only be changed in the DLL (CvEnums.h).
230
space), but showing a tech requirement without mentioning the ownership rule might
be a bit misleading.
See also 089 also explains in help text why a unit can't enter a tile (defenders maximally
damaged).
The AI uses a fingerprint (CvPlayerAI:: A mere count is used
AI_unitImpassables) to check whether units (AI_unitImpassableCount).
have the same impassable terrains and features.
The most significant bits of that fingerprint also
contain a count of the impassable terrains and
features so that ordering units by their
impassable fingerprints orders them (primarily)
by their impassable counts. 0 still means that
there are no impassable terrains and features.
Rationale Obviously not ideal to treat e.g. a unit that can't enter Desert and one that can't enter
land Ice as compatible wrt. their movement restrictions. And it was easy enough to
change and without paying a performance penalty.
See also The isAny...Impassable functions added by 003t are helpful here.
The AI ensures for each unit group that no unit in Unit groups (CvSelectionGroup) represent AI
the group a higher impassable count than the unit stacks. The behavior of an AI stack is
unit leading the group. This is accomplished by determined by the AI type (UnitAITypes) of the
disallowing units to join a group if the newcomer unit that leads the group. Group leadership is
would become the group leader and has fewer mainly determined by AI type (cf.
impassables than the current group leader, or if CvUnitAI::AI_groupFirstVal, AI_groupSecondVal);
the newcomer wouldn't replace the current group units with a specific role, e.g. city attackers or
leader despite having more impassables. (I did settlers, are preferred over units with more
not change the algorithm for selecting group general or supporting roles (e.g. reserve, escort).
leaders.) Civs under human control also have groups;
When a human civ comes under AI control (e.g. those groups represent current and past units
AI Auto Play), groups that don't satisfy the selections. (The current selection is also stored
invariant stated above are split up. by the EXE →
CvDLLInterfaceIFaceBase::getSelectionList.)
When the AI type of a newcomer and the current AI units that are unable to enter some terrain or
group leader are the same, then both need to feature (positive impassable count) cannot join a
have the same impassable fingerprint. For the group with a different impassable count. For sea
sea assault AI type, this isn't always enforced. assault units, impassable counts have to be
equal in any case (through a BBAI change).
Rationale The BBAI behavior is OK for the BtS units (Galley, Trireme), and I haven't changed
anything about that (I hope). Equal impassables are especially important for assault
units, but difficult to ensure because sea assault groups are formed in multiple places
(whereas AI group formation was otherwise centralized by K-Mod into
CvUnitAI::AI_omniGroup). BBAI doesn't ensure equal impassables for sea assault
groups either; there's special code for splitting out Galleys, so this is probably OK.
For impassables added by mod-mods, requiring equal impassable counts seems too
strict; can easily break the AI entirely when units aren't allowed to escort settlers. My
invariant allows a support unit (low AI_groupFirstValue) to join a group with a high
AI_groupFirstValue (UNITAI_SETTLE has the highest one) even if the group leader
has stricter movement rules than the newcomer. This seems like a sensible principle,
and it should avoid problems with paths computed for the group leader that other units
in the group may not be able to follow (not sure if this can actually happen; I guess the
pathfinder checks movement rules for each unit in the group anyway). Perhaps most
importantly, the invariant makes it sufficient to check the impassables of group leaders
231
in AI_omniGroup, i.e. it saves time.
The BtS behavior seems inconsistent insofar that it allows units without impassables
to join groups with impassables, i.e. it seems that a symmetrical check is missing.
See also The validation of AI groups after taking over from a human player are implemented
through 127, 127c and 700 (RiseFall::setPlayerControl).
CFC discussion
Tbd. Currently, a unit with one impassable could still join a settler with two different
impassables. Really need a set inclusion check, and not just for the case when group-
first values are the same. Don't know how to approach that.
057b Only relevant for mod-mods: Invisible settler units don't wait for an escort. (With the
BtS AI code, they wait in vain forever.)
Rationale Someone had this problem in their AdvCiv-based mod. The BtS AI code prevents
invisible and visible units from forming a group. I don't know if there's an important
reason for that other than that invisible units tend to have different tasks than visible
units. I'd rather that not mess with that. Letting an invisible settler go it alone isn't ideal
because the city will be defenseless at first, but at least the settler gets to take
advantage of its 2 movement points this way.
059 Help text for city health/ happiness from surrounding tiles
See also Based on refactored code for 901, which also changes the rules for health/happiness
effects across borders.
004b shows health/ happiness help for a future city when a Settler is selected.
232
AdvCiv BtS
When hovering over a tile in the radius of a city Tile hover text doesn't show any health or
owned by the active player or a tile owned by the happiness effects from features and
active player in the radius of any revealed city, improvements (only shows effects of resources).
health and happiness effects from improvements The city screen shows a tally of the health and
and features are shown. The hover text says happiness from surrounding tiles.
which cities are affected (this can include cities
not owned by the active player). Exception:
Health effects between -0.49 and 0.99, i.e. when
there is only an ordinary Forest, Jungle or Flood
Plains, are only shown when a Worker is
selected in the tile that the mouse hover over.
Rationale The +1 happiness from Forest Preserve should be shown in hover text; it's the main
reason for building Forest Preserves. I want to show happiness and health from
features and improvements together so that city names don't need to be listed
multiple times. (Traits can grant happiness from features and, through 901,
improvements can grant health; both unused.) However, I don't think I want to show
the small fractional health effects of BtS features all the time; they're not so important
and players are used to them. Hence the complicated conditions for when to show the
new hover text.
The city screen uses slightly more generic explanations for happiness and anger from features.
AdvCiv BULL (not in K-Mod)
When hovering over a Worker action button, the Optionally shows a hint in the action hover text if
changes in happiness and health for nearby the Worker build will decrease health in any
cities are listed. Fractional changes are shown in nearby city. That hint also says whether that city
gray if they'll be lost to rounding. has greater excess health than excess happiness
or vice versa.
Rationale The comparison between excess health and happiness doesn't seem very helpful and
it can't be properly explained with the available space. Also, without that extra info,
there's no need to make the new hover text optional.
233
If a player has more than 1 unit in the tile, that The owner is always shown in-line:
player's units are listed under a heading, e.g.:
Tokugawa (2 Units): Archer, Tokugawa, 3 str. Combat I
Archer 3 str. Combat I Archer, Tokugawa, 2/3 str.
Archer 2/3 str.
No per-owner unit counts are shown anywhere.
If a player has just 1 unit, the owner is shown in-
line. Due to the larger font, this line sometimes
wraps into a second line.
The unit count in the heading is broken down into
up to three categories if units of more than one
category are present. The categories are "army"
(military land units), "navy" (military sea units)
and "other". E.g.:
Tokugawa (1 army, 1 other):
Rifleman 14 str.
Airship 4 str.
In some cases, the heading is omitted, e.g. when
all units in the tile are owned by the active player
and they're few enough to count at a glance.
If there isn't enough space for all the units and
headings, the information shown about the tile's Same, though it can't be shortened to a single
center unit is (slightly) shortened or shortened to line. (The center unit is the one shown on the
a single line. map as a 3D model.)
If there still isn't enough space, units that have If there are more than 15 units, the first 15 are
both the same owner and type are aggregated still listed on a separate line each.
into a single line, e.g.: The rest is aggregated as described on the left
Archer (2), 2.5/3 str. Combat I x1 (minus the exception for Great Warlords), e.g:
This is applied to all units except for the center Archer (2), Tokugawa, 2.5/3 str. Combat I x1
unit and units with an attached Great General. These lines are often so long that they wrap
around.
If the algorithm expects that the aggregated
entries will still require more space than is No such fail-safe mechanism.
available (this should happen very rarely), a line
with a warning is displayed and, for some civs,
only the heading with the unit counts is shown.
The unit owners are ordered as follows:
First units without known owner, then those If the active player has units in the tile, then those
owned by the civ that owns the center unit, then units are shown first. Then ordered by player slot
ordered by (total) unit count, then by slot id. id (I think).
The units of a given owner are ordered as
follows: First transports and units in cargo Transports/ cargo: same. Then ordered by how
(interleaved so that one can guess which unit is recently the unit arrived in the tile (I think) and
in which transport). Then units of the same type unit type id.
as the center units, then units of the same
domain as the center unit. Then ordered by
domain, then by combat strength, then by unit id
(or unit type id if aggregated).
Config New option "List Units per Owner" on the “Map” tab of the BUG menu; enabled by
default. All the changes above only apply if the option is enabled.
Tbd. Use the change tag (see config\Tech Window.xml for an example) to toggle the
Unit layer twice when the status of the new option changes. Currently, the help text
234
attached to the Unit bubbles isn't updated until the Unit layer is manually toggled.
The “More Naval AI” mod allows human to cycle the center unit of a tile through key
presses (Git commit). Would be nice to have some means of viewing the full
information about any unit in a foreign stack. Not sure if this would be fully compatible
with AdvCiv. I think there's some non-UI code by me that accesses the center unit just
to get some arbitrary unit in a tile. Shouldn't matter how the center unit was chosen
then – but I'm not quite sure. Also a bit laborious to merge.
Rationale The main issue was that the BtS code wasted too much space. With the larger font
(002b), parts of unit list were frequently unreadable. The wrapped-around lines were
also difficult to read. The per-owner headings solve these problems and provide unit
counts, which I had wanted to add in some form and place for some time.
Another issue with the BtS algorithm: A mix of aggregated and non-aggregated info is
confusing, especially when the units shown separately are chosen mostly arbitrarily
(unit type id and slot id should only be used as tiebreakers).
See also 101 and 187 add some city-related info (revolts, air unit capacity) to the hover text of
city tiles, potentially limiting the vertical space available for units.
The owner of a Privateer is revealed if the Only revealed when the Privateer is in a City or
Privateer shares a tile with a visible non-PrivateerFort.
unit or when the Privateer is in a City or Fort.
Rationale Revealing Privateers in port makes some sense because units that are always hostile
(though BtS actually didn't check this) can only enter the port of their owner (well ... or
of a teammate). The same reasoning should apply to a Privateer stacked with visible
units whose nationality isn't hidden.
With the changes to help text, an anonymous Privateer stacked with other units would
have to be the center unit, and this would make it stand out more than I'd like.
See also 007 reveals the owners of Privateers when in Debug mode.
062 AI diplo comment states the reason for canceling a vassal agreement
AdvCiv BtS
When the AI cancels a vassal agreement, the Always says “It appears you are too weak to
diplo popup says, in vague terms, why the protect us ...”
agreement is being canceled.
Rationale Got the idea from this thread (K-Mod subforum). In AdvCiv, I don't think an
explanation is really necessary, as voluntary vassal agreements to humans are rare
and normally canceled because of the vassal's power rating, but it's still nice to have.
Also, “too weak to protect us” is misleading when the ratio between vassal power and
average power is responsible for cancelation.
235
Rationale Perhaps karadoc just didn't find these options helpful at all. They don't seem very
useful to me, but there isn't really any downside to my change, and it could convince
players who tend to enable all the BUG options to leave Actual Effects disabled,
resulting in a less cluttered UI.
K-Mod doesn't include the food and defense options. I suppose these were
deliberately omitted as the code seems very easy to merge. As far as I can tell, these
options would only apply to Baray, Walls and Castle, and I don't think that justifies two
additional checkboxes on the BUG menu.
Rewrote parts of the explanation text for the Actual Effects options as the original text was very
sparse. E.g. for the production option: “When checked, displays the buildings that will affect the
production rate and by how much.” Displays it where? Which buildings? The options are now under
the heading “Absolute Effects”, which seems more descriptive. (“Net Effects” would be another
alternative.)
Added a checkbox for the net effects of K-Mod only shows those effects when Alt is held
specialists to the BUG menu (and wrote help text down; can't permanently enable them. (It seems
for it). that BULL always shows net effects of
specialists; an option exists in the configuration
files, but isn't shown anywhere on the BULL
menu.)
Rationale Maybe an oversight in BULL. The options are good for making players aware of all the
features of the Actual Effects mod.
Credits VDNKh made me aware of the missing option (CFC post).
236
The last missing Whip Assist option would show hurry info on the city billboard (or it's
help text?). I suppose that the fast Deity-level players, who don't like to enter city
screens all the time, use this. Could perhaps merge it along with other BULL changes
to the billboards, but AdvCiv perhaps just isn't the right mod for such players.
Credits As far as I can tell, EmperorFool implemented the option that I've merged from BULL.
Separate option on the BUG menu (“City The “Tick Marks” option on the “General” tab
Screen”) for disabling hurry tick marks. Disabled enables all tick marks, including the little yellow
hurry tick marks by default. ones that show how much production is needed
to decrease the population loss from Slavery.
Rationale Two different tick marks make the production bar look cluttered, and it's nearly
impossible to guess what the hurry tick marks are for.
See also 078: Other changes to the BUG progress bar options.
064b Changes to overflow production rules. See the bullets in the blue boxes for the actual
changes. For context, let's go through the change history first:
Vanilla Civ 4 Warlords
Overflow production is capped at the maximum Excess overflow is turned 1:1 into gold.
of the total production cost of the completed
production order and the city's base production
rate (hearsay: this upper limit may have been
different prior to patch 1.61); any excess overflow
is discarded. As a comment in the code says “to
eliminate prebuild exploits.” (I.e. to prevent
players from producing items that take the city
less than a full turn for several turns in a row,
stacking up overflow toward e.g. a wonder,
spaceship part or military units whose tech
requirement is still being researched.)
Unofficial Patch 0.21 for BtS 3.17 (link) BtS patch 3.19
From patch notes: “Limited which production From patch notes: “Build-specific production
modifiers affect gold from production overflow.” modifiers are no longer counted for overflow gold
Lets the same modifiers apply as for Wealth. calculations.” However, the implementation works
quite differently, usually discarding excess
overflow without compensation. See e.g. this
post for details. This post by one of the authors of
the official patch confirms that Firaxis had only
meant to clean up the code from the unofficial
patch.
Unofficial Patch for BtS 3.19 K-Mod
From v1.0 patch notes: Kept overflow fixes from Same as the latest unofficial patch for buildings,
3.17 unofficial patch. but, for units, excess overflow is spent on
additional units of the same type if possible. If
From v1.4 patch notes: “Fixed extra overflow
there is enough overflow, multiple units can be
production bug when stopping culture process
trained in one turn.
after border pop.”
Issue with • Considering that overflow gold still occurs for buildings (e.g. Walls) and national
K-Mod rule units, K-Mod adds complexity to rules that were already complicated.
• On the highest difficulty settings in the late Classical or early Medieval era, AI civs
237
that see a large enemy stack approach can routinely produce more than one
Archer per turn through Slavery. This raises the cost for conquering mature cities
considerably – which might be OK for human-AI wars (though YouTuber Lain got
very upset about it in this video), but I suspect that it can lead to indecisive AI-AI
wars, and I don't want the invading AI to train and bring as many units as it takes.
• Usually, when excess overflow occurs, K-Mod produces another unit only partially.
To redeem the production spent, the player will have to continue training that unit.
But this will result in even more overflow as it's going to be a cheap unit and
maximal overflow is already being stored. For example, if a city with 105 production
per turn trains a Spy (40 production), it'll store 40 overflow and put 25 into another
Spy. If the player finishes that second Spy to avoid missing out on the 25
production, 130 overflow will result in 40 overflow stored, two more Spies and 10
production for a fifth one. Ultimately, this leaves it up to the player to avoid excess
overflow in the first place.
• When there are production orders queued up, it's counterintuitive that excess
overflow is spent on an additional unit that the player didn't ask for and not on the
queued orders.
See also 001v fixed an exploitable bug in the K-Mod overflow code. The fix was removed along
with the K-Mod code.
AdvCiv: Same as the latest Unofficial Patch, i.e. fully reverted the K-Mod change, and made the
following tweaks to overflow, chopping and Slavery:
• The overflow cap is set to the maximum of the city's food store capacity and (as as in
K-Mod/BtS) the city's base production rate. The production cost of the completed order no longer
matters.
Tbd. Could relax the cap a bit more, e.g. 150% of the food store capacity.
Rationale The overflow cap should be chosen with two goals in mind: (a) Prevent players from
stacking up substantial amounts of production and (b) set the cap so high that it's
unlikely to be exceeded unintentionally. As for (b), using the city's base production
rate is fair enough. As for (a), however, the cost of the completed order is not a good
indicator for problematic stacking. What should matter is the cost of the production
order that the stacked production is going to be used for. This is unknown, so some
estimate based on the overall game progress should be used. Since overflow is
somehow stored by the city, using the food store capacity makes sense to me.
Conveniently, the food store capacity is already adjusted to game speed, map size
and start era.
• Production from chopping is no longer converted into overflow, and instead remains stored
separately until the city needs it.
Rationale The accumulation of chopping production isn't an issue (or at least not one that
overflow conversion can address) because the player can always preserve chopping
production for a future production order by simply not chopping the Forests until
needed. Granted: It can be more efficient in terms of Worker utilization to chop Forest
ahead of time and keep the yield stored at the city; however, the BtS/K-Mod rules
already allowed this by having the city build a Process (which can't use up chopping
production), and my rule change has the substantial benefit of preventing chopping
production from ever getting converted into gold, and preventing hurry production
from stacking with chopping production to generate overflow (see below).
See also Wonder fail gold can still convert chopping production into gold. See Tbd. under 123f.
• The formula for the population to be sacrificed for Slavery takes into account the current
overflow and chopping production: That production is already guaranteed and doesn't need to be
covered by Slavery. Consequently, Slavery can't be used at all when the entire production cost is
already covered.
238
• The same goes for the computation of gold for rush buying, however, in this case, the current
production rate of the city is fully taken into account.
Rationale Slavery generates the most overflow when applied to an order that is already about to
complete. Ideally, hurry production should only add as much production as is needed
to complete the order at the end of the turn, resulting in 0 overflow. Of course
production from Slavery comes in chunks of 20 or 30 hammers, but the principle still
applies.
For rush buying, the entire production rate can be taken into account. If the player
rearranges the citizens afterwards, there can be overflow (can't be helped) or the
production order may no longer complete at the end of the turn. In the latter case, the
player can always rush buy again to close the gap.
As Slavery removes at least one citizen, the city's regular production from tiles can't
be counted on, but the currently stored overflow and chopping production are entirely
reliable. Strictly speaking, 1 production from the city tile is also guaranteed and my
original implementation had counted that 1 production. I've reverted that (see
CvCity::minPlotProduction) because reducing overflow by 1 isn't worth the
additional complexity. Related post of CFC: link
AdvCiv BtS/K-Mod
When an order is about to complete, the BULL (see 064 above) shows info about overflow
production yield tooltip on the city screen says production (including chopping overflow, which
how much overflow and chopping production will can't carry over separately) and gold, but only
carry over to the next order, and how much gold, when Slavery is involved.
if any, will be generated.
If overflow is converted into gold, an on-screen The overflow production is converted silently.
message says how much. (And K-Mod's additional units also appear
without any notification.)
Tbd. Would be nice to show a breakdown of hurry modifiers in the button tooltips. Also, the
impact on stored chopping production isn't shown on the Slavery button, however,
Slavery I'm hoping to remove eventually anyway, whereas rush buying is here to stay.
239
the extra modifiers are applied.
In theory, overflow generated through Slavery could be subject to an additional
penalty, e.g. reduced to 2/3, but I've found that too difficult to implement.
240
Moved the “Active” and “Info” tab up to the same portrait. The leader name also appears (no
height as the “Tech” tab, halved the horizontal change in AdvCiv) when hovering over the
margins and reduced the height of the bottom portrait.
margin to 25%.
The “Active” and “Info” have a peculiarly thick
The changes to the “Info” tab are only relevant if bottom margin.
BUG's “Enhanced Info” tab is disabled (which is
the case by default since AdvCiv 0.95).
Rationale Especially vertical space is valuable (even on large displays).
The height of the main panel on the “Active,” The panel takes up the entire height of the
“Info” and “Glance” tabs is reduced when there screen (apart from the margins), even if there is
are few civs to list. just one foreign civ to display information about.
Rationale The large panels look inelegant.
067 BUG era display uncoupled from NJAGC (game clock) and other changes to NJAGC
See also 002k: Year notation (AD/BC, CE/BCE) can be switched on the “Time” tab.
AdvCiv BUG
The upper half of the “Time” tab, which concerns The tab is called “Clock”. The switch for enabling
the era display, does not require NJAGC to be NJAGC (Not Just Another Game Clock) is in the
enabled. upper left corner and affects the era display and
the clock settings – can't have the era without the
The options on the lower half have been
clock. That said, the color settings apply to the
rearranged and a second dropdown menu has
era shadows on the tech tree even if NJAGC is
been added that allows the alternating views to
disabled.
be displayed for unequal amounts of time.
By default, if NJAGC and the alternate display
Default settings revised so that the game turn is
are enabled, the display switches every 5
shown for a longer duration than the time of day
seconds between game turn - slash - turn limit
(but the whole clock is still disabled by default).
and game progress as a percentage; the time of
Removed the option to show the game turn day is always on display.
progress as a percentage.
Config I've added an option for displaying the game era instead of the active player's era.
Then I realized that this would be a cheat as the game era can't be easily derived
from the game state until all civs have been met, so I disabled the option again. Can
be re-enabled through BugNJAGCOptionsTab.py.
Rationale Personally, I want neither an era display nor a clock, but there's no reason to couple
the two. The era display is even in a different corner of the screen.
The progress percentage seems entirely pointless to me; the other options I can see
some use in: Showing e.g. “126/750” instead of “Turn 126” can serve as a reminder
that the game is on Epic speed. I could also imagine that some players want to hide
the game year, e.g. to make room for the time of day.
The alternating display was perhaps not a great idea originally, but is kind of useful in
AdvCiv because of the increased font size (002b); the BtS clock doesn't fit on the
panel anymore. With the second dropdown menu I've added, one can also build a sort
of nagging clock that appears every 10 minutes just to remind the player that time is
passing. That's a bit more subtle than the BtS alarm function.
Credits TheLopez is the author of the NJAGC component.
241
068 BUG options can cause tech tree to be updated
AdvCiv BUG
When a BUG option that affects the visuals of the The “Tech Era” option that displays colored
tech tree is changed, a dirty-bit is set and the shadows on the tech tree and the options on the
whole Tech Advisor screen is reconstructed the “Clock” tab that set the shadow colors usually
next time that it is opened and then reflects the only take effect after a restart because BtS
changed settings. (CvTechChooser.py) caches the tech tree
widgets when tech tree is opened.
The “GP research” works without restart.
Rationale The BtS caching can't just be disabled. Opens the tech tree about one second faster
(in a Debug build) and keeps track of the horizontal scroll position.
069 Changes to plot lists and the PLE (Plot List Enhancements) component
Credits BUG lists 12mokeys and EmperorFool as the main authors of PLE.
See also PLE has a function that predicts the vertical space needed for help text
(getTextLines in PLE.py). This was sometimes underestimating the space,
presumably because of AdvCiv's larger fonts, so my adjustments in the PLE code are
tagged with 002b. That said, sometimes too much space was allocated (and I've only
made that worse), so I'm not sure if this is entirely a matter of font size. Anyway, too
much space isn't so bad, but too little space had meant that not all text was readable.
Tbd. Often, no help text is shown for plot list icons on the city screen. This error occurs
regardless of the plot list drawing method (vanilla/ PLE/ BUG). The handler for
WIDGET_PLOT_LIST gets called and composes the text correctly, but the text isn't
displayed. When loading a savegame and entering a city screen without selecting any
unit first, it seems to work correctly; so perhaps some of the code in
CvMainInterface.interfaceScreen (screen.addCheckBoxGFCAt?) needs to be
repeated in the updatePlotListButtons functions (near screen.changeImageButton)
when the city screen is up.
AdvCiv BUG
Rearranged the menu items and rewrote much of Originally, all the options on the “Plot List” tab
the help text on the BUG menu tab to make the required PLE to be enabled and to be in charge
dependencies and side-effects between the PLE of drawing the unit icons in the plot list. The BUG
options clear. Also changed some of the in-game team changed this gradually so that some
help text to match the terminology used on the options can also work independently of PLE, but
menu. they didn't update the menu (or only in part).
Rationale The PLE component is pretty complicated and mostly aimed at games with very large
stacks, but some of the functions are actually very simple and universally useful, so
it's good to have this sorted out.
PLE in-game help text shows turns-to-heal on a Shown without explanation on one line with the
separate line and spelled out. unit's strength and movement points.
Rationale Too difficult to guess what that number means; I had to look it up in the manual. And
vertical space isn't really (or shouldn't be) scarce.
When listing unit abilities, only the The full UnitHelp string is displayed (under a
BasicUnitHelp string is displayed. heading “Unit Specialties”), including a list of
unique replacements and the production cost.
242
Rationale Confusing clutter
Fixed a bug in AStarTools.py that had caused the PLE movement highlighter to crash
sometimes.
Fixed a bug in PlotListEnhancements.py that had prevented bar colors from getting updated
when changed through the BUG menu.
Fixed a possible bug in PLE.py that had caused health bars to be shown for civilian units. (Perhaps
was intentional.)
Fixed a bug in PLE.py: The names of unit owners had been shown in random colors.
Fixed a Python crash in MonkeyTools.getPlotHealFactor. Credits: keldath (CFC post)
Adopted a few of the help text changes in PLE into BtS (so that they apply if PLE is disabled):
The help text for a unit icon doesn't show the unit owner if the unit is owned by the active player.
The remaining movement points are shown (in addition to the maximum). XP is shown without
parentheses (also in tile hover text).
Rationale The game shows unit icons grayed out for units that belong to other players, and it's
pretty rare anyway that units of different players reside in the same tile. Therefore the
owner isn't important information in this context. Without the owner, the name, power,
moves, XP and promotions often fit into a single line.
Remaining movement points should be shown in order to match the information on
the info pane.
If the BtS drawing method is enabled, no Not sure about the PLE method and
indicator circles are shown for foreign units simultaneous turns. In singleplayer mode, BtS
unless they're wounded and the wounded and BUG display an indicator circle regardless of
indicator is enabled or have an attached Great the unit owner. For foreign units, it's always a
Warlord and the Great Warlord indicator is white circle – indicating that the unit isn't
enabled or when playing multiplayer with currently expecting orders – unless the unit is
simultaneous turns. wounded or has a Great Warlord (if the
respective options are enabled).
Rationale If the circle has no information value, it shouldn't be shown.
Tbd. Disable the circle also when the BUG drawing method is enabled.
243
I was going to set the color for positive gold to yellow to make gold rate and research
rate easier to distinguish. Now that it's implemented, the yellow is a bit too unfamiliar
for my taste (or just catches the eye too much). Also, if the gold rate is shown in the
gold/ commerce color, the research rate should really be shown in the research color,
and that's medium green (COLOR_GREEN_TECH I think); currently, the research rate is
light green (COLOR_POSITIVE_TEXT).
See also 004 adds light green and light red (COLOR_POSITIVE_TEXT, COLOR_WARNING_TEXT) to
the color palette of the BUG menu (through Config\init.xml).
244
calls. There might also be issues within the EXE (but I doubt it).
AdvCiv BUG
After each trade item listed, if the respective deal BUG has an option (“Deal Turns Left” on the
can't currently be canceled, the number of turns “Advisors” tab) for this, but that only applies to
that remain until cancellation is shown in the “Active” tab of the Foreign Advisor screen,
parentheses. (Disabled by default.) not the trade table.
Config I've extended the “Deal Turns Left” option so that it can either apply to the “Active” tab,
the current deals on the trade table, both, or neither. The default is neither.
Rationale In both contexts, hover text shows cancellation info; that should be enough. Gold-per-
turn items already show the amount of gold in parentheses, and the double
parentheses look a bit strange, e.g. “Gold per Turn (3) (6 Turns)”. It's also not totally
obvious what this means, i.e. that the first number is the amount of gold and the
second the turns until cancellation.
245
through dark background panels, but the group “Import,” “Export,” [gold icon].
headings have been removed.
Rationale The two different perspectives are confusing, and the removal of the group headings
frees up space for a larger “Surplus Resources” box (see below).
The column for resources that the other civ is The “(we can) Export, (but they) Won't Trade”
unwilling to import has been removed and the column contains the resources that both civs are
column for resources that the other civ is able to trade. The “(we can) Import, (but they)
unwilling to export has been split into “We Don't Won't Trade” essentially also contains those
Need” (resources that we already have – denial resources plus some resources that the AI is
reason: “you must be joking”) and “Won't Export” unwilling to trade for other reasons.
(all other reasons).
The “Surplus Resources” box has been renamed Only surplus resources are listed in that box. All
to “Domestic Resources” and lists all resources our non-surplus resources appear multiple times
that we're able to trade. Surplus resources are in the “Won't Trade” columns though.
listed first and can easily be recognized by the
yellow number that says how many copies we
own; that number isn't shown for non-surplus
resources.
Rationale The description on the right should make clear that the BUG layout is redundant. The
information in the “We Don't Need” column still overlaps with the “Domestic
Resources” box, but, without that column, a complete list of foreign resources would
be missing.
Tbd. When the player has surplus resources of more than 28 resource types, the first row of
the “Domestic Resources” box is going to be too small, and icons are going to be
shown outside the box or even off-screen. This is because I don't know how to display
multiple rows of resource counts (the yellow numbers). Not an urgent problem
because 28 is a lot when there are only some 35 resources in the game, and on
widescreen displays, all resources might fit in a single row. On that note, the code
should check whether all resources (incl. non-surplus) will fit into a single row – easy to
do – and show the second row only when needed – not quite so easy.
246
human turn (see 001e), then the problem will go away.
If an AI civ cancels multiple deals at once, 133 shows all canceled trade items in a
single popup. 074 doesn't support multiple popups in a row.
073 makes sure that the resources of all known players are visible on the “Resources”
tab of the Foreign Advisor. (One could argue that unrevealed resources that the AI isn't
offering for trade should be secret, but this would take some effort to implement.)
075 Units in cargo wake up when the ship has reached land and is out of moves
AdvCiv BtS
When a ship has spent all moves, has no further Units are set to the “sleep” activity when they
moves or other missions queued and is in a land enter a ship. I don't think they ever wake up from
tile (city, Fort) or adjacent to land, any land units that automatically.
in cargo that are able to move are woken up.
Units that have been given any order while in
cargo will not wake up. (Technically, units are set
to a new activity type called “boarded” when they
go aboard, and they have to be in that state in
order to wake up.)
All of the above only applies when automatic unit
cycling is enabled (it is by default).
Rationale Because of automatic unit cycling, it's easy to forget that units can disembark when a
ship reaches its destination with its final movement point. The cargo units then lose an
entire turn.
I'm limiting the wake up conditions as much as possible because units asking for
orders prematurely can be annoying. Hence also the restriction that an embarked unit
will only ask for orders once.
Tbd. Perhaps an option “Wake Up Cargo When Reaching Land” on the “General” tab under
“Commands.” Hopefully not needed. GlobalDefines option?
It might be that units are distributed rather unintelligently at times when a stack of land
units is moved onto a stack of transports. C2C thread
247
My Games\Beyond the Sword\Profiles –
either in Default Profile.pfl or in a custom
file created by the user through the “Other” tab of
the player options menu. (Unless that pfl file is
set to read-only through Windows file properties.
That's a way to make the options revert to a fixed
configuration at program start.)
Rearranged, renamed and, in two cases, hid The pfl file is written in a binary format that will
items on the player options menu, however, break when options are removed from or added
without changing the format of the options profile to CIV4PlayerOptionInfos.xml or
or the order of options in XML, so that these CIV4GraphicOptionInfos.xml, unless blank
changes won't cause any compatibility issues. options reserved for mods (PLAYEROPTION_
Moved some of the checkboxes from the right MODDER) are used.
column of the “Graphics” tab into the left column, “Graphics Level” doesn't seem to have any effect
mixing them with the dropdown menus. E.g. the of its own. Looks like a change in that dropdown
“No Movies” option is now placed above the merely causes several other settings to change,
“Movie Quality” dropdown and “No Buildings” (in namely the other three “quality” settings, anti-
Globe View) under the “Globe Quality” dropdown. aliasing, “Low-Res. Textures”, “No Movies”, “No
Removed the “Graphics Level” dropdown, Buildings in Globe View”, “No Effects”, and
meaning that the setting will remain at whatever “Animations Frozen”. They probably forgot “High
value is stored in the player's profile. Detail Terrain”, which was added by patch 1.61.
Rationale A widget that will overwrite several other settings is similar to a reset and that would
have to be very clearly communicated. However, on current hardware (say, post-
WinXP) most of the settings tied to “Graphics Level” hardly affect performance (or
even power consumption), so it's better (and easier) to remove this master switch
entirely.
Config Can always change the “Graphics Level” by unloading AdvCiv.
Tbd. Find out if “Render Quality” has any effect. I'm seeing no immediate effect, and, after
restarting, the terrain always looks a little different, so it's difficult to be certain that
there is no change. There could well be some very minor impact, or a noticeable
impact only in combination with other settings, e.g. only at a low resolution. On the
web, I've only found a few baseless claims. If there is no appreciable effect, then it
should perhaps be force-set to “low” (to make sure that no computing time/ power is
wasted) and the dropdown removed. Currently, my tooltip says “Effect Unknown”.
And test some very high resolutions to see how the fonts and icons scale; then
possibly add a warning about that to the “Screen Resolution” tooltip. I'll need a larger
monitor for that.
The space cleared in the right column of the The checkboxes on the first two tabs are
“Graphics” tab allowed me to add headings to haphazardly arranged and not structured by any
structure the remaining checkboxes, to move two headings.
options from the “Controls” tab to the “Graphics”
tab that might as well be graphic options (“Quick
Moves” and “Numpad Help”) and then to add
headings to the “Controls” tab as well.
Rearranged the checkboxes on the first two tabs
and made some (mostly minor) name changes,
in part to take advantage of the headings; e.g.
having a heading “Automation” means that
“automate(d)” doesn't have to appear in all of the
option names.
248
Rationale Regarding “Quick Moves”, the options for unit controls on the “Controls” tab and those
for animations on the “Graphics” tab are both concerned with unit animations. Putting
them all on one tab might be nice, but “Quick Defense” and “Show Friendly Moves”
need to be on the first tab for easy access, and there isn't enough room there for all of
them. Even moving only “Quick Moves” and “Combat Zoom” to the “Controls” tab
would require a major reshuffle. And these two really are just visual changes, whereas
most options on the “Controls” tab allow a tradeoff between optimal play and pace, e.g.
the automation options, “Wait at End of Turn”, “Stack Attack” and I'd say also “Quick
Defense” as this option makes it sometimes impossible to keep track of all enemy
attacks.
Changed almost all tooltips to provide more Many of the tooltips more or less just repeat the
precise information and, in some cases, hints name of the option, which is usually not self-
and recommendations. Added tooltips to the explanatory (certainly not for new players). No
dropdown menus and to the reset and exit tooltips for the dropdowns and buttons.
buttons.
Added a “need restart” popup to the “Low-Res. Restart popup for “Fullscreen”, “Single Unit
Textures” option and the “Globe Quality” menu, Graphics”, “High Detail Terrain”, “Graphics
and added info about having to restart or reload Level”, “Audio Speakers”.
to the tooltips of any options that need it.
Removed the banner from the “Audio” tab; the A banner of a sound card vendor (sponsor?) is
cleared space remains mostly unused. shown on the “Audio” tab.
Device names in drop-down menus shortened as I never even knew that a custom music folder
needed to make sure that the menu fits in the can be configured because the button had been
window. Moved speaker settings and custom off-screen.
music folder to the left column.
Removed the panel for network settings from the The only network setting is “Modem” vs.
“Other” tab. That means, the connection speed “DSL/Broadband”. Not sure if this has any impact
set in the profile is assumed. on networked multiplayer games.
Rationale No one has a non-DSL modem. Can still change this through "Bandwidth" in the INI
file. With this panel removed, the Profile panel is the rightmost one, which makes
sense: after configuring everything, the player may want to create/save a profile. Also,
in BtS, one can get the impression that a profile is just some sort of user id for network
games.
Regarding the layout of the “Audio” tab: It's better to have voice chat on the lower right
than speaker settings and custom music folder because the voice chat options are a
bit complicated and rarely used.
Tbd. Should perhaps mention in the tooltip for “Show … Moves” that those options have no
effect when playing with simultaneous turns.
Changed the default values of several options (at my discretion).
Rationale Doesn't matter much because the BtS defaults are set in the profile upon installing BtS
and, when a mod is loaded, the values in the profile are used. The defaults do matter
when a player manually resets the profile, or if it is automatically reset, which happens
under some rare error conditions. Also, the defaults can be looked up in XML as a
reference.
The reset button on the “Graphics” tab doesn't Each of the four tabs has its own reset button
affect the “Fullscreen” checkbox, nor the “Screen that affects all settings on that tab except (I think)
Resolution” and “Menu Background” dropdowns. “Screen Resolution”. The default values for the
The quality dropdowns are set to “high” and checkboxes on the first two tabs come from
MSAA to 2 samples. The reset button tooltips the ...OptionInfos XML files, about the others
explain what gets reset and how that will affect I'm not sure. For the “Graphics” dropdowns, the
249
the current profile. same settings as for medium “Graphics Level”
seem to be used, i.e. 2 MSAA samples and all
The need-to-restart popup is only shown if one of
levels at medium. The effect on the menu
the options that was changed requires it.
background dropdown seems erratic.
Removed the reset button on the “Other” tab.
When “Graphics” or “Audio” are reset, the need-
to-restart popup is always shown.
Rationale It should be obvious that the game is normally played in fullscreen. Perhaps a sensible
resolution could be set based on the resolutions supported by the hardware, but that
might take some work to implement. The menu background is a matter of taste.
With only the Clock options left, a reset button on “Other” is unnecessary, and could be
misunderstood as affecting all tabs.
Renamed the “Detailed City Info” option to Also shows a research icon on the billboard of
“Numbers on City Bar”, and it only shows the city with the highest research rate, a gold
production turns and turns to grow. icon for the highest gold rate and a production
icon for the highest production rate.
Rationale The meaning of the icons is obscure and, as the capital usually has the top gold and
research rate, they're quite unhelpful except possibly for the production icon. Without
the icons, the option makes sense on the “Graphics” tab because the turn numbers
are really just a visual aid for players who find the one-turn projections always shown
on production and food bars insufficient.
See also 002f allows the icons to be enabled through the BUG menu.
Tbd. Would be nice to add a tab for controlling some important settings in
CivilizationIV.ini. To get those settings more visibility and to allow them to be
changed from within the game. (For some, it may be impossible to apply them
immediately, but the options screen has warning tooltips and popups for such cases.)
Wish list: MouseScrolling, MinimapTrilinearFilter (some might prefer it if they try
it), SetMaxFrameRate (unlimited frame rate might be a bit wasteful for a turn-based
game), HidePythonExceptions, MaxAutoSaves, AutoSaveInterval, CheatCode,
ScreenHeight, ScreenWidth (for custom dimensions in windowed mode; don't know if
they could be immediately adopted), LoggingEnabled, RandLog, MessageLog (the log
settings would have to be given clearer names).
Example of how to change an .ini setting from within the DLL: “We the People” Git
commit by Nightinggale
The “INI” tab should also show the path of the .ini file to which the settings will be
written.
250
rival whose demographics are visible through that rival has even been met. Only the value is
espionage. displayed though (e.g. the number of soldiers).
Alternatively, as an option, a "?" can be shown in The main point of these columns was, I suspect,
the “best” and “worst” column when the demo- to provide points of reference for the player's
graphics of the best or worst rival aren't visible. demographics.
Or, as another option, the name of the best or
worst rival can be shown even if its demo-
graphics aren't visible. A “?” is then displayed if
the best or worst rival hasn't been met.
Config The “options” are just boolean flags near the top of Assets\Python\Screens\
CvInfoScreen.py.
Rationale See under Credits above. I particularly don't like that the player can tell on turn 0 that
some unmet rival has the Charismatic trait. Giving away any concrete rival values is
problematic unless those values are revealed through the graphs anyway, i.e. when
demographics are visible through espionage. Potential problem: If a player focuses all
his/her espionage on one or two targets in order to reveal their research goals, then
the rival columns may not contain much useful information. I've tried a less restrictive
approach (still in the code as an option) that also doesn't give away values but names
the best and worst team regardless of espionage; however, I worry that this could
incentivize players to check the “Demographics” tab every few turns.
The rival average is rounded to the nearest The average is computed over all civs except the
multiple of 5, no longer includes vassals and active player. It's rounded to the nearest smaller
teammates of the active player and isn't shown integer and shown regardless of the number of
when there are fewer than 4 rivals alive. Minor civs alive.
civs are also excluded.
Rationale The (more or less exact) average of land tiles gives away how many civs start at the
coast, and the other values probably aren't safe either. Moreover, the changes from
turn to turn could reveal information throughout the game. Coarser rounding appears
to solve these problems, and the resulting approximate average is still useful (at least
by the midgame) for putting the player's values into perspective.
With just 3 rivals, if best and worst are known, the one in the middle could be
computed from the average, which is tedious. Hence no average when the sample
size is small.
Credits Exclusion of minor civs adopted from “Dawn of Civilization” (Git commit)
Removed the final row (Export-Import). It can be The value is the player's total commerce from
re-enabled through an option (see Config above), foreign trade minus the sum of the commerce
but this will result in a vertical scrollbar since that other civs receive from the player.
there is only enough space for 8 demographic
values now. If it's enabled, the value is the
player's total commerce from foreign trade.
Rationale Seems like the least useful statistic. It doesn't make much sense to subtract other civs'
commerce because Civ 4 isn't a zero-sum game (unless only two civs remain); it's
mostly flavorful (trade balance is a widely known economical concept). Commerce
from foreign trade is still shown on the Finance tab (Economics Advisor).
See also CFC post by a player confused about the significance of the Export-Import stat.
Layout changes: Except for rival average and the Only the first column has double rows, showing
first (title) column, all columns have double rows the name of the value (e.g. “crop yield”) on top
with one item on top and another at the bottom. and the unit of measurement at the bottom (e.g.
“million bushels”). All the other columns just show
The worst/ best rival columns show the value on
a single number.
251
top and the rival name and rank on the bottom.
The (player) value and rank columns have been
merged into a single column with the value on
top and rank at the bottom.
No icons; all text.
Changed most of the labels to use the available
space efficiently and resized the columns. Also
using some icons. Shortened a couple of leader
name translations (French, German, Spanish) to
make them fit into the columns.
Rationale Putting the rival value, name and rank all in one table cell would be difficult to read.
Since the average column has only a (numeric) value to show and it would look
strange to leave the top cell empty, all values have to be shown on top so that they're
easy to compare (and all ranks at the bottom). Since the unit of measurement should
be on the same row as the value, I've put the units on the same line as the names of
the values. That's a bit tight, but it fits.
Decimal (“thousands”) separators added.
Rationale To make the large numbers easier to read.
When the Info screen is shown after winning, Same except that the BtS Demographics tab
losing or retiring, all info on all tabs is revealed as didn't have anything to hide. And all info
if in Debug mode. continues to be revealed after selecting “just one
more turn” (extended game).
Rationale Don't want additional info to be revealed in the extended game; the player can enter
Debug mode for that.
The yield statistics about rivals are moving averages.
Rationale/ To be consistent with 004s, which shows moving averages on the “Graphs” tab.
See also
252
shown as part of the semi-transparent portion of solid portion of the research bar and thus
the research bar. indistinguishable from the current research
progress. The semi-transparent portion shows
the per-turn research rate without overflow.
However, the production bar on the city screen
shows overflow (only) in the semi-transparent
portion.
Rationale Solid overflow suggests that the overflow has already been spent, but it isn't spent until
end of turn (because it's really part of the research rate). And it's inconsistent with the
production bar.
I'm keeping the BtS behavior if tick marks are disabled because the per-turn research
rate without overflow is an important statistic that should arguably be visualized
somehow, either through the semi-transparent portion or, preferably, through tick
marks.
AdvCiv K-Mod
“Great People Rate Breakdown” merged from Unavailable (not merged from BULL)
BULL, but without an option, i.e. the hover text is
always enabled. It shows, when hovering over
the GP bar on the city screen, how many GPP
are generated by buildings and how many by
specialists.
079 AI greetings
AdvCiv BtS
Only about half of the AI leaders brag about their If the AI doesn't warn about its worst enemy (see
best unit (based on CONTACT_DEMAND_TRIBUTE). below), it brags about it's current best unit with a
probability of 25% unless Pleased or less
When a braggart AI has a new best unit, it brags
powerful than the player. The roll is repeated
about that unit at the first opportunity (unless the
every time that the AI is contacted. AI personality
best unit is known anyway because AI techno-
doesn't matter.
logies and resources are visible to the human
player) and, if contacted again, with a random
chance as in BtS.
Rationale To eliminate the need for contacting the AI multiple times to find out its best unit in the
early game. At first, I implemented a random chance of never bragging about a
particular unit based on the CONTACT_DEMAND_TRIBUTE divisor, but, ultimately, I think
it's better to make the early warmongers always reveal their best unit. (For some of the
peaceful leaders, this would be out of character and shouldn't be needed either.) Of
course, contacting the AI every few turns is still tedious, but I don't think the infor-
mation is usually relevant, so I'm not implementing an alert message or sth. like that.
See also 005a changes the CONTACT_DEMAND_TRIBUTE divisor for several AI leaders. Most of
the leaders with a sufficiently low divisor (less than 400) are listed there.
The AI remembers when it has warned a human If there is a worst enemy, there's a 25%
player against trading with a particular enemy, probability that the AI will warn about it when
and is more likely to warn if it hasn't warned contacted. This is accompanied by an angry
before and less likely otherwise. facial expression in BtS, and, in K-Mod/AdvCiv,
by the trade-refusal expression.
Rationale Mainly to reduce the frequency of the somewhat jarring stop-trading leader animations.
253
After the first era, the AI says “we would Will say “watch out for our worst enemy” only if
encourage you to stop trading ...” in the greeting the accumulated trade value in AI memory is 0,
only if the human player has annual deals with and otherwise, i.e. basically if the human has
the worst enemy. ever traded with the enemy, “we would
encourage you to stop trading ...”
Rationale To address a to-do comment by the original developers: “maybe make this a little
looser (by time...)”
254
owner of the target city is expected to be short work, go directly to the target city if
possible.
Implement UWAICache::updateRelativeNavyPower (see comments there) and an
auxiliary function for the intel ratio. Once there is a cached intel ratio,
CvPlayerAI::AI_targetCityVal could also evaluate resources from the city owner's point
of view so as to be able to “take the Oil.” related CFC post
CvUnitAI::AI_assaultSeaTransport should estimate
a) (easy) the strength of the own escort (just add up the strength values) and
b) the strength of defending ships that will intercept the group. Cheat by using the
target's (unless barb/minor) UWAI fleet power – once i implement that
relativeNavyPower function, the cheat will more or less go away. Also need to
account for factors that may distract the defending fleet. Perhaps based on the number
of the target's coastal cities plus half the number of own coastal cities (enemy could
use its fleet to harass those) plus one quarter of the number of coastal cities of our war
allies.
See also If 162 (crossing a border on the same turn as declaring war spends all movement
points) is replaced with some form of ZoC rule, more AI changes will be needed.
040 deals with naval AI for founding cities and 046 with stranded units.
AdvCiv K-Mod/ BBAI
When a group of AI units is supposed to start a Only avoids ending a turn inside the enemy's
war, the pathfinder avoids entering the enemy's border. Doesn't avoid moving through.
border earlier than necessary.
Rationale An oversight by the earlier modders. It would be even better to enter the enemy's
territory without declaring war when it's clear that the units are going to leave and re-
enter, but that would be a bit more work to implement.
In a non-”total” war, when a naval assault stack is AI_assaultSeaReinforce was added by BBAI.
large enough to serve as reinforcements but too Naval assault stacks consider that routine if they
small for an initial attack and no reinforcements have at least as many units loaded as are
are needed abroad, then the AI looks for a required for a land-based AI city attack stack
landmass with at most two hostile cities and (AI_stackOfDoomExtra). An initial attack
launches an attack there if the assault stack (AI_assaultSeaTransport) is only considered
appears to be powerful enough. when the naval assault stack has at least twice
as many units loaded as are needed for a land-
based attack. (That's the intended BBAI behavior
anyway; because of a bug – fixed by K-Mod – it
hadn't actually worked that way.)
Rationale 2*AI_stackOfDoomExtra() is already ca. 10 in the Classical era. That's often overkill
for attacks on enemy colonies.
See also Discussion on CFC: link
255
from.
Barbarians ignore units positioned adjacent to a Reportedly, the BtS AI is generally unable to plot
city when deciding from which tile to attack the around enemy units; in K-Mod, I can only recreate
city. this for Barbarians vs. units blocking the entire
inner ring of a city.
Tbd. Non-Barbarian AI stacks still disregard tiles with enemy defenders when deciding from
which tile to attack a city. K-Mod comment: “consider fighting for the best plot”
The choice of the tile to attack from needs to take into account how dangerous the
enemy units are. Currently, once the AI has decided on an attack path, it won't enter
the city directly even if all defenders abandon the city.
When war is imminent or ongoing for some 8 to In rare cases, the AI will build up city attack
12 turns, the AI becomes more willing to merge stacks in more than one city, each failing to
city attack stacks over longer distances. accumulate enough units for deploying to an
enemy city.
Rationale A bit of a kludge, but keeping track of the rate at which each stack grows seems like a
disproportionate effort.
Credits spqkfk has brought this issue to my attention.
Tbd. CvUnitAI::AI_moveToStagingCity should avoid gathering city attackers in a
vulnerable border city when there is a real risk of a (human) pre-emptive attack,
especially when war hasn't been declared yet. Not so easy to implement because the
city threat rating – currently the main criterion for selecting the city – isn't on any
particular scale (tends to be higher in the late game than in the early game), so one
can't easily combine this with e.g. city defense a lesser criterion. I guess one could
first calculate a threat rating rank. Should arguably also take into account the distance
to enemy cities with a high CvPlayerAI::AI_targetCityValue; I think UWAI already
caches that.
Added some thresholds for utility values The AI will, eventually, pillage every road around
calculated for tiles that the AI considers pillaging its target city, and, at least in K-Mod, continue to
when too weak to attack a city. Those thresholds wait for reinforcements even once everything has
are based on the size of the city attack stack. been pillaged. Stack size doesn't matter (so long
When there is nothing worthwhile to pillage, the as it's not big enough to conquer the target city).
city attack stack retreats.
Rationale Keeping pressure on the city will lead to more and more defenders getting produced
with very high priority, which will often outpace the attacker's reinforcements.
Moreover, a large stack camping in enemy territory costs gold in supply (even if the
cost is halved for the AI), is vulnerable to an eventual counterattack and leaves the
homeland vulnerable as well (also to third-party attacks). Against a human target
especially, this can feel like lose-lose AI behavior.
256
unavailable.
Rationale The other victory conditions make some sense without any opponents.
Difficulty factor for Hall-of-Fame score gets divided by 4 when playing without competition.
Rationale Don't want solo wins (especially not Domination) to end up at the top of the Hall of
Fame screen.
085 Changes to the tabular scoreboard (i.e. only applies when “Tabular Layout” is enabled
on the “Score” tab of the BUG menu)
See also 120h changes the meaning of the espionage column.
For a scrollable scoreboard, this Dawn of Civilization pull request could be helpful.
Though I don't mind the scoreboard taking up much of the screen height.
AdvCiv BUG
When an underscore is placed before a letter in The formatting string on the “Score” tab of the
the “Column Order” formatting string, the BUG menu allows players to select which
respective column appears only if the “Expand columns should be displayed and how they
on Hover” option is enabled and the mouse should be arranged. Underscores in the string
hovers over the scoreboard. By default, the don't have any meaning and are ignored.
trade network, Open Borders, Defensive Pact,
power ratio and Golden Age columns are set to
appear only on mouse hover, and “Expand on
Hover” is enabled by default.
Config See the help text for the “Expand on Hover“ option on the “Score” tab of the BUG
menu. The letters with a preceding underscore should be placed on the left side of the
scoreboard, at least to the left of the player score (letter “S”) and civ display name
(letter “C”) to make sure that the score and name don't move away from under the
cursor when the scoreboard expands.
Previously (v0.95 and earlier), all the info in the expansion columns was disabled
entirely by default, so it's all nonessential and players who find the expanding
scoreboard distracting only need to toggle off “Expand on Hover”. However, players
who want e.g. the power ratio to be shown permanently, will have to edit the “Column
Order” string to remove the underscore and may also want to move the power ratio
column farther to the right. For reference, the K-Mod default display string was
!?2WSZVC6EPTUNBDRAHQ*LO, BUG's default is !WSZVC?EPTUNBDRAHMQ*LO. The
AdvCiv default can be found in Assets\Config\Advanced Scoreboard.xml under
“DisplayOrder”. (In case that it gets overwritten when importing settings from another
BUG installation.)
When no expansion columns are set in the display string, then the “Expand on Hover”
option becomes automatically disabled. This is done to ensure that no time is wasted
by the DLL on checking whether the cursor gets moved off the scoreboard. Especially
relevant when a player imports (copies) settings from another BUG installation.
See also 106d changes the default formatting string for the scoreboard.
Based on 003r (code for deferred UI updates)
Rationale To make some info about other civs quickly available without obstructing the view on
the main map all the time.
Choice of the extra columns: The trade network icon isn't helpful in itself, but the
hover text (merged from BULL) lists trade routes and active deals.
257
Tbd. In large games, unit animations (if enabled) generally stutter a bit while hovering over
the expanded scoreboard. Camera movement (e.g. arrow keys) while hovering also
isn't entirely smooth. I think that's just the result of recomputing and redrawing the
scoreboard once per game update (i.e. every 250 ms). The only (potential) remedy I
can see would be to write a (Python) update function that only reinitializes the
scoreboard widgets. Cf. comments in CvPlayer::setScoreboardExpanded. The
problem seems to get a bit worse when all columns are enabled. It gets much worse
with more than 30 civs. Bug report
It seems that sometimes (rarely?) moving the cursor onto the scoreboard right after it
has collapsed causes the frame rate to drop 5 FPS, suggesting that the scoreboard is
getting redrawn without intermittent game updates. Or perhaps it's just somehow a
special case of the problem described above.
Probably won't fix: When moving the cursor quickly from the expanded scoreboard to
the flag button, the mouse focus switches to the main map behind the flag button.
That's probably a side-effect of the CvInterface::makeSelectionListDirty call in
CvGame::update.
Another side-effect: When the mouse is moved across the scoreboard onto a Globe
layer button and the scoreboard collapses while the mouse button is down, the click
on the Globe layer button isn't registered. Probably can't be helped because the DLL
can't tell whether a mouse button is being held down.
During diplomacy the scoreboard can be expanded, but will then remain expanded until diplomacy
ends.
Rationale Workaround for a problem with flickering hover text; see comment at the start of
CvPlayer::setScoreboardExpanded.
AdvCiv BtS/BUG
Column added that shows the Golden Age icon Golden Ages and revolutions are announced, but
when another civ is in a Golden Age or the I'm not aware of any way to check – reliably – if
negative-gold icon when in Anarchy. Help text for an opponent is currently in a Golden Age or in
the icons says how many turns remain. Anarchy. Golden Age and Anarchy length are
public knowledge though.
See also 152 uses the “fist” icon for AI war trades. That icon has become strongly associated
with AI war planning through the BUG mod. So that icon can't be used for Anarchy.
And I like the negative-gold icon better anyway.
Rationale For the active player, Golden Age and Anarchy are already prominently displayed in
BtS; therefore show the scoreboard icon only for other players. The more often no
icon needs to be shown (for any player), the better because then the entire column
disappears.
Hover text for the power ratio column added. BUG has added the power ratio column. No
Explains what the ratio means and why rival hover text. The power ratio is only shown if a
demographics are visible: by how many rival's demographics are visible through
espionage points the threshold for seeing espionage. In BUG, the power ratio column is
demographics or research (whichever applies) is enabled by default, in K-Mod, disabled by default.
exceeded. Power ratio column enabled by default
but only appears when the scoreboard is
expanded.
Color-coding is customizable through the BUG
For teammates of the active player, high and low menu (“Score” tab) but the settings apply to rivals
power ratio aren't color-coded. and allies alike.
See also Color settings for power ratios (Advanced Scoreboard.xml) are tagged with
258
advc.004.
Rationale The power ratio is useful (especially because it implies visible demographics), but
bulky and potentially confusing, in part, because it isn't obvious which power rating is
in the divisor. Hover text and expanding scoreboard address these problems.
Tbd. The info about the see-research threshold might make more sense in the rival-
research help text. Would have to add a new help widget for that because the widget
currently used doesn't have room for the rival player id in its data structure; but that's
not much work. Could then also remove the active player's research progress from
the help text (unexpected in this context). Still, showing the see-research info in the
power ratio help text is quite economical as it doesn't take up any extra space (see-
research implies see-demographics).
While I wouldn't want to use the attitude and worst enemy icons even in the expanded
scoreboard, it would still be nice to add some simple hover text to them:
Worst enemy: “You are Alexander's worst enemy”
Attitude: just “Friendly” etc.
Some useful info that could be shown in hover text for the religion icons? No text at all
currently and they're always shown.
Clicking the active player's name or score on the The scoreboard is minimized when the active
(maximized) scoreboard has no effect. player is clicked. The minimized scoreboard
shows only the active player's row.
(The scoreboard can still be hidden entirely
through “Toggle Scoreboard”.)
Rationale I don't think minimized scoreboard is good for anything, and players who accidentally
minimize the scoreboard may not know how to maximize it again.
See also Post on CFC asking how to maximize the scoreboard.
A score breakdown is shown only when hovering When hovering over the active player's score or
over a civ's score value. Always for the active name, a score breakdown is shown. Can't show
player and, for others, in Debug mode if the Ctrl score breakdowns for other civs.
key is held down.
When hovering over the active player's name on
the scoreboard, help text shows whose worst
enemy or war enemy the active player is, and the
active player's total war weariness is shown. (I.e.
pretty much the same info as is shown by K-Mod
when hovering over the active player's portrait on
the Foreign Advisor screen.)
Rationale Want to make worst-enemy info and war weariness easier to access.
Tbd. Combine the functions CvDLLWidgetData::parseContactCivHelp and
CvGameTextMgr::parseLeaderHeadHelp; they do largely the same thing.
AdvCiv BtS
When rival research is visible, the scoreboard Show turns remaining.
shows the tech progress as a percentage.
Rationale The turns remaining fluctuate too much as the AI adjusts its sliders or goes into
Anarchy. Plus, the percentage can be shown even when no tech has been chosen
yet, avoiding confusion as to whether research has stopped being visible. (Naturally,
this problem could also be solved e.g. by showing some sort of empty tech icon when
no tech is being researched.)
259
086 Hover text on the “Finances” tab (Economics Advisor) revised
See also Hover text merged from BULL is tagged with "BULL - Finance Advisor".
AdvCiv BtS/BULL
Mostly removed headings that didn't contain any Some items in the commerce, income and
additional information. expenses breakdowns have hover text with
explanations or additional breakdowns.
Finance tab lists commerce from domestic trade even when it's 0.
Rationale To avoid confusion.
Credits Th334
260
on the main map and the unit action buttons are
displayed.
Rationale For just studying the map for a while or for taking a screenshot. The fewer
distractions, the better.
Alt+U is already taken by the Unit layer; Shift+U by “unload all”. Unfortunately, the unit
debug menu blocks both Ctrl+U and Ctrl+Shift+U.
“Deselect” seems to be the more commonly used (and, in a way, more linguistically
correct) term, but I associate that more with unchecking an option.
Config Through XML\Units\Civ4ControlInfos.xml. The key combination can't easily be
changed there however because I've hardcoded the same combination in
CvGlobals::suppressCycling. If automatic unit cycling is not suppressed, then it'll
immediately select another group (or the same as before). That's also why the keys
need to be held for a moment.
261
by 2, meaning that 100% corresponds to 125.
Rationale A longer slider makes it a bit easier to position the slider at a particular percentage.
That said, there seems to be a bug in the slider component (in the EXE) that makes
the slider position change by 1 when releasing the mouse button. A much longer slider
might (mostly) fix that problem, but some players keep the slider permanently on
display, so it mustn't take up much space.
FoV values below 10 aren't useful for anything, so I've removed those from the slider.
At a value of 100, Huge maps still don't fit entirely on the screen without zooming into
Globe view, but 125 seems to be enough. The high slider positions aren't useful for
playing the game, only for screenshots and AI Auto Play. For the low and medium
slider positions, I want to keep the 1:1 relation between slider percentage and actual
FoV value so that players who have their favorite FoV value memorized don't need to
adjust.
Tbd. I've tried to work around the slider precision problem in CvMainInterface.
handleInput. It might work if one could distinguish between the user hovering over
the slider and dragging the slider; but I see no practical way to do that. Anyway, I've
left some comments in the code. I think PlatyUI uses +/- buttons instead of a slider.
That's probably the better solution.
262
Don't want to reveal the entire score history on the first meeting though.
The 5-turn restriction is supposed to avoid a very short visible interval that would be
barely noticeable.
Partial graphs disabled by default because they're not useful enough to risk confusing
players.
See also Screenshot of some partial score graphs attached to this CFC post
092 The size of most HUD widgets increases with the rendering resolution
Rationale HD displays
AdvCiv BtS
When playing at a rendering resolution greater The panel at the bottom will always cover the
than 1024x768, most widgets (buttons, panels, distance between the info pane on the lower left
tables) of the main screen and city screen HUD and the big flag button on the lower right, i.e. the
increase moderately in size. Spaces between width of that bottom panel scales with the
widgets also become a little larger on higher horizontal resolution. Similarly, the width of the
resolutions. panels at the top of the screen scale with the
horizontal resolution, and the height of the side
panels on the city screen scales with the vertical
resolution. Apart from that, all the extra space
available on high resolutions gets used for the
main map at the center of the screen.
The plot indicator bubbles are arguably also part
of the HUD; their size increases with the
rendering resolution, probably based on the
screen height as the smaller aspect.
Config Can be disabled on the General tab of the BUG menu. Layout changes to the list of
city resources will apply even if the HUD scaling option is disabled.
Rationale People sit farther away from larger screens and then it becomes difficult to make out
small widgets. Some parts of the HUD were also pretty crammed. It's nice to see a
large excerpt of the map on the main screen, but sacrificing a little bit of that space for
less eye strain is a good trade. On the city screen, showing a large portion of the main
map isn't really helpful, perhaps even distracting. Better to make the side panels
wider, affording more space to the building, trade route and resource lists.
See also Through the UI theme, 002b increases the size of all text except for text in the game
text font (e.g. city names, text on progress bars). HUD scaling further increases the
size of some particular bits of text on the city screen, namely in the trade route,
building and resource lists.
See 092b below about the size of the plot indicators (resources, units). Those
indicators are placed by the EXE.
004m adjusts the camera distance on the city screen to the field-of-view value (which,
by default, scales with the screen resolution).
097 adds building icons to the list of city buildings. Without HUD scaling, this would
leave fairly little space for building names.
137 decreases the aspect ratio of the map grid. The scaling of the panels in the lower
left and right corner is done with the modified aspect ratio in mind, i.e. the panels are
a bit higher than what would be ideal for the BtS map grids.
263
Request for a bigger minimap on CFC (6th quote box). Another post, not aimed at
AdvCiv specifically, asking for a bigger minimap. Kjotleik has (greatly) enlarged the
minimap without touching the unit pane: CFC post (with screenshot; code attached)
Suggestions on CFC to adopt changes to the city screen from the History Rewritten
(HR) mod. I did make the resource list and specialist area easier to read, but not in
the same way as HR, and I haven't adopted any HR code.
A little later than AdvCiv, a larger minimap has also, independently. been implemented
in Realism Invictus: SVN revision
Tbd. Wider help text area. I suspect that the line wrapping behavior implemented in the
EXE causes the width of the HelpTextArea widget to be limited. I doubt that there is
any easy workaround. The “We the People” mod has run into the same problem (Git
issue) and so has Realism Invictus (CFC post). One could still experiment a little with
the various parameters. A more promising approach is to replace the HelpTextArea
with a combination of other widgets. The PLE “info pane” (PLE.py) is already
implemented that way. (I'm guessing that this was implemented prior to the 1.61
patch, i.e. before the release of the DLL source.) The DLL would then have to pass
empty strings to the EXE when asked for hover text (CvDLLWidgetData.cpp), and,
instead, make a DLL-to-Python call that places the text in the PLE-style help text
area.
Implemented through a simple framework for Hundreds (thousands?) of magic constants
laying out rectangular shapes and some throughout CvMainInterface.py that specify the
functions that scale distances according to the position and size of all widgets in absolute terms,
resolution. This makes it easy e.g. to place the e.g.
GP bar centered horizontally inside the city screen.addStackedBarGFC("GreatPeopleBar",
screen's right side panel with a small amount of xResolution - 246, yResolution - 180,
194, iStackBarHeight,
space to the sides that will increase a little on InfoBarTypes.NUM_INFOBAR_TYPES,
higher resolutions: WidgetTypes.WIDGET_HELP_GREAT_PEOPLE, -1, -1)
# Helper column inside the right side panel
gSetRect("CityRightPanelContents",
"CityRightPanel",
RectLayout.CENTER,
# Place below the organization area
# (city religions, corporations)
gRect("CityOrgArea").yBottom() + VSPACE(4),
-HSPACE(9), # horizontal margins
# Column extends down to the corner panel
gRect("LowerRightCornerPanel").y()
- gRect("LowerRightCorner").y() + 4)
gSetRect("GreatPeopleBar",
"CityRightPanelContents",
# Align at the bottom of the column
0, RectLayout.BOTTOM,
# GP bar takes up the full width of the column
RectLayout.MAX, self.stackBarDefaultHeight())
# … (Can do the above long in advance of
# adding any widgets)
# Will look up rectangular layout data
self.addStackedBar("GreatPeopleBar",
WidgetTypes.WIDGET_HELP_GREAT_PEOPLE)
264
widget (by guessing its name?) and move it (assuming that it's already present before
getting opened, i.e. just hidden). Well, no, it's apparently a CyGTabCtrl, and that
seems to be a top level thing (cf. CvOptionsScreen). Maybe I could debug the EXE
after a call to CvDLLInterfaceIFaceBase::showTurnLog, see if I can locate the
hardcoded position. It should be ca. 92, more likely stored as an integer than as a
floating-point value.
The log will remember its last position and can therefore be moved manually by the
player, but, personally, I like it to be always in the same place and not in some slightly
random place where I've dragged it.
I've squeezed some elements on the top left together (guarded by bScaleHUD checks
in three code locations) and, on screen height 1200 or less, it just works out without
the culture slider intersecting with the log, but I don't think it'll quite work for screens
higher than that., and, if the espionage slider isn't hidden (change 120c), then that will
always intersect with the log. That problem had been introduced by BtS (and could've
easily been fixed by the BtS devs).
092b Scaling of “plot indicators” (icon “bubbles”; I call them “balloons” in help text)
AdvCiv BtS
By default, the size of the plot indicators The size increases roughly in proportion to the
increases only slightly with the screen height, screen height and also slightly with the field of
field-of-view value and camera distance. This is view and camera distance. Width might also
implemented through a runtime patch, matter; the precise mechanism is unknown. This
specifically, by overwriting the operands of a few behavior and the base size are hardcoded in the
binary instructions in the EXE in the code section EXE.
of the process's virtual address space.
Config Options on the Map tab of the BUG menu for restoring the BtS behavior or for setting a
particular diameter in pixels. About the default setting (“automatic”), note that, when
changing the field-of-view value, the plot indicator size won't immediately be adjusted;
will have to toggle the resource or unit display off an on to update the size in that case.
Rationale Ideally, in my estimation, the plot indicators should have a diameter of about one
quarter of the side length of a plot. A plot indicator considerably larger than that will
appear enormous and may block up information, and a plot indicator that is many
times smaller than its plot will look tiny (less of a problem, so long as the icon can still
be made out). My adjustments seem to have this result, by and large. This is difficult to
gets one's head around logically as field of view, resolution, camera distance and the
player's distance from the screen all correlate with each other.
I'm not sure if the plot indicator size should change when zooming in and out. If so, it
should become bigger when zooming in, not smaller, but this can't really be changed.
(Re-applying the runtime patch each time that the zoom level changes seems like a
bad idea.)
265
See also CFC thread about the runtime patch technique.
I've posted several times before about the plot indicator size, usually in response to
some inquiry about decreasing it; most recently here.
This thread makes me hopeful that localized editions of BtS use the same EXE as the
MULTI5 (EFIGS) Complete Edition.
This post by a Linux user seems to confirm that the runtime patch works on
(presumably) Wine.
Other parts of the HUD being resized by change 092 had made the oversized plot
indicators even more jarring.
See 004m about the field-of-view value. And that change also makes guesses about
the player's typical camera distance.
The implementation is based on 061, which informs the DLL of the screen resolution.
Tbd. It is not yet clear how compatible this change is with various operating systems,
compatibility layers, virus scanners and, possibly, variants of the EXE. Will just have to
wait for error reports. So far, the feedback has been encouraging.
When deciding whether to draw plot indicators near the upper or lower edge of the
screen, the EXE seems to assume that certain areas are covered up by the HUD. Due
to change 092, those assumptions no longer hold true. It doesn't really hurt to let the
plot indicators overlap with the semi transparent HUD, but, if one pays close attention,
it's clear that it's not quite working as intended. Could try to search the EXE for those
spurious coordinates (FP32-encoded?); for example, the plot indicators disappear at a
distance of ca. 163 pixels from the bottom. Long shot.
266
imminent). I've tried yellow, and coloring only some words; didn't like that either. Not
going to invest more effort for now.
Not sure if production decay could simply be disabled and this option removed. In
theory, players could keep a small army in their production queue to avoid unit
expenses and (in multiplayer I guess) to hide their strength.
096 Tech tree reflects the current game state (to an extent)
Tech help text on the tech tree takes into account the active player's context for unknown techs.
Will e.g. not list the free Great Artist from Music if another civ has already discovered Music. This
change does not hide any ability icons in the tech boxes.
See also I've posted about this on CFC here and here (items 1 and 2).
Show tech-religion icons on the tech tree. Tech-religion icons (tiny religion icon
superimposed on the icon of the tech that founds
(Don't do this after all. I've commented the code
the religion) are shown in choose-tech popups
out.)
and on the main interface (when no research is
chosen), but not on the tech tree.
Rationale I wanted to show the icons so that players can tell more easily which techs will still
grant a religion when playing with the Choose Religions option. However, the tech-
religion icons are difficult to make out on the tech tree (smaller icons there than on the
main interface) and, currently, the whole tech tree has to be redrawn when an icon
has changed since the last time that the tech tree was opened, and this results in a
noticeable delay. Not quite worth it I think. One can still tell through hover text on the
tech tree (see above) whether a tech will found a religion.
267
097 Building icons in list of city buildings
AdvCiv BtS
To the left of each building's name, the building's Buildings are only listed by name.
icon is shown.
Config Can be disabled on the City tab of the BUG menu. There's also an option for showing
only an icon (no name), which might be helpful when playing in a small window (for
whatever reason – emulator on a portable device?).
See also 092 (HUD scaling) makes the building list wider and may, depending on the screen
resolution, increase the icon and font size in the building list.
Rationale I think experienced players can identify buildings faster from the icons. Apart from the
Palace (which has 4 different effects to be displayed in the city list), available space
isn't really an issue, even at the original size of the building list.
Tbd. Sort the buildings in a sensible order. The current order, by ID, i.e. as listed in XML,
isn't that bad – players are used to it, it groups buildings with similar functions together
and is somewhat chronological overall –, so some thought would have to be put into
how to improve it. I've left two rather naive attempts commented out in the code:
sorting by production cost (too different from the original order, doesn't reliably keep
wonders grouped together), and by construction year. The latter results in an order that
varies from city to city, which isn't desirable I think. It would be nice to have through a
toggle button.
I suppose free buildings (e.g. Monument from Stonehenge) should be at the top, then
Palace (as a quasi-free building? along with all national wonders? along with all
government centers?), other wonders at the end. Apart from these constraints,
perhaps chronological based on the research cost of the most expensive tech
requirement. That said, having e.g. Library and University listed right next to each
other is nice too, makes the effects column look less busy. So perhaps rather sort by
the (main) type of effect, with tech requirement (or, for simplicity, just building
production cost) as the secondary criterion. One might just reorder the XML file
manually, but that'll lead to problems with savegame compatibility.
The same order should then also be used by change 086 for the city bar help text.
Currently sorted alphabetically. Displaying the buildings as a wrapping horizontal list of
just fairly large icons (and no effects) could also be a nice option to have for the city
screen. Might be the easiest to process for experienced players. Well, again, being
able to change the display method directly on the city screen would be best – but will
take some extra implementation effort.
Credits Based on the implementation in the BAT mod. (It's really just a few lines of code
because the table widget in BtS already has an option for including a DDS graphic.)
BAT also marks free buildings with a plus symbol, but I find that too obscure (maybe if
an explanation could be added through hover text?).
The names of obsolete buildings are grayed out No indication in the building list whether a
in the building list. building is obsolete.
Config Not optional. The gray is pretty light (i.e. doesn't stand out very much from the white
default text color), I don#t think this change will bother anyone.
See also 004w lets hover text say when a building is obsolete.
268
A city can spread tile culture onto another In BtS, cities spread tile culture only within a
landmass only at a range of one tile beyond the radius equal to their culture level, i.e. to tiles
city's culture level. Within the same landmass within the city's culture range. K-Mod has
the range is equal to the culture level plus 3 as extended the tile spread range by 3 tiles beyond
in K-Mod. On water, culture can spread only the (proper) culture range in order to allow a
onto workable tiles as in K-Mod and BtS. higher number of cities to participate in culture
“wars” over contested tiles. In both BtS and
K-Mod, a city can spread culture only to tiles that
are within the workable range (2 tiles) from some
tile on the same landmass as the city. This
means, tiles within the culture range of a city can
remain neutral because tile ownership requires at
least 1 point of tile culture.
Rationale To prevent puzzling situations like this (A, B - cities of the same owner, L - a non-city
land tile, W - a water tile):
ALL
WWW
WWW
LLLWLLB
None of the land tiles on the bottom are workable from the area of A. The bolded land
tile is workable from the area of B and, under the K-Mod rule, B only needs culture
level 1 (“poor”, 0-9 city culture) in order to spread culture to that land tile. The result is
an owned tile that has only one adjacent owned tile (the water tile to the northwest)
and that has two unowned tiles between itself and the borders around B.
Under the AdvCiv rule, the bolded land tile will be unowned.
See also Doing away with the “only spread onto workable water tiles” rule could make surprise
attacks against large coastal cities more difficult (see 162). That said, having
ownership of water tiles that are positively non-workable could be confusing, and I
think the BtS rule reflects international law pretty well.
099f prevents culture spread onto unowned tiles.
025: Reduced culture spread from vassal to master
Increased the base rate of culture spread (“free city culture”) a little bit (from 4 in K-Mod to 5),
making culture spread from buildings a little less important.
Config I've put the CITY_FREE_CULTURE_GROWTH_FACTOR global define
(GlobalDefines_advc.xml) back in use, albeit with different semantics than in BtS
because culture spread works very differently in K-Mod.
Rationale One measure for preventing culture rates from buildings, especially wonders, from
being overwhelming in the early game – now that I've reverted most of the K-Mod
changes to building culture.
See also 200, 201: Changes to building culture rates.
099b: Tile culture decay – and expedited decay on “stolen” workable tiles – should
also (and probably more so than the base culture rate tweak) help rein in culture
spread from wonders.
AdvCiv BtS
Once a wonder is obsolete, its culture rate 1000 years after a building has been constructed,
doubles. Building culture rates do not double its culture rate gets doubled. This rule is, as far
after 1000 years. Disabled by default; instead as I can tell, entirely undocumented. The UI also
added a loading screen hint about the BtS rule. doesn't show the construction dates anywhere.
Rationale Disabled this again after a quick test because this change reduces the contribution
269
that wonders can make toward a Culture victory too much – wonders that never go
obsolete, that is. Would have to accompany this change with large culture increases
for Medieval wonders and would have to set obsoletion techs for most wonders.
The original idea was to make the rule less obscure and more transparent, and to
make an early commitment to a Culture victory less decisive.
Config Can be enabled in GlobalDefines_advc.xml through
DOUBLE_OBSOLETE_BUILDING_COMMERCE.
See also Some other disabled rule changes are collected under change id 500.
No culture spread from cities during anarchy. Occupation sets a city to “no culture level”, which
also blocks culture spread. I don't think anarchy
prevents culture spread.
Rationale Seems more consistent with the idea of anarchy halting economies. E.g. Cottages also
don't grow during anarchy.
270
See also Chapter about "Immortal Culture"
130w adds a diplo penalty for cities with high foreign culture.
099b Tile culture decays
Each round, the culture value of each player (civsTile culture doesn't decay. (But it's treated as 0
and Barbarians) in each tile is decreased by when a civ is eliminated.)
1.3%.
When a tile is within the city radius of at least one
civ, the tile culture of civs that don't have the tile
within a city radius decays faster: if the tile is
within the outer ring of any city radius, 2.3
percentage points are added to the decay rate,
and 4.6 percentage points if it's within the inner
ring of any city radius. Exception: civs with less
culture in the tile than the city owner with the
highest culture don't suffer from expedited decay.
(This change does not affect city culture.)
Rationale Should lead to fewer unworkable tiles (see also the rationale for 035) – especially with
K-Mod's increased range of culture spread in mind – and fewer issues with stranded AI
stacks (see also rationale for 034). Higher decay rates would accomplish more, but I
don't want tiles to flip too easily around conquered cities. That said, in BtS, it's too
difficult to culture-flip tiles in the radius of a conquered city, especially in Renaissance
or later; tiles have tens of thousands of culture points by then. It generally takes too
long for city culture rate to translate into relative tile culture in BtS.
Why not simply tweak the culture spread formula so that tiles near cities receive more
culture? The player only sees the culture percentages, so, visually, it doesn't make a
difference. I don't want to increase culture on tiles that are near multiple cities of the
same civ lest that "two cities would almost always be able to culture press a solo city"
(from the K-Mod readme file). The main goal is to allow civs to work tiles in their
(exclusive) city radii. That's also why I'm exempting civs with less tile culture than the
city owner. It's fine if another civ has 45% tile culture so long as the 55% civ is able to
work the tile. The exemption also makes it easier to implement this change without a
performance penalty.
Config TILE_CULTURE_DECAY_PER_MILL and CITY_RADIUS_DECAY in
GlobalDefines_advc.xml
See also 201 restores most of the building culture rates that K-Mod had reduced. This change
was introduced with AdvCiv 1.0. At the same time I've increased the decay rates by 0.3
percentage points (originally, I had used 1%/2%/4%; adding half a percentage point to
that seemed too much in a test game) and one of several tweaks to compensate for
the building culture changes. Moreover, I had had the impression that mature
conquered cities were still taking a very long time to acculturate, and this CFC post
also argues (toward the end) that the decay is too slow.
035 (disabled): City owns all tiles that no other city could work
It turns out that "RoM: A New Dawn" also has a culture decay mechanism
(SourceForge link to revision), but theirs is only triggered every 50 turns and then
halves tile culture. For performance reasons I suppose; but I've managed to make the
computing time negligibly short in my implementation after some tweaking.
Impassable tiles are exempt from expedited decay.
Rationale Doesn't matter who owns those tiles, but perhaps such tiles can be useful for
visualizing which civ is culturally dominant.
271
Cities in occupation spread no tile culture. Cities in occupation produce 0 city culture, but
the present city culture generates tile culture as
normal.
Rationale This should give civs that allow their cities to revolt a harder time.
No increased decay in city tiles, nor in tiles owned by Barbarians. And increased impact of stolen
tiles in the inner radius of Barbarian cities on revolt chance.
Rationale Don't care if Barbarians are able to work tiles. Rather give those tiles to civs with
strong culture. Also increase the revolt chance then so that engulfed Barbarian cities
get put out of their misery before long.
Culture in city tiles doesn't affect which tiles are workable. The increased decay would
make revolts and anger from foreign culture easier to handle, which isn't what I want.
The exception for city tiles can lead to higher culture percentages of the city owner in
tiles surrounding the city than in the city tile. This is a bit odd, but not a real problem I
hope.
099c Cities revolt regardless of culture range
See also 210b adds an alert about positive revolt probabilities
Any city with sufficiently strong foreign culture Foreign culture can only cause a city to revolt if
can revolt, but the revolt can only flip the city if the owner of that culture is alive and has a city
the owner of the foreign culture is alive and has a nearby, i.e. close enough so that the first city is
city nearby. (And can't flip if flipping is disabled in within the culture range (based on culture level)
game options.) of the second city.
Made some adjustments to AI willingness to
accept capitulation vs. trying to capture further
cities.
Rationale To remove another incentive for eliminating civs, to make conquests more costly and
culture more relevant.
Resurrecting a prior owner seems needlessly messy; the probabilistic occupation
times (change 023) should make revolts from dead culture painful enough. Joining the
Barbarian civ would be easy – but strange, I think, because the city would then train
units based on the Barbarian tech level.
Not sure if cities with high living foreign culture but outside of foreign culture range
should be allowed to flip. Let's say the rebels only dare joining the homeland if the
homeland is near enough to protect them.
Config Can (largely) restore BtS behavior through REVOLTS_IGNORE_CULTURE_RANGE in
GlobalDefines_advc.xml.
Barbarian culture can cause cities to revolt. They Essentially the same, but Barbarian cities have
can't flip to Barbarian control though, and practically never enough culture range to cause
Barbarian culture strength is only counted half in another city to revolt.
surrounding tiles.
Culture in tiles adjacent to the city always
contributes to the foreign culture strength, and,
ultimately, the revolt chance.
Cities can't flip from a master to its vassal; only
go into occupation. Increased strength of foreign Can flip between vassal and master. No way then
culture in cities of capitulated vassals. for the master to get the city back.
Rationale Not sure about this. Seems more flavorful/ historical to let conquered Barbarians
revolt. Might play better without these revolts; players don't expect them, and
conquering Barbarians should be easier than conquering civs. Then again, Barbarians
don't generate much culture, so it doesn't take much effort to suppress them, at least
272
not when the surrounding tiles don't count. Could say that only counting the city tile
models the (political) disunity of the Barbarians.
Could easily implement flipping to Barbarian control. Historically, that hasn't really
happened; see the list of colonial uprisings here (Wikipedia). More accurately modeled
as a period of unrest.
Flipping from master to vassal could incentivize elimination over capitulation. Also, I
find it ultimately more annoying than challenging.
Config BARBS_REVOLT switch in GlobalDefines_advc.xml
See also 025 reduces culture spread from capitulated vassals
If a city can't flip on the third revolt (because the No extra penalty if flipping isn't possible;
cultural owner is dead or flipping disabled in occupation periods just keep getting longer.
options), it loses one population instead (and
goes into occupation).
Rationale To discourage players from ignoring revolt probabilities (the lost turns don't become
punishing until numerous revolts have taken place). And it would be strange if cities
could just keep revolting. The loss of population reduces the revolt probability so that
the city should eventually end up depopulated but pacified.
Extra AI defenders in cities that might revolt. No code for this at all. The AI tends to put units in
Some of these come from the floating defender border cities though, against external threats.
pool. The AI also trains some more floating
defenders when struggling with foreign culture.
When too many defenders would be necessary
(based on city population and era), the AI will not
assign any extra defenders and essentially wait
for the city to flip.
Rationale Since revolts no longer occur only in border cities, the AI had to be adjusted.
See also advc.ctr: The AI for city trades might cede cities under foreign culture pressure. (Not
yet sure how that will work.)
273
099e AI for promotions that reduce revolt chance
AdvCiv Warlords
The AI ignores revolt protection when selecting A promotion with revolt protection is chosen
promotions and when moving units. based on whether the cultural owner of the
current tile differs from the actual owner.
When moving units, revolt protection is ignored.
Revolt protection from promotions was added in
Warlords but remained unused. K-Mod gave the
Leadership promotion 50% revolt protection.
Rationale Too much work to do this properly (see Tbd. below). What Warlords does is worse
than nothing.
Tbd. The promotion should be selected based on the revolt chance in a nearby city, the
number of units already stationed there and the revolt protection percentage. When
there is a city with a high revolt chance, a unit with revolt protection should be given a
defensive Unit AI type and stationed in that city.
274
was always possible to hold down the Shift key while hovering over a visible tile in
order to show the culture percentage. All that code still exists and is tagged with
“advc.099f” – it's only commented out.
275
screen. war as part of a peace treaty.
Rationale Shouldn't show the option if the AI practically always refuses, and Cautious attitude
despite war is an oddity that shouldn't matter. Could instead remove the attitude
checks while at war. Seems more realistic that such options can't be discussed.
Would also take a bit of implementation work because the the war trade should be
evaluated assuming that the peace treaty is already signed.
100b Brokered peace shown in replays
Brokered peace is shown in the replay log Replay log only says "has made peace with".
("brokered by ...").
276
The culture garrison strength (CGS) of a unit CGS values are set in XML (iCultureGarrison)
equals its current combat strength with the to e.g. 3 for Warrior, 4 for Archer, 6 for Maceman,
following modifiers: 9 for Rifleman, 12 fopr Tank. The total garrison
• City defense modifiers (Archery units, Garrison strength of a city is the sum of these values.
promotions)
• Generic strength modifiers (Combat
promotions) E.g. Catapult has iCultureGarrison 4, same as
• -50% for non-lethal units (Siege units except Axeman; Machine Gun 9, same as Rifleman.
Machine Gun)
The iCultureGarrison values in XML are
ignored except that iCultureGarrison=0 in
XML still means 0 CGS. All non-land units have 0
CGS (as in BtS).
Hover text on the main map and city screen Hovering on the nationality bar shows the revolt
(nationality bar) says how much more garrison probability; other than that, no help text.
strength is needed to bring the revolt chance
down to 0, or, if it's already 0, how many units
could be safely relocated.
See also 023 reduces the CGS of damaged units.
500b (disabled by default) introduces a defensive strength (DS) value that determines
whether citizens fear for their safety. It seems that using the exact same formula for
CGS and DS wouldn't work well. In particular, while some effect of Walls and Castle
on CGS is plausible, they shouldn't be a major factor (cf. this CFC post of mine).
Rationale It's mainly about the help text. Players will often want to station exactly as many units
as necessary to bring the revolt probability down to 0. By making CGS nearly equal to
combat strength, players don't need to be aware of the values set in XML. The BtS
XML values also increase too slowly over the course of the game. This makes
outdated units too useful for revolt suppression. Combat strength increases too
steeply throughout the game compared with foreign culture strength. I'm balancing
that out through a change to the foreign culture strength formula (see above). That
formula is now very complicated (see also below; referred to as “revolt strength”
there), but it was already fairly complicated in BtS, and the crucial thing is that CGS
has a simple, predictable effect so that players know how many units they need in
each city.
As for the Siege modifier, siege units just seem badly suited for quelling revolts. It's
asymmetrical warfare.
Credits Elkad and VDNKh have asked for help text to be added (CFC link).
Tbd. Currently, the main map doesn't show how much CGS is needed while a city is in
occupation; perhaps that should be changed.
Should perhaps explicitly show the effect of revolt protection (Leadership promotion)
in the hover text of the nationality bar. Perhaps wait with this until I add revolt
protection to Jail.
Armored units having the highest CGS values is perhaps a bit counterintuitive (and
makes them even more powerful). There are historical examples of tanks being
effective at suppressing revolt though ...
Consider giving Spy a positive CGS, possibly also recon units. Espionage should
somehow help against revolts. ("Spread Culture" does in K-Mod, but needs to happen
before conquering the city, which requires some foresight.)
277
Config I've written code for a partial breakdown of the revolt probability but didn't find it
helpful enough in the end. The code is commented out in
CvDLLWidgetData::parseNationalityHelp.
Revolt chance is adjusted to game speed (e.g. Through the victory delay modifier; e.g. divided
revolt chance divided by 125% on Epic speed). by 150% on Epic speed. BtS didn't have any
speed adjustment.
Config New modifier in Civ4GameSpeedInfos.xml – with the same values as the Golden Age
modifier.
Rationale Culture spread is arguably the most important factor for revolt supression, and game
speed has no impact on culture spread.
Foreign culture strength increases with the ratio Increases with the game era. And the game era
of techs known to the cultural owner (even if that only affects the culture strength counted for
player has been defeated). Over time, that ratio surrounding tiles, not the culture strength from
shifts toward the maximum of the owner's and city population.
cultural owner's known-tech ratio. The ratio gets
quantized to a number between 0 and 10.
Rationale This era modifier is pretty noticeable, so plausibility matters. Involvement of third
parties (game era) isn't really plausible: if the city owner hasn't been able to acquire
their tech, why should the insurgents be able to. The one civ that would be likely to
deliberately support the insurgents is the cultural owner itself.
Using the tech era of the city owner is undesirable because it could discourage that
player from reaching a new era. Era numbers are also a bit too coarse. However, a
smooth increase of revolt probabilities would be even worse because it would
encourage players to make slight changes to city garrisons all the time.
Using only the tech of the cultural owner would encourage the city owner to defeat or
stifle the cultural owner. A slight incentive for that is probably a good thing, but I don't
want it to matter much most of the time.
See also CFC post (last spoiler box) observing that foreign culture strength can't keep up with
late-game garrisons. That was when the tech of the cutural owner had only affected
the culture strength counted for surrounding tiles (as in BtS). And I#ve made some
other tweaks in response to that post.
AdvCiv BtS
Revolt strength is reduced based on the highest Only tile culture of nearby civs matters. The 10%
city tile culture of any civ, even if that civ doesn't in the example would lead to a high revolt
have a nearby city. For example, when the probability because it's much more than the
owner of a city has almost no culture, say, 1%, owner's 1%.
and the only other nearby civ has some culture
but also not much, say 10%, the revolt
probability is low or zero.
Rationale Don't want to reward civs for just 10% (or so) culture, especially not uninvolved parties
in wars. Also implausible that the 10% would find sufficient support for a revolt.
See also A somewhat common issue because of 099 (culture of dead civs sticks around).
278
Revolt strength reduced if foreign tile culture isn't Revolt strength is increased by up to 100% if
far higher than owner's tile culture. E.g. if foreign owner's tile culture is small, but high owner's
tile culture is just 25% greater than owner's culture can't reduce the base strength from
culture, revolt strength is reduced to 25%. population and surrounding tiles.
This makes revolts easy to suppress with one or Cities with up to 49% tile culture of the owner can
a couple of units when the owner's tile culture is still have a high revolt chance.
close to the foreign tile culture.
Rationale Counterintuitive that a city could easily flip at nearly 50-50 tile culture. The change
rewards the owner for building up culture, even if the owner hasn't (yet) reached
parity.
City flipping after conquest enabled by default. The option is called "City flipping after conquest"
(Actually, flipped the option to "No city flipping and disabled by default.
after conquest" and kept it disabled by default.)
Rationale Part of my efforts to weaken military strategies. I want to build on the revolt
mechanism, so it should be (fully) enabled by default.
When a city flips while at war, the garrison is The garrison is killed. Bumping only happens
bumped (moved to the nearest legal tile). Only when flipping at peace-time.
Barbarian garrisons are killed.
Rationale Killing a stack of units is pretty outlandish. Bumping Barbarians would be unusual, and
killing them is less problematic wrt. game balance. I guess they just lay down their
arms.
Credits The issue had been pointed out (and narrowed down) by DarkLunaPhantom here.
Added the number of prior revolts to the Help text only shows the revolt probability.
Nationality help text, and whether the city will flip
on the next revolt.
All civs that know a city are notified about a Only the actual owner and the cultural owner are
revolt. notified.
Revolt probability (if > 0) shown on the main map Need to enter city screen to see revolt
as part of the city tile help text. probability; no way to see revolt probability of a
foreign city.
Config Option on the BUG menu (Map tab) to show the revolt probability in the city bar hover
text instead.
See also Help text for air unit capacity (187) is similar to revolt probability insofar that BUG
show that information in the city bar hover text (and AdvCiv moves it to the tile hover
text by default).
advc.ctr shows revolt probabilities on the (non-BUG) Domestic Advisor screen.
MNAI shows a projection of the number of turns until 50% nationality is reached in
help text (Git commit). Might be helpful(?); not so easy to compute in AdvCiv because
of tile culture decay (099b).
Rationale Revolt probability in visible foreign cities shouldn't be secret – all factors are public
knowledge.
City-related information normally belong into the city bar hover text – the tile hover
text doesn't even say whether a city exists in the tile. However, for deciding whether
culture garrisons can be moved out of the city, it's more convenient to have the revolt
info in the tile hover text along with unit info. One can argue that the revolt info isn't
strictly city-related because it includes info about culture garrison strength, which is
unit-related.
279
A fist icon can be shown above the billboards of The fist icon is shown above the billboards of
cities where the revolt probability is positive. The cities under occupation, along with an occupation
icon is then still shown (along with a countdown) countdown. No billboard icon for positive revolt
above the billboards of cities under occupation, probability.
even if those cities have a revolt probability of 0.
Config Option on the BUG menu (Map tab); disabled by default.
See also 002f deals with other billboard indicators.
Rationale Seems useful, but clashes with the occupation indicator, and I can't think of a different
– self-explanatory – icon for positive revolt chance. A yellow fist would make sense,
but the icon is very tiny, so a different color will probably make it difficult to recognize
as a familiar icon.
Revolt probability is initially based on the current Always based on the highest-ever population of
population of the city. If the city has ever had a the city.
higher population than currently, then, over the
course of 37 turns (slightly longer or shorter on
speed settings other than Normal), a gradually
higher population is assumed, up to a maximum
of the highest population ever. Then the assumed
population decreases again toward the actual
population.
Culture in the eight adjacent tiles factors into Ownership of the adjacent tiles always counts,
foreign culture strength; the effect increases over and can increase culture strength significantly.
time (same mechanism as above for population). Culture points in those tiles don't count directly.
After 50 turns (on Normal speed), culture
strength is further increased when adjacent tiles
are owned by the foreign civ.
Each citizen angry about sacrificed population Sacrificing population doesn't lead to a lower
(“we cannot forget your cruel oppression”), is revolt chance because only the highest-ever
counted as 2.5 population (instead of just 1) and population matters for that. It can get rid of 2
the resulting foreign culture strength is increased citizens angry about foreign culture for the price
by a modifier based on the square root of the of 1 being angry about oppression.
oppression anger and speed-adjusted; e.g. 50%
for one angry citizen on Normal speed. The AI
doesn't use Slavery in cities that already have a
positive revolt chance.
280
Rationale I think the BtS rules are supposed to make cities flip faster once the adjacent tiles
have flipped. Loss of tiles will often lead to population loss, which would normally
reduce culture strength. Also wouldn't want to outright punish players for growing
population in conquered cities and certainly don't want them to starve the population
on purpose. (My guess as to the original intention behind ignoring the current
population is that the designer saw it primarily from the perspective of a player trying
to flip a border city – don't want culture strength to decrease as as food production
tiles around the city flip.) However, eventually, when a city stays at a small population
count, it's revolt chance should decrease accordingly, and using the highest-ever
population directly after conquest contributes to the problem of a scarily high initial
revolt probability. Hence the sawtooth curve.
I agree that cities enveloped by foreign culture should flip quickly, but I don't want
conquered cities to be untenable, and I don't want players to feel compelled to
continue their wars in order to push back foreign borders. My rules are supposed to
give the conqueror time to build up some culture.
Slavery would be an easy way to get around anger from foreign culture, and to keep
the population small, making the city easier to pacify. Also, Slavery could be used to
raise units for revolt suppression in the very city that needs to be suppressed.
Prior to AdvCiv 0.97, hurry anger (regardless of the number of angry citizens) had
caused the population to be treated as 5 greater and there was no speed adjustment.
(Note that anger duration is e.g. three times longer on Marathon than on Normal
speed.) That turned out to be too punishing (and too implausible). Slavery should
should be an option for urgent production orders, in particular Courthouses.
That's all overly – and really unacceptably – complicated (already in BtS). It's OK for
now; players don't really need to know the details. But eventually this should be
greatly simplified.
See also If 035 is enabled, it's cultural ownership (highest tile culture that matters for the revolt
chance after 50 turns.
912d nerfs Slavery a little and allows it to be disabled.
CFC post (response to Elkad) about the effect of hurry anger.
Tbd. Maybe the penalty for using Slavery is now a bit too small. Losing one or even
multiple citizens lowers the revolt chance substantially in small cities; the increased
anger can't always (over-)compensate for that.
Should population growth increase the city owner's city tile culture? A supressed
population would typically not grow as fast as its supressors … However, this could
encourage sacrificing or starving the city population.
Hover text for the nationality bar shows when sacrificed population increases foreign culture
strength.
Rationale Players who normally use Slavery all the time are unlikely to notice that revolt chance
is lower without hurry anger; need some UI support for this. Ideally, players should be
aware before sacrificing population, but I don't think they'd necessarily read hover text
for the hurry button. They'll likely inspect the nationality bar though (sooner or later)
when cities have much higher revolt probabilities than in BtS.
I'm not showing how much hurry and conscript anger add to foreign culture strength.
Culture strength isn't really part of the UI's vocabulary, so it would have to be
expressed as additionally required garrison strength. In any case, it's awkward to
implement and that time would be better spent re-designing the culture strength
formula or replacing Slavery.
281
Barbarian cities flip on the second revolt. After a Flip on the first revolt. No protection after
city is conquered or founded by Barbarians, it conquest except that no revolt can occur under
has has 0 revolt probability for 8 turns (adjusted occupation (and cities can generally only revolt
to game speed through the Golden Age modifier).when within the culture range of the city's cultural
Barbarian units can suppress revolts just like owner). Barbarian units have 0 culture garrison
non-Barbarian units. strength (but this doesn't affect the occupation
timer).
Rationale Given the increased revolt probabilities in K-Mod and AdvCiv and the removal of the
range restriction for revolts (099c), a single Barbarian revolt happens (way) too
quickly. A holy city conquered by Barbarians in the early game would flip back in
something like 10 turns. Two revolts are still too quick, and, even for cities that can't
flip, it looks strange if they go into revolt so easily.
I've tried some other remedies (letting Barbarians eliminate some of the former
owner's tile culture upon conquest; increased chance for decreasing the occupation
timer in Barbarian cities), but a grace period seemed like the most effective approach
in tests since Barbarian conquests tend to happen in the early game when a
Barbarian city can quickly generate some tile culture if they're not interrupted by
revolts.
See also 023 changes to the occupation timer.
The revolt chance is increased on account of city Only a) increases the revolt chance, and also
religions if applies to capitulated vassals. Dead culture can't
cause revolts.
a) the civ to whom the revolt culture belongs is
alive, not a capitulated vassal of the city
owner, has a state religion and that religion in
present in the city; or
b) if the city owner has a state religion, and that
religion is not present in the city but some
other religion is.
In case b), the increase is only 2/3 of case a).
No change: The revolt chance is decreased
(which may cancel out the above) if the city
owner has a state religion, and that religion is
present in the city.
In case a), the revolt chance is also decreased When there is a non-state religion in the city, then
(but not by as much) if the city owner has no an oppressive state religion (which is not present
state religion. in the city) is no worse than no state religion.
AI city owner is slightly inclined to switch to the
religion of the foreign population.
Hover text on the nationality bar shows when, on
The UI shows only a revolt chance, no
balance, religion modifiers increase foreign
information about how it gets computed.
culture strength.
Rationale I almost removed this complicated stuff entirely, but it's kind of nice that spreading
one's state religion can help flip a city. The BtS rule doesn't work for dead culture, so I
felt that some replacement was needed to balance out the decreased revolt chance
from owner's state religion. The BtS rule also doesn't work well for capitulated vassals
of the city owner: The owner can just tell the vassal to switch to a different religion; not
an interesting decision, and players that aren't aware of the religion/revolt rules get
confused or screwed.
282
Reduced the religion-based modifiers (see Religion can double or halve foreign culture
above). Now at most +/-33% foreign culture strength.
strength
Rationale Spreading one's state religion had made a huge difference previously, going from
doubled to halved foreign culture strength, i.e. a factor of 4.
Config STATE_RELIGION_MODIFIER parameters in GlobalDefines_advc.
Patrolling units tend to move in a consistent Patrol movement is memoryless; narrow patters.
direction. Leads to wider patterns.
Rationale The patrols make "show enemy/friendly moves" unusable, and there isn't much of a
point. After all, borders grant visibility. I guess patrols add some uncertainty to small-
scale surprise attacks (can't be sure how many units exactly are going to be near a
city at a given time) and could help against nukes. Well, anti-nuke AI behavior needs
to be improved at a later point anyway.
Patrols in foreign borders make some AI visibility cheats less obvious, but that's not a
good enough reason. Patrols in unowned land can keep Barbarians away from the
AI's rivals; unowned land should only be patrolled if it's not too far away from the AI's
cities.
Tbd. I didn't disable inner-border patrols entirely because, in order to patrol unowned land,
AI units may have to traverse owned land. Moving in one direction for a longer time
also helps with that. That said, patrols in unowned land don't seem crucial either.
Against Barbarians, the guard-city-site AI routine is probably more effective.
The 10-tile distance check should perhaps also consider cities of (non-human)
teammates and vassals. Might not be worth the extra computing time though.
283
Moves of non-hostile Workers, Missionaries and All unit moves are shown.
Executives within their owners' cultural borders
are no longer shown when the "show friendly
moves" option is enabled. As for non-hostile
ships, moves of human ships and cargo ships
are always shown (except AI ships on patrol),
moves of other ships only when moving into
sight, out of sight or inside the borders of the
observing player.
Rationale These land moves are practically never interesting. For ships, it's a bit trickier
because a passing Caravel could matter (target for Privateer, or could be carrying a
Spy), but mustn't show patrolling Destroyers. Cargo units that can carry city attackers
need to be shown in any case.
By not showing moves of cargo ships on patrol, I'm giving away some info about the
intentions of the AI. That said, a lone cargo ship is practically always a patrol, and
patrolling AI Galleys are just too annoying to watch.
Config SHOW_FRIENDLY_WORKER_MOVES and SHOW_FRIENDLY_SEA_MOVES in
GlobalDefines_advc
Tbd. Could be an issue for enemy moves as well when there is city visibility from
espionage. So, should perhaps apply the change to enemy moves too.
Related: Fixed a bug that caused AI non-combat units to oscillate between safe cities when at war. See
change 001.
(Also fixed in K-Mod 1.45, now using the K-Mod fix.)
"show friendly moves" can be toggled using Shift + M. If the option is toggled this way, the change won't be
visible in the Options menu, and won't be saved upon leaving the game.
(Disabled through a switch in GlobalDefines_advc.xml. Turned out I had never used this.)
No moves are shown when in Globe view. If the The camera jumps around, but the moving units
Unit layer is active in Globe view, then the layer aren't visible in Globe view. If the Unit layer is
colors and indicator positions are updated as enabled, the positions of the unit indicators are
foreign units move (without a delay and updated as foreign units move, but the layer
regardless of the show-moves options). colors aren't updated.
See also Requires 004m to be able to tell if the Unit layer is active.
284
See also Related CFC post (I haven't implemented a check for stack size in the starting tile.
Would make the option more complex, would lead to patrols passing by a large stack
to be shown on two subsequent turns, doesn't serve the primary purpose of helping
players spot incoming invasions.)
285
city owner.
Confusing: When inspecting a city that has just grown, the new citizen has no job at all
(not listed as a Citizen specialist either).
See also 120d: Mission cost for Sabotage Production no longer shown on the Espionage
screen. It had previously been possible to guess based on that cost whether a city was
close to completing a wonder.
001: Bugfix in CvPlayer::getUnitArtInfo that shows unit art on the city screen in
the owner's art style.
286
targets. There's a bullet toward the end of the WIP section about that.
Two more ideas:
Don't update distances for every one of our cities on every turn. Distances change
gradually through tiles being revealed, routes constructed, border expansion and other
factors – it should be OK to skip a city with, say, an 80% probability (adjusted to game
speed). Major changes in diplomacy should result in an immediate full update: Open
Borders, Vassal, Permanent Alliance, declaration of war. Only if we're directly involved
in one of those. Also: upon the discovery of certain technologies. A tech is discovered
every 4 turns or so, so doing it after every tech is undesirable.
Try parallelizing the distance computations. On that note, AI war evaluations (based on
the cached distances) could also be suitable for parallelization.
(This one no longer sounds promising now that pathfinding has become much faster.) Take advantage of
the triangle inequality: If we have computed a path distance from A to B and from B to C, we could use
that as an approximation of the distance from A to C if B is a non-hostile city, i.e. not owned by the
prospective war target or a current war enemy. One might first let a new class CityGraph compute a
sparse graph with edges chosen based on area id, air distance and city size. Edges between our own
cities will have to be allowed too. Graph updates: Local updates for changes that occur throughout a turn
and a full update when updating the UWAI cache: Go through all relevant pairs of friendly and potentially
hostile cities as before and make the graph compute a shortest distance using a standard graph algorithm
(Kruskal/ Prim or something to compute all shortest paths). Turn that shortest graph distance into
something slightly optimistic to account for direct paths being shorter than triangular ones.
287
more reliably on cities of rivals en route to a peaceful victory.
Rationale It's important that AI civs aiming at a military victory are able to pivot from war against
a nearby target to war against a remote target that is getting close to a peaceful
victory.
Tbd. Still no working very well I think. Part of the problem is that the militarily powerful civs
often have very acrimonious diplomatic relations with their neighbors and pretty
positive relations with remote rivals.
The per-continent AI target cities get updated K-Mod updates the best target city on each
when the enemy status of a rival changes. This continent only every few turns, presumably in
will also discard any target city of a vassal set by order to make AI offensives more focused.
its human master (“we'll do our best”).
Rationale Looks like an oversight. It doesn't make sense to cling to a target city whose owner is
no longer an enemy.
Unless the military power ratio is very much in Tile defense factors into the targeting decisions
favor of the attacker, the AI prefers to target cities of individual stacks, but is not a factor in
with low tile defense. AI_targetCityVal and thus not a factor for the
per-continent target cities of an AI civ.
Rationale While the per-continent target cities are only intended as intermediate targets, it still
doesn't make sense to target e.g. a city with a Castle when the power ratio is nearly
even.
See also cdtw.2 gives cities with very low defense extra weight as target cities when in the “Fast
Movers” AI strategy.
Unless the military power ratio is very much in In BtS/ K-Mod, AI_targetCityVal can't even tell
favor of the attacker, among potential target cities whether a city will have to be assaulted from the
that require a naval assault, the AI prefers to sea.
target continents with few enemy cities.
Rationale Should help the AI pick up lightly defended islands when an invasion of the enemy's
main continent isn't feasible.
Make the AI somewhat inclined to target cities Resources near potential target cities are
with strategic resources. evaluated, but only from the point of view of the
attacker.
Rationale Very coarse – better than nothing. There is no (non-cheating) AI code for evaluating a
resource from the point of view of another civ, and writing such code (and making it run
fast) would be too much work. Also difficult to predict whether conquering a city will
actually change ownership of nearby resource tiles; so I'm not even trying.
AdvCiv BBAI
Increased the impact of distance. Now probably BBAI had reduced the impact of distance so that
about the same as in BtS. (comment in the code) it “scales sensibly with
map size”.
Rationale The BtS formula was flawed (mainly when it came to naval attacks I think), but I don't
think the map size should matter. Even on the biggest maps, the AI shouldn't generally
target cities that are one or two dozen moves into enemy territory. (AI attack stacks will
opportunistically attack cities along the way, but it's still not a good idea to try and cut
deeply into enemy territory.)
104e Halved military power values of ships through the DLL.
Reduced military power (not combat str.) of Maceman from 9 to 8; Samurai at 9 (no
change), Berserker at 9 (was 10), Jaguar at 5 (was 6). Increased power of Infantry to
288
22 (was 20).
Rationale UWAI handles naval and land power separately, so the power of ships relative to land
units doesn't matter. But the K-Mod AI uses a single power rating, and, considering
that ships are only useful in certain situations, ships contribute too much power. Also,
even if UWAI is enabled, some strategic AI choices are based on a single power
rating, and the Statistics screen shows only one rating as well.
High power of Maceman makes UWAI overestimate Maceman when predicting military
build-up; appears as a better offensive unit than Grenadier. The bonus against melee
isn't that useful for this type of unit at that point of the game (whereas 7 power for
Crossbowman seems OK). UWAI (if enabled) increases the power values of all
offensive units that can receive city raider promotions; this gives Maceman another
boost.
The 25% bonus of Infantry vs. Gunpowder is very valuable, whereas Woodsman I
shouldn't be enough to bring Jaguar to the same power as Swordsman (which has 1
more strength). Montezuma is suicidal enough without overestimating his unique unit.
Config Civ4UnitInfos.xml
See also 131 also makes some changes to XML AI settings, e.g. the asset value of Infantry.
The BASE mod also halves the military power of ships (but I didn't get the idea from
there). 131c changes some power values of buildings.
104f More narrow conditions for Dagger strategy
No Dagger while in a chosen war; Dagger Having started a war doesn't affect Dagger.
disabled entirely when UWAI is enabled.
The Dagger strategy can overrule the "Get Better
Units" strategy; that's why the K-Mod AI can
make Archer rushes.
Rationale Staying in the Dagger strategy while at war doesn't make much of a difference for the
K-Mod AI, but it gets in the way of my UWAI testing (UWAI running in the background
while K-Mod decides).
The purpose of the Dagger strategy seems to have shifted from BAI to BBAI to K-Mod.
Here's the original description by Blake. The latest purpose was probably to build up
units without having a war plan, and thus also without giving away war preparations
through WHEOOHRN; then a sudden strike. UWAI solves this problem differently.
104g Don't demand tribute from unreachable civs (implemented based on UWAI code)
104h Moved the BtS and K-Mod code for negotiation of peace terms into a separate
function, and made some minor functional changes (that also take effect when UWAI
is disabled):
If the winning side doesn't have much interest in continuing the war, gold (and no tech)
is considered as reparations.
The choice of tech for reparations is less randomized and more based on matching the
target value for the reparations.
104i Refusal to talk (RTT) when at war. A new AI memory type,
MEMORY_DECLARED_WAR_RECENT is used for distinguishing a DoW at the request of a
third party or through a defensive pact (DP) or a vote from a normal DoW.
Config The MemoryDecayRand value of the new memory type determines the RTT duration in
wars on behalf of a third party. This value can be set through
Civ4LeaderHeadInfos.xml, and a default of 11 is hardcoded in the DLL
(CvLeaderHeadInfo::getMemoryDecayRand). That default value corresponds to an
expected RTT duration of 11 turns. (Though, as in BtS, war success and AI personality
289
can shorten the duration.)
Tbd. When the AI is already willing to talk according to the BtS rules, adding
DECLARED_WAR_RECENT memory has no effect. Thus, a civ could e.g. make peace with
the target of a force-war resolution right after the vote. Not sure what to do about this.
For a start, the turn on which a vote takes place or a war ally is brought in should be
remembered.
When a DP leads to a DoW, then declared-war-recent memory is added for all involved parties, not
just those that join the war through the DP. When peace is made between two civs, the civs
become willing to talk to the other side's DP allies.
Rationale Otherwise, the target of the original attack would be free to negotiate peace, while the
allies that declared war because of the DP would be forced to continue the war.
See also kekm.3 allows DP despite war
Tbd. War votes should arguably lead to a (10-turn?) period of forced war. The current code
based on AI memory can't enforce war between two human civs (or just for 1 turn).
When two civs make peace, all their declared-war-recent memory is set to 0, i.e. both become
willing to talk to everyone (unless war utility is too high).
Rationale Refusal to talk is a matter of fairness toward a third party (sponsor, DP ally, voting
members of the AP). When a war party bows out (possibly said third party itself), it's a
big enough change in circumstances to disregard any commitments for continuing the
war.
104j Change in a master AI's war plans affects war plans of its vassals. The unit stacks
decide where to invade first. Active even if UWAI is disabled, meaning that BBAI's
CvTeamAI::AI_isOkayVassalTarget function ("Block AI from declaring war on a
distant vassal if it shares an area with the master") no longer works.
Rationale With K-Mod's AI changes, I doubt that isOkayVassalTarget is really needed, whether
UWAI is enabled or not.
I'm not allowing unit stacks to anticipate wars triggered by Defensive Pacts (DP)
because diplo penalties need to be taken into account, so the strategic side of the AI
needs to choose the target for the declaration of war and the tactical side needs to
respect that decision.
See also 003b: It could be important for performance that CvTeam::getMasterTeam is
precomputed.
104k Moved rounding of trade values into an auxiliary function (no functional change)
104l Caching of war utility to keep the user interface fully responsive when checking if a civ
is willing to talk or willing to trade certain items. No functional change outside UWAI,
but had to put some code to switch caching on and off into CvDLLWidgetData.cpp.
104m Handling of tribute demands redirected to UWAI; fewer random AI requests.
Regardless of whether UWAI is enabled: AI doesn't ask for help, an embargo or (no
change) tribute if it's about to declare war on the player (war preparations complete).
On Noble difficulty and higher, the AI only makes tribute demands with a significant
trade value; e.g. won't just ask for a food resource or some small sum of gold.
The AI can demand gold per turn (not possible in BtS). The demanded sum is based
on the human player's commerce rate and expenses (not on the current gold income
which is often negative or near 0).
Rationale This should also address problems with players pillaging their own roads in order to
cancel a deal that results from a tribute demand for a resource. That trick doesn't
always work (the resource could be next to a river or in a city tile) and requires two
290
roads to be pillaged, which is somewhat costly in the early game. So AI resource
demands can make sense; don't want to disable them entirely.
See also advc.ctr: The AI can also demand cities.
AdvCiv (regardless of whether UWAI is enabled) BtS
The AI may demand multiple resources at once The AI demands only a single surplus resource.
as tribute and resources that the human player
has only one of aren't off-limits.
The AI may demand the human player's map in Only one tech or the map.
addition to a technology.
Rationale A map or a single surplus resource isn't nearly valuable enough for +1 relations and a
peace treaty.
When the AI asks for help or tribute, it includes a The peace treaty gets signed as a separate deal
peace treaty in the proposed deal. in response to a “diplo event” that triggers when
a human agrees to give help or tribute.
Rationale So that annual tribute and help deals can be identified (through the peace treaty) and
canceled automatically. Also more transparent this way: The peace treaty appears on
the trade screen.
Config The display string for a peace treaty offered by the AI at peacetime is set by
TXT_KEY_TRADE_SIGN_PEACE_TREATY in Civ4GameText_advc.xml. Currently says
“Sign Peace Treaty (10 Turns)” whereas, in other contexts, it says just “Peace Treaty
(10 Turns)”. Players have gotten confused (CFC posts 1 2) by the AI “offering peace”
despite not being at war. Hopefully the word “sign” puts more emphasis on the offer
being a (lasting) treaty. Don't want to invent a new term – it is very much a Peace
Treaty like the one signed upon ending a war.
See also City trades (advc.ctr) and war trades (146) also imply a peace treaty and show it on
the trade table.
Tbd. Should perhaps also add a peace treaty to the trade table as soon as a human player
lets the AI side put something on the trade table if nothing has been added to the
human side yet. When something else is added to the human side, the peace treaty
should be taken away. So that a peace treaty is on the table if a human player asks for
tribute or a gift. Or maybe this is too distracting ...
Peace treaties are canceled by CvDeal::verify AI civs cancel experied peace treaties at the start
at the start of a game turn – players never have of their turn, which usually means that the peace
to do it manually. treaty remains in place during the preceding
human turn unless the human player cancels it
manually.
Rationale More convenient in general, and will auto-cancel expired annual tribute and help.
An AI civ won't ask a human civ for help unless It's enough for the human civ's asset score to be
the human asset score is at least ¾ of the AI civ's half as much as the AI civ's asset score.
asset score.
Rationale Feels unfair to be asked for a handout by an AI civ that is clearly doing better.
104n Diplo votes
104o Handling of sponsored wars and conditions for vassal agreements when UWAI
enabled.
104p Target size for invasion stacks based on difficulty and less random (even when UWAI
is disabled). Always choose a target city while war is imminent. (BtS sets no target with
one chance in three.) Smaller target size on landmasses without capitals where the
291
enemy has at most 3 cities.
Rationale Except on high difficulty settings, the AI often took too long to get invasions started
after finishing preparations. The change for small landmasses is really unrelated to
UWAI; warfare tends to play out on a smaller scale there.
See also 253: Marathon speed also results in a slightly higher target stack size.
104q Changed some K-Mod uses of WarPlanStateCounter to AtWarCounter
104r Handling of empire split
104s Propagate UWAI decisions about limited, total and naval war to other parts of the AI:
• Treat faraway land targets as only reachable by sea.
• Treat preparations for “total” war the same as ongoing or imminent “total” war in
AI_maxUnitCostPerMil.
• Change Area AI from Offensive or Massing to a naval assault type when UWAI
thinks that the attack should be made via sea.
• Increase train-invader chance when preparing a total war. (K-Mod: Chance only
increased once the war has started.)
• Tweak code that makes AI cities less interested in buildings and missionaries while
preparing for war. War preparations now carry greater weight than an imminent or
ongoing war. (But, overall, an ongoing war that goes badly still affects AI cities even
more than preparations.) Rationale: Once stacks are coalescing or moving, cities
don't need to focus as much on military production; but it tends to take the AI too
long to get to that point.
104t Handling of team changes: Permanent Alliances and elimination of a team member
104u Fixes initialization issues with scenarios
104v Messages about AI war preparations in all-AI games
See also Chapter about all-AI games
104w Make all the AI's cash and gold-per-turn (up to a limit based on total commerce)
available for peace deals, and trust the UWAI code not to spend more than peace is
worth.
See also 039 announces the conditions of peace deals to third parties.
036 and 550f make more gold available for trades other than peace deals.
104x Loading of AI-related parameters from AI_Variables_GlobalDefines.xml
104z Handling of random events that lead to war/ peace: "Spy Discovered", "Wedding
292
Feud", "Great Mediator", "Heroic Gesture".
AdvCiv BtS/K-Mod
Spy Discovered – No change There is some BtS code for deciding if the AI
wants war, and K-Mod improves that code a bit.
Wedding Feud – Fixed a bug: When a response The event data doesn't say that one of the
to a random event will anger a rival civ that the responses can lead to a DoW; the AI only knows
AI dislikes, the AI picks that response only if the that the response is going to worsen relations.
rival is not too powerful.
If a rival is powerful, the AI is all the more inclined
to anger that rival. As a result the AI will, on rare
occasions, get into a war with a far too powerful
rival.
Great Mediator, Heroic Gesture – Reduced the The DLL gets no info at all about this event, so
probability for peace from 50% to 33%. the AI has to decide based on the "AIValues" of
the two possible responses. Both have the same
value, so the AI ends up picking a response at 50-
50 odds.
No Change The other side can still decide to continue the war
but, if that's also an AI civ, it never does (no
change in AdvCiv).
No Change Through, what karadoc calls "an ugly hack" in the
respective canTrigger functions, K-Mod prevents
the event from triggering when either side refuses
to talk.
Rationale I don't want to invest time here because there are serious issues with almost all
random events; the sane approach is really to disable them. The war/ peace events
are especially consequential though, so I'm applying some more band-aids.
I'd like to add that the war/peace events more or less hinge on irrational AI behavior.
Giving the opponent an option to make peace is pointless – the two civs could just
negotiate via the trade table. And Wedding Feud lets one civ pay 60 gold for a
relations penalty, and the other civ is simply asked whether it wants to declare war
(diplo penalties still apply).
The proper way to handle the last three events would involve adding tags to the
EventInfo schema so that the DLL can tell what the events actually do. (The DLL
could probably also identify them based on EventTriggerData, but that's messy.) And
CvRandomEventInterface.py would have to call some new Python-exposed DLL
function instead of just always starting a war (in the case of Wedding Feud) or always
making peace.
If I wanted to overhaul the events, MongooseMod (see "Event Overhaul" in
LunarMongoose's feature list) would have to be the starting point. This Rise of
Mankind revision could also be of interest. I don't think it fixes the war/peace events
though (or only through his DLL, which is closed-source).
I'd tend to throw out the diplomatic events (which require the AI to role-play; better
work more on the Dynamic Diplomacy changes instead). Similarly, tile yield changes
could be better handled by separate mechanisms for depletion/ degradation,
prospecting and propagation. Pandemics and uprising would also deserve separate
treatment. In the end, mostly events that ask a player to pay gold should remain
(though these will only make sense if binary research can be discouraged somehow)
and events representing natural disasters.
See also 106g is responsible for recording war/peace events in replays.
293
This open Git issue of the “We the People” mod mentions the problem of missing XML
tags for certain random events.
137 tweaks the map-size scaling of quests.
"No Random Events" enabled by default. All options on the Custom Game screen are
disabled by default.
Rationale I feel that at this point (v0.94), the mod makes improvements in so many areas that
players might expect that Random Events have also been overhauled. So I want to
signal somehow that this isn't the case. Renaming the option to "Random Events"
(disabled by default) would be more consistent, but players who update from v0.93
would have to toggle the option then.
As of v0.98, they're again enabled by default. I haven't improved anything about
Random Events, but I've noticed that games started via “Play Now” always use the
default options. My intention had only been to show the option as disabled the first
time that a player enters the Custom Game screen.
See also 101 renames "City Flipping after Conquest" to "No City Flipping after Conquest". That
was done earlier in the mod's development when updating was less of a concern.
294
106 Announcements and replays
See also Some additions to the replay log are covered by change 150
004f disables celebrations
See 104z about random events. Most messages about random events are irrelevant,
but I don't want to fix this because I think players should just disable them.
127 records start and end of AI Auto Play in replays.
127b stores jump-to info about most announcements (e.g. click a DoW announcement
in the Event log to jump to the captial of the civ that declared war).
120f announces and records spy missions that cause a revolution.
210: Civ4lerts
071 shows a message when first meeting a rival.
010 shows a message when a noncombat unit is killed through an attack.
The “Dawn of Civilization” mod has added BUG settings for customization of
announcements about Great People, religion spread and random events. CFC post
(For AdvCiv, I think I have a sensible middleground and no need for customization.)
Tbd. Would be nice to show and record messages about captured and razed wonders. I
think Civ 3 had those. I've already written the code and translations (not on GitHub),
but it turns out that CvPlayer::acquireCity isn't the proper place for my code
because the raze-city popup isn't resolved until later. This really complicates things.
The random events that spawn Barbarians should be announced even if the player
that triggered the event hasn't met the active player. (Maybe, ideally, not if the active
player's capital is on a different landmass.)
AdvCiv BtS
Only GP births of known civs are reported. The All GP births are reported; "in a faraway land" if
city owner is stated if the city isn't revealed, e.g. the city is unrevealed.
"in the Incan Empire".
Show only the GP name in yellow. Entire message in yellow. Makes it harder to pick
out the yellow BUG gold-trade alerts.
Rationale Gotta kill some messages. This one is implausible (how do you learn about GPs on an
undiscovered continent?), and doesn't have great strategic value.
Finished wonders are always reported (no Message says "faraway" when the city isn't
change); the city is stated if revealed. revealed. If the owner is known, it is listed on the
Statistics Screen. The message never states the
city, but highlights it on the map.
No change to the way religions and corps are When a religion or corp. is founded, if the holy/
reported. HQ city is unrevealed but the city owner known,
report only "faraway".
The name of the city where a GP is born is no "Antony van Leeuwenhoek (Great Scientist) has
longer recorded in replays. Record it as "The been born in St. Petersburg (Catherine)!"
Great Scientist Antony van Leeuwenhoek has
been born in the Russian Empire." (important info
at the start and the end)
295
Rationale "In the Incan Empire" is extra information. Reporting "faraway" (as in BtS) is
misleading in this case. Not reporting them at all would also be bad. Should either
report all GP births of a civ or none. The crucial info is how many GPs a rival civ
produces, and not so much which GPs specifically.
Wonders: just to be consistent.
GP in replay: In order to shorten the message a little. The city is irrelevant.
Tbd. Perhaps remove the GP name from replays, i.e. just "A Great Scientist has been born
in the Russian Empire".
Relocation of a civ's capital is announced to Conquered and razed cities are announced;
other players (but not recorded in replays). without special mention of the capital.
Regardless of whether the old capital was Constructed Palace isn't announced.
conquered or razed or whether a new Palace
was constructed.
Rationale Most of the time, it's easy enough to tell from the city name when a capital gets
conquered, but shouldn't have to scroll around the map to find out the name and
location of the new capital .
See also 127: In spectator mode, the announcement is shown regardless of map knowledge.
AdvCiv BUG/ Civ4lerts
No more BUG alerts about civs no longer willing The alert about resource trades triggers
to trade a resource. whenever the set of resources offered by a rival
changes from one turn to the next.
See also 210e makes the alert trigger also when the AI becomes willing to import a resource.
Rationale It's a helpful alert, but fires too often. Typically, the willing-to-trade part is more
important. The player then either trades for the resource or decides not to. In the latter
case, it's not immediately helpful to know that it's no longer available.
Tbd. The same reasoning can be applied to the tech trade alert, though techs seem to
become unavailable less frequently. Unavailable techs and resources hint at inter-AI
trades and/ or changes in AI attitude. The proper solution is to implement a new alert
for AI attitude changes and one for inter-AI trades. (Update: The latter has been
implemented by now, 210d, but turned out to be too noisy.)
Will probably still need the "no longer willing" alert because the AI could also have
started building a wonder.
Civics changes except to Free Religion excluded
from the replay log.
Replays record when a leader enters a new era.
Except for Liberalism, technological progress is
(disabled by default)
only recorded indirectly through civics changes
Replays record the first discovery of each tech. and constructed wonders.
Era transitions and first discoveries are shown in Cities founded in green, religion and civics
green. Cities founded are shown in the owner's changes and random events in white.
player text color. Religion changes in light blue.
Cities hit by nukes, meltdowns recorded. And Only announcements; not mentioned in replays.
report meltdowns to all players that know the city, Meltdowns are only reported to the city owner.
and record when a city reaches Legendary
culture.
296
Rationale Civics changes are not very important and occur very frequently; make replays difficult
to follow. (Religion changes tend to be rarer and more consequential.)
Replays should give some indication of technological progress. Era transitions were
my first idea, then I thought first-to-discover would be even better. There's some
redundancy when techs cause religions to be founded, but I guess that can't be
avoided.
Colors: Green should be the color of research. For cities founded, I've tried magenta
(the color used by the disabled city-founded Civ4lert) and COLOR_CULTURE_RATE, but
they're too hard to read against the brown background of the Replay screen. I've also
tried white (now that civics changes and random events are no longer reported), but
found player colors easier to follow. (Although replay messages are otherwise not
color-coded based on the affected civ; so it's inconsistent.)
See also ctr uses COLOR_CITY_BLUE for city trade alerts.
Config SHOW_FIRST_TO_DISCOVER_IN_REPLAY, SHOW_ENTERED_ERA_IN_REPLAY and
USE_PLAYER_TEXT_COLOR_IN_REPLAYS in GlobalDefines_advc.
Tbd. Perhaps recording every tech is too much and era transitions too little. Could do era
transitions plus Liberalism plus first discovery of techs granting a free GP.
EVENT_MESSAGE_TIME_LONG is no longer used. Extra long display duration for e.g. founded
religions and corporations. Originally also for
religion spread (duration reduced by K-Mod).
Rationale Annoying; not a good way to draw attention (nor are the events in question that
important).
See also 106c: Civ4lerts had also used EVENT_MESSAGE_TIME_LONG.
AdvCiv K-Mod
Announce feature growth in the fog of war (so Feature growth is only announced on actively
long as – no change – the nearest city belongs to visible tiles. (It seems that BtS had announced
the active player). feature growth even on unrevealed tiles – but
you'd think that this would be a widely known
bug. Maybe the announcement gets killed
somehow when the tile is unrevealed.)
Rationale Terrain features aren't subject to the fog of war.
106b Message limit
Config Since AdvCiv 1.0, this option is disabled by default because it's potentially confusing
for players new to the mod. It can be enabled on the “General” tab of the BUG menu.
This change only applies when playing with the "Minimize Pop-Ups" (MPU) option.
Rationale It's awkward when the Event Log opens along with a popup because then the Event
Log can't be closed until the popup is dealt with. This happens all the time when
playing without MPU. Also, I suppose players who don't use MPU are fast players that
don't pay a lot of attention to each individual message.
Config Override: MESSAGE_LIMIT_WITHOUT_MPU in GlobalDefines_advc.xml
AdvCiv BtS
297
If more than 3 messages are waiting at the No limit on the number of messages. The Event
beginning of a turn, don't display them on the Log is only ever shown when the player opens it.
main interface; open the Event Log instead.
Major events are kept in the Event Log
Exception: Messages about most major events
indefinitely, whereas minor events are cleared
are always displayed on the main interface.
after 20 turns and info messages after 2 turns.
The following major events are not shown on the The following events are major:
main interface when the Event Log is opened:
War started/ ended, alliance formed, defensive
• Golden Age begun pact signed, capitulation/ vassal agreement
• city founded signed/ broken, tech discovered, first to discover
• city liberated, ceded Liberalism, circumnavigation, wonder/ team
• foreign city flipped project built, city founded, civics or state religion
• city captured/ razed changed, revolution started/ ended, Legendary
• wonder built culture reached, religion or corp founded, city
Also not shown, and now only a minor events: religion/ corp spread or removed, city liberated/
when a religion or corp spreads in a city, birth of flipped, game won, GW sustainability reached (K-
a GP, civics changes, tech discovered. Mod), vote source established (UN, AP), city
captured/ razed, Golden Age begun/ ended, civ
The signing of a Permanent Alliance is now a conquered, GP born/ GG killed, empire split,
major event. spaceship launched/ failed, nuke.
Also open the Event Log when there are 1 or 2
messages along with a diplo popup (unless that The Event Log button becomes inaccessible
popup is just an AI civ making first contact with when a diplo popup opens (hotkey also blocked).
the human civ). On-screen messages are cleared in between
In Hotseat, always open the Event Log when turns, including those that haven't been displayed
there is a new message. yet. This means that a player who follows
another human in the turn order misses most
messages.
Rationale The main interface really isn't suitable for displaying frequent messages. It's obtrusive;
the display delays add up; messages can disappear too fast. My limit guarantees that
after waiting for 3 messages, no further messages can arrive.
When a diplo popup opens, any messages on the main interface become difficult to
read, so it's important to provide access to the Event Log. The player should be able
to learn what happened during the AI turns before making any decisions.
Major events on the main interface: These can easily get buried and missed in the
Event Log because they occur already during opponent's turns. Especially when
playing without sound. The ones that I've excluded are either not that important or
there is some additional mechanism that alerts the player (e.g. tech splash screen
when a tech is discovered). Religions are spread all the time; that's not a major event
at all.
Tbd. Could repair message delivery in Hotseat; opening the Event Log is only a
workaround solution. Would have to store messages within the DLL when they are
triggered, and call CvInterface::addMessage only at the start of the recipient's turn.
Can also rewrite that function in the DLL if necessary; probably just wraps data into a
CvTalkingHeadMessage object and calls showMessage.
Messages about major events don't appear on the main interface until all diplo popups
are through. Same problem in BtS. CvPlayer::postProcessMessages already gets
called before diplo popups are displayed and already tells the EXE to show major
event messages. Still, when CvGame::update returns, the messages get held up by
the diplo popups. This issue will hopefully be easier to resolve once AI-to-human
diplomacy is moved to the start of the human turn (see Tbd. under 001e).
298
See also 120c allows players to hide the espionage slider when it's at 0. The default position of
the Event Log appears to be hardcoded somewhere in the EXE and the BtS
expansion didn't update it after adding the espionage slider – with the result that the
Event Log overlaps with the espionage slider.
092 (scalable HUD) can lead to an overlap of the Event Log with the culture slider (i.e.
even when the espionage slider is hidden).
The “We the People” developers are considering improvements to the message
delivery system: GitHub issue. Doesn't sound like they'll add something that AdvCiv
could adopt. Sorting messages by importance can mix up causes and effects.
I got the following idea (and uploaded a mockup here): When there are more than
three new messages at the start of a turn, don't to select any unit and don't display
any popup; instead show all new messages in the unit command area and put all
minimized popups in the info pane, along with a button to start unit cycling, instruction
labels if needed, and any further buttons that could be helpful at the start of a turn
(e.g. buttons for cycling through unhappy and unhealthy cities). Remove all those
widgets when a unit is selected (but show them again when no unit is selected). Could
also have little buttons next to each message for dismissing only that message, and
tiny versions of the button graphic that comes with some of the messages (to
communicate that the message can be clicked). Not sure if all this is doable in the
SDK. Main problem: Diplo popups. I don't think it will be possible to give the focus to
the command area or any panel therein when the Diplo screen is up, meaning that the
player will be unable to scroll through the new messages before dealing with the Diplo
screen, and there's only enough space for four messages at once. That's an
advantage of the current solution: The Event Log can take the focus.
All messages are cleared from the main interface Once displayed, messages only disappear when
at end of turn. they've been on display for the proper amount of
time (depends on message type).
Any messages still queued for display are When a human player's turn ends, all messages
flushed before that (i.e. cleared without having still waiting to be shown to that player are
been on display). displayed at once (delay skipped).
Rationale When turns are ended in quick succession, in BtS, messages from different turns get
displayed together, which can be confusing. Dropping messages without ever
displaying them isn't much of a problem anymore because the Event Log tends to
open periodically and the missed messages are in there.
At the end of each human turn, a special Each message in the Event Log is preceded by a
message with text "Older messages:" is put into date. All messages with the current turn's date
the Event Log. On the next turn, the player can are certainly new, but those with the previous
tell from this message which messages are new. turn's date may or may not be new. E.g. tech
The special message never appears on the main discovered is sent at end of turn and appears at
interface and it expires after 1 turn, meaning that the start of the next turn.
only one such message is ever in the Event Log.
Rationale By the midgame, there are more than three messages on most turns, so scanning the
log for new messages is something the player does all the time, and it's vexing when
it's not clear which messages are new. Also easy for a message to slip by unnoticed.
I've tried some things (backspace characters, setting the message turn to -1, same
text color as the Event Log background) to get rid of the date in front of the special
message, but it appears to be impossible from within the SDK.
106c No more alerts upon loading savegame
AdvCiv BUG
299
The BUGEventManager fires BeginActivePlayerTurn fires after the end of
BeginActivePlayerTurn only right after the the previous turn, and when loading a savegame.
previous turn ends, not when loading a
savegame.
Consequently, alerts aren't checked (and aren't Alerts are checked after loading. Since Civ4lerts
displayed) when loading a savegame. doesn't store data in savegames, the alerts
assume a blank slate, and display a bunch of
messages, e.g. for all technologies that anyone is
willing to trade.
Alerts have the same display duration as normal Alerts are displayed for 20 seconds.
events: 10 seconds.
Rationale Arguably a bug. BeginActivePlayerTurn shouldn't fire multiple times per turn, but
that's what happens whenever a savegame is loaded.
Listing all trades upon loading can't be considered a feature either. That info is
presented better by the Foreign Advisor.
See also 127: Other changes to AI Auto Play
Tbd. When cycling to another player with Alt+Z, BUG alerts fire. Should instead only do a
silent check (and fire only after ending the turn). For the alerts added by AdvCiv (210),
this is already fixed; see comment in CvPlayer::setIsHuman – though the BUG
alerts will require a change in Python.
As a special case of the above, cycling after the creation of a colonial vassal can
result in a (harmless) Python crash because Civ4lerts.py isn't yet aware of the new
player.
106d Civ4lerts and Scoreboard settings changed
See also 004v also makes changes to the scoreboard.
kekm.30 adds an option for civ and leader icons.
092 addresses some minor layout issues that were covered here prior to AdvCiv 1.06.
AdvCiv K-Mod
Enabled some alerts by default, namely Worst K-Mod disables all alerts by default (whereas
Enemy and all those from the second batch standalone BUG enables them all).
("MoreCiv4lerts") except domination and map
trade.
Enabled the "willing to talk" alert by default, and It's the other way around.
disabled "peace treaty" by default.
Refusal to talk not reported when it happens at
the start of a war.
Rationale The ones I've enabled are essential for intermediate players, whereas domination and
the first batch of alerts (city management and trade gold) are only essential for
perfectionists.
AI willingness to sign a peace treaty implies willingness to talk. Additionally, the
"willing to talk" alert covers ending embargoes; very helpful to learn about those.
Changed the Advanced Leaderboard default layout so that open borders (B), espionage advantage
(E), defensive pacts (D), trade network (N) and whether they have any vassals (V) aren't
displayed.
300
Rationale Frees up space on the main interface, and I find it difficult to imagine that players can't
remember whom they have these relations with. The vassal indicator is redundant
when "Group Vassals" is checked (as is the case by the K-Mod default).
Config The in-game BUG menu contains a formatting string. See above for the letters I've
removed (B, E, D, N, V).
See also See 120h about the espionage icon.
085 shows B, D and N by default if “Expand on Hover” is enabled on the BUG menu
(disabled by default).
AdvCiv K-Mod/Civ4lerts
The "pending" alerts only trigger when a negative Trigger also when a city is about to become
event is about to happen: when a city is about to happy or healthy or is about to grow.
become unhappy or unhealthy or is about to
The non-"pending" city alerts trigger when a city
shrink.
becomes healthy, unhealthy, happy or unhappy
or when a city shrinks or grows.
Rationale When something bad is about to happen in a city, the player may want to do
something to prevent it, and when something bad has happened, the player may want
to do something to repair it. I think that's the purpose of these alerts. Presumably, the
triggers for positive pending events were only added for consistency – most (all?)
alerts trigger on some condition and the negation of that condition (e.g. willing to
trade/ no longer willing to trade). However, reducing the noise from alerts is more
important than consistency.
I'm not removing any non-"pending" triggers because players may want to check the
job assignment when a new citizen is born or when an angry citizen goes back to
work. I don't think this reasoning can apply to has-become-healthy, but in this case, I
don't want to break the pattern.
Config Added a single BUG option for all three “pending” alerts that restores the K-Mod
behavior. This has been requested in here (CFC).
Tbd. Should've named the new option “Only Negative Pending” and enabled it by default.
Currently, it's “Also Positive Pending”. Not sure if it's still worth changing this now.
See also God knows what the "Borders Pending" alert was supposed to be good for. I've
removed that to make space for 210.
AdvCiv K-Mod
"Happiness Pending" (i.e. about to become All Civ4lerts are disabled by default in K-Mod.
unhappy) enabled by default. (I think BUG as a standalone mod enables them
all by default.)
Rationale "About to shrink" is often helpful to know too but annoying in recently conquered
cities.
Tbd. One reason why it pays to be alerted about cities that are about to shrink is that the AI
(and thus the governor) doesn't take into account that cities can lose only 1 population
per turn. Once it's decided that a city will shrink, the correct play is normally to
deprioritize food for one turn. This is tedious, so the governor should do it
automatically or there should be some additional penalty for a food deficit when the
food store is empty.
AdvCiv BUG
With the exception of the revolt alert, the city I've seen “has become happy” trigger under
alerts can't trigger for cities under occupation. occupation.
301
Rationale Potentially confusing, and the new owner is probably going to take a look at the city
once occupation ends, so there's no need for tracking its status in betweentimes.
106e Report all religion and corp changes
Show a message whenever a corp spreads in a Message only shown to city owner and to players
revealed city. Announce religion spread only if that have the religion as their state religion or
the religion differs from the city owner's state own the holy city (in the case of religion spread)
religion, or if the player owns the city or the holy or to players that own the HQ (corp spread).
city. Once the player is in the Industrial era,
announce religion spread only if the player owns
the city or the holy city.
When a corp spreads in a city that isn't revealed HQ owner may receive messages about
to the HQ owner, the city becomes revealed to unrevealed cities.
the HQ owner.
Don't announce the establishment of a corporate Three messages: one for completing a wonder,
HQ, and don't announce that the HQ spreads the one for establishing the HQ and one for
corporation to the HQ city. I.e. show only one spreading the corporation. (K-Mod already got rid
message when an HQ is founded, namely (e.g.) of a redundant message upon expansion of a
"Alexander has completed Mining Inc. in Athens". croporation.)
Rationale Update (v0.91): The foreign religion spread messages get too annoying in the mid-/
endgame; therefore disabled post-Renaissance. Perhaps there should be a "Show
foreign religion spread" Civ4lert, but that would have to be enabled by default, and
then players would have to manually disable it in the midgame – if they'd even realize
that this is possible.
Update (v0.92): It's actually also too annoying before Renaissance. No longer
announcing if the religion is already the city owner's state religion.
Tbd. Does a holy city generate gold from unrevealed cities?
Config The era threshold for foreign religion spread messages can be changed through
STOP_RELIGION_SPREAD_ANNOUNCE_ERA in GlobalDefines_advc.xml.
The v0.92 update can be disabled by toggling ANNOUNCE_STATE_RELIGION_SPREAD in
GlobalDefines_advc.xml.
106f Announce canceled Defensive Pact (DP)
AdvCiv BtS
Canceled DP are publicly announced and DP are announced and recorded when signed;
recorded in the replay log. only the parties involved are notified of
cancelation.
106g No random events in replays
Random events aren't recorded in replays. All random events are recorded in replays.
The replay says "in response to a random event"
when a declaration of war or a peace treaty was
triggered by a random event.
Rationale Most of the random events are unimportant, and many are quite wordy, making
replays difficult to follow. The war and peace events are exceptions.
Tbd. There are some other important events, e.g. fulfilled quests.
See also 104z improves the AI response to war and peace events a little.
106h Replay lists game settings
302
Most info from the Settings tab (Victory screen) is The relevant info is stored in the replay file but
stored in the first entry of a replay. not displayed anywhere. The Hall of Fame
screen only shows difficulty, world size, starting
era and game speed.
Rationale For old replays and replays shared with other players.
Config SETTINGS_IN_REPLAYS in GlobalDefines_advc.xml
See also 004 adds custom map options to the Settings tab. Those options are included in the
replay entry.
Tbd. Would be nice to indicate which color is the player color, but I don't think replays
support the <color> tag, and I don't want to show an entire entry in the player color.
106i Replay file format
See also CFC post by me about the format
Could also load savegames from other mods. See the ModName and SelfMod
classes in the Taurus mod about that. I've already introduced the ModName class into
AdvCiv for the replay format changes; cf. this Git commit.
Option added for omitting the mod name from The result of gDLL->getModName() is stored in
replay files, meaning that AdvCiv replays can be replay files. When no mod is loaded, that call
viewed without loading (or even installing) the returns an empty string. All mods share a single
AdvCiv mod. Replays folder. The Hall of Fame screen loads
By storing a mod id number in a part of the replayall replays from that folder, compares the mod
file that BtS ignores and through a hack (as name stored in each replay file with the current
CvDLLUtilityIFaceBase::loadReplays is not result of gDLL->getModName() and displays only
in the DLL), AdvCiv is able to load replay files those that match.
without a mod name and to distinguish AdvCiv Double-clicking a replay file appears to bypass
replays from unmodded replays. the name check, so there is a way to view
replays created by a mod without installing the
mod. But this doesn't work on Steam installations
(not sure about Windows 10), and it doesn't work
via the Hall-of-Fame screen.
Config Prior to AdvCiv 1.06, the mod name was omitted by default and an option for
changing that existed only in XML. Now the mod name is included by default and can
be omitted through an option on the System tab of the BUG menu. If BtS will be
unable to read the replay, the mod name is included regardless of the BUG option.
This can be the case in mod-mods that add a map size, victory condition, difficulty
level, game speed setting or player color.
Rationale Mainly makes it easier to share AdvCiv replays with other players. Whether it's
generally desirable to show replays from different mods on the same HoF screen is
debatable. I think I'd prefer it, provided that replays from different mods are easy to
distinguish (see name prefix below), but I'd rather not inflict this on others.
See also 003k is a prerequisite as, otherwise, no data can be added to the CvReplayInfo class.
106 (see above) uses player text colors in city-founded replay messages. This doesn't
make the compatibility issues worse because player colors are used in any case for
the minimap and score graph.
106h (see above) ensures that AdvCiv replays are identifiable as such by showing the
mod name in the first replay message.
106m stores the minimap resolution in replay files.
AdvCiv is able to load unmodded replay files and those from other mods.
303
Config Disabled by default; can be enabled through GlobalDefines_advc.xml. Not all
replays can be loaded; see the comments there.
Rationale Certainly nice to have the ability to show replays from any mod without having to
install it, but this doesn't have to be enabled all the time.
Tbd. If loading of non-AdvCiv replays is enabled, the HoF screen should show mod names
somewhere and offer a filter-by-mod menu. The HoF screen is in the SDK, so this is
doable – but a bit of work.
I've added some sanity checks to the function BtS relies entirely on a try-catch block to filter out
that reads the serialized replay data. files that don't have the proper format.
When a game is started, loaded or exited, any After entering the Hall of Fame screen (from the
replay data loaded by the Hall of Fame screen is opening menu or at the end of a game), all replay
cleared. data is kept in memory until the program is
exited.
Rationale Memory is generally a non-issue for AdvCiv, but there could be a lot of replays
(especially if those from other mods are loaded too), and each could contain
thousands of messages and minimap color changes.
Replay file names start with "[AdvCiv]". The replay name is composed of the player
name, year of the final turn and, apparently, a
two-digit random number to avoid name
collisions with earlier replays. BtS associates the
.CivBeyondSwordReplay file ending with
Civ4BeyondSword.exe, but this does not cause
the proper mod to be loaded.
304
Tbd. Looks like I've introduced this problem somehow, i.e. it should be possible to start
replays at game end.
106j A deal canceled during an AI turn is only immediately announced if it's an open
borders agreement, defensive pact or peace treaty; canceled gold and resource deals
aren't announced until the start of the next human turn. Exception: If a resource deal
is canceled because the trade connection was lost, the announcement is shown
immediately.
Rationale Only important events should get an immediate announcement. Canceled resource
deals are (typically) followed by either a diplo popup or a declaration of war – unless
the trade network was severed.
106k City name changes in replays
At the end of each turn, the game checks if the City name changes are not recorded in replays. If
name of any city has changed since the start of a city is renamed, future replay messages refer
the turn. If so, the name change is recorded in to the city by its new name, but older messages
the replay log. remain unchanged.
Rationale I'm recording the change at end of turn because a player who renames a city might
change his/her mind once he/she sees the new name on the main interface; don't
want to spam the replay log with temporary changes.
305
Rationale For some of the Advisor screens, it can be helpful to see parts of the main map and
HUD in the background and some can't easily be scaled up. Otherwise, as is in the
case of the replay screen, there's no reason not to adjust them to the available space
(except that it takes some work).
Credits Somehow I never thought of scaling up the replay screen (easy to forget that it's in the
SDK because neither the expansions nor BUG modify it) until I read this post by
Kjotleik. I didn't ask him for his code because I'm assuming that it, again, only works
for one screen resolution.
The idea to increase the minimap resolution came from CFC user VDNKh (link).
When the HOF_STORE_REPLAYS_AS_BTS option The background texture for the replay minimap is
(see 106i) is not enabled, then replay files store (apparently) stored as bitmap with 8-bit color
the MINIMAP_RENDER_SIZE value that was used depth, an aspect ratio of 2:1 and a width
to generate the terrain texture. This allows determined by MINIMAP_RENDER_SIZE, 512
players to change the texture resolution without pixels by default. (I suppose the margins are set
breaking compatibility. to black when the map doesn't have a 2:1 aspect
ratio.) The game can only read replay files whose
texture dimensions match the current
MINIMAP_RENDER_SIZE.
Config The XML settings mentioned above are in GlobalDefines_advc.xml.
Rationale I haven't changed the default MINIMAP_RENDER_SIZE because I want to stay
compatible with BtS. But at least players who don't care about that can use a higher
resolution and maintain replay compatibility within AdvCiv. (Another concern with a
higher resolution is that the same resolution is used for the minimap on the main
interface, where the BtS resolution is sufficient and a higher resolution might carry a
slight performance penalty. Switching back and forth between resolutions as the
replay screen is entered and exited doesn't seem to be possible.)
Credits VDNKh made me aware that maximizing the replay screen has made the terrain
texture a bit blurry. (CFC post; under “requests”)
See also 106i deals with other changes to the replay file format.
106n Replays can show terrain texture from before the end of the game
If REPLAY_TEXTURE_ERA is set to an era number, Replay files include a terrain texture generated at
then the minimap texture for the replay is stored the end of the game. That texture may show
when a player first reaches that era. The texture roads, railroads and the effects of deforestation
is included in savegames and written into the and global warming.
replay file when the game ends. This does not
break compatibility with the BtS replay format.
The texture has a size of 128 KB (unless
MINIMAP_RENDER_SIZE is increased; see 106m);
the EXE might compress that a bit when
appending the texture (bitmap) data to a
savegame.
By default, no texture data is stored in
savegames and the texture generated at the end
of the game is written into the replay file (as in
BtS).
Config REPLAY_TEXTURE_ERA in GlobalDefines_advc.xml
306
Rationale I'd prefer to use a pre-industrial texture, i.e. REPLAY_TEXTURE_ERA=4, because
railroads are very noticeable (and blurry) on the maximized replay screen and didn't
exist for most of the time period covered by the replay. However, I think using the final
map is also a logical choice and getting rid of the railroads and global warming effects
isn't worth a substantial increase in savegame sizes.
See also This post outlines some obstacles against showing terrain changes in replays.
106n Replays can show terrain texture from before the end of the game
If REPLAY_TEXTURE_ERA is set to an era number, Replay files include a terrain texture generated at
then the minimap texture for the replay is stored the end of the game. That texture may show
when a player first reaches that era. The texture roads, railroads and the effects of deforestation
is included in savegames and written into the and global warming.
replay file when the game ends. This does not
break compatibility with the BtS replay format.
The texture has a size of 128 KB (unless
MINIMAP_RENDER_SIZE is increased; see 106m);
the EXE might compress that a bit when
appending the texture (bitmap) data to a
savegame.
By default, no texture data is stored in
savegames and the texture generated at the end
of the game is written into the replay file (as in
BtS).
Config REPLAY_TEXTURE_ERA in GlobalDefines_advc.xml
Rationale I'd prefer to use a pre-industrial texture, i.e. REPLAY_TEXTURE_ERA=4, because
railroads are very noticeable (and blurry) on the maximized replay screen and didn't
exist for most of the time period covered by the replay. However, I think using the final
map is also a logical choice and getting rid of the railroads and global warming effects
isn't worth a substantial increase in savegame sizes.
106o Announce war/ peace changes for vassals along with their masters
See also 002l supresses the war horns sound for declarations of war triggered by defensive
pacts.
AdvCiv BtS
Declarations of war and peace deals that involve A separate message for each pair of teams that
vassals are announced in a single message. change their war/ peace status. E.g. 9 messages
when a team with two vassals declares war on
another team with two vassals.
Rationale Makes especially large all-AI games difficult to follow.
307
When at war and on the defensive, floating Floating defenders in defensive wars are
defenders are now assigned like under the Alert1 assigned as under Alert2.
strategy.
The AI is more willing to mount a counter- Once an enemy DoW is no longer considered
offensive (offensive Area AI), even when a war is recent, the AI relies on its war success rating for
no longer recent, and war success has been selecting its stance (offensive or defensive Area
poor. (War success is still considered though.) AI).
AI personality (LimitedWarPowerRatio) slightly
factors into the choice between defensive and
offensive Area AI.
Rationale Need to counterattack more. Shouldn't rely much on war success even in long-ish
wars; successes from an initial surprise attack can give a false impression (see also
130r under Tbd.). Unless the power ratio is highly unfavorable, just sitting there isn't
the most effective tactic, and it's also boring to play against.
Risky counteroffensives seem out of character for some leaders, and very much in
character for others; hence the leader personality factor. Use LimitedWarPowerRatio
because counteroffensives should have limited objectives.
See also 104p changes the stack size required for launching an attack
AI civs are less willing than in BtS to go on the defensive when the number of nearby enemy units
exceeds the number of cities owned by the AI civ.
Credits From More Naval AI (Tholal)
All AI cities try to add a stationary city defender In the Classical era, regardless of difficulty level.
beyond the first around the Renaissance era – And another in Renaissance in coastal cities.
except on Deity and Immortal difficulty (around
the Medieval era). Coastal cities add a third
defender in Renaissance (essentially no change).
Config The DLL sets the era bounds based on the unit production modifiers in
Civ4HandicapInfos.xml. (So it's not really configurable, but the era number also
isn't as hardcoded as the description above makes it sound.)
See also CFC post (item2) arguing that the AI leaves its non-border cities too lightly defended
in AdvCiv on Deity difficulty. When this was written (AdvCiv 0.99), the extra defender
came in Renaissance, regardless of difficulty. (And the first item refers to a mundane
bug that has by now long been fixed.)
253 may also add the extra defender earlier when playing on Marathon speed.
Rationale An extra defender everywhere is a big production sink now that AI production
discounts have been reduced (through change 251), especially in the early game.
That forum post probably describes an AI enemy in the Classical era; so I could
address that situation (to an extent) by adding the extra defender already in the
Classical era on Deity. However, I don't really think that this would make the AI more
difficult to beat overall as it's not all that often possible to sneak up on the AI through
the territory of a third civ that the AI isn't afraid of. It's also a pretty clever stratagem
that I don't mind being rewarded a bit. (The reward isn't going to be that great
because the conquered cities won't be connected to the player's core territory.)
Tbd. Perhaps shouldn't add a coastal defender when no threatening civ is known.
308
Reduced the impact of the era number on the The baseline was something like 6 floating
number of floating defenders. defenders per city by the Industrial era – in
addition to the stationary defenders.
Rationale This was probably the worst part of the BtS formula for floating defenders. Often, a
third of an AI civ's units were floating defenders in the late game and thus unavailable
for offensive operations (except through the “Crush” strategy).
When preparing a land war, the number of No distinction between a land war in preparation
floating defenders is increased only slightly. and an ongoing land war.
Rationale Once war is imminent (preparations complete), there is usually still enough time to
train some extra defenders before a counterattack is (maybe) launched.
AdvCiv BBAI
An AI civ following the "Turtle" strategy stops Turtling AI civs keep building defenders until they
building defenders when their number exceeds a can make peace or the power ratio shifts in their
threshold. favor.
As a result, the Turtle strategy seems to get
used only rarely and briefly.
Rationale A turtling civ can't recover economically from building Archers for 50 turns.
AdvCiv BtS
AI doesn't try to guard non-city tiles when a war Nothing to prevent guarding of resources or
starts looking hopeless. Forts. Not sure if an urgent need for defenders
elsewhere can cause the AI to stop guarding
non-city tiles.
Rationale If they're strategic resources, it could actually be crucial to keep them, but I don't think
that's generally feasible when the AI gets beaten badly. It's normally more useful to
guard the cities then.
Reduced impact of Space victory stage 3 on city Extra defenders in capital and all cities building
defenders. spaceship parts.
Rationale Space victory is a lengthy process, and stage 3 begins with the completion of Apollo.
Doesn't usually mean that the AI just needs to survive in order to win.
When the AI computes the (spatial) closeness Cities on different continents are considered to
between two civs, cities on different continents be closer to each other than those on the same
are considered to be less close to each other. continent.
Closeness mostly affects the distribution of AI
defenders, the Alert strategy, raze decisions and
the price of sponsored war.
Rationale Arguably an oversight by S. Johnson (or whoever wrote the PlayerCloseness code).
The intention was probably to use a wider search range for cities on other continents,
not to treat them as being nearer.
See also In some situations, the impact of a land connection is further increased:
022: Alert strategy
104o: WHEOOHRN when already fighting a war (currently disabled)
The AI counts units that temporarily guard a city Only units with the appropriate (permanent) Unit
as defenders in certain situations. AI type are counted.
Rationale I'm not sure how often this comes up, but I think the change can't hurt.
309
Credits Merged from "RoM: A New Dawn" (Afforess). SourceForge revision: link
Rationale Removing all bad tiles makes the starting region look unnatural. A few bad tiles give a
start more character and provide more variety without hurting the player much. (Until
the midgame, some tiles typically remain unworked anyway.)
(“Normalization” seems like a bit of a misnomer for these terrain upgrades. It fits better for the extra
resources placed in order to reach a target found-city value. Anyway, it's all referred to as “normalization”
in the code.)
Bad terrain is never replaced under a precious Desert Gold always gets upgraded to Plains
resources and a bad feature on a precious Gold, and Jungle is cleared from Grassland
resource is only removed in the inner ring around Gems.
the starting location.
See also The “precious” resource class is introduced by change 129.
Rationale High-commerce resources near the capital tend to be too powerful. If they happen to
have a drawback, then it's for the better and that drawback shouldn't be taken away.
Stricter limit on the number of extra Forests Places Forests almost everywhere unless the
placed around a starting site deemed too weak. Forests increase the found-city value sufficiently,
Also don't place (too many) extra Oases when i.e. if the site is no longer too weak.
there are already a lot of Flood Plains or Oases.
Rationale Usually, no number of extra forests will close the gap in found-city values, so BtS
essentially creates a dense forest around every weak starting site. Too obvious. Could
argue that Forests should increase the found-city value more when normalizing, but I
don't think AI civs actually get that much out of Forests near their capital.
See also I might switch the order of normalization and starting site reassignment in the future;
see Tbd. under 027. Therefore the found-city value of Forests during normalization
shouldn't depend on human/ AI status
When placing additional resources, resource Resource types already exiting around a city
types that already exist in the city radius are aren't taken into account.
probabilistically avoided, especially in tiles
adjacent to the existing resource, and especially
for resources that don't normally form groups.
310
Rationale To make starting sites look more natural. Also, clusters of food resources or Stone/
Marble don't play well; aren't normally allowed to occur for good reason. Weird
resource clusters will still appear occasionally; good for variety's sake.
All resource placement during normalization is The placement of food resources
randomized. Tiles in the inner ring are preferred, (normalizeAddFood) is, shockingly, not
but only probabilistically. randomized and K-Mod hasn't fixed that either.
Meaning that, if possible, food always gets added
east of the starting site. Specifically, Corn gets
added. Thus, the inner ring has absolute
precedence for food; for “extra” resources
(normalizeAddExtra), tiles in the city radius are
tried in a uniformly randomized order, meaning
that the outer ring has a chance of 60% (12/20).
Rationale Prefer the inner ring so that players have more leeway to move the starting settler.
See also 129 randomizes the order in which resource types are considered.
Normalization can add at most 2 hills; up to a Normalization ensures at least 3 hills within the
total of 3 (no change). city radius.
Rationale For more variety; having just 2 hills isn't a major handicap. That said, starting sites
with 0 hills initially are probably very rare.
Food resources (except seafood) and hills BtS doesn't check this; may place extras on an
placed during normalization have to be placed on island in the city radius. PerfectMongoose does
the same landmass as the starting site. Other have such a check.
extra resources also aren't placed on other
landmasses – if it can be avoided.
Rationale At least food resources can be crucial for making a starting site playable.
When the decisions about placing extra Tries to make the lowest found-city value at least
resources and features during normalization isn't 80% of the best.
made by starting position iteration (027), then
the aim is to make the worst starting site at least
75% as good as the best in terms of found-city
value; 80% in multiplayer games (no change).
311
Rationale Makes it more attractive to move the starting Settler. Don't want players to settle
blindly and hope for the best (or regen) when a starting site looks poor. When all city-
cross tiles are revealed upfront, and hidden resources are unlikely (see below), there
isn't much to hope for. Can accept the starting site for what it is or go find a better one.
Config START_SIGHT_RANGE in GlobalDefines_advc
In singleplayer games, initially hidden resources As far as I can tell, yields from all hidden
are disregarded when choosing and normalizing resources are fully factored into the found-city
starting sites. Initially hidden resources are thus value when choosing starting sites. Only their
no more likely to appear around starting sites strategic value is discounted. A poor starting site
than anywhere else. (Less likely, in a way, can hint at a hidden resource in the surrounding
because Horse, Copper and Iron can't be occur city cross.
on rivers.)
Rationale A poor starting site hinting at hidden resources breaks immersion.
It seems that BtS and K-Mod don't even take into account in which era a resource is
going to be revealed, i.e. Coal would be valued about as highly as Copper. This
needed to be fixed one way or another.
The flip side is that AdvCiv can theoretically produce very strong starting sites
because addExtras is unaware of hidden resources. That's something to keep an eye
on. That said, at least for the AI, the city radius of the capital isn't much of a predictor
of, say, the a civ's score in AD 1.
The AI moves its starting Settler if it sees a better The AI always founds its first city on turn 0
site on turn 0 after moving its exploration units (if without moving the Settler.
any). Most of the time, the AI still founds its first
city on turn 0 (possibly after moving the Settler
just 1 tile), and it practically always has a city at
the end of turn 1.
I've made a few adjustments in the found-value There is special code in AI_foundValue for
function to help the AI evaluate potential sites for selecting starting locations, but that's not really AI
its capital. code. E.g. it evaluates also tiles beyond the city
In particular, a low-ish value is assumed for radius.
unexplored tiles. Unexplored tiles are normally treated as having 0
This change does not apply to scenarios; AI value.
always settles in place as in BtS.
Rationale The starting site isn't assured to be locally optimal, and moving the Settler is
sometimes, rarely, very advantageous. (More often, moving the Settler is only slightly
better than settling in place.) Put differently: The AI's ability to move the Settler means
that the starting site selection and normalization code doesn't have to try hard to find
or create a local optimum.
Credits Merged from the Better BUG AI mod, mostly by copying the code by Fuyu and
Afforess. I've made a few adaptations and added some special clauses to the found-
city value function because neither the tile evaluation for starting tiles nor the normal
evaluation was quite right for this AI decision.
AdvCiv Better BUG AI
The AI is reluctant to move its starting settler It can happen that can AI civ moves its settler
farther than 1 tile on crowded maps. very close to another civ's capital. Since borders
haven't expanded yet, the AI won't necessarily be
aware of the nearby rival capital.
Rationale Capitals at a close distance can be a major (random) handicap for both civs involved.
312
Credits Elkad reported a game that (s)he quit after AI Willem had founded his capital at a very
close distance. link
AdvCiv BtS
Exploration units that civs receive at game start All units that an AI civ receives at game start are
are placed on a different tile than the starting placed in the same tile. For humans, only the
Settlers, Workers and defensive units. If more Settlers are placed in the same tile; every non-
than one exploration unit is received (AI on Settler unit is placed alone on a separate tile.
Immortal and Deity), each one is placed The UnitAI type (City Defense, Explore, Worker)
separately. of the non-Settlers doesn't matter.
Since the starting Warrior that humans receive
counts as an exploration unit, nothing changes
for human civs under typical game settings. If a
human civ receives free defensive units or
Workers (low difficulty settings or later-era start),
then there is a slight change: Those units are
placed on separate tiles in BtS; now they're
Can't be placed on a different landmass than the
placed together with the Settler(s).
starting site, but can, in rare circumstances, be
Exploration units can be placed at most 3 moves placed across a large bay, i.e. a long (walking)
away from the starting site. distance away from the future capital.
Rationale My guess is that the separate starting tiles for human units were implemented in order
to nudge beginning players away from immediately fortifying the starting Warrior in the
first city. The separate placement also reveals a few more tiles and thus makes it
easier to move the starting Settler; I like that (though it may not have been the original
goal) and, now that the AI knows how to move its starting Settler, I want the additional
visibility also for the AI.
And of course it's always nice to make the rules for human and AI civs more alike.
Config BtS has a Python callback “startHumansOnSameTile” that can make human units
start in a single tile. That should still work, but won't affect AI units.
See also The path distance check is based on pathfinding code written for 104b.
Resources added during normalization can't More than 3 coastal food ruled out, and more than
result in more than 3 seafood; more than 2 3 ocean food ruled out, but both taken together
unlikely. Coastal seafood resources now count practically unlimited (up to 6).
as "high-food" resources.
Rationale Cities with more than 2 seafood grow unrealistically fast; doesn't play well either. This
happens too often.
Tbd. When I get around to XML balance changes, I intend to reduce the food yield of Pig
Pasture and Fishing Boats by one. Should make starts with overabundant food less
common.
See also 001: Whale doesn't count as a food source at all.
Try to avoid placing food as extra resources when a site already has enough food and just needs
to be buffed.
Rationale As above; don't want sites with very much food that often. Note that a high proportion
of resources allowed for normalization are food resources.
Gold can't be placed during the normalization step.
Config bNormalize flag in Civ4BonusInfos.xml.
313
Rationale There's a pretty good chance that a Gold resource will turn a relatively weak site into
one that is too powerful.
Tbd. Don't want to block Gems entirely, but would probably better not to place them at
rivers during normalization. (I wouldn't want to prohibit river Gems in general.)
AdvCiv K-Mod
Reduced the chance of lakes as extra freshwater 30%-50% chance of a lake instead of a river,
sources (in favor of rivers). depending on whether the starting tile is coastal.
(And civs will also start at a lake when there
happens to be one already before the
“normalization” step and when no river can be
placed. In BtS, starts next to a lake had occurred
only in these circumstances.)
Rationale Lakes do have the advantage of granting freshwater to up to 8 tiles while a coastal
river (single segment) only affects 2 or 3 tiles. Therefore lakes make it easier for
players to move their starting settler and support more Farms.
I'm still dialing the lake chance down because most of the early civilizations emerged
near rivers.
When adding a lake for freshwater, tiles adjacent K-Mod randomized the placement without regard
to the starting site are (strictly) preferred. BtS had for distance from the starting site. karadoc was
also done that, but K-Mod had randomized the aware of that: “[S]ince the lake placement can be
placement of lakes. anywhere in the fat cross, it is less likely to be
adjacent to the city and so that's why you might
No freshwater source gets added if there is
see fewer fresh-water starts.” source
already a freshwater tile adjacent to the starting
site (i.e. a freshwater source two tiles away from
the starting site).
314
Slightly increased StartingLocPercent for most The starting locations selected by the map script
difficulty levels, meaning that human civs receive are reassigned by the DLL based on the difficulty
slightly worse starting locations than in BtS. setting. StartingLocPercent is a percentile
rank for the human civ.
E.g. on Noble, humans receive the median On Noble, humans always get locations that are
location if the total number of civs is odd; one slightly better than the median (40% rank), i.e.
better than the median if the total number of civs they get an advantage over the AI civs. (In as
is even. much as the game can't accurately determine
whether one starting location is better than
another.)
Rationale Noble should only favor human or AI when there is an important reason to do so. And
I like giving humans rather bad starts on the higher difficulty settings; it's a more
organic handicap than e.g. free tech (see also chapter SPaH about this).
See also 250d slightly reduces some AI advantages from the difficulty setting.
Config Through Civ4HandicapInfos.xml; though I've also changed the way these values
are handled by the DLL a bit (see below).
If the difficulty level sets StartingLocPercent to Human players only ever receive the second
100 (Deity: 95), then the human players receive worst starting site.
the worst starting sites.
Rationale Could be a bug. Or the developers didn't trust their starting site heuristic and worried
about players getting unplayable starts. This shouldn't be an issue with K-Mod
(rewrites the starting site heuristic).
Doesn't really matter since StartingLocPercent isn't 100 on any difficulty level.
Except in scenarios that assign specific starting In team games, a round-robin algorithm is used
locations to specific civ leaders, the starting sites
to assign to each team starting sites of a similar
assigned to human players are selected based total value; afterwards, sites may be swapped
on the difficulty setting. around to bring members of the same team
closer together geographically. In non-team
In team games, an initial assignment of starting
singleplayer (no change), human starting sites
sites is made either by SPI (see 027) or through
are assigned based on difficulty
the BtS algorithm (see on the right; with a couple
(StartingLocPercent). In non-team multiplayer,
of tweaks). Then, if all teams have the same size,
starting sites are swapped (pairwise) between humans receive the best starting sites.
teams so that the difficulty setting takes effect
without causing team starting sites to become
dispersed.
Rationale I see no reason not to use StartingLocPercent in multiplayer and team games.
(Other than the implementation effort to make it work for team games.)
See also 135c: other multiplayer changes
CFC post about issues with the BtS algorithm for assigning starting sites to teams.
If a map script calls useDefaultImpl in The DLL will select new starting sites (based
assignStartingPlots, the DLL reassigns those team membership and difficulty) and ignore the
sites through swaps based on team membership sites selected by the map script.
and difficulty (see above).
Rationale This seemed like the easiest way to let PM use the standard reassignment algorithm.
See also Chapter about PM
315
If a map script overrides findStartingPlot but Overriding either findStartingPlot or
not assignStartingPlots, then the DLL swaps assignStartingPlots means that the DLL has
starting sites around unless a custom map option no part in the assignment of starting sites.
is set to the value “Historical”. (If assign
StartingPlots is overridden, then the DLL
doesn't swap anything; see previous blue box.)
Rationale In principle, a map script that overrides findStartingPlot may choose specific
starting sites for specific players, but none of the official and bundled map scripts do
that – so, generally, it's fine to make swaps in the DLL. In my opinion, a script that
assigns player-specific sites should override assignStartingPlots. However, the
EarthEvolution3 map script – which is essentially a real-Earth scenario wrapped into a
map script – only overrides findStartingPlot, and has an option for “Historical”
starting sites (enabled by default) that breaks if the DLL swaps locations around.
Hence the hardcoded exception.
See also CFC post reporting EarthEvolution3 being incompatible with AdvCiv 0.99 (fixed in
v1.0).
316
109 AI improvements for isolated starts
AdvCiv K-Mod
AI civs that haven't met any rival by the second Optics is prioritized when isolated but not Science
era focus more on Science, and less on the in general.
flavor values set in Civ4LeaderHeadInfos.xml
until they meet a rival.
Isolated AI civs are reluctant to pursue a culture AI civs that haven't met anyone adopt Economy
victory. Focus; I don't think that strategy is reliably
adopted when there are Friendly or faraway
Adopt the "Economy Focus" strategy when
neighbors.
alone, or when no threatening civ is known.
Economy Focus (a BBAI-introduced strategy)
reduces the production of military units.
Rationale All naval technologies have a Science flavor, and faster research will reach Optics
faster.
See also 130n bases religion hate on the number of known adherents. 130p decouples enemy
trade penalties from the has-met counter. Both should make it easier to find partners
abroad.
317
In the late game, it doesn't normally make sense to grow cities further. I'm still giving
food a fairly high weight because the AI should only avoid growth, not actually shrink
cities (leave that to human players who know what they're doing).
Per-turn limit (equal to the current era number) When in financial trouble, the AI will immediately
for the number of military units that the AI may disband as many units as it takes to reach its
disband when in financial trouble. (Doesn't apply desired upper bound on military spending.
when already in strike.)
The AI won't disband any military units when
When in financial trouble while losing a war, the losing a war (except when forced by the rules in
AI may still disband units but is hesitant to do so. a strike).
Rationale Allowing the AI to disband an arbitrary number of units is clearly dangerous. Income
may well increase (gradually) in response to financial trouble. Not disbanding at all in a
bad war will eventually lead to strike (and then the AI doesn't get to pick the units).
So long as the AI has any undeclared war plan, it tries to cap its military spending.
Rationale Declaring war will often reduce the funds of the AI through canceled trades or angry
citizens, and unit supply can add to expenses (though the AI gets a 50% discount on
supply costs). Declaring and then having to disband units is really bad.
See also vedg posted a savegame where this happens to the K-Mod AI.
When deciding which units to disband, the AI Based on production cost, XP, unit AI type and
takes unit locations on the map into account (in a mission AI type. And every city has to retain at
rudimentary way – plot danger, city threat, least one defender.
mission target plot).
Rationale Try not to disband units that might be about to die in combat.
318
AdvCiv BtS
Can't pillage routes on unowned tiles that contain No special restrictions for pillaging unowned tiles.
a (non-Spy) unit of a different team. Can, in particular, pillage routes in order to slow
down another civ's units.
Rationale Not an important change. Yanking out roads from under other civs' stacks is pretty
bizarre, and occasionally exploitable.
Rationale Just prolongs the inevitable. (It does look strange when the last non-vassal player in a
game capitulates, but, even then, it's better not to drag the game out.)
319
"Your land is too far away" rules out vassal The AI refuses to become the vassal of any civ
agreements only until the Industrial era. If the that it doesn't share a continent with.
prospective master is in the Industrial era or later,
its power rating is decreased when not sharing a
continent with the vassal, but a vassal agreement
is possible.
Master refuses to accept voluntary vassal whose Only considers refusal when acceptance means
population is much smaller than the master's war.
unless aiming for Conquest victory or liking the
vassal.
Rationale Peace vassals are fickle and may lead to wars with third parties. Not worth the hassle
unless they bring a considerable economic value.
When deciding whether a vassal breaks free, the A capitulated vassal with, say, 12 tiles initially
territory of the vassal is treated as at least 10 gets to break free after losing 6 tiles (from war or
tiles large. Thus, a vassal that has fewer than 15 culture pressure). Voluntary vassals don't care if
tiles left when becoming a vassal can only break they lose tiles.
free by gaining land, not by losing land.
Rationale Through change 143 (cancelation of voluntary vassal agreements), vassals with very
little territory left can end up changing hands a lot.
Civs that are at stage 3 or 4 of any victory Civs that are close to domination victory refuse to
strategy refuse to sign vassal agreements, and become vassals (such civs will normally also be
break free if they can: "We'd rather win the way too powerful to accept, so this is pretty
game." pointless). In K-Mod, civs refuse to accept
vassals that are at stage 3 or 4 of Culture or
The leader of AP or UN also refuses/ breaks free.
Space victory ("Surely, you must be joking"); may
also cancel the agreement. Diplo victory not
covered.
Rationale Don't want a civ to win the game while hiding behind a master who can't cancel the
agreement, especially not a human master. Important to let the vassal refuse (not the
master) because the master could be human.
See also 115 prevents civs with too little production capacity from pursuing a Space victory,
which is important for this change: Technologically advanced civs might otherwise
refuse to ever capitulate once they have the Apollo Project.
143b prevents vassals from having nukes.
014 prevents capitulated vassals from pursuing victory strategies.
A colonial vassal can break free like a normal Only attitude can cause an independent colony to
voluntary vassal, but the vassal's personality has break away. And since the +10 "granted us
less impact and stricter piower and attitude independence" bonus doesn't decay, this
thresholds apply. happens practically never.
Rationale A War of Independence should at least be a possibility.
See also 130r causes "granted us independence" memory to decay.
An AI civ ready to become a vassal contacts the The same contact-delay is used for vassal
prospective master only with a per-turn agreements as for permanent alliances, but this
probability. The probability is based on the only affects offers to human players. There is
scoreboard rank of the master – between 1 in 20 only a 1 in 80 chance of implementing a
if the master is ranked in the middle of the permanent alliance but no such probability for
scoreboard, and 1 in 40 if the master is at the voluntary vassal agreements; they're checked
top. Increased by 400% if at war with anyone. each turn and are directly implemented.
320
Rationale It's possible that the Warlords developers had meant to use the permanent alliance
probability also for vassal agreements and misplaced a closing curly brace. Be that as
it may, civs are too quick to sign vassal agreements when their power ratio takes a
dip, which doesn't only happen in defensive wars, but also when an AI focuses on its
economy (AI strategies Economy Focus or Get Better Units) or after an unsuccessful
aggressive war.
The change only affects AI-AI vassal agreements. Could also implement it in a way
that makes civs more reluctant to become vassals of human civs, but that's a bit more
work, and I think it's still difficult enough for humans to obtain AI vassals because
humans can't generally afford large enough armies to impress the AI.
Probability based on rank should reduce snowball effects.
When a vassal is more advanced than its master, The master may gift techs to the vassal but not
the vassal may decide to gift tech to the master vice versa.
from time to time. This is contingent on a
sufficiently high relations value (Cautious when
capitulated, otherwise Pleased).
Rationale The master should gradually catch up with a technologically more advanced vassal.
Normally this happens through tech trading, but sometimes the vassal is too far
ahead. Not (historically) plausible that it takes a civ forever to absorb the tech of its
vassal. From the vassal's point of view, one can argue that a voluntary vassal is – to
an extent – invested in its master's success. A capitulated vassal prefers to break free,
but this is always a long shot and, if relations have thawed, helping the master win is
still better than a rival victory.
See also 130v makes vassals always Friendly toward their master – this does not apply when
deciding whether to gift tech.
In this demo game of mine with an earlier version of AdvCiv, Tokugawa managed to
make Willem capitulate in the midgame despite being some 10 techs behind; the two
remained unable to trade tech for much of the rest of the game because it took
Tokugawa too long to catch up.
130z deals with tech gifted between non-vassal rivals.
AdvCiv BBAI (v0.83)
Disabled BBAI's human-as-vassal option. This option had allowed human players to offer
themselves as vassals to an AI master. The
option was disabled by default (through XML).
K-Mod enabled the option, but K-Mod AI changes
CvTeamAI::AI_surrenderTrade seem to have
broken it. At least in K-Mod 1.45, I can't bring any
AI civ to accept a human vassal, and the
explanations (denial text) don't make much
sense.
Rationale Looks like too much work to make this work. Also, it's rarely smart to accept a human
vassal – it's not going to send military assistance and will work hard on breaking free.
See also Rise & Fall and Debug mode allow human players to take control of a vassal. This still
works; I've only disabled the option of becoming a vassal through diplomacy.
Config Can re-enable it through BBAI_Game_Options_GlobalDefines.xml, but I don't think
the AI is ever going to accept.
321
112b AI changes to surrender decision
See also 123d blocks an exploit where cities gifted to a war ally can lead to faster capitulation.
AdvCiv K-Mod
AI civ doesn't surrender unless there are Enemy positions matter for peace treaties, but
numerous enemy units in its territory on an surrender is only a matter of power and war
important landmass (or having been nuked). success.
Also refuses to surrender If 30% or more of the
civ's population are on a landmass with few
enemy units.
Response is "You'll have to take it from our cold, That response isn't used anymore at all. BtS used
dead hands" if denied. it for cities that the AI didn't want to trade.
“It looks like your offensive has run its course” as
of AdvCiv 0.99.
Rationale Let the enemy demonstrate that they can reach our important cities before
capitulating.
See also CFC post about the refusing-to-surrender response.
Don't surrender while there are units en route to This is checked before signing peace treaties but
the master's territory. not when considering surrender.
If a war enemy is the worst enemy of an AI civ The worst enemy's power is treated as 25%
and the attitude toward that enemy is Furious, lower regardless of attitude.
the enemy's power is treated as 10% lower than
it actually is. I.e. the enemy needs slightly more
power in order to achieve capitulation.
Rationale Should perhaps disable this power adjustment entirely. It makes some sense
flavorwise, but makes capitulation easier to achieve when the winning side already
has a much larger army when the war starts; otherwise, it'll take time to get the upper
hand, and "This war spoils our relationship" will typically lead to a Furious attitude.
From a human pov, it's annoying if the AI won't capitulate when a war has already
become tiresome.
Tbd. Attitude could play a bigger role when there is more than one powerful war enemy.
When considering capitulation, the power The master's power is modified based war
modifier based on war success is applied to the success, and therefore only matters when
vassal's power, meaning that war success comparing the vassal's power with that of the
matters not just for the vassal-master power ratio master.
but also when comparing the vassal's power with
the average power of other civs.
A civ refuses to capitulate unless its power rating The threshold is 80%.
is at most 76% of the global average power
rating.
The impact of war success on capitulation is Can increase the master's power by up to 100%.
reduced a bit overall. Can reduce the vassal's
power by at most 45%.
Rationale Perhaps the average power shouldn't matter at all for capitulation. Now matters less
when the master's war success is high.
322
See also 251 reduces the AI work rate bonuses from the difficulty setting.
AdvCiv BtS
The City AI prioritizes workers until the total Workers prioritized only when there are far too
number of needed workers is reached. few of them; otherwise, any decent building takes
precedence.
And several tweaks to the probability of training
a worker and the target number of workers (total
and per city).
Rationale The K-Mod AI tends to train 1 worker per city (BtS: fewer), which is about right for an
experienced human player, but the AI isn't good at scheduling its workers, so 1/city
isn't enough. Also note that the AI generally isn't good at choosing city production.
Can't go too wrong with a worker – except in the very early game and unless there are
evidently too many already.
Should be about 1.5/city now. (Also a matter of traits, leader personality – especially
BuildUnitProb –, coastal cities, colonies ... so it varies a lot.)
Config Can be tweaked through WORKER_RESERVE_PERCENT in GlobalDefines_advc.xml,
but that only affects the upper limit for the total number of workers that an AI civ may
produce and not (or only indirectly) the number of workers assigned per city and how
worker production is prioritized.
Tbd. Should take into account currently researched tech (e.g. Calendar, Railroad).
Workers without any important task should flock to a settler (if any) or even start
building a road toward any guarded city sites (CvUnitAI::AI_guardCitySite); will
currently only move there once a new city has been founded (except for colonies:
workers are already being shipped together with settlers).
See also 117: AI chopping; 121: Forts; 040: Improvements on landmasses without cities
Fuyu has tried to get the AI to build more Workers as well, but I think, by now, my own
code supersedes his; haven't looked at the details though. The code in question is in
CvCityAI.cpp, marked with "Build more Workers" (also "Worker Counting"?).
The number of Workers that the AI aims at The AI only checks for unimproved tiles. Whether
having near a city takes into account Forests and the missing improvements will require extra work
Jungles on workable tiles. for clearing terrain features isn't checked.
Made the AI more reluctant to chop Forests near a city that is producing a Worker.
Rationale If the AI has time to chop, then it can't be that short on Workers.
When a city has 2 assigned workers but requires Not sure if BtS can reassign workers at all so
only 1, the AI considers assigning one of the long as there is anything left to improve near the
workers to another city. current city. The code for reassignment is
apparently erroneous (K-Mod comment: “Is it just
me, or did they get this backwards?”) The K-Mod
code still got it somewhat backwards I think (see
my own comment in CvUnitAI::AI_workerMove)
and doesn't allow reassignment when a city has
2 workers and needs only 1.
Rationale This change/ bugfix should make AI worker management quite a bit less inefficient. A
BtS comment (by Blake probably) above CvCityAI::AI_getWorkersHave says:
“Workers have/needed is not intended to be a strict target but rather an indication. if
needed is at least 1 that means a worker will be doing something useful”
So, the number of workers needed is a conservative estimate; more workers than that
are probably way too many.
323
When deciding whether to let a small city grow The decision is, in part, based on the yields of
before a settler or worker, the AI anticipates the tile that an additional citizen would work.
border expansion and improvements. Unowned tiles are disregarded and only existing
tile improvements count.
BtS has an extra clause that prevents cities
below size 3 from producing any workers or
settlers until the owner has at least 3 cities.
K-Mod and AdvCiv have mostly removed this
restriction.
Rationale Especially relevant for the capital at game start.
See also A bugfix in the tile evaluation code (CvCityAI::AI_getPlotMagicValue) has been
tagged with “advc.001”.
Made the AI reluctant to produce Workers in The number of other cities on the same
colonies that had already been fully improved at landmass isn't taken into account when the AI
an earlier time and need more Workers only due decides whether to produce a Worker.
to a new tech or a change in AI yield weights.
Added code to avoid shipping out more Workers All idle Workers can get shipped out and are then
than a landmass can spare. urgently replaced because BBAI has added
some high-priority clauses for landmasses with 0
available Workers.
Fixed a likely bug in the code for ferrying The number of needed Workers decreases as
Workers in between cities: Only the Workers improvements are built, so the error is self-
needed by each potential target city had been correcting. However, in the late game, the AI may
counted, not the workers already available there. quickly ferry all idle Workers to some small
landmass and delete most of them once they
become idle again because the landmass will
then have far more Workers than needed.
Rationale These changes were prompted by a test on an Archipelago map with Tropical climate
starting in the Modern era. The AI ended up deleting dozens of Workers. Deleting
some Workers is reasonable under these settings – Workers are relatively cheap this
late in the game and a colony (with free initial population due to the start era) on a
large Jungle-covered island needs a large group of Workers a.s.a.p. However, the K-
Mod code kept producing, ferrying and deleting Workers even once all land was
settled and improved.
324
Idle Workers that have retreated to a city tile are Workers that have retreated to a city (which is
counted as available to that city; Workers in what idle Workers normally do) are not counted.
cargo destined for another landmass are not Workers in cargo are counted regardless of the
counted as available. transport's destination. The BtS code had worked
differently, but probably also incorrectly.
Rationale A bugfix really.
AdvCiv BtS
The number of Workers available to a city is There's an update once per turn (still true in
updated over the course of a turn. AdvCiv); updates throughout a turn happen in
CvUnitAI::AI_improveLocalPlot and
AI_nextCityToImprove, which covers only a
fraction of the possible Worker moves.
Rationale Mainly to avoid transporting or deleting too many Workers in one turn.
325
AI city-attack stacks will attack even when the In such a situation, the AI will rather try to pillage
attack looks risky and costly if the stack can't surrounding tiles.
bombard the city further and can't find a good
alternative target to attack.
Rationale Attrition warfare should be a last resort; tends to work out more badly for the
aggressor than a costly (or perhaps even a failed or ephemeral) city attack. Both
sides may just keep adding units, staying deadlocked for dozens of turns.
114d Decreased random portion of attack courage
The random summand added to AI attack AI units have a bias toward attacking based on
courage is between 0 and 12 for AI civs and leader personality. The bias is composed of a
between 0 and 31 for Barbarians. Increased the deterministic base value between 0 (e.g. Ashoka,
base attack odds change of Barbarians by 2. Barbarians) and 6 (Ragnar and Napoleon) and a
portion chosen at random once per turn between
0 and 32 for the Barbarians and between 0 and
16 for all civ leaders.
Rationale If the AI attacks completely rationally, defensive tactics won't really work anymore; but
I think making the AI a bit more rational won't hurt.
Not the Barbarians though, which had attacked a lot more mindlessly in BtS than in K-
Mod (don't recall if that's due to a K-Mod or a BBAI change).
Config Partly through the DLL, partly through Civ4LeaderHeadInfos.xml.
114e City attackers in a friendly city may opportunistically attack enemy units approaching
the city (“leave attack”).
Credits More Naval AI (Tholal)
326
Rationale The K-Mod AI goes for military victories too often (or early) for my taste. The BBAI
approach of letting the AI play more rationally is fine, but let's not turn it into a
wannabe HoF player.
50% means 24% of the world population and 32% of the land, i.e. about a "double
share" in a standard game: 2 in 7 is 28.5%. This shouldn't quite be enough to trigger
domination 3.
55% means that 35% of the land is needed for stage 3. That's right between 3 in 7
(42.8%) and 2 in 7.
I'm factoring in the number of civs because it is easier to conquer more land when that
land is divided among several weak opponents than when it is owned by a few
powerful ones.
Added a condition that makes the AI less willing No such condition.
to go for Conquest victory if there are many rivals
on other continents.
Escalated the conditions so that the conquest The half-rivals-defeated condition is checked for
stage is essentially one less than in BBAI/K-Mod. stage 4 (which becomes stage 3 in AdvCiv), but
Added requirements for stage 4: half of the initial there are also alternative conditions for that
rivals, rounded down, need to be defeated. stage.
Rationale As above: military victories are too commonly pursued. Also: It's problematic when an
AI civ goes for a military victory before naval invasions become feasible, because it's
too difficult for players on other continents to interfere in time.
Made the conditions for culture victory strategies more narrow.
Rationale Culture-loving AIs can be unpleasant to play against (culture pressure, wonder
grabbing), so the AI should only go for it when there is a realistic chance of success.
(Only relevant if UWAI is disabled.)
When in multiple wars at once, the AI ignores its AI in Conquest 4 or Domination 4 never ends a
military victory stage and applies the normal chosen war so long as war successes are
decision process to any war that is no longer favorable.
recent. I.e. multiple wars are still possible, but
the AI won't just refuse to talk.
Rationale It's OK that an AI close to a military victory likes to fight wars, but it doesn't have to
insist on fighting everyone at once.
Conquest 4 only when owning at least half of the world's cities.
Rationale Even when militarily superior, conquering so many cities is going to take time.
Space victory not pursued if total production Once Apollo Project is built, stages 3 and 4 can
clearly insufficient. be reached just through technological progress.
Stages 3 and 4 require a significant portion of the
necessary parts to be completed.
Rationale To discourage small civs, say, with just three cities, from pursuing a space victory. If
they want to have a chance, they'll need to expand instead. Also to discourage civs
that had come close and then lost half of their cities at war; such civs should at most
be at stage 3.
If a civ has a very large total production rate in the endgame, Space victory is considered even if
other civs are a bit more advanced technologically.
Rationale Mostly to allow civs that are pursuing a military victory to switch to Space victory if
they run into a stalemate with another very powerful civ.
327
Domination 2 requires the AI to be in the upper Upper half suffices.
third of the scoreboard.
Rationale Military victories can't really be won from way behind. (Which isn't to say that civs in
the middle of the scoreboard shouldn't start wars.)
115b Stages for Diplo victory revised
AdvCiv BBAI/K-Mod
Based mostly on the current (voting) population Based on leader personality, randomness and, a
of the own team, vassals and friends. Personality little bit, on Aggressive AI and Always Peace
and randomness still factor in; game options game options.
don't (unless Diplo victory disabled).
Stages 3 and 4 can be run regardless of other Stages 3 and 4 are impossible if already in stage
victory stages. 3 or 4 of another victory condition.
AI prioritizes food a bit at stage 4 (grow votes). K-Mod takes into account the favorite civics of
rivals when evaluating civics at stage 3.
Rationale This part of the victory-stage code hadn't been revised by karadoc and it didn't do
anything intelligent. Checking for peaceful game options isn't good: Diplo victories are
usually half conquest, half diplomacy.
Diplo victory isn't often a viable route for the AI. I've made the changes mostly
because I had already written code for estimating voting populations for UWAI.
Diplo victory stage 2 factors into the decision to Only stage 1 is considered for AP/UN. No
build AP and UN. The AI avoids building AP/UN if avoidance.
another civ seems closer to Diplo victory. (NB: Building evaluation also affects AI tech
paths, i.e. the AI is able to aim at Mass Media – if
it can properly evaluate the UN.)
Tbd. Doesn't look reliable; at best, it'll no longer build the UN when it's obviously a terrible
blunder.
See also 178 is supposed to improve CityAI decisions about the AP.
031 makes the AI more willing to found cities when near Domination.
AdvCiv BtS
When near a religious victory, the AI is more "Missionary" is a BtS strategy that is adopted
inclined to pursue the "Missionary" strategy, and based on AI flavor and the number of civs with
its vassals switch out of Theocracy. Open Borders and whether they've already
converted. Victory doesn't play a role.
The AI makes no effort to deal with Theocracy.
Rationale Should at least allow the AI to win an AP victory when all human players are already
members of the AP. Will otherwise have to use Holy Wars to bring down the humans.
Tbd. AP victory conditions need to be overhauled. It's silly that a single converted city
makes all the difference in victory votes. (War votes are already addressed by
kekm.25.)
328
The AI proposes the victory resolution when it AI chooses uniformly at random from all the
gets the chance and a team member is at Diplo resolutions that it supports.
victory stage 4.
Voting AI abstains if it likes two candidates Votes for the candidate with the lowest internal
equally. id; normally humans have lower ids than AI civs.
Also abstains when at stage 4 of a victory May vote for someone else's diplo victory even
condition. e.g. after launching a spaceship.
Tbd. The AI still proposes random resolutions in all other cases, and this is often agonizing
to watch.
Under “let's discuss something else”, should allow asking the AI whether it would vote
for the active player. Could call the option sth. like “If there was an election next
tuesday ...” Then just call CvPlayerAI::AI_diploVote (should make that const too).
Snarky attitude-flavored responses would be nice.
115c Victory strategies in zero-sum games
AI doesn't pursue Diplo victory when there's just Diplo2 possible with just one rival, but UN and AP
one other team left; AI does pursue Conquest if require at least two other teams.
there is just one other team to begin with.
Conquest1 requires at least one civ to be a
vassal or eliminated; doesn't work if there are
only two teams at game start.
Rationale Both only really relevant for games against a single AI opponent.
115d Show human victory stage in debug mode
Debug mode has no bearing on victory stages. The victory stage of human civs is computed as if
they were AI civs when in debug mode.
(No change.) Also, human civs can never be at stage 1 or 2 of
a victory strategy, only 0, 3 or 4.
Rationale Since R&F, UWAI and other parts of the AdvCiv AI code use victory stage in order to
determine whether a (rival) civ is getting close to a victory condition, it's important to
see the human victory stage the same way that the AI sees it.
Stage 1 and 2 are probably too unreliable and might lead to peculiar decisions from AI
governors of human cities. I'm guessing that's why BBAI restricts human victory
stages. Fair enough; the AI only needs to know when a human is close to victory; 0, 1
and 2 don't (need to) make a difference.
Tbd. The AI_calculate..VictoryStage functions aren't ideal for determining how close a
civ is to victory. The main purpose of these functions is to determine whether and how
much the AI should focus on a particular victory condition; therefore, e.g. AI flavor
values factor in. Would be better to write separate code for measuring the progress
toward victory.
115e Minor misc. changes to AI decisions about victory strategies
329
The redistributed weights also affect AI decisions remaining conditions do not increase. E.g. when
about the use of Great People. Some other AI Space victory is disabled, AI leaders become
decisions – which seem to interpret the victory more interested in Culture only insofar that being
weights as more general personality traits – still well positioned for a Space victory can't get in the
use the weights as defined in XML. way of plans for a Culture victory.
Rationale Don't want AI leaders to play (somewhat) aimlessly when some conditions are
disabled. However, zero weight should still mean that the AI doesn't pursue the
respective victory condition.
330
When an AI civ conquers a city that, if The dangerous city is razed in any case.
reconquered, may soon lead to a Culture victory
of the previous owner, the conquering civ razes
the city if reconquest seems plausible (based on
power ratios and nearby units).
Rationale The BBAI comment actually said to raze unless we "overpower" them, but no power
check was there.
AdvCiv K-Mod
The AI is extra reluctant to raze Barbarian cities. Some parts of the raze value computation
already directly or indirectly take into account
whether the city is Barbarian.
Rationale Some advantages of conquerting cities from Barbarians probably aren't fuily covered
by the K-Mod code. E.g. they tend to have smaller tile culture values and other
Barbarian cities hardly exert any culture pressure. Also, it practically never makes
sense to raze a city just to make sure that the Barbarians can't ever get it back.
More importantly, the AI doesn't currently evaluate whether Barbarian cities are worth
conquering (or if it does, it's not working well). When a city is razed, this AI flaw
becomes obvious to the human player. Better try to cover that up than to break
immersion.
See also Tbd.-note toward the end of change 300 about improving the AI for targeting Barbarian
cities.
331
Tbd. Chopping along rivers is historically sound but on hills not so much. Perhaps I'll allow
Mines to coexist with Forest (though some areas were deforested for producing
charcoal for smelting ores).
The AI should arguably chop even more. I intend to nerf chopping instead, probably
by restricting the yield to apply only to buildings and ships.
Should arguably only chop if that'll speed up the current city production, i.e. if it isn't
already about to finish. I've only implemented that for the decision to chop while
producing a Worker (covered by 113) so far.
See also 113 also includes chopping opportunities in the estimated Worker tasks.
064b prevents chopping production from being converted into overflow gold.
AI chops Forests outside of city radii. The AI never chops Forests on tiles that no city
Restrictions: can work on.
• Only when there is nothing else to do.
• Not when automated and chopping is
disallowed in options.
• Not if there is already anger from global
warming.
• Not near planned city sites.
• Not on improved tiles (e.g. Fort).
• The AI builds a route to the tile before
chopping.
Possible future cities, distance and the correct
timing of the chop aren't considered.
Rationale My conditions are simplistic and rather conservative. At least the AI now fells
unworked Forests within its own borders at some point.
Tbd. Considering to set 0 yield from chopping outside the BFC; then this change will be
obsolete.
See also 119 prohibits chopping on unowned tiles, i.e. the AI doesn't have to worry about those
tiles.
012 gives Forest and Jungle a defensive bonus that only the tile owner benefits from.
Therefore this change in K-Mod 1.45, which makes the AI more inclined to chop
Forests in the inner city ring, has no effect unless change 012 is disabled. (I've still
merged that K-Mod change.)
332
Rationale A minor thing that vexed me in one game. The AI should stop inconclusive wars
between its partners.
The second part is probably a bug in K-Mod. A comment says, "if [we] like them
enough to not declare war on them", and this isn't what the code does.
See also UWAI (104n) partly handles peace vote decisions, but 118 still applies.
An AI civ will always defy when its last city is to 1 chance in 3 to defy when a city owned by the AI
be assigned to another civ. civ or its teammates is to be reassigned. That's
all.
Credits krikav managed to eliminate an AI civ through an Apostolic Palace vote: CFC link
Tbd. Check how important the city is relative to the AI civ's total economy and how much
defiance will hurt etc. BBAI comment: "Wonders, holy city, aggressive AI?”
Ideally use existing city evaluation functions.
333
to use that mission).
Messages about rival counterespionage missions are shown in white, not in red.
Rationale Often, the affected player isn't even using espionage, so a counterespionage mission
shouldn't use the color of alarm.
Capitulated vassal disregard their master and Not sure if there's something to prevent
other vassals of the master when checking for capitulated vassals from trying to steal their
tech-steal targets. master's tech (or anyone's).
Rationale When a vassal switches to an espionage economy to steal tech from the master, then
the commerce generated by that vassal is essentially lost to the master. This would be
too much of a disadvantage, potentially discouraging players from accepting vassals.
Tbd. Capitulated vassals should only ever attempt to steal techs that the master doesn't
already have.
Made some tweaks that reduce the weight that the AI assigns to espionage commerce (now in a
function CvPlayerAI::AI_calculateEspionageWeight).
Rationale My impression is that, on average, the AI weight should be as defined in
CIV4CommerceInfo.xml: 1 gold being worth 0.25 espionage. There are situations
when espionage is worthless or almost, so the average weight excluding such
situations should be a bit higher, somewhere between 0.3 and 0.4. The K-Mod code
seemed to end up at the upper margin of that range.
See also Actually, the average weights assigned by K-Mod were quite a bit higher, but that was
due to a bug described under 001.
120b AI Spies less malicious
Tbd. Higher AI diplo penalty for malicious missions, and no diplo penalty for failed missions.
E.g. 2/3 chance of a diplo penalty (and spy identity revealed) for successful malicious
missions, 1/3(4?) for successful non-malicious missions. Espionage screen should
then indicate which missions are considered to be malicious.
See also 130v makes Spies less likely to attack capitulated vassals.
AdvCiv BBAI
AI uses "malicious" espionage only when Attitude threshold not leader-specific. With
Cautious or Annoyed, depending on the leader's Aggressive AI, malicious unless Friendly,
no-war threshold. (If no war at Pleased, then otherwise malicious unless at least Pleased.
malicious at Annoyed; if no war at Friendly, then
malicious at Cautious.)
Aggressive AI has no impact on AI malice.
(AI may also be malicious when planning war or
against a civ that is close to victory; no change.)
Rationale The "take that" missions are rarely beneficial for the AI (although the K-Mod AI uses
them quite well). I like them for flavor, but, flavor-wise, malicious espionage only
makes sense against enemies. Aggressive AI still has an indirect effect because war
plans enable malice, and Aggressive AI leads to more AI war plans.
No fomented unrest, poisoned water or Cities in disorder are only exempt from
sabotaged building while a city is in disorder. sabotaged building K-Mod comment:
"disorder messes up the evaluation of production
and of building value"
Rationale Cities in disorder won't lose food.
No revolt incited when city defenders are The K-Mod code only make sure that the
334
overpowered by a factor of 8:1 or worse. defenders aren't too powerful. Will even use the
revolt mission against undefended cities.
(Whereas BBAI had a clause – disabled in
K-Mod – that blocked the revolt mission when the
attackers were more than twice as powerful as
the defenders.)
Rationale 2:1 as in BBAI would be too strict. Just because a city can be conquered without
inciting a revolt doesn't mean that a revolt isn't worthwhile.
The Espionage Economy strategy greatly K-Mod added this strategy; comment in
reduces AI espionage weights against civs from AI_Defines.h: "run high espionage slider to
whom no techs could be stolen. steal techs at a discount."
When hoping to steal a tech from a particular civ,
the weights of other civs are halved.
Decreased chance malicious missions further Espionage Economy already decreases the
when in Espionage Economy. chance of malicious missions.
Rationale Espionage Economy tends leads to a much higher espionage output than normal.
Even 10% of that can amount to a lot of wasted commerce if it's spent on frivolous
missions.
120c Hide the espionage slider when it's at 0
AdvCiv BtS
Espionage slider not shown on the main interface Once Writing is discovered, the Espionage slider
when it's at 0. Added the slider to the Espionage is shown on the main interface, city screen and
screen. Finance tab of the Economics Advisor.
Rationale More room on the main interface. Many players hardly ever touch the espionage slider.
Config Optional through the "General" tab of the BUG menu. Since AdvCiv 0.98, the slider is
again always shown by default.
See also 120g requires Alphabet for adjusting the slider.
106b benefits from this option because, at its (hardcoded) default position, the Event
Log overlaps with the espionage slider.
History Rewritten also places the espionage slider on the Espionage screen (though I
don't suppose it's removed from the main interface).
Tbd. Occasionally (rarely?), the Espionage screen gets garbled when the slider is moved
from 0 to 10. See comment in CvPlayer::setCommercePercent.
Position the Domestic Advisor window so that Positioned so that there is room for three sliders;
there is space for two sliders above it and space unit icons are half-obscured.
for unit icons below it.
Rationale Even if the espionage slider is shown on the main interface, I don't think it's important
to show it when the the Domestic Advisor is open.
335
green.
Rationale If it isn't paid, it isn't a cost.
Credits The green numbers I've seen in another mod, probably BULL or BUFFY.
No mission costs are listed if the player can't Mission costs are listed as soon as the player
train Spies (i.e. prior to Alphabet). Exception: learns the location of a rival city.
Costs are shown if the player controls a Great
Spy.
Rationale Rather distracting to see the costs early in the game.
See also Ties in with change 004w (uncluttering the UI).
A Great Spy prior to Alphabet is a rather academic possibility since the Great Wall no
longer provides Great Spy points (change 310).
If mission costs are shown, the Sabotage Three separate entries. Costs are shown for all
Production/Improvement/Building missions are except Sabotage Improvement. The cost for
shown as a single item "Sabotage" with mission Sabotage Production gives away the number of
cost "?". hammers spent on the target city's unfinished
production. The cost for Sabotage Building is
Sabotage Project is shown with a cost, but
based on the cheapest building in the city.
omitted entirely if the city doesn't have a project
(a.k.a. Spaceship Part).
Rationale The Sabotage Building cost is mostly unhelpful – unlikely that the player wants to
sabotage the cheapest building.
The amount of invested production is useful information (close to completing a
Wonder?) – but arguably information that the player shouldn't get for free.
The cost for Sabotage Project doesn't give anything away I think; Spaceship Parts are
listed on the Victory screen.
See also 103 allows Spy units to investigate cities; that's the fair way to find Wonders under
construction.
045 hides buildings in rival cities (meaning that the Sabotage Building cost does give
away secret information)
See also Should show the missions as in BtS when able to investigate the city. And should
additionally name the cheapest building and the current production and its progress as
"hammers/hammers needed".
"Steal Technology" is shown without a cost if the The cost for stealing the target's cheapest tech is
player is unable to trade techs with the owner of shown unless there is nothing to steal.
the target city. If they can trade, the cheapest
tech (on which the mission cost is based) is
shown in parentheses in addition to the cost.
"Steal Treasury" shows the amount of gold that Can compute the amount of gold from the shown
would currently be stolen (and on which the mission cost.
shown mission cost is based).
Rationale Don't want to give away the cheapest tech in situations when tech is otherwise secret
(pre-Alphabet, No Tech Trading option). If a cost is shown, the cheapest tech can be
deduced; more convenient and transparent to just name the tech. Same with gold.
See also 004i tells a player from whom gold was stolen how much was stolen.
336
AdvCiv BtS
The effects of poisoned water and fomented The effects of spy attacks are treated just like
unrest don't affect the AI population target, other causes of bad health and anger when
meaning that the AI tends to prioritize food more setting a population target, meaning that the AI
after a spy attack (in order to keep the current lets its population shrink after a spy attack (may
population despite food lost due to anger and bad even de-prioritize food).
health).
See also 160 slows down starvation
Tbd. The AI should be more upset about poisoned water and fomented unrest than about
other spy missions. Could implement that, but spies get identified too rarely (25%;
ESPIONAGE_SPY_REVEAL_IDENTITY_PERCENT) for it to matter. Perhaps give these
missions a 50% chance of revealing spy identity even when the spy isn't caught? See
also Tbd. under 120b.
337
120h Keep espionage-against ratios secret
AdvCiv K-Mod
Espionage-against ratios aren't shown anywhere BtS shows as a ratio on the scoreboard and on
(as in K-Mod) and the espionage icon on the the Foreign Advisor screen how many espionage
scoreboard (disabled by default) is shown when points the active player has accumulated against
the active player has set a positive weight on the each rival (that info is still available on the
Espionage screen against a rival. Espionage screen) and how many espionage
points the rival has accumulated against the
active player. Since K-Mod 1.26, this espionage-
against ratio is no longer shown. The espionage
icon on the scoreboard is disabled by default in
K-Mod, but, if enabled, it shows whether the
espionage-against ratio is greater than 1.
On the Espionage screen (no change in AdvCiv),
an espionage icon is shown next to rivals against
whom the active player has set a positive
espionage weight.
Rationale The K-Mod change seems to irk some players greatly, but I don't see why. One reddit
user writes that “it makes espionage much more difficult, annoying and non-
worthwhile.” That sounds like tech stealing strategies depend on the espionage-
against ratio somehow, but the cost of espionage missions isn't based on that at all, it's
based on the total espionage ratio (points that active player and target respectively
have ever accumulated against anyone) and that ratio is still shown on the Espionage
screen. (Plus, in K-Mod, it's cheaper to conduct missions against civs with a large
population.) Also, how hard can it be to guess, approximately, the AI espionage
weights?
So I'm keeping the K-Mod change because the espionage-against ratio is misleading
(suggests that the ratio of points accumulated against each other is important) and can
give away information about unmet rivals and AI war plans. The espionage icon on
scoreboard probably can't really give away such information, but it's more
straightforward to keep the espionage-against ratio entirely secret. Also, the BtS
condition for showing the icon was difficult to guess (as there's also the total
espionage ratio shown prominently on the Espionage screen) and nearly impossible to
guess when espionage-against ratios are hidden. The new meaning of the scoreboard
icon is consistent with the icon shown on the Espionage screen.
Tbd. The scoreboard icon probably isn't very useful now. Perhaps add some hover text
and/or let a right-click on the icon set the weight to 0. Note that the passive missions
(demographics, see research) are already covered by other scoreboard columns
(power ratio, current research).
AdvCiv/ Vanilla Civ 4/ Warlords BtS
Messages about spy missions against a human Messages are shown immediately when the
player are shown at the start of that player's turn missions are executed.
(bForce=false).
Rationale Don't want players to infer the spy owner from the timing of the messages. The original
Civ 4 code in CvUnits.cpp (e.g. CvUnit::destroy) had gotten this right; BtS mucked
it up.
338
AdvCiv BtS
The cost for stealing a technology is based on the Same, but partial progress is ignored.
number of research points that the recipient
would need in order to discover the technology,
i.e. partial progress counts.
Credits VIP mod
Rationale More intuitive to me. As for balance, this could make quite a difference for players who
never increase the espionage slider. The espionage points generated from buildings
alone are usually too few for stealing a technology or, often, carrying out any useful
mission. If partial progress counts, then even small amounts of espionage can be
converted into research. This will require some attention to detail on the player's part,
and that could actually annoy players who dislike the espionage system; but I'd like to
give it a try.
339
For deciding whether to build a Fort or a cheaperThe Worker AI frequently builds Forts on
improvement to connect unworkable resources, resources that aren't (yet) workable. Forts are
the AI uses a heuristic that considers the always preferred on these tiles.
following circumstances:
• How busy Workers currently are overall;
• whether the tile has natural defenses;
• whether a city is planned on or next to the tile;
• and whether a Fort would function as a canal.
AI always prefers any improvement with a Once Fort tiles become workable, the AI is
positive yield over Forts on workable tiles, and hesitant to replace Forts with yield improvements.
replaces the Fort when a tile with a Fort
becomes workable (once a Worker finds time to Also likes to build Farms and Cottages on
do it; not necessarily high priority). revealed but yet unusable resources, and doesn't
(Fixed a possible bug that may have prevented improve-
replace them with improvements that connect the
ments that connect a resource – like Forts – from being resource later on.
replaced – even by an improvement that also connects the
resource). Probably not a bug after all. I think my change
only gives higher priority to replacing Forts.
Rationale I've posted some screenshots about the K-Mod problems here.
Forts cost a lot of Worker turns and often have to be replaced later on, so the AI
should be hesitant to build them. Possibly a bug in BtS: The AI picks the most
expensive improvement; was perhaps intended to be the cheapest (hard to say).
My heuristic using natural tile defense leads to a reasonable number of Forts in
reasonable locations. Not really smart, but looks good on the surface.
Forts can theoretically be better than yield improvements even on workable tiles. A
Silk Fort preserves the underlying forest, which is worth 1 production vs. the 3
commerce from a Plantation. 3 commerce is generally preferable to 1 production, and
I don't think the AI can figure out when 1 production is better. Better stick to the
obvious improvements.
Tbd. I don't think I've actually seen an AI canal yet (not through CvPlayerAI::
AI_getPlotCanalValue either).
Increased the value assigned to GPP when K-Mod comment: "[...] because of the flawed way
choosing jobs for citizens by 38%, but made the that food is currently evaluated, I need to dilute
value decrease faster with each additional GP. the value of GPP so that specialists don't get
value more highly than food tiles. (I hope to
correct this later.)"
Rationale I've noticed that the AI doesn't create enough GPs in the first half of the game and
rather too many in the second half. I didn't look into the food evaluation issue
mentioned by karadoc, but AI cities still seem to grow normally in tests.
AdvCiv BtS
When AI yield priorities are adjusted in response The city AI may lower the priority of production
to high expenses, then the adjustment is done yields when (overall) expenses are high. The
gradually over the course of several turns. priorities are fully recomputed each turn without
any inertia.
340
Rationale Comment in the Dune Wars mod: “ALN - this causes a few issues in DuneWars and
in general. if it causes a wholesale move towards commerce, the ratio changes next
turn shifting back to production, leading to a possible endless seesaw [e]ffect”
I haven't observed such a seesaw effect, but it sounds plausible.
(I didn't adopt any code from Dune Wars; I think their solution is specific to that mod.)
Made the city AI prioritize food more in situations when happiness and health allow for a lot of extra
population.
AdvCiv BtS/K-Mod(?)
When a player adds a specialist on the city Manual changes to the citizen assignment don't
screen to a city that has citizen automation disable automation, they only force the AI
enabled, the AI assumes that all specialists of governor to keep that particular assignment.
that type are forced. When a player forces any such assignment on
the AI, the AI may reassign any non-forced
citizens in response. When the AI has already
assigned one (non-forced) specialist and the
player adds another specialist of the same type,
the AI may in response reassign the non-forced
specialist. This can mean that the human
assignment has no visible effect. (The non-visible
effect is then that the one specialist can't be
reassigned by the AI in the future.)
Rationale When a city already has one Scientist and the player adds another, the player most
likely wants there to be two Scientists.
When building “territory” railroads Railroads on worked tiles should arguably be
(AI_routeTerritory(/*bImprovementOnly=*/true)), handled primarily by workers assigned to cities,
the AI prioritizes worked tiles over unworked tiles but those workers can't always immediately build
and up to 3 workers can team up depending on all railroads that increase production yields, so
the build time (i.e. mostly on slower game speed workers that improve their owners territory in
settings). general end up building such railroads as well.
Those workers prioritize tiles solely based on the
distance to their current tile. Tiles that another
work is already building a route at or adjacent to
are disregarded.
Credits Idea by Elkad (CFC post)
When the AI gains access to a new worker build Those AI caches are normally updated at end of
through a tech trade (or the WorldBuilder), the AI turn, which works nicely when a tech is
updates the best build and best route-to target discovered through research. If a tech is received
stored for each city immediately. during another player's turn, AI workers will
spend a whole turn with cached data that ignores
the new build. In the case of railroads, AI workers
may begin lengthy “route-territory” missions on
that turn, substantially delaying railroads on
worked terrain improvements.
Rationale Mainly for railroads. For other builds, it's normally just a 1-turn delay.
Removed or tweaked various conditions under In most(?) cases, AI workers headed for a target
which AI (and automated) workers had placed with the best build value lay down routes
routes while moving to a target tile. connecting their current location to the target tile.
Rationale The BtS behavior can result in long delays for important builds.
Credits Elkad pointed out that the BtS behavior is far from optimal when it comes to railroads.
341
Tbd. Further improvements regarding railroad constructionsuggested by Elkad: CFC post
Even when a building has a very high utility and Will hurry too readily in the early game when
is thus desirable to get earlier, the AI will not Workers aren't quick enough to improve tiles. This
hurry the building if that's inefficient in terms of
is a bit of a feedback loop because unimproved
lost food versus gained production – i.e. when worked tiles are a main driver of training
the building is a wonder with a hurry penalty. additional Workers. Also, in general, if Slavery is
When evaluating the cost of not working a tile used a lot, cities stay small, and thus Slavery
due to population loss from Slavery, the value is remains efficient (small cities need less food to
increased if the tile is unimproved and expected regrow population).
to be improved soon.
Rationale The K-Mod yield calculations are very well done I think (certainly better than anything I
could write), just the part that evaluates how urgently the city needs production is
bare-bones.
The AI doesn't hurry as much as a highly competent player now, but that makes sense
to me because the AI generally produces units and buildings ahead of time (or for no
particular purpose) and thus doesn't benefit much from getting them a couple of turns
earlier.
Not sure how much the AI uses rush buying now. (Well, basically, hardly ever as in
K-Mod because the AI won't adopt Universal Suffrage, and I can't blame it.)
See also 064b changes the interaction between hurry production, chopping and overflow a bit
(rules-wise).
110 shifts yield priorities, in part, to match the use of Slavery.
912d reduces the hurry production from Slavery. The AI should be able to handle
(small) changes to that variable; it's part of the calculations.
Civ 4 Reimagined also tones down K-Mod Slavery: "AI doesn't use slavery as
extensively as before which results in bigger cities and stronger AI overall." (source)
342
Tbd. Software design: Would be nice to move the AI code for city trades out of CvPlayerAI
through object composition and an abstract “TradeAI” class that other trade evaluation
classes could be derived from as well in the future, e.g. if the rules for tech trades are
changed (that would be under change id 550) so that a rational AI can be put in place.
TradeAI should have functions willGive, willReceive, giveVal, receiveVal,
imposing the structure described under ctr (AI), and should be serializable.
Any non-annual trade items can be offered in Cities can be traded only as part of a peace deal;
exchange for a city. otherwise they have to be gifts.
Rationale Mainly to make diplomacy more rewarding when tech trading isn't possible, i.e. when
playing with the “no tech trading” option, but also when a civ has fallen behind. (I'd also
like to move tech trading from Alphabet to Scientific Method and add a tech diffusion
system.) Could also make culture-based strategies more rewarding and interactive:
Flipping cities through culture often isn't feasible, but a combination of culture pressure
and payment can work.
See also Dawn of Civilization players make a case for city trades here and here. Their
arguments seem to be mostly specific to mods based on Rhye's and Fall though.
In order to be able to receive a city through trade, All cities can be traded between humans. The AI
a civ needs to have at least 10 percent tile accepts all cities from humans where it has at
culture there. Unless at war, the civ also needs to least 1% culture, and otherwise refuses only if
have at least half as much tile culture as the the city is 10 or more tiles away from the nearest
current owner. (Exception: Liberation to colonial AI city, or when in financial trouble (which rarely
vassal.) occurs).
Outside of peace negotiations, cities change
For trades between human players, the recipient hands between AI civs only through liberation
is required to have higher culture if that player (which requires much more than 10 percent tile
has already owned the city at some earlier time culture).
and the two players aren't at war.
Vassals can only receive cities through liberation;
see next blue box.
Config The 10% are set in GlobalDefines_advc.xml (CITY_TRADE_CULTURE_THRESH).
Rationale Should make it harder to gift worthless cities to the AI. It's also implausible that a city
could be given over to a nation that has no history there. Tile culture also implies
geographical vicinity.
Ceding a city to a civ whose nationality is clearly a minority there is also implausible –
except when negotiating peace terms. Nowadays, ceding even uninhabited territory
tends to prompt frantic popular opposition, but this was not so in pre-modern times.
Therefore any stricter nationality conditions should be part of the trade denial check so
that leader personality can be factored in.
Generally, only culturally contested cities should be tradeable; too many trade
possibilities otherwise I expect.
The special condition for human-to-human trades is intended as a safeguard against
back-and-forth trades (e.g. for bumping units forward).
A master civ can trade any cities to its vassal Can only liberate cities to vassals. If a vassal isn't
where the vassal has more culture than the the civ that would receive a city upon liberation,
master. The vassal may reject the city. then the vassal can't receive the city at all.
343
Rationale I suspect that the restriction was put in place to prevent masters from demanding their
vassals' cities, and that the inverse direction had been assumed to be covered by
liberation. Not true in the case of a city that is culturally contested between a vassal
and a third civ.
Giving cities to vassals means less human city management; should be encouraged
(and allowed, to begin with).
The stricter culture clause is just flavor. I suppose the master population wouldn't want
to be ruled by the vassal.
Vassals can accept cities from rivals, but can't Vassals can't cede cities to anyone but can
cede cities to rivals, not even through liberation. accept cities – except from their master.
Rationale A vassal gaining extra cities should be fair enough. The master may not like it, but
vassal are allowed to work toward independence.
A vassal giving cities away would be problematic because the master doesn't get to
decide that a vassal's remaining cities are no longer worth protecting
See also Consequences of a city traded to a vassal: doesn't trigger a peace treaty.
When enemy units (war enemies or Barbarians) Only liberation cares about hostile units, and that
are near a city (within a 5x5 square), that city can clause is only about units hostile to the new
only be traded to a war enemy. owner.
While at war with the previous owner of a city,
that city can't be traded to civs that aren't at war
with the previous owner.
These two restrictions don't apply to liberation.
The former is implemented as a trade denial
condition with explanation text “We are afraid of
your enemies” or (for a human recipient) “it's out
of our hands”.
Rationale To prevent players from giving threatened (and possibly untenable) cities to an
uninvolved party. In reality, other civs (including the enemy at the gates) would simply
not recognize such a change in ownership.
Not sure about the liberation exception.
Only revealed cities can be traded for. Can receive previously unknown cities as part of
a peace deal. AI civs accept unknown cities from
human civs as gifts.
"... make a trade proposal" option hidden when Proposal can lead to an empty Trade Screen.
there are no eligible trade items.
Rationale A minor change while I'm at it. Not plausible that the AI is (supposedly) able to decide
whether to accept a city that it has no knowledge of. Moreover, unrevealed cities are,
in principle, secret in K-Mod, and the Trade screen can leak that info.
An empty Trade screen is a bit confusing, and became a more common occurrence in
the early game after I excluded unrevealed cities. "What do you think of ..." - "Yes?"
"Let's discuss something else" is also confusing (when there is no third civ to talk
about), and I've rectified that in a different mod (Git commit), but I actually find the BtS
behavior too funny to change it.
AdvCiv K-Mod
344
Apart from colonial vassals, only former owners K-Mod added a “base culture [value] to dilute the
of a city are eligible for receiving it through true culture values.” (Git commit) As a result, civs
liberation. with 0 culture level can be eligible for liberation.
Rationale I'm not sure if that side-effect of the K-Mod change was intended. I think allowing
liberation to arbitrary civs in some obscure circumstances only complicates matters.
Tbd. The computation of the liberation player is still highly obscure. In summary: Can
always liberate to a colonial vassal that has its capital on the same landmass.
Otherwise, the liberation player is is the one with the highest score – unless the
current owner has the highest score. The score is city culture with a dilution factor from
K-Mod, biased for the original owner when liberating upon conquest, strongly biased
against rivals of the current owner, taken times a factor between 1 and 2 based on the
team' culture in the city tile (K-Mod) and divided by capital distance (air distance,
doubled if colony).
Maybe do something based primarily on tile culture (city culture of other civs isn't even
visible on the UI). That already accounts for distances – though nearby cities may
have recently changed hands, so a distance factor or sanity check would still be
needed.
AdvCiv BtS
Keep the option of liberating a city right after After conquering a city that can be liberated, the
conquest. canTradeItem is now called to make raze popup includes an option to liberate the city
sure that the (implicit) city trade is legal. if the player that conquered the city is able to
enter the territory of the liberation player. The
Cities ceded this way count as liberated for the
liberation player is computed with a bias for the
“you liberated our cities”, “traded fair and
city's original owner (i.e. the founder). However,
forthright” and “traded with our worst enemies”
the city counts for “you liberated our cities” only if
relations modifiers. The raze popup says
the liberation player would be the same without
“liberate” in parentheses to clarify this. The
the bias for the original owner. It never counts for
popup says “let the … empire assume control” if
fair trade and enemy trade.
the new owner hasn't owned the city before.
(This can only happen with colonial vassals; see The raze popup says “return control to the …
the previous box.) empire” even if that player has never owned the
city.
When the liberation player upon conquest differs
from the peacetime liberation player, the popup The recipient can't refuse. (no change)
choice of keeping the city is followed by a note The option to cede a city after conquest was
saying that liberation to the original owner won't already present in Vanilla Civ 4; when BtS added
be possible at a later time. the notion of a liberation player, the code was
updated to cede to the liberation player instead of
the highest-culture player.
Rationale I haven't added a trade denial check because, otherwise, for equal treatment of human
and AI, human players would have to receive a popup allowing them to reject a city;
way too much work, and it's fair enough to say that the new owner is somehow taken
by surprise.
The bias for the original owner is an obscure rule – until I read the code, I had
assumed that liberation through the raze popup worked just like through the trade
screen. That said, it's flavorful to restore a city to its original owner after/ as part of its
“liberation.” (Perhaps there should be some simpler advantage to it.)
The relations boost from liberation has to apply in any case; otherwise, the raze popup
is a trap. The trade modifiers aren't all-upside, but treating them differently from
liberation would add to the confusion and getting around the enemy trade penalty this
way also wouldn't be particularly plausible.
345
Tbd. Perhaps remove the bias for the original owner (bConquest in CvCity::
getLiberationPlayer).
Can liberate a city even if there is an enemy sea unit There must not be any unit hostile to the prospective
or non-combat unit visible from the city. city owner visible from the city. Otherwise, the city can
still be traded, but it doesn't count as a liberation (no
diplo bonus).
Rationale The visible-enemy restriction is reasonable – if the new owner has to fight for the city, it's not
really liberated –, but units that can't attack the city shouldn't block liberation.
Disabled this in AdvCiv 0.97 because trade denial handles hostile units now. That said,
the trade denial check ignores all ships. I've left the old code as a comment in
CvCity::getLiberationPlayer in case that I want to merge it into the denial check.
(Removed that comment too on 22 Mar 2020.)
346
When a city is ceded, reset the anger timers for The timers are reset only if the new owner is an
Slavery, Drafting and defied resolutions unless AI civ (and always after conquest; no change).
both the old and new owner are human or the
new owner is human and the old owner an AI
teammate.
Rationale Don't want to treat human and AI civs differently without a good reason, and don't want
players to be confused by “We can't forget your cruel oppression” anger from actions
of the former owner.
Two human players could collude to trade cities back and forth in order to reset anger
timers. That needs to be prevented. I don't think this trick will work with a human player
and an AI teammate, but let's make sure (I guess).
When a city under occupation is traded, Units are bumped before setting the occupation
occupation status is set before bumping out any timer, meaning that units in surrounding tiles are
units. teleported away although a city under occupation
doesn't have a culture range.
Rationale Arguably a bug.
After a non-liberation city trade between non- No peace treaty (unless the city was granted to a
vassals, a peace treaty is signed automatically. human player as a gift or tribute).
Rationale Don't want human players to sell a city to the AI and immediately declare war and
reclaim the defenseless city. Not a problem in BtS because the AI won't pay for cities.
I want vassals at least to be able to accept cities from rivals, but they mustn't force a
peace treaty on the master. A human selling cities to a vassal before a declaration of
war doesn't seem like much of a problem; the vassal isn't going to have much to trade.
See also 146 signs a peace treaty after a war trade.
347
New tab “Cities” on the Foreign Advisor screen. Shows a table with all cities that the active player
can trade much like the “Tech” tab does for technologies. An occupation (fist) icon indicates when a
city can be liberated. When an AI civ is unwilling to cede or receive a city, hover text shows the
denial reason. When not all cities fit into a table cell, points of ellipsis are shown and hovering on
those points shows the omitted cities.
To implement the city table, BUG's IconGrid module has been extended, allowing multiple text
elements (with hover text and on-click action) to be added to a single table cell.
Config The “Cities” tab can be disabled through the “Advisors” tab of the BUG menu.
Rationale A bigger role for city trades requires better UI support. The only place that dealt with
city trades was the “Liberation” column of the Domestic Advisor (more about that
below); not the right place for information about trades, and the Domestic Advisor was
already too cluttered.
Tbd. Perhaps it's habit-breaking that the “Tech” tab is no longer right next to the “Exit”
button. That could easily be amended by switching the “Tech” and “Cities” tab.
The BUG option to disable the “Cities” tab could later be removed to unclutter the BUG
menu. But so long as city trades are novel, it makes sense to have an option.
Clicking on the name of one of the active player's cities opens the city screen behind the Foreign
Advisor and highlights the city on the minimap. Clicking on the same city name again or right-
clicking on any city name closes the city screen.
Rationale Want to help player locate the cities. Unfortunately, the camera can't move (ensured by
the EXE I think) while an Advisor screen is open. The Foreign Advisor obscures all the
interesting parts of the city screen, so the city screen in the background isn't helpful.
However, as a side-effect, the city gets highlighted on the minimap (visibility circle and
larger city blot) and the player can close the Foreign Advisor to inspect the city and
can then close the city screen with right-click (see 004t) to see the city on the main
map.
Tbd. Clicking a foreign city's name does nothing; should at least highlight that city on the
minimap, but I'm not sure how to do that (without opening the city screen, which can't
be allowed for foreign cities).
Perhaps clicking a city owned by the active player should close the Foreign Advisor
screen and then center the camera on the city (like the BUG Wonders tab). And right-
click for the current behavior (opening the city screen in the background).
An alternative approach would be to show just a near-fullscreen minimap on the
“Cities” tab with cities that can be traded highlighted through colored blots; all other
info in hover text – but could blots on that map have hover text? Also sounds like too
much work. Though a nice large minimap could also be useful for … well,
screenshots?
The rightmost column of the (non-customizable) The rightmost column instead shows a fist icon
Domestic Advisor shows the revolt probability of for all cities that can be liberated to an existing
cities with a positive revolt probability. The civ. (Prior to AdvCiv 0.97, the icon was also
occupation (fist) icon is used as the heading for shown next to cities that could be split off as an
that column. independent colony.)
Rationale Liberation to existing civs is now handled by the “Cities” tab. Liberation to a new civ is
presented better by the “Liberate” button on the Domestic Advisor screen. It wouldn't
hurt to show that information redundantly, but it's not really within the purview of the
Domestic Advisor, the icons are pretty obscure and revolt probabilities are more useful
(they also require a bit more space, but everything still fits even at screen width 1024
pixels).
348
See also The Immortal Culture changes make revolts more relevant than in BtS.
Tbd. The Domestic Advisor could use hover text to explain its headings and maybe also for
some additional information.
Alert for city trades added. When a conquered city can be liberated, the raze
popup shows an option for that; similar enough to
a notification – in that one special case.
(Since the BtS AI only trades cities when at war,
notifications aren't really needed.)
Config Can be disabled on the “Alerts” tab of the BUG menu.
See also Implemented based on the AdvCiv4lerts class (210).
Show the alert messages in the previously Some parts of the game are color-coded pretty
unused COLOR_CITY_BLUE. reliably, e.g. green for research and technologies.
I don't think cities are part of that color scheme;
in replays, founded cities used to be shown in
green. BUG used magenta (normally used for
culture) for city-founded alerts.
See also 106: For city-founded messages in replays, I use the player-specific text colors.
210c: City-founded announcements are shown in plain white.
Rationale Colored alerts stand out more at first (which is not what I want), but, after a bit of
getting used to, are easier to identify at a glance to (usually) ignore them. That's my
experience with the BUG tech trade alerts anyway. COLOR_CITY_BLUE is surprisingly
easy to read against the blue background of the Event Log but doesn't stand out
much. For game text, blue tones weren't used much at all (I guess because of the blue
backgrounds and water tiles). Other ideas would be COLOR_CITY_BROWN,
COLOR_CULTURE_RATE or a similar new COLOR_CITY_VIOLET with r=50%, g=30%,
b=100% – that's not too similar to the player colors of Sumer and Rome.
Show an alert when another player becomes willing to cede a city. When at war with that player,
show the alert only if the war enemy would be willing to give the city in exchange for peace.
Rationale Since the rules for city trades are fairly narrow, I'm not restricting the alert to AI players.
There's no way to get a city from the AI while at war if the AI won't make peace in
exchange for the city because only one side can give items in a peace deal.
No “... will no longer cede” alert. Doesn't sound too helpful and might flicker while at
war. (If it's needed after all: Don't report cities whose owner has changed, nor cities
that have become the capital. Perhaps don't report anything after making peace.)
Show an alert when another player becomes willing to accept a city in trade.
Rationale Mainly so that players know when a city becomes tradeable through the gradual
spread of a foreign culture.
Show an alert when it becomes possible to liberate a city to a player other than the city's previous
owner.
Rationale Liberation to the previous owner – typically after a war – is almost always possible and
rarely desirable.
AdvCiv K-Mod
Show all cities that can be traded on the trade Exclude “take it from our cold dead hands” cities.
screen (and on the “Cities” tab).
349
Rationale It was a good change for K-Mod (and for AdvCiv until v0.97) because the AI said that
about nearly every city when at peace, and those untradeable cities were cluttering the
trade screen. It may also have been part of the K-Mod changes to make unrevealed
cities secret. These things are now addressed by the game rule restrictions on city
trades: Can't trade for unrevealed cities and can't trade for cities without a significant
amount of the new owner's tile culture.
When a human tile flips to a different owner, sleeping and fortified units of the old owner are woken
up.
Rationale So that human players can't forget about units fortified in or near a traded city. Should
also be useful when border tiles flip through culture pressure; units forgotten on such
tiles can even increase away-supply costs.
See also 163 wakes up teleported units
Tbd. What if a human player has units fortified on a teammate's or vassal's tile and that tile
flips to a third party?
350
ones even easier to get along with; BtS (or rather especially Vanilla Civ 4) is too one-
dimensional in that regard.
AA: Brennus, Pacal, Shaka, Montezuma – Chieftains that care more about clan than
country, and rulers of city states.
CP: Alexander, Augustus, Cyrus, Darius, Huayna Capac, Hannibal, Julius, Justinian
Emperors of classical antiquity. Enlarging the inherited realm is a point of pride. Cities
with little tile culture may yet be acculturated. However, in the end, it's up to the whims
of the emperor.
AC: Mansa Musa, Pericles – Pericles ruled over a city state, but there was also a
sense of Hellenic identity. Mansa Musa is more of a classical emperor, meaning he
doesn't easily part with land, but he also can't resist a good deal.
AP: Ashoka, Hatshepsut, Hammurabi, Gilgamesh, Ramesses, Suryavarman, Ragnar
Mostly pre-classical emperors; less interested in colonizing acquired land. Conquered
cities especially are to be exploited (e.g. sold), not integrated.
CC: Charlemagne, Isabella, Joao, Mehmed, Saladin, Suleiman, Wang Kon, Zara Y.
Medieval sovereigns. Care more about feudal ties than country. They do worry that the
recipient of a city might plot against them; or worse: they could be heathens.
CF: Frederick, Louis, Willem, Elizabeth, Mao, Tokugawa
The first four are rulers over early (proto-)nations. They only abandon their citizens
under duress. Conquered lands are negotiable, but they're also interested in
expansion. Mao: As a modern ruler also not happy to cede land, but he did cede some
land to the USSR when relations weren't entirely friendly. Tokugawa: Tough one.
Giving up Japanese citizens should be taboo. To minimize contact with foreign
cultures, it would seem best to trade conquered cities away. Though he doesn't really
like to trade either, nor does he like foreign cities at his borders …
AF: Bismarck, De Gaulle, Napoleon, Victoria, Boudica, Sitting Bull
The first four are leaders of colonial nations, but arguably not too keen on cementing
colonial rule and willing to engage in politics. And, let's say, two proud chieftains to
whom the land of their forefathers is sacred.
PF: Churchill, Stalin, Peter, Catherine, Gandhi, Lincoln, Roosevelt, Washington
The first four have an aversion against giving up what they've once taken, except
perhaps to a “fraternal country.” The other four are modern democratic rulers that are
reluctant to put a liberated people under the thumb of some less enlightened ruler.
PP: Kublai Khan, Qin Shi Huang – Want to give this combination to someone. Not sure
about Qin. Kublai was practically a Chinese emperor but didn't have Chinese roots, so
he shouldn't be absolutely attached to any ethnicity. On the other hand, he was an
extremely powerful emperor, so he doesn't quite see why he should give anyone
anything.
FF: Genghis Khan – Maybe due to his fierceness; or arrogance since his campaigns
were so successful.
As for the 20% nationality threshold, I've tried 10%, same as the threshold for being
able to receive a city in trade (CITY_TRADE_CULTURE_THRESH), but that didn't work well
in situations when two war allies divvy up the spoils of a successful war. If both owner
and potential recipient start at 0 nationality, then the latter would have to increase its
nationality faster than the owner in order to receive the city before the stricter attitude
threshold applies, which often isn't doable and also isn't consistent with the idea that
having half as much nationality as the owner should suffice for a trade.
20% also has some supporting precedent in history. For example, the parts of Ukraine
that Russian nationalists have been seeking to “reclaim” all have a population of at
least 18% ethnic Russians (map on Wikipedia).
The AI refuses to trade away cities with a trade The AI reponds “surely you ask too much” when
value greater than 4/7 of the trade value of the AI asked to trade a city where its city culture is more
capital except when at war. If the other side is a than 50%. This only applies to teammates. Rivals
351
rival, the denial reason is “you'll have to take it are told to take any city “from our cold dead
from our cold dead hands,” otherwise “surely you hands” except when negotiating peace.
ask too much.”
When in financial trouble, AI civs refuse to accept
The AI refuses to accept cities with a negative cities where they have 0 tile culture (“we don't
trade value (“we don't want to trade this”). Even if want to trade this”). Cities with 0 tile culture are
the trade value is positive, the AI rejects small also rejected when they're too far away from
cities in very poor surroundings. every currently owned city.
Neither of these conditions apply to liberation. None of the AI denial checks apply to liberation.
Rationale Want to exclude major cities in order to limit the possible gains from tech-for-land
deals. One could just assign very high trade values to large cities, but excluding those
cities through a denial condition should be more convenient for players; don't need to
bother making offers then.
I could think of various heuristics for identifying important cities (e.g. the score
computed in CvCity::getLiberationPlayer could be a starting point), but using
trade value is the easiest to implement. That's also the approach taken by UWAI for
war trades – trade denial based on trade value. Cities in disorder are are problem, but
the trade vaue computation needs to deal with that in any case. Performance could be
a problem, but I don't think it will be. A more likely issue is a flickering city trade alert
when the value of a city is near the threshold. Let's hope that this will be rare (would
be a bit tedious to smooth that over).
The special condition for cities on poor land (CvPlayerAI::AI_isAwfulSite) was
added prior to AdvCiv 0.97 in order to discourage players from founding cities in the
worst possible spots and then gifting them to the AI to improve relations. I was going to
remove it in favor of a trade value check, but now I think it's safer to apply both checks.
I've considered merely relaxing the trade value threshold when at war (instead of
waiving it), but at least the UWAI code usually doesn't value peace highly enough
(even when losing badly) to give up any major cities in peace deals. Saying “take it
from our cold dead hands” could look bad when it's obvious to the human player that
the respective city is about to fall.
The 0-culture conditions are obsolete because the game rules now prohibit such
trades. Recognizing cities that are more trouble than they're worth is, again, something
that the trade value computation can handle better than some ad-hoc heuristic.
Tbd. A downside of denial based on trade value is that no specific reason can be stated.
But maybe the AI could still somehow respond with “your land is too far away”
(DENIAL_TOO_FAR) in some situations.
The AI refuses to accept cities in trade when Nearby enemies (any units, not just land units)
there are hostile land units nearby and nearby prevent liberation, but there is no such trade
potential defenders don't clearly outnumber the denial check.
potential attackers: “We are afraid of their military
might.” Doesn't apply when negotiating peace.
Rationale To eliminate loopholes that can make the AI look bad. Ideally, hostile transports should
be counted as well and the condition should be checked in peace negotiations to make
sure that the winning side isn't gaining a city that it will immediately lose to some other
war party. That could be implemented, but isn't worth the effort I think.
See also Uses code similar to the city safety check (139).
A similar trade denial condition described among the rule changes deals with units
hostile to the current city owner.
The AI refuses to accept cities that are under Occupation and disorder don't affect trade denial.
occupation if the resistance is coming from a
352
third party: “Maybe we'll change our minds in a
few years.”
Rationale Computing trade value during disorder isn't a problem, but don't want humans to
deliberately let a revolt happen before trading a city to the AI. It's tempting to prohibit
all city trades during disorder, but it would seem strange for the recipient to insist that a
revolt in its own favor be suppressed before accepting the city. One could argue that
the city might flip on its own, but it's better to address that angle through the trade
value computation (certainly the AI should accept a city as a gift even if it will flip).
Capitulated vassals refuse to trade cities to their Vassals can't cede cities to anyone and can't
master unless the capitulated vassal is above the accept cities from their master.
population threshold for breaking free and will still
be above the threshold after losing the city:
“Surely you ask too much.”
AI civs don't trade cities to their capitulated
vassals if that would put the vassal above the
threshold for breaking free or if the vassal is
already above the threshold: “You've grown too
powerful for us.”
See also 130v about the mod's general approach to capitulated and voluntary vassals.
See the rule changes to city trades about restrictions that apply to all vassals.
Rationale Capitulated vassals shouldn't ruin their chances of breaking free. Master civs shouldn't
help their capitulated vassals break free.
When close to a Conquest victory, the AI refuses to trade away any cities except when negotiating
peace.
When close to a Space victory, the AI refuses to trade away high-production cities and cities that
are producing a spaceship part.
Stated reason in both cases: “We'd rather win the game”
Rationale The Space conditions will rarely matter, I expect, because the trade value conditions
already prevent the AI from ceding major cities. For Culture victory, that should 100%
be the case.
An AI civ with a war utility value above 30 may refuse to accept a city in a non-liberation trade
when the city is insignificant compared to the economic output of the recipient and the war utility
value. (If UWAI is disabled, a coarser heuristic based on attitude and military power is used instead
of war utility.) Stated reason: “We have our reasons”
Rationale To avoid signing a peace treaty. On the one hand, gaining one decent city is usually
more than the AI will accomplish by actually declaring war on a human player; on the
other hand, when humans can rely on getting a peace treaty in exchange for a city,
they may exploit that by recklessly exposing themselves or by buying time for a
peaceful victory in the endgame.
“We have our reasons” will alert humans about the high wa rutility value; probably
obvious anyway in the rare cases when this will come up.
Tbd. Should perhaps still add a special message to the city trade alert – to make sure that
players don't feel encouraged to keep an eye on the City Trades tab for AI war plans.
By default, 0 trade value is assigned to liberated At peacetime, the game rules and UI prevent
cities, meaning also that the AI will respond that cities from being traded (except between two
no trade is possible when asked what it will give human players).
in exchange for liberation.
353
When negotiating terms for peace, liberation has Liberation never affects a city's trade value.
no impact on a city's trade value.
Rationale Mainly because I don't want to render the liberation choices in the conquest and
colony (Alt+F1) popups useless. If the AI pays for liberation, even if it doesn't pay
much, it'll always be preferable to liberate cities through trade. Therefore, I'm
interpreting liberation as the recipient having a rightful claim to the city and insisting on
getting it for free (granting peace isn't really a payment). Admittedly not very realistic.
In gameplay terms, the reward for liberating a city is the relations boost (see a few
boxes below).
It would be easy enough (by reverting a one-line change in CvPlayerAI::
AI_counterPropose marked with advc.ctr) to let the AI make a proposal that leaves
the left side of the trade table empty when asked what they'd give for the liberation of a
city, but stating that no trade is possible (as in BtS) seems less confusing to me.
(Although a trade might actually be possible, namely, when the AI has a city that it can
liberate in return.)
Tbd. CvCity::getLiberationPlayer may have to be simplified because, when deciding
whether to trade a city away, players may want to take into account whether the city
will soon become eligible for liberation – meaning that the the recipient won't pay for it
anymore. That's currently impossible to gauge.
When considering to liberate a city in response to Human can request liberation, but the AI will
a human help or tribute request, the AI decides decide based on the regular trade value of the
based on a reduced trade value that only takes city.
into account how valuable the city is to the AI civ.
Rationale If humans are expected to liberate cities for free, there should be a real possibility of
the AI doing the same thing. The AI will also liberate cities without human importuning;
see below.
When considering a trade in which each side Regardless of liberation, the AI can never trade
liberates at least one city, a reduced trade value cities for other cities.
is counted for all liberations. That trade value
accounts only for the value that the city has to its
current owner; although, if the current owner is
human, then that value is capped at 50% of the
value that the city has for the AI recipient.
Rationale To facilitate reciprocal liberation, which is a win-win.
When a human player asks the AI to liberate a The UI doesn't allow humans to propose city
city and offers trade items in exchange or asks trades and the AI will say that no such trade is
the AI for a price, the AI computes the city's full possible.
trade value, i.e. as if the liberation conditions
didn't apply.
Rationale Liberation shouldnt ever be a handicap for the liberation player. Unlike AI players,
human players aren't going to “feel too entitled to pay” for a city, so they should be
allowed to pay regardless of liberation.
For non-liberation trades, the AI evaluation is K-Mod comment: “The way this function is
broken down into two similar components: One currently used is that it actually represents how
value expressing how much the current owner much the current owner values not giving the city
want to keep the city and one value expressing to this player. For example, if this player currently
how much the recipient wants to acquire the city. controls most of the city's culture, the value
When evaluating a trade proposal, both values should be lower rather than higher, so that the
are added up and, if the AI civ is the recipient, current owner is more likely to give up the city.
capped at two times the value of acquiring the Ideally the value of receiving the city and the cost
354
city. of giving the city away would be separate things;
but that's currently not how trades are made.”
Rationale The BtS approach is workable for tech, which mostly benefits one side without hurting
the other – so the trade value is essentially equal to the tech cost –, and for gold,
which is mostly zero-sum – the trade value is two times the amount of gold –, but ill-
suited for city trades, which can be zero-sum, but can also involve cities that would be
much more valuable to the recipient than to the current owner.
The cap based on the recipient's value is supposed to ensure that the AI doesn't pay a
high price for a city that is more valuable to its current owner.
See also Afforess has added a function AI_ourCityValue to Rise of Mankind – which is mostly
a copy of AI_cityTradeVal.
Tbd. Ideally, all trade evaluation functions (perhaps also the ones checking denial
conditions) should be broken down into the perspective of the giving and the receiving
side. E.g. how much the recipient civ benefits from a traded tech versus how much he
civ imparting the tech would like to withhold it from the recipient. This structure could
be imposed through a simple object-oriented framework.
AdvCiv BtS/K-Mod
The trade value computation is further broken A simple, yet arcane, formula based on
down into an economic “asset” value, an population (K-Mod: also highest-ever population),
amortization modifier and modifiers for strategic city culture, city tile culture, game turn (K-Mod:
considerations. The asset value doesn't just also turn founded and turn acquired), prior
cover the current economic value, but also tries ownership of the recipient and the trade values
to (crudely) estimate its economic potential of all bonus resources in the full city radius
(possibly hampered by culture pressure). (K-Mod: lower weight for the outer ring).
Estimated expenses are subtracted. K-Mod added an evaluation great wonders and
Holy City status (but national wonders of the
current owner and mundane buildings still
weren't covered).
The amortization modifier accounts for speed No meaningful game speed adjustment.
and other game settings.
The strategic modifiers account for the (old or None of these are directly addressed.
new) owner's total city count, number of cities on
the same landmass, whether the city might flip,
whether the extra population might soon let the
new owner win (Domination or Diplo victory), the
tactical situation (city imminently threatened or
already being evacuated) and relations – in
particular whether the either side could easily
conquer the city instead of making a trade or
(reconquer it) after making the trade.
Credits I've reviewed Afforess' code in Rise of Mankind (RoM; SVN revision) but only adopted
(in part) code dealing with religions and corporations present in the city. The RoM code
takes into account production costs of buildings, but buildings aren't public knowledge
in AdvCiv. Therefore, and to save time, my code uses the building count for a vaguer
estimate of building utility. There are checks for imminent danger of conquest, same
landmass as capital and financial trouble; the new AdvCiv code handles these things
in a slightly more sophisticated manner. This CFC post suggests that the RoM AI often
overvalues cities.
See also 104d: The asset value is also used by UWAI.
355
The tactical evaluation when at war is based on 139.
045 makes most city buildings secret.
Rationale The K-Mod formula doesn't seem adequate now that city trades will be more
commonplace. (Apparently, the K-Mod hadn't been tested much either; there was a
major bug in the computation of a city culture multiplier. That code is now deleted; the
final version is from 22 Mar 2020, after this Git commit.)
I don't think the exact numbers matter much, but some of my additions could be
important for preventing the AI from overpaying for human cities.
The AI city evaluation is a bit stacked against No anti-human bias in AI city evaluation.
human city owners through a distrust multiplier
(between 2/3 and 5/6 depending on attitude) and
AI refusal to compensate humans for avoidable
hardships (e.g. losing a national wonder).
Rationale Really just humility on the part of the AI: The human player probably knows better how
valuable his or her cities are and wouldn't give cities away that are very valuable.
Hopefully, no bias will be apparent.
When trading with a human, the AI trade value The final result is rounded to a multiple of 10 and
computation ends with a multiplication by a the computation doesn't use any sensitive
secret factor near 1 that gets re-randomized information.
unpredictably (hopefully) every few turns. Then
the usual rounding to a multiple of 5 is applied
Rationale To obscure the specifics of the computation. In particular so that the AI prediction of a
(near-)future war and minor AI information cheats (when evaluating human cities)
aren't exposed.
See also 136b changes the standard rounding of trade values from a multiple of 10 to a multiple
of 5.
The AI recognizes awful city sites, doesn't accept If a city is close enough and has enough culture,
such cities in trade and razes them after the AI accepts it, and doesn't normally raze it.
conquest.
Rationale The BtS behavior can be abused by gifting the AI useless cities, and the AI will even
be thankful for it (fair trade diplo bonus). See strategy advise here (CFC).
That strategy still works, the city site just mustn't be extremely bad.
AdvCiv K-Mod
When “making this deal work” or determining “the K-Mod comment: “We're only going to allow one
price for peace” (AI_counterPropose), the AI city on the list. (For flavour reasons.)” And only
can add more than one city to the trade table, but when at war. Looks like BtS had always put a city
only if a single city and all available non-city tradeon the table when at war; K-Mod only adds the
items aren't enough to cover the current gap in city to a list of trade items and later greedily picks
trade values. items from that list to find the best fit for the gap
in trade values (that's still the basic approach in
(This doesn't apply to peace deals between AI
AdvCiv).
civs. There's a separate logic for those, which still
allows only one city to change hands.)
Rationale Seemed like the easiest way to allow multiple cities without changing the basic
algorithm. Don't want the AI to propose a city trade over a tech trade.
Trading multiple cities for peace rarely ever makes sense. I want to allow it for humans
just so that the AI doesn't wrongly claim that peace isn't possible. At peacetime, in the
late game or on large maps, trading one city for two or two small cities for a
356
declaration of war may not even be so unusual.
See also 104h: Slightly changes the conditions under which the AI adds cities to its initial
proposal for a peace deal.
AI_counterPropose prioritizes cities for trade The single city that the AI will propose is chosen
based on the difference between the owner's based on AI_targetCityVal.
trade value and the recipient's trade value, i.e. it
tries to find positive-sum (as opposed to zero-
sum) trades.
Rationale Seems like a better heuristic. More importantly, using AI_targetCityVal leaks
information about where the AI will focus its attacks. Not a well-known exploit, but, in
this CFC post, one player is onto it.
AI_counterPropose doesn't add city liberations to the trade table except (see a few boxes above)
when the trade value computation ignores liberation.
Rationale This only applies in the rare situation when a human and AI civ both have at least one
city that they can liberate. It's difficult for the AI to decide which cities the human player
might want to liberate or accept – at least in some situations, and it's in any case a bit
tedious to implement. Letting the human player put the cities on the table shouldn't be
too much of an inconvenience; the AI will then fill in other trade items as needed.
AI diplo memory about liberation is increased or reduced by 50% depending on the (non-liberation)
trade value of the liberated city.
See also In line with similar changes to raze and nuke memory: 130q
When computing the effect of a liberated city on To my knowledge, the full trade value is counted
trade memory (“fair and forthright”, “traded with by BtS and K-Mod.
our worst enemies”), the trade values of both
sides are counted (not just the value of the old
owner as in some other cases -- see higher up in
the boxes about liberation trade value), but the
total is reduced a bit.
Rationale The AI shouldn't be too grateful or upset when a city is returned to its rightful owner
(but +2 from liberation alone would seem a bit too meager).
Counting only the loss of the old owner wouldn't make sense for the enemy trade
value. Actually, it would make sense to count only the new owner's trade value (that's
the player whom third parties resent), but that would be awkward to implement as BtS
normally uses just one trade value that accounts for both sides.
When asking for help, the AI may ask for a city if The only asks for help in the form of free tech.
that city has significantly higher value for the AI
civ than for the human civ, and if its trade value
isn't much higher than that of the tech that the AI
would otherwise ask for or if there is no tech that
the AI could ask for.
Rationale No important reason. To incentivize liberating AI cities, for more variety in help
requests and to enable help requests when tech trading is disabled. I feel that the AI
shouldn't ask for help in the form of zero-sum trades, e.g. gold per turn. Cities can help
the recipient much more than their current owner.
When demanding tribute, the AI may demand a Tribute can take the form of tech, world map, a
city if that city isn't far more valuable to its current resource or gold (lump sum).
owner.
Rationale Flavor, variety, give players that are behind in technology some option to avert war.
357
The demanded item being too valuable is less of a concern than with help requests.
See also 104m allows the AI to demand gold per turn and lets the AI consider the various types
of tribute demands in a randomized order until a valid demand is found.
For each city that can be ceded, its AI owner Same rhythm (though, in principle, entirely
checks every 20 turns, the first time being based predictable). Due to the trade denial conditions,
on the city's id and thus unpredictable, whether only liberation is considered. Liberation to the
that city can liberated or is significantly more previous owner is ruled out. So, typically, it'll be
valuable to another civ. If so, the owner may liberation to the original owner of a city.
contact that other civ, offering the city.
Rationale I'm extending the contact-to-liberate mechanism to cover also AI offers for city trades
to both human and other AI civs.
While a city is evacuating through change 139, the AI checks on every turn for a third party that the
current owner might want to cede the city to through liberation.
Rationale What a human player would also do. Non-liberation trades of a threatened city to a
third party are disallowed by the (new) city trade rules.
When offering a city for liberation, the AI asks the If the AI offers a city, it's always for free.
recipient to also liberate a city if possible.
Usually, it's not possible and then the AI offers to
liberate the city for free.
Rationale Consistent with how the AI treats human offers for liberation (see somewhere higher up).
The AI does not offer (free) liberation when the For offering liberation, the AI owner needs to
city is of considerable value to its current owner, have at least Cautious attitude toward the
if it's almost as valuable to the current owner as liberation player.
to the liberation player or if it's too valuable to the
new owner. The value threshold for that last
condition is based on attitude. All the thresholds
scale with the game progress and speed. The AI
also tries to avoid empowering (non-colonial)
vassals too much.
Rationale Don't want the AI to hurt itself severely through a city gift, and don't want it to boost a
rival too much.
As for vassals, liberating a city that'll will be much more useful to the vassal is a good
move, but the vassal mustn't become so strong that it'll be able and willing to break
free.
The AI refuses to cede a city to its previous The AI never contacts the previous owner for
owner (trade denial: “Maybe we'll change our liberation. It could, in theory liberate to a previous
mind in a few years”) for, on average, about 15 human owner who asks for the city as a gift or
turns. tribute.
The AI doesn't offer to liberate a city for free No such strategic considerations.
when it thinks that war with the liberation player
is a possibility in the medium term.
Rationale I'd like the AI to be able to return a conquered city to its previous owner, even without
payment, when the two civs are no longer at each other's throat and the city isn't doing
much for the new owner. The AI being too quick to return a city will look very bad, so
perhaps these conditions will have to be tightened further. Conquered AI cities
permanently enclosed by foreign culture also look bad though.
After conquering a city, the AI may immediately Only human conquerors can immediately liberate
liberate it if the liberation player is a third party. a city after conquest.
358
The same conditions as described above for free
liberation apply except that no trade denial
checks are performed.
See also Among the rule changes to city trades, the (unchanged) BtS special rules for liberation
after conquest are described. Those rules also apply when the AI considers liberation
upon conquest.
Rationale Easy enough to do; as a rule, human and AI should play by the same rules.
The AI may offer a city for trade if it is much more valuable to the recipient or if the city isn't much
more valuable to its current owner and the recipient has far more assets (population, land, tech,
buildings) than the current owner. The AI then tries to find a city of the recipient that satisfies the
same conditions – to propose a one-for-one city trade with additional trade items for the side that
gets the less valuable city. Usually, there is no such city, and then the AI looks for arbitrary trade
items (i.e. tech, gold) that the recipient can offer in return. AI city trade offers to human players
include a discount.
Rationale See the rationales given at the start of the city trade documentation.
AI-to-human trades aren't crucial, but make the AI appear a bit more alive.
See also The discount is the usual incentive for humans to actually consider the AI offer.
Through 026, the AI may also offer more gold than it normally would.
When two AI civs are negotiating a joint war, the The civ already at war may offer one or two techs
civ that is already at war may offer a city (in and/or gold.
principle several, but I doubt that will happen) in
exchange for the declaration of war. Unlike in
other city trades, the offered city doesn't have to
be more valuable to the recipient than to the
current owner, at least not when the war is going
badly.
Rationale Not sure how frequently this will come about, but it could be pretty awesome when an
AI civ that seemed already doomed brings in a powerful neighbor as a war ally by
ceding a city.
Tbd. Such trades would work as a matter of course due to my changes to
CvPlayerAI::AI_counterPropose – but that function isn't actually used for war
trades; perhaps it should be (see comments in CvPlayerAI::AI_proposeWarTrade).
359
Loopholes closed by K-Mod (not a complete list I think):
AI never agrees to Cease Fire. Spread Culture spy mission doesn't increase city
culture.
Tbd. If I ever want to write AI code for Cease Fire: CvPlayerAI::AI_considerOffer
would be the place (see comment near the start of that function).
123a Can't gift Missionaries to bypass Theocracy
AdvCiv BtS
Can't gift a Missionary to a civ in Theocracy Can bypass the Theocracy restriction by gifting
unless the Missionary matches their state Missionaries. The AI will normally use them too.
religion.
Can't gift Caravels to a civ without an OB Can gift Missionaries inside Caravels in order to
agreement. spread a religion without OB.
Rationale The Theocracy restriction is pretty pointless this way. And keeping borders closed
should keep Missionaries out, period.
Credits Kek-Mod fixed the Theocracy part independently. I hadn't thought of cargo units (other
than Caravels), so I've adopted part of the Kek-Mod fix.
See also kekm.4
Help text based on 093
123b Unused
123c Chains of cargo units
Land units can only be loaded as cargo if they Loading and unloading don't require moves
have at least 1 move left. (although Loading consumes all moves).
Can move land units across arbitrary distances
No change to air units; can still be loaded right over water within a single turn by using a chain of
after rebasing. dispersed cargo units.
123d Reduce war success when trading away a city while at war
When a city is traded away, and the old owner is A player can conquer a city (+25 war success
at war with any earlier owners of the traded city, against the enemy), gift it to a war ally (no
the war success of the old owner against these change to war success), wait for the enemy to
earlier owners is reduced by 25. conquer the city again (+25 war success against
the player's ally), and repeat. The war enemy will
then assume that the war against the player is
going very badly.
[Actually, BtS counts only 10 war success points
per city; BBAI has increased that to 25. So this
isn't as much of an issue in BtS.]
Rationale Not so easy to exploit, but occasionally leads to quick capitulation.
Reducing the war success against all earlier owners can be overkill, but this is difficult
to avoid.
Tbd. The war success counted for a conquered (or traded) city should be based on the
importance of the city. Currently, every city counts as WAR_SUCCESS_CITY_CAPTURING
– which should remain the base value, to be multiplied by some modifier – except the
capital, which already has a modifier of 1.5 (was 2 in BBAI; I've reduced it). The
function that records war success is CvUnit::setXY.
123e Privateers can no longer plunder gold from Barbarian cities
360
Credits Civ 4 Reimagined 1.2
See also 033 prevents Privateers from plundering vassal cities.
123f Fail gold only for great wonders and at most once per wonder
Tbd. Perhaps convert only 50% of the invested production into gold and the rest into city
culture. That should be a separate change id though because it's a balance change
rather than just closing a loophole. For now, fail gold remains a valid tactic, and this
gives wonders with very weak abilities (e.g. Chichen Itza) at least some use.
AdvCiv BtS
When a great wonder is completed in a city, that After a message about a rival finishing a wonder,
wonder is immediately removed from the another turn passes before the game removes
production queues of all other cities, generating the wonder from production queues and
fail gold. generates fail gold.
Exception: Members of the team that has No such exception.
completed the wonder never receive fail gold.
When a player has invested production into a Fail gold is generating regardless of whether the
wonder but removed that wonder from the wonder is queued. This allows crafty players to
production queue, no fail gold is generated. cash in multiple times per wonder.
World projects are treated just like wonders. Units, national wonders, great wonders, world
Units and national wonders never produce fail and team projects are all treated alike, meaning
gold. that fail gold can also be obtained from e.g.
Missionaries (see this CFC thread).
Rationale The Wealth process should be used for converting production into gold, and that's
already a pretty efficient conversion. Award fail gold only when it has to be done,
namely when a civ is beaten to a wonder by a rival. If there was no such
compensation, wonders would become too unattractive and frustrating. (Civ 6
reportedly has that problem.)
AdvCiv K-Mod
Units never produce overflow gold. K-Mod uses excess production on additional
units of the same type. Overflow can still occur I
think, but only on units with a national limit.
As for buildings (no change): BtS 3.19 with the
unofficial patch converts production into gold, but
cancels out building-specific modifiers like Stone
for Walls.
Rationale A side-effect of disabling fail gold for units, and I don't think that overflow gold should
be a worthwhile tactic.
Config MAXED_UNIT_GOLD_PERCENT in GlobalDefines_advc.xml.
Tbd. Once I remove the whip ability (hurry through population), it should be all but
impossible to use the overflow rules for converting production into gold.
123g Need to choose research a.s.a.p. at the start of a game
Once the player has founded a city, a choose- A choose-research popup appears one turn after
research popup appears. If the player ends the founding the first city. If the player manages to
turn without addressing the popup or sets avoid choosing a tech to research, then, during
research back to "no technology" after dealing the first five turns, research is stored as overflow
with the popup, the AI chooses a tech for the research; that research is spent once the player
player and the popup appears again on the next does select a tech and research modifiers are
turn. applied based on the selected tech. After five
361
turns, the AI chooses for the player. Not choosing
a tech for five turns can yield a little bit of extra
research due to known-tech modifiers; see the
After founding the first city, the choose-research description here on CFC.
popup appears before the choose-production
The choose-production popup appears first.
popup.
Rationale My guess is that the Civ 4 developers wanted to delay the choose-tech popup by one
turn to make the first turn easier for beginners, and set the limit to five turns because
the player might move the Settler around a bit before founding a city. For this mod,
this wouldn't make sense, and is a needless (and exploitable) complication.
Choosing tech before production should actually be a bit easier for experienced
players than vice versa.
See also Thread with detailed info on the subject (and a post by me)
362
long-distance trade routes between large cities, but these cities aren't usually the
borderland trade hubs that would realistically profit from trade passing through. Boils
down to the question if trade routes should be represented from end to end or hop by
hop.
For resource trades, only one side needs to be Trade connections are always symmetrical, so
able to reach the other. this isn't an issue.
Rationale Want a civ that establishes a trade connection to be able to trade resources right away
(as in BtS), instead of having to wait for the other civ to e.g. also research Sailing.
Trade along rivers doesn't require any tech; back Trade along owned rivers works from the
to how it worked prior to BtS. beginning, along unowned rivers only with
Sailing. Sailing help text just says "enables trade
Trade along unowned coasts still requires
on Rivers"/ "...Coasts".
Sailing. Help text says "Enables trade on Coasts
outside own borders".
Rationale Not sure why this change was made in BtS. The distinction between owned and
unowned rivers is pedantic, and confuses players (people ask about this now and then
on CFC). Rivers now work just like roads when it comes to trade.
Tbd. Want rivers to speed up movement as in Alpha Centauri. Fishing could enable this.
An AI civ is willing to sign Open Borders with OB based only on a personality-based attitude
another civ only once it has revealed a land tile threshold.
owned by that civ, or if AI attitude is one level
above the normal OB threshold, i.e. at Pleased in
most cases. Otherwise: "We would have nothing
to gain."
Exception (added in AdvCiv 0.99): If all revealed
tiles are located on continents where the AI civ
doesn't have any cities, then the tile will only
cause the AI to open its borders if a trade
connection exists between the AI capital and the
tile (through Sailing or Astronomy).
Relevant mostly for mod-mods: If the AI has a
unit adjacent to a tile that the unit can't currently
enter and will be able to enter through OB, then
the AI is willing to sign OB based on the normal
attitude threshold. (Even if the tile is not a land
tile and doesn't have a trade connection. I don't
think this can easily happen with the BtS/AdvCiv
roster of units.)
Will sign OB at attitude one level below the AI signs OB regardless of attitude when sharing
normal OB threshold when sharing a war but, a war.
again, only if there is a revealed owned tile.
The AI initiates OB with another AI (or proposes 20 turns after becoming willing, at least 20 turns
OB to a human) 10 turns (on average) after delay in between proposals (30 on average).
becoming willing to agree to an OB proposal. The
delay in between OB proposals is at least 40
turns (45 on average).
Rationale Don't want the AI to sign OB when it clearly won't benefit from the trade – at least not
at Cautious attitude.
Once the AI is willing to sign OB with another AI, it shouldn't wait for another (up to)
363
20 turns.
Credits Got the idea for signing OB more quickly from Civ 4 Reimagined 1.3. They even set it
to 5 turns.
See also 130i reduces the diplo bonus from OB that don't actually benefit the AI. This makes OB
less with remote AI civs less of a matter of course and thus makes it more important to
stop the AI from proposing OB over and over (through an increased contact delay).
130r: adjusts contact delays to the game speed setting.
Tbd. The condition for being able to immediately enter foreign borders with a unit is at best
a kludge. Let's assume that some mod-mod has a Medieval Cog unit that can reach
foreign lands across Ocean but (unlike Caravel) can't enter foreign borders without
OB, and assume that Astronomy is still required for cross-ocean trade. Don't want the
AI to be unwilling to sign OB when a Cog reaches another continent. The current AI
code will only make the AI willing to sign OB when the Cog is right at the borders; as
soon as it turns around, the offer will be off. I don't think it makes much sense to allow
cross-ocean movement without allowing cross-ocean trade, so maybe I should just
remove the kludge. It's also potentially expensive in terms of computing time.
The AI makes it a high priority to build at least The AI prioritizes exploration only until meeting
one naval explorer once it knows Sailing. all civs.
AI considers Galley to be suitable for exploration. Unit AI types for Galley are only Transport and
Attack. Before Caravels, only Work Boat and
Trireme have the Explore AI type. (Though
CvPlayerAI::AI_unitValue may have
considered Galley as an exploration unit
regardless of the types listed in XML.)
Rationale Due to the trade route rule change, the AI needs to explore coasts more reliably.
Should use Galleys too because Work Boats get picked off by Barbarians at some
point and Triremes come too late.
See also 905a increases the speed of Galleys; this makes them more suitable as explorers.
Trade can pass through hostile plots if these Trade can never pass through hostile plots and
plots are affected by a naval blockade by a party blockades can only prohibit trade.
that is not hostile to the trading civ. In particular,
the trading civ itself could blockade the plots.
The AI does not use blockades to enable trade.
Water tiles with a friendly unit can be worked despite being Blockade prevents tiles from being worked despite the
blockaded. Disabled again. It's a bit more sensible but too presence of units protecting the tile. Those units will have to
unimportant to bother. engage the blockading unit to make the tile workable.
364
a civ's trade network, if that structure is revealed the tile needs to be revealed in order to carry
to the civ. trade. Otherwise, it's sufficient if the tile is
revealed, even if the tile is fogged and no
structure existed the last time that it was visible.
(Structures on unowned tiles are unusual though,
so this isn't really a problem in BtS.)
Rationale Consistent with the (AdvCiv) rule that trade only works along revealed tiles and can
only be conducted with revealed cities.
See also Somewhat important for 004z, which lets the trade layer show trade connections on
unowned tiles. Don't want the Trade layer to give away structures hidden in the Fog of
War.
001i fixes other issues with routes in the fog of war.
Tiles workable by a city on a different landmass Whether a tile is workable doesn't matter for
can be connected to adjacent water tiles through trade connections. A connection between land
a route. This means, a resource on an island and water requires a river, city or fort. This
within the workable radius of a (mainland) city means, an offshore resource that is worked by a
doesn't require a fort in order to be connected. mainland city can (unless there is a river on the
island) either be worked for its maximal yield (no
fort) or be connected to the trade network (fort) –
but not both.
Rationale This keeps confusing players, see e.g. this thread on CFC. My change removes the
awkward choice between connecting the resource and exploiting its improvement
yields. It doesn't remove the confusion in situations when a tile is owned by the player
but not workable. If any owned route would connect to coast ... – see the notes below
regarding the rule change from AdvCiv 0.95 to 0.96 about that.
The different-landmass clause wasn't added until v0.96. At first (v0.95), I thought I
wouldn't need to make this a special rule for islands. However, allowing all workable
tiles to be connected to water through a route meant that no coastal city/ fort was
required for a long-distance coastal trade connection in the early game and that a
single route sufficed for connecting any coastal resource. In v0.96, there was the
additional requirement of owning no cities on the resource's landmass. That seems
like a needless complication to me now.
See also 040: The AI transports Workers to workable tiles on other landmasses.
Other mods have addressed this problem as well, Realism Invictus at least, though I
don't remember how exactly.
Naval trade passing through a fort doesn't Trade can pass through land tiles only through a
require a route on the fort. route, river or city (has a route built in).
Rationale Looks like an oversight that happened when forts were given their additional abilities
by the BtS expansion.
Credits Bug report (toward the end of the post) with screenshot
Mercantilism allows trade routes with vassals of Only with the master. (And the master can have
the same master (and with the master). Help text trade routes with its vassals – no change.)
(Civics screen, new-civic popup, Civilopedia) Help text says that trade routes with all foreign
says that Mercantilism blocks only trade routes civs are blocked. I don't think the exception for
with rivals. vassal/ master (presumably introduced by
Warlords) is mentioned anywhere.
Rationale This minor rule change makes the improved help text easier to phrase.
365
125 Culture from trade routes disabled
AdvCiv K-Mod
Trade routes generate only raw commerce. Trade routes generate foreign tile culture in
Trade routes only generate culture if the city tile already addition to raw commerce.
has some culture (more than 0 points) of the trade partner.
(Decided to disable it entirely instead.)
Rationale The only real upside of trade culture is flavor, and I don't think this justifies the added
complexity. The confusing part is that trade culture could also be added to city culture
(but it isn't). Tile culture from faraway trade partners may be a disadvantage in local
border disputes; difficult to say.
Unimportant culture in plot help text is another problem. Very small percentages aren't
shown, but this means plot culture sums up to just, say, 97% sometimes, which is
confusing. (99% is OK – everyone's used to that.)
Another issue: The Nationality bar on the city screen can show only culture of up to
four different civs, and this can't be changed within the SDK.
Config USE_KMOD_TRADE_CULTURE in GlobalDefines_advc
366
126 Changes to the later-era start option
See also 138 changes the religion assignment when starting in a later era
307 makes Machine Gun ineligible as a free starting unit (because it can't stop
Barbarians from pillaging).
314 allows tribal villages when starting in the Medieval era.
AdvCiv BtS
Added one free tech for each era after Ancient When starting in a later era, every civ receives at
(except Future) to each difficulty setting that least all Ancient techs. Neither human nor AI
grants free technology to the AI. These free receive free techs beyond those.
techs are only granted when starting in the
respective era.
Similarly, the human player receives additional
free techs on Chieftain and Settler.
On Settler to Chieftain and Monarch to Immortal,
the new free techs are
Mathematics, Machinery, Printing Press,
Steampower and Plastics.
In addition to those, AI Deity and human Settler
receive
Ironworking (only AI), Alphabet (only human),
Feudalism, Gunpowder, Steel and Refrigeration.
On difficulty settings that grant free units to the Every civ receives additional free units in later
AI, more units are granted when starting in a eras. AI civs also receive free units granted by the
later era: another defensive unit for each era difficulty setting. All free units are chosen based
beyond Ancient, another Worker for every 2 eras on the start era, e.g. Riflemen as defensive units
and another Scout or Explorer for every 3 eras. when starting in the Industrial era.
Rationale Games starting in later eras tend to be much easier to win than normal games, surely
in no small part, because the AI doesn't get a proper head start. No tech advantage,
and the extra free units are relatively few compared with the total number of free units,
which may even allow a human player to conquer a high-level AI right away.
Config The free tech is configured in Civ4HandicapInfo.xml.
See also 301 prevents Barbarians from using Copper and Horse until these resources are
connected by some city. This used to be a problem with Classical starts – Barbarians
would have Axemen and Horse Archers right away, whereas the (AI) civs needed
some 50 turns to establish access to Copper or Horse.
Tbd. The free techs aren't carefully chosen. At some point, I want to change the era of some
techs; can reconsider the freebies after that.
Later-era starts probably still have balance issues that make them too easy or too
difficult to win; I've never even finished a test game starting in a later era. Would be
nice to make at least Classical and Medieval starts playable; these aren't that different
from normal games, but could be different enough to be refreshing.
A tech can only fulfill a requirement of another For example, in the Earth1000AD scenario, India
tech when all tech required by the first tech are starts with Paper but doesn't have any of its
known. prerequisites. This does not prevent India from
researching Education (enabled by Paper).
Rationale I'm not sure why I've placed this change under this change id. It seems that I didn't
document it at the time. Could be relevant for free techs granted in later eras but isn't
currently relevant. Also not relevant for Archery as a free tech on Monarch difficulty in
367
the Ancient era because Archery is a dead-end. Used to be relevant for free Pottery on
“King” difficulty (250a), but that difficulty setting no longer exists.
Reverted this change in AdvCiv 1.05 because it's not fully compatible with the AI
evaluation of tech paths in K-Mod 1.46. That can be relevant when techs are granted
through the WorldBuilder, or maysbe in some third-party scenario.
The point and XP thresholds for Great People When starting in Renaissance, the GP thresholds
(GP) are not affected by the start era. are decreased by 10%, by 20% for Industrial,
30% Modern and 40% Future.
Rationale The initial GP threshold is much lower when starting in Renaissance (namely 100)
than when a normal game reaches that era, and, with the two initial cities with two
population each, free Forges and Mercantilism, civs can and will immediately breed
Engineers. This is pretty strange, so I was going to increase the initial GP thresholds
for Renaissance and later starts. However, when starting in Renaissance, it takes way
too long to discover essential Renaissance techs like Astronomy, and easy access to
Great People can mitigate this problem. Now I'm simply using the standard thresholds
as a compromise.
Config Civ4EraInfos.xml
See also 005b skips early GP names when starting in a later era.
008a makes minor changes to the wonders available in later start eras.
The non-Ancient scenarios of the Dawn of Civilization mod pretend that a certain
number of GP have already been born. Git commit: GitHub
Free buildings per start era: When starting in the Medieval era or later, all
cities founded throughout the game receive some
free buildings.
Medieval: Granary, Walls Medieval: Granary, Lighthouse (if coastal)
Renaissance: Market, Library Renaissance: Aqueduct, Forge
Industrial: Aqueduct, Forge Industrial: Market, Harbor (if coastal)
Modern: Courthouse, Grocer Modern: Library, Courthouse, Jail
Future: Factory, Recycling Center Future: Factory
Rationale Want to keep it at two buildings added per era. Walls kind of spoil the fun, but Medieval
rush tactics seem too potent in BtS. Free Walls in the Industrial era are immediately
obsolete but still raise city defense. No more room then for the coastal buildings. I also
don't like that these give a somewhat obscure extra incentive (an additional free
building) for settling at the coast.
Library instead of Forge in Renaissance should help jump-start research, especially
through Great Scientists. Aqueduct should stick with Forge as it helps against the
health penalty.
I suspect Jail was added in the Modern era because espionage was the big novelty
when the later-era start option was implemented.
Config Civ4BuildingInfos.xml; to disable Walls (and Dunn) in the Industrial era, set their
MaxStartEra to ERA_RENAISSANCE.
Tbd. Test this to see if the tech cost modifiers based on start era need to be adjusted.
Decreased the start turn for Medieval and Renaissance start a little.
Rationale Should match the tech pace better (or less badly).
Config Civ4EraInfos.xml
Culture level thresholds (except “Fledgling”) are The start era does not affect culture level
reduced when starting in the Medieval era or
368
later. For example, starting in the Modern era thresholds.
halves the culture level thresholds.
There was an unused tag iCulture in
Civ4EraInfos.xml that may have been intended
as a multiplier for culture level thresholds.
Another unused iCulture tag, in
Civ4GameSpeedInfos.xml, remains unused (but
that one is arguably superseded by
The victory screen shows how much culture is Civ4CultureLevelInfos.xml).
needed for victory. The victory screen only says that “Legendary”
culture is needed.
Config Civ4EraInfos.xml; I'm using the iCulture tag.
Rationale To make Culture victory viable regardless of the start era. To this end, it would be
enough to change the “Legendary” threshold, but might as well change the others too
for a smooth progression. Don't change the first threshold (“Fledgling”) unnecessarily
though; players know that one by heart.
Space victory arguably comes too early when starting in the Modern or Future era.
This can't really be fixed; players arguably should disable Space victory. Looking at it
this way, lowering the threshold for Culture victory may mean that players will also
want to disable Culture victory; inconvenient. That said, I don't want to base the culture
level adjustment on the assumption that Space victory will be disabled.
Tbd. I've no idea if halving the Legendary threshold is enough to make a Modern-start
Culture victory viable. I haven't tested (AI Auto Play) any of the values so far.
See also 251 adjusts the culture level thresholds to the game difficulty level.
369
While Auto Play is enabled, the proxy AI civs (i.e.Auto Play doesn't affect player handicaps;
originally human-controlled) adopt the AI however, proxy AI civs do benefit from AI bonuses
handicap. defined by the game handicap.
E.g. in a singleplayer game on Emperor In the example, the proxy AI civ incurs 100%
difficulty, the human civ normally incurs 100% times 80% = 80% inflation. Both factors come
inflation, and the AI civs 90% times 80% = 72%. from Emperor.
The 90% comes from the AI handicap (Noble),
and the 80% from the AI adjustment of the game
handicap (Emperor). On Auto Play, the proxy AI
civ also incurs 72% inflation.
Rationale For simulating all-AI games, proxy AI civs should play by the exact same rules as the
normal AI civs. AI Auto Play could also be used for fast-forwarding a normal
singleplayer game e.g. when a human victory looks inevitable. In this case, the human
AI civ should play by the same rules as a normal human. That's not what the original
AI Auto Play does (see example above), and implementing it like that actually looks
difficult. For development purposes, it's far more useful to treat proxy AI civs like
normal AI civs.
This change makes it unnecessary to take the human AI civ out of the game (e.g. by
surrounding it with sea Ice) when running a "Battle Royale"-style AI tournament.
Tbd. Should scenarios with unequal AI handicap settings (e.g. Earth1000AD) be exempt
from this change? E.g. the default handicap of France is Chieftain. If a player plays as
France, sets the game difficulty to Emperor and starts AI Auto Play, what should the AI
handicap be? Currently, it's the average of the other AI handicaps: Prince. I don't think
the difficulty from the scenario is accessible from the DLL if the player configures a
different one on the Custom Game screen.
See also The difference between player handicap and game handicap are also explained under
708.
The proxy AI ignores automation options, in Proxy AI civs don't replace improvements and
particular "Workers leave improvements/ don't chop Forests if the respective options are
forests". set.
Minimized popups (from the "minimize-popups" Minimized popups can remain on the screen for
option) are killed when Auto Play starts. some time.
Reminders (Alt+M) are not shown while in Auto Reminder messages and popups scheduled
Play. before starting Auto Play appear during Auto Play.
Rationale Probably just things jdog5000 hadn't thought of.
See also This K-Mod 1.45 commit ensures that AI workers don't automate their workers,
however, the automation options also affect AI code that gets executed by non-
automated workers.
Auto Play ends at the end of the player's turn Auto Play ends at the end of a proxy-AI turn.
that precedes the active player in the turn order, During the subsequent round of AI turns, the
i.e. normally at the end of a Barbarian turn. That human civ is already treated as human.
means, the human civ is treated as an AI civ
If the human civ is not in slot 0, e.g. in a scenario,
during the AI turns. In particular, other AI civs
it is also already treated as human during the AI
can't send diplo messages to the human civ, and
turns in lower slots.
thus there can't be diplo popups when human
control resumes.
370
Rationale It's counterintuitive that e.g. running Auto Play for a single turn only skips over the
human turn but not the AI turns.
Diplo messages upon resuming are problematic because they force the human player
to make decisions. Makes it impossible to simulate an all-AI game in chunks of e.g. 50
turns without any human influence. More generally, running Auto Play in multiple short
chunks produces markedly different results than a single long run; not good.
Caveat: While there can't be diplo popups anymore right after Auto Play ends, popups
are unusually frequent on the next turn. This is because the last-contacted timers of
the AI civs keep decreasing during Auto Play. Put differently: The AI has much to say if
you haven't spoken in a while.
For a fair all-AI game on Noble or Prince difficulty, it should now suffice to activate
Auto Play on turn 0; for other difficulties, the WorldBuilder is needed for giving the
human civ the same initial freebies as the AI civs. Could automate this (special
treatment for Auto Play on turn 0), but it seems not quite worth the effort.
Config A Python change (AIAutoPlay.py)
Tbd. The player can still be forced to make a proposal or vote on one right after Auto Play
ends.
(Not sure if this still applies to the latest version of AdvCiv. Generally, I think there is
no difference anymore between a single long AI Auto Play run and multiple short
ones.)
See also 044 creates autosaves also at the start of the active player's turn.
The AI attitude cache is updated when AI Auto Play starts and ends and when an autosave that
was created during AI Auto Play is loaded.
Rationale Some of the “first impression” relations modifiers don't apply to humans (i.e. they do
and should apply during AI Auto Play).
Disable the Ctrl+Shift+M shortcut. That combination causes 1 turn of AI Auto Play,
billed as “auto moves”/ “moving your units”.
Rationale One turn of AI Auto Play is not the same as letting the AI move the human units – see
the notes above about handicaps and the AI Auto Play lasting through the AI turns. It
might still be kind of handy to have a shortcut for 1 turn of AI Auto Play, but it shouldn't
involve the M key. Ctrl+Shift+1 collides with unit grouping shortcuts, Ctrl+Shift+F1 is
taken by the GameFont display ... Anyway, considering that 1 turn is the default
duration for Ctrl+Shift+X (a K-Mod change? I think it was 10 turns originally), I don't
think a separate shortcut is needed, and it seems safer to always require another click
for confirmation before starting AI Auto Play for any duration.
See also Also want to avoid confusion with the similar key combination for the savemap
function. Accidentally running 1 turn of AI Auto Play instead of saving the map would
be bad.
AdvCiv BtS/ K-Mod
371
Renamed CvDLLInterfaceIFaceBase:: Apparently there is a function CvInterface::
addMessage to “addMessageExternal”. Renamed addMessage in the EXE, which is responsible for
the wrapper for that interface to “addMessage”. displaying on-screen messages (immediately
(Some of the changes described above and through the bForce parameter, otherwise, the
below are implemented in that wrapper function.) message gets stored at a CvPlayer object). That
function is exposed to the DLL through a class
CvDLLInterfaceIFaceBase, and gets called in
numerous places. The call locations don't check
if the recipient of the message is human, which is
wasteful and results in a minor memory leak.
K-Mod fixes that through a wrapper function
CvDLLInterfaceIFaceBase::addHumanMessage
that discards non-human messages, and
changes all call locations from addMessage to
addHumanMessage.
Rationale Karadoc may not have realized that the it's possible to rename CvInterface::
addMessage despite it being a virtual function. Be that as it may, having a public
function called “addMessage” that programmers aren't supposed to use isn't good.
Discarding the messages to AI players does not avoid the overhead of composing the
message string; but that's not a concern because the number of on-screen messages
needs to be kept small in any case for usability reasons.
See also CFC post by me about wrapping addMessage calls.
Spectator mode
AdvCiv AI Auto Play mod
When both in AI Auto Play and Debug mode, the Messages are displayed as if the player was in
human player receives messages about the control, i.e. based on the information available to
following major events regardless of whether the the player's civ.
civs and cities mentioned in the messages are
known to the player's civ: war/peace, Defensive
Pact or Permanent Alliance signed, vassal
agreement started/ended, city conquered/razed,
capital relocated (though not a major event; cf.
106), city culture-flipped, city or colony liberated,
wonder completed, Golden Age started/ended,
religion founded, state religion changed,
I think the original Auto Play mod delivered
resolution of the Apostolic Palace or UN passed,
messages as if the human player was in control,
Legendary culture reached, nuke
including indicator bubbles on the map that
launched/intercepted, meltdown.
weren't cleared until Auto Play ended. No
The messages are shown in the usual colors and indicator bubbles in K-Mod (good), but colors and
can be located on the map once Auto Play ends location info were also removed.
by clicking on them in the Event Log.
Rationale Civics changes (except Free Religion) and random events aren't reported because
they occur too frequently.
It would be nice if messages did not refer to the player's civ as "you" (e.g. "You
declared war on Alexander!"), but it's too much work to change this.
Sadly, one can't use the Event Log to jump to locations that aren't revealed to the
active player. The EXE checks isRevealed with bDebug=false before moving the
camera, without calling any DLL code beforehand. (CvDLLWidgetData::
doGotoTurnEvent isn't called either.)
372
See also 104v shows messages about AI war plans when in Spectator mode.
007b requires Debug mode for some debug/ cheat key combinations. This should
allow players to keep cheats ("chipotle") permanently enabled without using them by
accident.
106 added the notification about meltdowns for players other than the city owner.
Tbd. Also show messages about diplo resolutions that don't pass?
Known issue: CvRandomEventInterface.py calls CvInterface::addMessage
directly, which means that the code in CvDLLInterfaceIFaceBase::
addMessage for suppressing info messages during Auto Play has no effect on
messages generated by random events. Would have to expose the DLL's
addMessage function to Python to fix this, but that's a bit laborious because of all the
non-primitive call parameters.
Can use AI Auto Play in multiplayer by setting Multiplayer is supposed to be supported in the
ENABLE_AUTOPLAY_MULTIPLAYER to 1 in final version (2.0, which is, as far as I can tell, the
GlobalDefines_devel.xml. All players become version included in K-Mod): "AIAutoPlay is now
automated and de-automated at once. multiplayer compatible [...]: it will apply to all
players, not just the one who activates it."
(source)
This final addition probably wasn't tested much;
due to what looks like a bug, only one player gets
automated at a time, and only one can be
returned to human control.
The K-Mod cheat mode check wasn't Moreover, K-Mod 1.30 made this change:
implemented correctly. Cheats weren't disabled "Autoplay and change player functionality is now
in multiplayer when a singleplayer game was only available in cheat mode." However, cheat
started beforehand. Now fixed. mode ("chipotle") isn't recognized in multiplayer
games.
See also 135c allows Debug mode and WorldBuilder in multiplayer.
Tbd. Known issues:
When AI Auto Play ends in a game with simultaneous turns, the game sometimes
goes OOS. Perhaps not difficult to fix. (But not that much of a problem because AI
Auto Play with simultaneous turns isn't really useful for OOS debugging anyway –
because the RNG sequence isn't reproducible.)
Interrupting AI Auto Play through Ctrl+Shift+X stops AI Auto Play only on one
machine.
Would like to disable AI Auto Play in singleplayer mode when playing with the “Lock
Modified Assets” option because AI Auto Play can work as a cheat in difficulties below
Noble. However, if it's disabled through BugEventManager.py, AI Auto Play will
remain disabled after exiting to the opening menu and creating a new game without
“Lock Modified Assets”. So I'd have to disable it somehow in the AI Auto Play
component itself.
Start and end of Auto Play are recorded in replays.
See also Relevant mostly for R&F
Civ4lerts are not updated during Auto Play and AI civs don't have attached Civ4lerts, but when a
no alert messages are displayed right after Auto human civ comes under AI control during Auto
Play ends. Play, its Civ4lerts keep getting updated. When
Auto Play ends, alerts are displayed based on
the differences between the current game state
and that on the last turn under AI control.
373
Rationale The updates during Auto Play are a waste of CPU time. And the game state after Auto
Play ends can be completely different from the game state before Auto Play started;
alerts shouldn't try to communicate that difference.
See also 106c prevents alerts from being shown right after loading a savegame.
Tbd. I've added an is-AutoPlay check to every onEvent function in the two Civ4lert scripts.
The cleaner (and faster) approach would be to unsubscribe the Civ4lert objects from
being notified of game events when Auto Play starts and to re-register them when
Auto Play ends. (It's an Observer design pattern.) My Python skills aren't quite up to
this task.
(The alerts added by 210 are disabled during Auto Play in a clean manner through the
AdvCiv4lerts class.)
When the active player is defeated during AI Auto When the checkPlayer method recognizes that
Play, the (non-human, non-Barbarian) player with the active player has been defeated, it creates a
the next highest id becomes the active player. AI Settler unit for that player at coordinates (0,0) in
Auto Play continues uninterrupted. (If this order to prevent the game from ending. A popup
procedure fails somehow, checkPlayer in for selecting a different player is launched and
AIAutoPlay.py is used as a fallback.) gets displayed at the start of the (defeated) active
player's turn. Not sure if that had been working
correctly in K-Mod. If it fails, the active may end
of with a Lion unit; I guess that happens through
BtS code.
Rationale I think AI Auto Play is mostly used for testing and for watching all-AI games. In those
cases, it doesn't really matter which player is the active (human) player, but
interrupting AI Auto Play can be annoying when it runs unobserved. It's also difficult to
ensure that the original procedure works smoothly.
See also A bugfix in CvPlayer::acquireCity (listed under 001) causes players to be defeated
as soon as they lose their last city – rather than delaying defeat until the start of the
next game turn. This makes it more difficult to get checkPlayer to work correctly and
without failed assertions.
When AI Auto Play is used in One-City Challenge The special rules only apply to players so long as
or Always War games, those rules continue to they are under human control.
apply to the automated human player.
Rationale Should help with testing those options through AI Auto Play.
374
When the player clicks on an announcement in Announcements about events that don't happen
the Event Log, the camera will normally focus on in a particular tile don't get associated with any
a tile that has something to do with the respectivetile on the map. Clicking on such an
event: announcement in the Event Log has no effect.
Anarchy, Golden Age begun/ ended, project Apart from the click-to-jump behavior,
completed, civic/ religion change, announcements with an associated tile will
circumnavigation: Jump to the capital of the highlight that tile with a flashing dot on the
affected civ. minimap (no change in AdvCiv).
DoW, war trade alert: Jump to the capital of the
civ that started the war (unless it's the active
player) or has become willing to start a war.
Peace made, PA, DP, vassal agreement signed/
broken: Jump to the capital of the civ that has
initiated the treaty/ cancelation. (One might as
well jump to the other capital; this is pretty
arbitrary.)
Colony liberated: Jump to the location of the new
capital.
Diplo vote: Jump to the location of the vote
source (AP or UN); when a resolution passes,
also show an indicator bubble on the map.
Rationale No harm in allowing these camera jumps via the Event Log. (The flashing dot doesn't
amount to a distraction.) Mostly helpful for following Auto Play games, in order to jump
back and forth on the map as wars are declared, ended etc.
Indicator bubble for passed resolutions: "This is the city you need to conquer in order
to stop such resolutions in the future."
375
Rationale Since ChangePlayer now requires the cheat code for everything, a different shortcut
would have to be used. Ctrl+Shift+G is available. However, it seems that the
automatic graphics updates after changing a civ or leader are sufficient. When there is
no visible effect (except for a harmless failed assertion from change 210), the shortcut
will only cause confusion.
Use a hack that temporarily sets a Barbarian unit After a civ change, flag graphics are updated by
flag for every plot in order to update the flag temporarily changing the active player's era.
graphics. During the era change, AI Auto Play is enabled in
(Prior to v0.97, I had instead added a bGraphicsOnly order to suppress the new-era popup.
parameter to CvPlayer::setCurrentEra that caused the
function to return after setDirty(Flag_DIRTY_BIT,...).)
Rationale The new hack seems less intrusive. Also allows the flag graphic to be changed
separately from the civilization.
See also Brief discussion about updating flag graphics in the Realism Invictus thread
No option to change a player's team. The Ctrl+Shift+P popup allows teams to be
reassigned. However, the reassignment is
ignored by the code that processes the popup
and therefore has no effect.
Rationale I'm not interested in that feature, so I'm not going to fix it.
Update the AI attitude cache for both civs after No update of the AI attitude cache.
switching human control.
Rationale Some of the first-impression modifiers don't apply to human players, so the cache
needs to be updated.
See also 127 updates the AI attitude cache at the start and end of AI Auto Play.
Merged parts of the CvGame::nextActivePlayer function (Alt+Z) into BBAI's CvGame::
changeHumanPlayer function (Ctrl+Shift+L) because their functionality overlapped. This also
seems to have fixed an issue with the diplo screen refusing to put certain trade items on the table
when trading with a previously human-controlled AI civ. Apparently, the diplo screen (in the EXE)
checks the net IDs of the trade parties, and the BBAI code hadn't updated those.
And, in single-player, the DLL no longer relies on the EXE for providing the correct net IDs when
loading a savegame from within a running game. It seems that the net IDs stored by the DLL aren't
reliable when different player IDs are active in the running game and in the savegame. This could
explain why, by my recollection, player cycling through Alt+Z had also been causing the diplo
screen issue sometimes (not just Ctrl+Shift+L).
Tbd. Perhaps an alternative (cleaner?) fix for the issue with loaded savegames would to be
set to -1 for the human proxy during AI Auto Play. (I don't know if the problem had only
been occurring with saves created during AI Auto Play.)
There appears to be a rare – perhaps unrelated – issue that makes it impossible to
add either gold or gold per turn to the trade table. I've only encountered this once in a
R&F game, but this Realism Invictus bug report seems to describe the same problem.
While the net ID issue had, technically (at times also visually), allowed trade items to
be added but then immediately took them off the table again, the second issue
prevents gold from being added in the first place; in the DLL, nothing seems to
happen at all once the amount of gold has been entered, in particular no call to
CvPlayer::canTradeItem or updateTradeList.
See also CFC post about the player switching and gold trading issues also occurring in RFC
mods. And another CFC post about the gold trading issue, not mod mentioned.
376
128 AI cheats less obviously with visibility
AdvCiv BtS
An AI unit can't target units on invisible tiles The Unit AI treats all tiles within a unit's search
unless those units are within a randomized range as visible.
subrange of the search range around the AI unit.
Units in visible tiles (e.g. visible by a different AI
unit) can be targeted within the whole search
range; no change.
Rationale This (well known) AI cheat becomes very obvious when AI ships pursue human
Privateers or intercept human cargo. (The search range is a multiple of the number of
movement points, and ships have lots of movement points.)
Can't just exclude all invisible tiles because this would leave the AI completely unable
to pursue units. I also doubt that AI patrols could search for enemy cargo ships
effectively.
With my change, the AI sometimes finds targets on invisible tiles, and sometimes
doesn't. This looks similar enough to human guessing and deduction, which also isn't
always successful.
When checking for possible enemy attacks (plot Plot danger is usually only checked within a 2-tile
danger functions), the AI treats enemies in tiles range, so most of the tiles are visible, but this
that are not currently visible as if they were isn't enforced.
visible with a probability of 50%. This is
implemented through a hash value salted with
the game turn number, meaning that the outcome
doesn't change if the plot danger functions are
called several times for the same tile on the
same turn. E.g. if a human Worker builds a road on neutral
territory, an approaching Wolf or Panther will
When plot danger is checked for human units
cause the game to interrupt the Worker, even if
(e.g. to wake up a threatened Worker), only
the animal is still 2 tiles away and out of sight.
visible threats are considered (no cheating).
Rationale Same as above.
See also 001k fixes a bug in the plot danger functions.
001i prevents the plot danger functions from taking into account roads in the fog of
war.
004l lets the AI use the pathfinder in the early game to check for possible human
attacks.
The tactical AI for air missions uses perfect Always ignores the fog of war when checking for
information only sometimes (randomly) when enemy interceptors.
checking for enemy air interceptors.
Rationale At least for the paradrop mission, playing fully by the rules would seem too easy for
human players to take advantage of. The AI could also look bad with Airships against
a sparse human Fighter force. Cheating always, on the other hand, can be noticed.
(Though I think few players if any have ever noticed. So I wouldn't really mind simply
reverting this change if it turns out to hurt the AI significantly.)
See also Based on code written for 004c (enemy interception chance in help text).
377
129 Changes to resource, feature and river placement during map generation
See also 021 prevents Fur from being placed on hills and allows Banana, Sugar and Ivory on
Plains Jungle.
advc.tsl makes some changes to the Fractal landmass generator.
108 makes changes to starting site normalization
191 changes how random civs and leaders are chosen
AdvCiv BtS
Place fewer copies of resources that have a lot The number of copies of a given resource is
of eligible tiles, and thus would normally be proportional to the number of tiles where the
placed abundantly. E.g. a bit less seafood on resource could be placed.
maps with lots of coastline, and sparser
resources overall on Huge maps (but still far
more in total than on Large maps).
Rationale Make unusual maps a little less unusual and more playable.
Config SUBLINEAR_BONUS_QUANTITIES in GlobalDefines_advc
When placing (strategic) resources based on the The number of resources placed for the iPlayer
map's player count, the number of resources to XML tag increases linearly with the number of
be placed is increased a little bit on maps with players alive.
fewer than 8 players and decreased a bit on
maps with more than 8 players. E.g. on a map
with 16 players, the number of resources placed
is the same that BtS places for 14 players.
Rationale On overcrowded maps, strategic resources can become conspicuously commonplace.
Should be OK to place fewer copies when there are more players from whom to
capture or snatch away resources.
Tbd. There isn't a strong reason for applying this change to large maps that aren't
overcrowded. So perhaps it shouldn't apply to such maps.
When placing a cluster of resources, the The targets are processed in clockwise order,
probability of placing an additional resource and each one gets the same probability (25 or
decreases exponentially with each resource 50%, depending on the resource) until the upper
already placed. The potential target plots are limit is reached.
processed in a randomized order.
Rationale Make large clusters less likely, especially on maps that have large areas of uniform
terrain because such areas are especially likely to receive large resource clusters
(e.g. Ivory in a large area of Plains).
378
The map generator avoids placing more than It seems that a cluster can theoretically fill an
two resources of a kind adjacent to each other, entire 3x3 square. The number of copies to be
in particular when placing a cluster of resources placed on the map in total puts a cap on this, but
on a 3x3 square. not on large maps.
Added a separate resource class for Gold, Silver Nothing to ensure that multiple clusters are
and Gems. Clusters of these resources are now placed apart.
kept far enough apart to prevent a single city
from working all resources in both clusters.
(Actually, Silver can't be placed in clusters
anymore at all; see a few boxes below.)
Clusters of Gold, Gems and Ivory get spread out All clusters get spread across a 3x3 square.
over 21 tiles (a “city cross”); individual Gold and
Gems resources can't occur adjacent to each
other within that range. Decreased the
placement probability so that the number of
resources in a cluster is, on average, smaller
than in BtS (despite the increased diameter).
The map generator can produce large clusters of
Still not rare to get more than 1 Gold or Gems precious metals/stones that make for very
within a city's radius, but 3 or more are quite rare powerful (starting) city sites. 5 such resources
now, even on large maps. aren't that uncommon on large maps.
Rationale Starting plots with more than one Gems or Gold tend to be overpowered. Could also
be fixed when assigning starting plots or during normalization; however, the cluster
placement algorithm also scaled badly with map size, so it needed work anyway.
Ivory: Large clusters aren't really useful and look a bit strange; let's give the jumbos
some more room. (So long as War Elephants don't become too widely available this
way … If that's a problem, then it could help to restrict Ivory placement during the
normalization of starting sites.)
See also 108 never removes bad terrain or features from precious resources when normalizing
starting locations. Also weakens starting locations overall, and increases the value
counted for commerce a bit when evaluating starting locations.
Fur, Gold, Silver and Gems can appear on Fur, Gold, Silver, Gems, Banana, Corn, Cow,
multiple landmasses. Deer, Pig, Rice, Sheep, Wheat, Dye, Incense,
Ivory, Silk, Spices, Sugar and Wine (19 out of 35
resources) get placed only on one continent.
Rationale The single-continent restriction doesn't match the distribution of those resources on
Earth at all. As for encouraging trade, Fur isn't really a concern because it often
appears in groups. The precious minerals at least sometimes appear in groups and
their terrain restriction also tend to cluster them a bit.
Tbd. For Spice, Wine, Incense and Dye, the single-continent restriction is also dubious, and
they also appear mostly in clusters. (The restriction is defensible though by arguing
that e.g. Spice represents only black pepper and other spices of southern Asia; that
Wine refers only to Old World vines; Incense only to frankincense; and Dye only to
indigo.) Perhaps just remove the restriction for Wine, Incense and Dye; that would still
leave more than 1/3 of the resources overall unique to one continent.
Config bArea in Civ4BonusInfos.xml
Spices can appear at most at a latitude of 45°. 60°
379
Rationale I guess Firaxis were thinking of mustard, caraway and maybe horseradish. These
really are the only spicy spices that grow in a temperate climate. And mustard is not
even native there. 45° (maybe rather 40 …) is justifiable for cumin. But cumin wasn't
anywhere near as important as a trade commodity as the spices imported from and
via India. For realism, a limit of 25° or 20° would be best I think. However, I don't want
to deprive the higher latitudes of resources too much. I did want to make a least a
moderate change for the sake of the True Starts game option.
See also advc.tsl avoids placing temperate and subtropical civs near Spice resources.
Tbd. See below under FIsh – such a change could allow Spice to be restricted a bit more.
Relaxed the latitude restriction for Crab. Crab can only occur at latitude above 40°.
Decreased the overall frequency of Fish a little. Fish tends to be the most common resouce.
Rationale Too few Crabs; was quite a bit more rare than Clam. A latitude restriction for Crab isn't
realistic at all; they're caught all over the world. That said, keeping the range of Crab
and Clam at least somewhat apart is arguably good for gameplay.
Decreased Fish frequency to compensate for the Crab change. As an Ocean resource
(potentially), it also has too much impact on city placement.
Tbd. Would like to restrict the latitude range of Fish. That would be realistic insofar that,
historically, mainly fish from the North Atlantic was used as a (long.distance) trade
commodity. On the other hand, fish was a major food source for the Norte Chico
civilization near the equator … Perhaps, ideally, Fish would be more common in
higher latitudes.
Livestock resources can only be placed at a No lower bound for Horse and Cow. Pig had
latitude of at least 9°; Sheep: 25°. required at least 10°, Sheep 30°.
Rationale To account for the tsetse fly. That only affects Africa, but there also aren't a lot of large
farm animals in equatorial Brazil, Malaysia and Indonesia (though there probably are
some regions there with plenty of water buffalo or pigs). 9 or 10° makes a difference
on Standard-size maps (at least on Fractal). 9° only excludes livestock from 4 map
rows, 10° from 6 map rows.
Sheep are commonly kept in southern Iran and northern India, so 30° is a bit too
strict.
Tbd. Equatorial “jungle” (rainforest) is still far more productive than it should be.
Horses can be placed at a latitude of 9° (see 0-90°
above) to 68°.
Rationale Wikipedia lists 66.9°N (Finland) as the world's “nothernmost Equine veterinarian”. I
suppose Yakutian horses probably also aren't kept farther north than that.
The restriction won't matter much as there isn't much Tundra beyond 68° latitude.
Reduced the unique range of Horse and Oil a There have to be at least 6 tiles in between two
little bit. Horse resources and 7 in between two Oil
resources.
Rationale Understandable for gameplay reasons, but quite unrealistic. Now a little less so. The
steppe belts of the Earth are vast grazing grounds for horses.
Tbd. I have some plans for making (native) access to Oil less crucial. Eventually, Oil should
actually form clusters.
380
Map scripts try to place at least 0.78 Silver 1 Gold per player and 0.67 Silver.
resources per player, and only 0.78 Gold
resources.
Gold can appear on Ice, Desert and unforested Gold only on Desert and unforested Plains, and
Plains, river possible, whereas Silver can appear Silver on Ice and unforested Tundra. Both can
on forested Grassland and on Tundra regardless appear next to rivers.
of Forest, but not along rivers.
Silver can't be placed in a cluster.
Adjusted AI tech value so that Bronze Working is
prioritized when starting next to a Silver Forest.
Rationale Gold was arguably more rare throughout most of history. More importantly, Gold is
very powerful, and fewer occurrences should improve the game balance a bit. That
said, Grassland Silver Hill is nearly as powerful as Desert or Ice Gold Hill. Therefore I
haven't made Silver more abundant than Gold; don't want to make it too much more
important than in BtS.
Allow Silver to appear on forested Grassland to make it more easily accessible. Also,
restricting Silver to extreme latitudes is, as far as I can tell, completely unrealistic;
should really appear on just the same tiles as Gold. The intention was probably to
make Gold and Silver more distinct. I'm trying to keep them distinct but make the
distinction more historically informed. The most famous gold rushes happened in the
Australian desert, Alaska and maybe "on the banks of Sacramento," as a shanty says.
Silver can't be or isn't commonly panned from rivers. The densely forested Central
European mountain ranges have seen silver rushes in the Early Modern era
(Berggeschrey). Grassland Forest also fits with Colorado and British Columbia.
Indeed, silver mining might be more reliant on charcoal for refinement than gold
mining.
Ancient Egyptian gold deposits and silver in Attica and Baetica also fit.
Silver clusters disabled because, on Grassland Hills, they can be pretty powerful and
can easily occur near starting sites.
Gems can only appear on Jungle Grassland; thus distinct from Silver.
Credits Inspired by Civ 4 Reimagined 1.2, which also makes Silver more common than Gold.
See also The BASE mod also allows (my translation) “Gold in cold areas and Silver in warm
areas” – though I didn't get the idea from there.
rom3 enforces terrain restrictions also when Mines make random discoveries. As
Mines remove Forest and Jungle, feature requirements are not enforced.
When the same placement priority is set for two BtS relies on the order of the XML file (mostly
types of resources in XML, decide randomly alphabetic) in these cases. That results in a bias
which type to place on the map first. for certain resources near starting locations and
causes Sugar (one of the last resources in the
Similarly, during starting site normalization, go
file) never to be placed on extremely crowded
through the resource types in a random order
maps.
when looking for a suitable food or extra
resource.
See also Prompted by this CFC thread about certain resources never appearing on very
crowded maps.
381
Rationale Having a great variety of starting locations (or rather – among balanced and
historically plausible starting locations) is pretty important, so arbitrary biases should
really be avoided.
With my changes, some resource type may still be omitted on extremely crowded
maps, but it won't always be the same type.
See also advc.enum: The FOR_EACH_ENUM_RAND macro makes it pretty painless to randomize
the order in which alternatives are considered.
During normalization, 108 also avoids placing resource types that already exist
around the city.
When generating river sources, ties in the order For rivers sources, certain tiles are prioritized,
in which BtS considers tiles are broken randomly. especially hills and peaks, but e.g. among all hill
and peak tiles, those with the lowest map index
are tried first.
Rationale Should increase the variety among generated maps a little.
When deciding where to place a river segment, Rivers tend to flow away from peaks and hills
all four tiles (or rather: their terrain types) at and toward flat land and water. The terrain of the
whose corner the segment will arrive are given tile at whose southeastern corner a segment will
equal weight. arrive is given much higher weight than the
surrounding tiles. This gives one riverbank more
weight than the other and sometimes gives the
terrain orthogonally adjacent to the river segment
more weight and, at other times, the terrain
diagonally ahead of the segment.
Rationale Probably just laziness on the part of the Firaxis developer; obviously both sides of a
river should be treated equally, and the terrain next to and ahead of the river should
always matter, or at least it shouldn't make a difference whether the segment goes
west-to-east or south-to-north etc.
Increased the attraction of rivers to water tiles a bit.
Rationale Should result in somewhat shorter rivers overall. BtS generates very long rivers too
frequently for my taste.
Added a limit for the number of resources of one When placing a resource with a single-landmass
type to be placed on a landmass: Can only place restriction, as many resources are placed as
up to there are valid locations. Resources that can't be
placed on the target landmass aren't placed at
2 + ((number of tiles on the landmass) / 25).
all.
Excess resources are placed elsewhere; that can
The target landmass is chosen randomly with a
include small islands.
bias for large landmasses. K-Mod has added a
clause that rules out small islands entirely.
Rationale Mainly so that single-landmass resources can also appear on small islands. E.g. the
Spice Islands hadn't been possible with the BtS/K-Mod rule.
When selecting a landmass for a resource that is Only based on total landmass size and the
only supposed to appear on one landmass, take number of single-landmass resource types have
into account how many tiles on each landmass already been assigned to each landmass.
are eligible for receiving the resource.
Rationale Especially Banana was sometimes placed quite densely on landmasses with very little
Jungle. Can still happen though.
382
Decrease the variance in the number of Banana The number of resources placed is based in part
and Fish resources placed. on player count (fully predictable), in part on the
number of tiles eligible for receiving the resource
(somewhat unpredictable). Further variance is
explicitly added through the RandApp (random
appearance) XML elements.
Rationale See above about Banana; having an especially high number can look bad. I think
having very few Bananas sometimes isn't very interesting either. Similarly, neither
abundant nor scarce Fish plays particularly well.
Tweak the calculation of per-tile latitude values in The topmost row gets the maximal latitude value,
the DLL: The maximal latitude value (normally 90 etc.
– but see next blue box) is assumed to refer to
the top edge of the map and the minimal latitude
value (normally -90) to the bottom edge. The
latitude values of tiles are interpolated based on
this. Consequently, e.g. the latitude value of the
topmost row will normally be slightly less than 90.
Rationale The game shouldn't suggest that a whole row of tiles exists at 90° or -90° latitude.
This change gives all latitudes that aren't close to 90 a tiny bit more space; should
have only minimal impact on the terrain and resources that get placed.
Set the default latitude limits to 87 and -87 90 and -90
respectively. These apply to all map scripts that
don't set their own latitude limits, i.e. to all(?)
scripts that generate some sort of alternative
Earth, in particular Fractal.
Rationale Combined with the above, this sets e.g. the topmost row of tiles to 85 degrees on
Standard-size maps. So this chops off a little bit more of the extremely distorted
latitudes.
See also 137 changes the aspect ratio of all maps that don't set custom dimensions. Since the
aspect ratio is still greater than 1:1, one could assume that latitudes get vertically
compressed based on their distance from the equator, akin to the Miller cylindrical
map projection (but I wouldn't use such a complex formula), i.e. one could assign
smaller latitude bands to the polar regions than to the tropics and temperate zones.
But perhaps one should then also place a bit more land in the polar regions (most
map scripts have a explicit or implicit bias against that), so maybe it's best not to wade
into that,
Increased the grain adjustment for the placement I think how this works is that the Fractal algorithm
of hills, peaks and vegetation on Huge maps. normally creates larger clumps of elevation,
terrain(?) and features on larger maps. The grain
adjustment counters that to some extent.
Config Civ4WorldInfos.xml
Rationale With the BtS adjustment, Huge maps can still have big lumps of hills that can easily fill
the entire radius of a city. I don't think that plays well. It's nice if Huge maps look a little
bit coarser than smaller maps, but that's too pronounced in BtS. I think the surface of
the real Earth is a lot more fine-grained still than Huge maps in AdvCiv, so realism
isn't a problem.
129b No flood plains on river bends
383
Flood Plains appear only on Desert tiles that are Also on river bends and tiles diagonally adjacent
orthogonally adjacent to a river. Desert tiles that to a river mouth.
are only diagonally adjacent to a river still get 1
commerce from the river but no Flood Plains
feature.
Oasis can appear diagonally adjacent to a river (but is no Oases can't be adjacent to rivers.
more common there than on non-river tiles).
384
Config Can enable the code from the Unofficial Patch through GlobalDefines_advc.xml.
Rationale Don't want to encourage players to raze cities that were founded on Flood Plains just
so that the Flood Plains can be worked. Tedious micromanagement. In scenarios, the
Unofficial Patch may “re”place Flood Plains where none have ever existed. And
players may get the impression that Flood Plains aren't removed in the first place and
get confused about why founding on a Flood Plains doesn't yield extra food in the city
tile.
The disappearance of a Flood Plains also isn't necessarily more implausible than the
disappearance of other terrain features: The citizens may well have engineered the
river or degraded the soil so that it's no longer arable.
385
Increased the frequency of hills a tiny bit.
Rationale Don't want to change the balance too much, but more non-arable land would feel
more realistic.
386
See also 112: vassal agreements (especially voluntary ones, whereas 130v and 130d focus on
capitulated vassals)
141: No diplo effect from gifted GP
553: “Shared discoveries” relations modifier
AdvCiv BtS
130a Sustained peace
"Years of peace" only start to count when an AI Years of peace are counted from the beginning of
civ is met. The turns needed per relations bonus the game. The relations bonus is one for every 60
decrease from 60 initially to 30 in the middle of turns (and at most 2).
the game (normally AD 1700) and then stay at
30.
Rationale Being ignorant of each other's existence shouldn't "strengthen relations," and civs that
have just met shouldn't have strengthened relations. That said, don't want to make it
too difficult for civs that start isolated to find partners on other continents. The
decreasing threshold should also help keeping "years of peace" relevant after war in
the late game – when the game may end in 100 turns, it's almost irrelevant whether
relations are going to improve 60 turns from now.
See also 130k adjusts this counter to the game speed setting.
130b Personality-based modifiers
Peace weights reduced to 45% of their BtS Relations modifier from peace weight between -6
values and warmonger respect to 75%, resulting and +4, warmonger respect between 0 and 2.
in (fractional) relations from peace weight
(The peace weight of an AI leader is apparently a
between -2.7 and 1.8, and from warmonger
measure of that leader's love of peace. It's partly
respect between 0 and 1.5 and putting their
randomized at game start. Leaders with similar
rounded sum between -3 and 3. To this sum, a
peace weight like each other, and leaders with
modifier from the difficulty setting (see 148) and
dissimilar peace weight dislike each other.
a base modifier are added (e.g. Gandhi +2,
Tokugawa -1; no change). Warmonger respect says whether a leader is
considered to be a warmonger, and warmongers
like each other.)
Rationale I think these modifiers are intended to prevent warlike leaders from fighting
inconclusive wars among each other while the peaceable leaders get ahead
economically. Fair enough, but it's overdosed, sometimes leading to practically
inseparable bonds between peaceful civs. The excessive modifiers make diplomacy
overall too predictable from the beginning.
Config Only through the DLL; the personality values in XML are unchanged.
387
Tbd. When there is a large majority of either warlike or peaceable AI leaders in a game, the
small minority doesn't stand much of a chance. Can easily happen when AI leaders
are chosen at random. It's less of a problem with the change above, but I'm still
considering to adjust the hidden modifiers based on which leaders are in the game.
Could adjust the modifiers versus all AI leaders that are too popular or too unpopular
overall. Don't want every game to have perfectly balanced diplo though ...
Another problem: Don't want the modifier to give away info about the leaders that the
player hasn't yet met. If only met civs are taken into account, the first impression
modifier may change upon meeting a civ. But "a first impression is a lasting one"
suggests that the modifier doesn't ever change. One could lock them in at the time of
the first meeting, based only on the civs met thus far.
Or should I bias the random leader selection instead?
Perhaps gradually lower the first impression modifiers throughout the second half of
the game: brief CFC discussion
See also Explanation of Civ 6's “first impression of you” modifier (only conjectures as the
source code isn't released): CFC post
388
Apart from rank differences, game score ratios Only based on rank, specific scores don't matter.
also affect the relations modifier.
Rationale To stabilize the relations modifier. Ranks can easily change from one turn to the next.
See also Rank hate can oscillate in the early game. 148 alleviates this problem by lowering the
relations threshold for worst enmity (i.e. making the AI more hesitant to single out a
worst enemy).
Civs in the lower half of the leaderboard no longer have +1 relations with each other. However,
certain leaders still grant a relations bonus to civs ranked beneath them (no change), and rank-
based penalties are reduced among civs in the lower half. They're only slightly reduced though so
long as relatively few civs are known.
Rationale It's not necessarily wise for civs in the lower half to stick together either. Cooperation
is just one way to improve, war another. That being said, there mustn't be high
penalties for civs that are themselves struggling to keep up.
Tbd. Perhaps peaceful leaders should grant the bonus after all (as proposed by CFC user
Inthegrave here). Though not in the Ancient era.
Willem dislikes civs that are ahead of him and Willem is the only leader that dislikes civs that
likes civs that are behind him, just like all the are behind him, and likes those that are ahead.
other leaders.
Rationale Probably a mix-up by the BtS developers.
No diplo bonus from rank when the low-ranked AI victory strategies were introduced by BBAI;
civ is already at stage 3 or 4 of a victory strategy. the diplo modifier is only based on rank.
Conversely, AI civs at stage 3 or 4 of a victory
strategy only assign a diplo penalty to civs at
victory stage 4.
Rationale In the endgame, score and rank become unreliable measures of how well a civ is
doing.
Rank player vs. Peter 7-4 6-4 5-4 4-5 3-5 2-5 1-5
Modifier AdvCiv +1 +1 0 -1 -2 -1 0
Modifier BtS intended(?) +2 +1 +1 +1 0 -1 -1
Modifier BtS bugged(?) +1 +1 +1 +1 0 0 -1
Example 130c
389
130d A master can't be its own vassal's worst enemy, and capitulated vassals can't be
anyone's worst enemy. Can't ask civs in a vassal-master relationship to stop trading
with each other. If a vassal has either a forced (by the master) or unforced attitude of
Cautious or better toward a rival, then that rival can't be the vassal's worst enemy.
Rationale Most of the consequences of worst-enmity don't apply to the master anyway, in
particular, the vassal will always trade with the master. That means, a vassal with its
master as worst enemy effectively has no worst enemy at all. Perhaps OK, but
certainly don't want a vassal to promote trade embargoes against its master.
UWAI ignores relations with capitulated vassals; to be consistent with this, capitulated
vassals should not be worst enemies. Capitulated civs are already marginalized; their
enemies should be content with this.
See also The Dawn of Civilization mod also rules out worst enmity when the rank difference
between two teams is big. Git commit
130p prefers war enemies as worst enemies; 148 changes the relations threshold for
becoming worst enemies.
130e Worst enemy updated upon relations change
AdvCiv BtS
Whenever the relations value of an AI civ Worst enemy is only updated at the end of an AI
changes, that civ's worst enemy is immediately team's turn, i.e. never during a human turn.
updated. Attitude is updated immediately though, so, e.g.
after making peace with a human civ, if the AI
attitude changes from Annoyed to Pleased, the AI
will still consider the human its worst enemy for
the rest of the human turn.
Rationale Attitude and worst enmity should be consistent during human turns.
390
Apart from vassal and peace treaties, a trade Embargo doesn't affect deals with a positive
embargo cancels all deals, including those number of turns left to cancel.
recently signed.
The AI refuses to stop trading if it is currently
receiving reparations from or paying reparations
to the target: "Not right now ... Maybe we'll
change our mind in a few years."
Rationale It's confusing when some deals aren't canceled, especially between AI civs because
players can't see which inter-AI deals are recent. This contributes to embargoes being
largely irrelevant, and allows players to undercut AI embargo requests by renewing
resource trades every 10 turns.
Tbd. Or rather treat reparations as in BtS?
Can't propose a trade embargo if currently Except for the diplo penalty (negotiated a trade
trading with the target. Once enacted, the civ that embargo), the embargo does not affect the civ
proposed the embargo is affected by it as well, that proposes it.
i.e. the target won't talk to the instigator, though
there is no diplo penalty for having "stopped
trading with us", only the penalty for negotiating a
trade embargo.
Exception: A master can always tell its The vassal asks for compensation.
capitulated vassals to stop trading; this does not
disrupt the trades of the master. Moreover, the
capitulated vassal agrees to the embargo without
asking for compensation. The master still
receives a diplo penalty from the embargo target
though ("negotiated a trade embargo").
When a capitulated vassal breaks free or when a If e.g. a master asks its vassal to stop trading
civ capitulates, all stopped-trading memory of with a rival, the rival continues to not talk to the
and about that civ is deleted. vassal even if the vassal breaks away.
Rationale Trading with a civ after negotiating an embargo seems implausibly hypocritical.
The precondition for proposing an embargo (having no current deals with the target) is
needed because, otherwise, embargo proposals could be employed to terminate
uncancelable trades at will. This would be problematic in the case of per-turn war
reparations.
Regarding the exception for capitulated vassals: Colonies being allowed to trade only
with the mainland was a common practice in mercantilism. I'm keeping the diplo
penalty because I don't want players to routinely enact embargoes after accepting
capitulation; that would be a bit tedious.
Tbd. Should embargoes affect all players on the team that agrees to stop trading?
Currently, due to CvPlayer::isTradingWithTeam, embargoes only affect all team
members on the target side.
391
Stop-trading resolutions (UN, AP) cancel recently Recently signed deals don't prevent resolutions,
signed deals, and such deals don't prevent the but resolutions also don't cancel such deals.
resolution from being proposed. Exception: The
civ that proposes the resolution mustn't have
deals with the target that are too recent to be
canceled. The other AI civs try to honor their
commitments by voting against the resolution if
they have deals with the target that couldn't
normally be canceled.
Rationale To be consistent with the rules for bilateral embargoes.
See also Also consistent with kekm.25: war resolutions overrule peace treaties, but the
proposing civ mustn't have a peace treaty.
When a player proposes a trade embargo as part Normally refuses: "We don't like you enough" or
of a peace treaty, the AI doesn't refuse on "we couldn't betray our close friends".
account of attitude. Attitude (toward the war
enemy and toward the target of the embargo) still
factors into the trade value that the AI assigns to
the embargo.
Rationale Makes sense to ask the losing side in a war to stop trading e.g. with remaining war
enemies of the winning side, and the losing side should be open to this. Similarly, the
BtS AI doesn't check attitude when asked to change its religion as part of a peace
deal.
See also Similar issue with war trades as part of a peace treaty; see 100.
Similar rationale for 132 (change civics as part of a peace treaty).
Tbd. The AI should demand this when Furious and at war with the target or when the target
is the worst enemy despite the ongoing war. 039 might have to be adjusted.
When asked to stop trading, the AI assigns OB doubles the trade value of the embargo,
greater trade value to OB while at war. regardless of war.
Exception: trade value not increased when the
civ that asks for the embargo is at war with
everyone that the contacted civ is at war with.
Rationale OB are potentially more useful at war. Canceled OB can prevent the AI from reaching
its target cities. Unlikely to be a problem when the civ who's asking is a war ally.
Tbd. A proper evaluation of an OB agreement while at war would be too much work to
implement. But the AI should generally be very reluctant (possibly refuse) to sever OB
while at war and also while preparing war. The latter part is problematic because it
could expose AI war preparations.
Trade value charged by the AI for an embargo is No impact of attitude toward the civ that pays;
reduced by 25% if Pleased toward the (human) only the attitude toward the embargo target
civ that asks for the embargo, by 50% if Friendly. matters.
Rationale Embargoes seemed slightly overcosted overall (now that the preconditions are
stricter), and both attitude values should matter. At Annoyed attitude, the AI refuses
embargo trades anyway; therefore no point in a cost increase when attitude is low.
392
Refuse-to-talk duration after embargo is 18 turns 30 turns
on average. The trade value charged by the AI is
proportional to this expected duration (apart from
other factors).
"You agreed to stop trading with our worst 100 turns
enemy" is remembered for 50 turns on average.
Rationale 30 is too long considering that diplomacy is now more dynamic overall. And can let the
AI offer an embargo at a more reasonable cost now that the duration is shorter.
See also 130r makes the embargo target forget that the player stopped trading after 60 turns
on average. (The BtS AI never forgets this.)
Tbd. Should perhaps use the same AI memory decay rate for "You agreed to stop trading"
as for "You stopped trading." Not sure if 50 or 60 would be the better expected
duration though.
The relations penalty for negotiating a trade embargo is normally remembered for an average 60
turns (no change), but an embargo proposed against a war enemy is forgotten twice as fast by that
enemy (i.e. after 30 turns on average).
When a war ends, recent-embargo memory of all war parties is reduced to 1, meaning that
embargoed war parties become willing to trade 9 turns after the war ends (on average).
Rationale To make embargoes more useful and to help reconciliation after a war. Of course
players don't want third parties to trade with their war enemies – this shouldn't upset
the AI too much. Which is to say, being upset with a third party that agrees to the
embargo does make sense.
Furious AI civs don't ask for embargoes. The AI Typically, if the AI is Furious toward a player, then
also doesn't ask for an embargo if the relations that player is him-/herself the worst enemy. When
value toward the human is the same as toward the AI is Furious toward multiple teams, and the
the worst enemy or only one higher. player is not the worst enemy, then the attitude
toward the human doesn't prevent embargo
requests.
Rationale Not trading with other enemies of the AI is expected too much when already Furious.
And shouldn't keep digging when relations are already at rock bottom.
The relations-value clause should prevent worst-enemy oscillation.
If the AI attitude toward the (human) player that The most common attitude thresholds require
proposes an embargo is strictly greater than the that the AI is at least Pleased with the human
threshold (i.e. Friendly in most cases), the player and Annoyed or worse with the target of
attitude threshold for the embargo target is the embargo (else: "we couldn't betray our close
reduced by 1. However, except for Tokugawa, an friends"). Some AI leaders require Friendly or
AI leader still won't agree to stop trading with a only Cautious attitude toward the human and are
civ that he or she is Pleased with. willing to stop trading at Cautious attitude toward
the target. Only Tokugawa is willing to stop
trading despite being Pleased with the target.
Rationale The BtS thresholds for attitude toward the target are a bit strict – when Annoyed, there
isn't going to be much trading anyway. This change also makes Friendly attitude a bit
more rewarding.
Regardless of attitude, the AI refuses to stop Military power isn't taken into account.
trading if this means canceling Open Borders
with a dangerous civ: "We're afraid of their
military might."
393
Rationale Should make it harder to abuse the AI as a meat shield.
Power ratio is factored into the cost that the AI Only the game turn, number of cities, attitude
charges for an embargo. values and current deals matter.
Rationale Even if a civ is not an immediate threat, an embargo makes a war at a later time more
likely. Don't want humans to set a peaceful AI that is getting ahead in tech on a
collision course with a militarily more powerful civ through an embargo; or at least not
so easily.
The number of civs in the game factors into the embargo trade value.
Rationale An embargo is more consequential when there are few civs to trade with.
Tbd. Just counting the civs alive is a bit simplistic. Could copy code from
IllWill::preEvaluate for a start.
130g Relations penalty for rejected demand lifted during war
When an AI civ has been at war for at least 10 Rebuked demands are remembered for 150
turns, and it's a war the AI civ started, it forgets turns on average regardless of war.
about tribute demands rejected before the war.
Memory about demands is also erased when a
civ signs a vassal agreement. The vassal forgets
that its demands were rejected (but other civs
continue to remember demands that the vassal
rejected).
Rationale To make reconciliation after war easier. (Also, tribute demands are perhaps more
common with UWAI.)
The interpretation is that the rebuke has been avenged through war. (If the war was
unsuccessful, then the AI, apparently, had been wrong to make demands.)
Erasing the rebuke memory directly upon declaring war could obscure the fact that
the rebuke contributed to the DoW; the rebuke wouldn't be visible anymore on the
Foreign Advisor screen. Hence the 10 turn delay.
130h War-on-friend penalties
See also 130y deals with reduced declared-war-on-us penalties from vassals
When assigning war-on-friend penalties, master When a master civ is attacked, the aggressor
civs ignore their vassals, and vassal civs ignore gets a diplo penalty for declaring war on the
their master and the master's other vassals. master and – if the master likes its vassals – a
penalty for attacking the vassals. Similarly, the
Bringing in a war ally does not lead to a penalty
vassals resent the attack on their master, and
from vassals of the target (no change).
each vassal may resent the attack on the other
vassals (of the same master).
No war-on-friend penalty from anyone for Can get a penalty both for the master and its
attacking a capitulated vassal. capitulated vassal.
Rationale The "You declared war on us!" penalty suffices. Should make it a bit easier to have
normal relations with a vassal after helping it break free.
War on capitulated vassal: Relations toward a capitulated vassal should basically
never matter; see change 130v.
No penalty if the AI civ has war-on-friend memory about the attacked civ and the attacked civ has
recently attacked a liked civ (i.e. the liked civ has war plan "attacked" or "attacked recent").
394
Rationale If the AI is unhappy about a civ under attack, it shouldn't be unhappy about a third civ
attacking the aggressor (even if the AI still likes the aggressor).
Tbd. Not nice that this depends on information that the player can't see (AI war plan type).
The following should help a little (but still ...):
Vassals are upset about nukes dropped on their The forced attitude counts (as in most situations).
master only if the vassal's true attitude is Pleased
or greater.
Rationale As above, to decrease war-related diplo penalties from enemy vassals.
The confirmation popup for a declaration of war If war is declared through the diplo screen ("Your
lists all AI civs that are going to disapprove (if head would look good ...") or Alt+Click on the
any). Triggered Defensive Pacts are also listed. scoreboard, the "Does this mean war" popup
appears. When attempting to enter closed
borders, the "Entering will trigger war" popup
appears along with "You can peacefully enter if
you sign an Open Borders Treaty" if OB trading is
possible.
Rationale The list could be especially helpful in team games because the penalty is based on
team-toward-team attitude and I'm not sure that these attitude values are shown
anywhere on the UI.
Tbd. Perhaps something similar could be done with the raze-city popup when the city is a
holy one. Nukes also.
395
130j Friendly AI more resentful about bad actions, Annoyed AI happier about good actions
Changed scale of AI memory
Tbd. The scale factor of 2 is currently hardcoded in several places and a higher factor (3) is
used for declarations of war (DoW). Should either directly store the effect on relations
in the memory counters (e.g. decrease the DoW counter by 300 when war is declared
on the AI) or set a single scale factor in GlobalDefines. The latter approach would
have the advantage that any changes that a player makes to the AttitudePercent
values in XML would affect ongoing games and that there would be no danger of
overflow. A scale factor of 10 should suffice, and then it would take e.g. 3000 nukes to
cause a short int variable to overflow.
When an action displeases the AI, it adds 1 to The AI stores separate memory about each civ and for
corresponding memory if it's already Annoyed or each type of action, e.g. DoW or an accepted tribute
Furious, 3 if it's Friendly and 2 otherwise. When an request. When a diplo action occurs, the respective
action pleases the AI, it adds 1 if already Friendly, 3 if memory is increased by 1. The current AI attitude has
Annoyed or worse and 2 otherwise. no impact on this. (Although the AI e.g. doesn't make
This results e.g. in -4 relations for a DoW on a tribute demands at Pleased.)
Friendly civ, and only -2 if they're Annoyed.
(Disabled the attitude-based logic again.) Memory is
increased by 2 in all cases.
This faster increase of memory is evened out by The decay speed depends on the memory type
100% faster decay than in BtS for all memory and leader personality. E.g. Alexander
types, and the impact of each remembered remembers accepted tribute for 50 turns on
action is halved. average. That said, he could also forget about it
within just 5 turns or still remember it after 115
Since each action normally corresponds to a
turns (both ca. 10% probability).
memory value of 2, it's unlikely for an action to be
completely forgotten after a few turns, or to be
remembered fully for a long time.
"You razed our cities/ a holy city" and "You nuked
us" work differently; see 130q. (But not "You
nuked our friend".)
Rationale To make relations more dynamic. Also more plausible that a civ leader would be more
indignant about a DoW by a friend than by an enemy. The decreased randomness is a
welcome side effect.
It doesn't make sense to base the diplo penalty for razing and nuking on attitude because
these penalties only occur when already at war, and, then, the enemy attitude is usually
Annoyed or worse. One could, alternatively, treat raze and nuke like the other diplo actions, but
increase their base penalties; however, this would also affect razed cities with culture of non-
war parties (which aren't necessarily Annoyed), and the BtS base penalty of -2.5 is already
severe in this case.
I've disabled the core of this change in v0.91 because it's a change that players need
to know about, but that actually matters rarely. It can also create a counterintuitive
incentive to keep relations below Friendly.
The more fine-grained memory counting remains in place.
See also 130r uses an even finer scale for memory about declared war.
130k Some randomness added to AI diplo counters
See also 130i deals with the OB counter, and 149 with resource trade.
396
Counters relevant for diplo increase and For every civ, the AI keeps track of the number of
decrease probabilistically by either 0, 1 or 2 per turns spent in various relationships with that civ:
turn. war/peace, shared/opposed religion, shared
civics, resource trade, defensive pact, OB,
When the condition for increasing a counter is
shared war. E.g. the defensive pact counter is
not met, the counter is decreased by 1.7%.
increased by 1 on every turn that the two civs
have a defensive pact, and decreased by 1
otherwise.
Rationale While memory decay (130j) is too unpredictable in BtS, the counters are too
predictable. E.g. the "years of peace" bonus kicks in after exactly 60 turns.
Exponential decay should make diplo bonuses from counters less sticky.
The probability of increasing or decreasing a No game speed adjustment.
counter is adjusted to the game speed setting.
While an AI civ is in the Ancient era, the
probability is divided by the tech cost modifier
(e.g. 150% on Epic speed); after the Classical
era, the divisor is the memory decay modifier
(e.g. 125% on Epic speed); and, in the Classical
era, it's the mean of tech cost and memory decay
modifier (e.g. 137% on Epic).
See also 130r introduces the memory decay modifier for game speed adjustments.
Rationale On slower speed, more trades and wars tend to happen throughout the game than on
faster speed, but the difference is not that great, so the same middle ground as for
memory decay seems like a good compromise. The early game is special because
early wars are rare, so the peace and Open Borders counters usually increase
monotonically until the Iron Age or so, and at that point, the relations bonuses often
make AI leaders unwilling to attack each other on Epic and Marathon speed. Hence
the extra slow increase during the first game era.
The number of peace turns needed for Uses the same timer for trade route profit as for
maximizing the profit from foreign trade routes the “years of peace” diplo modifier – i.e. no
uses the same game speed adjustment as speed adjustment.
memory decay, e.g. 125% longer on Epic speed.
Config Separate modifier in Civ4GameSpeedInfos.xml: iFullTradeCreditPercent
130l Accepting an AI request reduces memory about a past rebuke and vice versa
AdvCiv BtS
397
(disabled by default since v0.85)
When an AI diplo request is approved by another Accepted and denied requests are remembered
civ, memory about previously denied requests of separately, and entirely so.
the same type is reduced by 1. Likewise, a
denied request reduces memory about previously
granted requests. Since each request normally
adds 2 occurrences to memory (see 130j),
subtracting 1 does not always have a visible
effect.
The following request types are affected by this
change: help, tribute, change religion, change
civics, join war, stop trading. Requests of differing
types do not affect each other; e.g. granting
tribute does not erase memory about denied
help.
Rationale Another means to turn bad relations around, and vice versa. Fairly low-key, I think.
Multiple AI requests in a row don't happen often, and only 1 memory is subtracted.
After some testing, I find that I never pay attention to this, and the other mechanisms
for more dynamic relations seem sufficient. Disabled in order to make the mod a little
less complex.
Config Can enable this change again through ENABLE_130L in GlobalDefines_advc.xml.
398
Rationale The everlasting relations bonus was reported as a potential bug for the Unofficial
Patch 3.13 but didn't get patched, and I agree that the BtS behavior is probably
deliberate. That said, a permanent relations bonus is clearly too big a reward for just
staying at war. My change should ensure that you need to fight alongside the AI in
(somewhat) good faith in order to get a relations bonus.
I don't think players need to know the specifics of the war success formula; I hope it
works pretty intuitively.
No shared war bonus if either war ally is a Shared wars can bring a master and its
capitulated vassal. capitulated vassals closer together.
No defensive pact bonus for capitulated vassals. All vassal agreements are treated as defensive
pacts when it comes to relations bonuses.
Rationale Capitulated vassals are dragged into war by their masters. They should generally be
unhappy about that. At best, the shared war experience can make up for this
unhappiness.
AI less likely to ask for military aid if the war is AI civs on whom a human civ has declared war in
still recent; same frequency overall. If Annoyed the past don't ask that human civ for military aid,
toward the player, the AI asks for an embargo but the current attitude isn't an obstacle.
instead of joint war. Past wars by the human
don't matter.
Also less inclined to ask for war against a civ that Can't ask if there's peace treaty, i.e. for 10 turns;
the player recently made peace with. beyond that, recent peace doesn't matter.
Rationale A joint war is asked too much from a civ that the AI considers to be an adversary. (Or
they could ask, but they shouldn't be mad when denied.) Embargo requests should
generally be more common when the AI is at war.
If the player has recently been at war with the target, then, apparently, the player is
unwilling or unable to defeat the target. Also don't want the AI to drag players into the
same war repeatedly.
Fighting against units inside another civ's borders War success has no impact on the shared-war
is extra effective at increasing the shared-war diplo, no matter where it occurs.
memory. Of course, these units need to be
hostile to the tile owner. Losing a unit in such a
fight counts as much as defeating a hostile unit.
Barbarians count as hostile in this context, i.e. it's
possible to get a "mutual military struggle" bonus
without even sharing a war, just by fighting
Barbarians inside the other civ's borders.
Fighting Barbarians elsewhere doesn't help
though, and the bonus won't exceed +1 unless
there is or was previously a shared war.
Units with hidden identity (i.e. Privateers) also
count (but not if the Privateer belongs to the plot
owner).
Rationale If someone engages enemy units in the AI's territory, that someone is really being
helpful, and not just competing for loot; the AI should appreciate that. Regarding
Barbarians, I sometimes find that my, say, scouting Chariot could help an AI civ
against Barbarian invaders, but BtS gives me no incentive to do so. The change
should make these situations more interesting.
399
The relations breakdown says “Our mutual Always present tense.
military struggle has brought us closer together”
when not currently sharing a war.
Rationale “Our struggle brings us closer” sounds a bit strange when not currently struggling
together. Might also help get across that the relations bonus is bigger while at war.
If UWAI is enabled, the AI does not ask the The human position is not considered by the AI.
player to join a war when it thinks that this would
be disastrous for the player. This is checked by
letting the proxy AI (see 130u) compute the
player's war utility. The AI may ask for an
embargo instead.
Rationale Would prefer to let the player decide whether a joint war is a bad idea, but the player
shouldn't be punished with a diplo penalty (help refused) for not being stupid.
400
The limits for the time-based ideological No such dynamic adjustment.
modifiers are decreased based on the portion of
known cities whose owner follows the ideology in
question. I.e. all revealed cities are counted so
long as their owner runs the proper state religion
(or civic), regardless of the religions present in
the cities. For the civ toward whom the modifier is
computed, even unrevealed cities are counted.
The high diplo bonuses from early civics, especially Hereditary Rule, are too easy to
get, and BtS diplomacy gets boring when everyone's in the same religion. Also to
reduce the overall (irrational) impact of ideologies on AI relations, considering that
change 148 reduces the threshold for Friendly relations (effectively) by 2 and that
change 130n reduces the limits for positive ideological modifiers only by 0.5.
The change seems also realistic: if everyone shares a trait, it gets taken for granted,
and lack of external enemies leads to infighting. And it's unwise to eschew everyone
when they all have "heathen" religions.
It's not so clear how the popularity of an ideology should be measured. Counting cities
rather than population makes it less important which tiles, exactly, are revealed. I don't
want players to worry about hiding or revealing their own cities or those of third
parties. Hence also the exception for the civ toward whom AI attitude is being
computed. This small vision cheat seems unlikely to leak exact city counts to
observant human players, and a rough estimate can be guessed from the player
score anyway. An important upside of disregarding unrevealed cities of third parties is
that, this way, the adjustment is mostly based on those civs that actually interact with
each other. E.g. when everyone on one continent is in the same religion, the same-
religion modifiers should be reduced a lot (i.e. about halved) at least until the other
continents (or their shores) have been explored a bit.
Tbd. When playing with Random Personalities, favorite civics and religions should arguably
be chosen based on the displayed leader rather than the leader AI personality.
Currently, favorite civics can, at some point of the game, be deduced from relations
modifiers toward other civs. BUG includes a pretty sizable module that does this job
for the human player and displays any knowable favorite civic on the Enhanced Info
tab (Foreign Advisor). Human players could still infer more by themselves, by taking
into account that the civics are much more popular than others, and the BUG
algorithm will break entirely of the same-civic modifier of an AI leader starts at +0
rather than +1. It's also stange that a leader wouldn't just announce the civic that
they'd like to promote in the world.
The different-religion penalty is also reduced when the offending religion has few adherents (again,
measured by revealed cities).
Rationale To make civs whose religion has failed to spread less unpopular. Also makes sense to
me that a religion with few followers would be more easily tolerated; it's not
threatening. Note that the adjustments to the different-religion penalty usually just
reduce the penalty by one if at all because the time-based portion is only between 0
and -2.
130o Changes to made-demand memory
See also 130v prevents vassals from acceding to tribute demands from rivals.
144: refusal of gift request.
401
When a human player declares war on an AI civ Accepting tribute results in a 10-turn peace
(primary DoW; not through DP), and that AI civ treaty. After that, there is no particular penalty for
remembers having paid tribute to the player, the declaring war despite tribute.
AI civ and all non-vassal AI civs that it has met
set their recent-demand memory about the player
to 8, which (due to change 130j) means that they
won't consider any requests for help or demands
for tribute by the player for (on average, on
Normal speed) 80 turns.
The declare-war confirmation popup warns the
human player about recent-demand memory
If the AI denies a demand for tribute, the human "You made an arrogant demand" regardless of
player does not receive a diplo penalty. Only whether tribute was granted; never goes away.
granted tribute results in "You made an arrogant
demand", and this memory decays after 30 turns
on average. I.e. the only negative consequence
of a denied demand is that the recent-demand
memory increases.
Accepting tribute still results in a peace treaty.
When an AI civ declares war (primary DoW) or
signs a vassal agreement, it sets all its arrogant-
demand memory to 0.
Rationale The BtS mechanism incentivizes players to demand tribute from civs about 10 turns
before attacking them anyway. Not at all how tribute should intuitively work, not how it
works when the AI asks tribute from a human player, and not an interesting decision.
Could go about improving this in many ways. My approach is supposed to be low-key
and low-effort. I've removed the penalty for failed demands because players need to
be able to tell if a civ has actually paid; if it hasn't, it's OK to attack. Moreover, a
penalty for a failed demand encourages reloading.
Not sure if the penalty (no requests for 80 turns) is painful, but at least it should stop
players from routinely receiving tribute before going to war.
Not ideal that the safety period is tied to memory decay – and thus randomized.
Wouldn't make sense to apply this change to AI civs that declare war after receiving
tribute from humans; AI civs never request or demand anything from each other, so
increasing AI-to-AI recent-demand memory would have no effect.
An earlier implementation kept the "arrogant demand" penalty for unsuccessful tribute
demands, and added a new type of diplo memory ("exacted tribute") to distinguish the
two outcomes.
Config The 80 turns are customizable in GlobalDefines_advc.xml.
402
Tbd. Arrogant demand should be remembered for a non-randomized period of time. Also,
30 turns is too long; try 25.
Would be nice to show info/ a reminder about this change on the diplo screen, before
or after the player makes a demand; however, the text with which the AI responds to a
demand is also used for vassal tribute (which doesn't cause "arrogant demand"
memory) and "We demand that you give us this in tribute" mustn't take up more than
one line because it's always shown while the player arranges trades. Could show a
message I guess (outside the diplo screen) ...
Would like rejected gift requests to add only 1 to recent-demand memory; lower
stakes that way. Would have to move code from CvPlayer::handleDiploEvent into
CvPlayerAI::AI_considerOffer for this.
See also 130h also adds warnings to the DoW confirmation dialog.
The AI remembers granted tribute demands for, 50 turns/ 150 turns
on average, 30 turns. Rebuked demands are
remembered for 120 turns.
Rationale To match the arrogant demand memory. And the rebuke memory decay was just too
slow generally in my opinion.
Config Implemented by reducing the BtS values read from XML to 60% in the DLL. Because I
didn't want to change the values for every single leader in XML.
Gandhi gets as upset as most other AI leaders Gandhi is the only leader who doesn't mind
(i.e. -1 relations) when he pays tribute. tribute demands.
Rationale Otherwise, the new mechanism couldn't apply to Gandhi, which would be strange:
why do the other AI civs not care when Gandhi is attacked after paying tribute?
Gandhi has still enough other quirks; he may well be the leader with the most extreme
personality overall.
When the AI disregards a request for a gift or a Each request adds fully to the recent-request
tribute demand because it still remembers a memory, meaning that, if the AI still remembers
recent request or demand (both based on recent- one recent request when a new request is made,
demand memory), recent-demand memory is it takes 40 turns on average until another request
only increased by one, meaning it'll take half as is considered.
long as in BtS until the next request/ demand is
Also, each tribute demand (regardless of
considered.
success) further worsens relations, up to a
Making requests and demands can't increase the maximum of 10 demands. I.e. one can worsen
recent-demand memory beyond 2. relations almost arbitrarily within a single turn.
Rationale Thanks to change 130j, there's now a lighter punishment available for aggressive
begging. 40 turns is awfully long.
If UWAI is enabled:
The AI remembers for 10 turns on average (plus Only remembers "You gave us tribute" (for 50
the duration of the peace treaty) whether a turns on average) but not whether the tribute was
human has recently accepted a demand. granted recently.
While the peace treaty from the demand lasts, The BtS AI never plans war during a peace
the AI doesn't plan war against the human. After treaty, but the K-Mod AI does; and the K-Mod AI
the peace treaty, so long as the demand is is able to declare war shortly after the peace
remembered as recent, the AI treats the human treaty ends.
as if its attitude was at least Pleased (as far as
war planning is concerned).
403
Rationale Since humans are now encouraged not to attack shortly after receiving tribute, it
seems like a double standard when the AI does it.
404
trades that are actually fair should still have some impact. This should also make it a
bit easier for AI civs to reach mutually Friendly relations (despite change 148, AI-AI
friendships are a bit scarce).
The coefficient was 5/6 instead of 4/5 until AdvCiv 1.04.
Open Borders (OB) with a worst enemy OB and DP factor into the trade memory for both
contribute significantly to the relations penalty. fair trade and enemy trade, but the deal value is
The impact is based on the number of turns that so small that the impact is negligible.
the two civs have had OB. None if the borders
aren't currently open.
OB (and Defensive Pact; DP) have no impact on Resource trades don't matter for trade memory.
the fair-trade bonus, and don't contribute to trade All ongoing deals can cause the AI to demand a
memory. Resource trades add to trade memory, trade embargo.
though the impact is normally small. The trade
value for the first ten turns is processed when the
deal is signed, then, once the deal can be
canceled, trade value is added turn by turn.
The AI refuses to sign a DP if a DP was recently The AI refuses to sign recently canceled OB, but,
canceled (explicitly canceled or through a war for DP, there is no such restriction.
declared by one of the signatories).
Rationale OB can be very helpful for the enemy civ, may even be crucial at wartime, so I don't
think the potential -1 from refusing a trade embargo is a sufficient penalty.
I prefer to keep OB and DP out of the trade memory, so that cancelation of those
deals immediately reduces the enemy trade penalty. This can't be abused by
suspending OB and DP just for one turn because of the AI's refusal to sign OB and
DP if recently canceled.
DP needed this kind of restriction anyway; too easy to flick DP on and off in BtS.
See also 130t factors attitude and worst enemy into anger about rival DP.
kekm.3 keeps DP intact after a foreign DoW.
550a gives civs that have fallen behind better deals by adjusting trade values. This
adjustment factors half into the trade score relevant for relations.
Tbd. May have to dial this up once there is tech diffusion from OB.
Peace treaties should perhaps also add to the enemy trade penalty. Can currently ask
for a gift or tribute to avoid getting asked to join a war.
If the AI itself cancels OB or DP, then it forgets Doesn't matter who canceled: canceled OB are
the cancellation twice as fast (5 turns on forgotten after 10 turns on average.
average).
Rationale It's frustrating when the AI attitude dips below the OB threshold (which is difficult to
notice in time) and, on top of having to get the attitude back up despite having lost the
OB diplo modifier, the human player has to wait for 10 turns (and often longer than
that). It does make sense that the AI is a little wary about signing the agreement again
– won't be able to cancel it for 10 turns then, and the other side has just proved to be
unreliable (at keeping the AI happy). It also makes sense that the AI is, on top of that,
upset when the other side cancels an agreement, possibly (the AI can't check this …)
at an especially inopportune moment. Important that humans can't just briefly close
their borders when it suits them (e.g. when an AI settler or army wants to move
through); that makes the AI look dumb.
Tbd. 10 turns generally seems pretty long, also between two AI civs: both memory counters
need to reach 0 and one side's contact roll has to succeed before a new deal can be
405
implemented. Reduce to 8 turns on average?
"Our defensive pact proves ..." applies only when Doesn't check if currently in a DP. The relations
currently in a DP. bonus is based on the number of turns spent in a
DP. That number counts backwards when not in
a DP.
Rationale More intuitive this way, and consistent with how the OB relations bonus works.
Reduced impact of OB and resource trades on the enemy trade penalty if the worst enemy has OB
with many civs.
Rationale An AI civ can't afford to be mad at everyone. This is less of a problem for tech trades
because one civ can only do so much tech trading.
Decreased the impact of gifts vs. trades on The AI tracks gifts and traded items separately.
enemy trade memory a little. Gifts are hated three times worse than traded
items.
Rationale I guess the idea is that trades aren't so bad because the worst enemy has to give
something away too. But trading is dominated by tech trades, and giving away tech
doesn't really hurt the worst enemy; it's very much win-win.
Reduced impact on enemy trade if the AI When an AI civ dislikes two civs equally, and one
relations toward the enemy and the enemy's of these enemies trades with the other, the
trade partner are similarly bad. distinction of "worst enemy" can oscillate
between the two.
When the worst enemy of an AI civ changes, that Even if the AI reconciles with its worst enemy, it
civ reduces its enemy trade memory about tradescontinues to be mad at civs that previously
with its (former) worst enemy by one third. traded with its former enemy.
Rationale Both changes are aimed at preventing situations where a civ that trades with the
worst enemy becomes itself the worst enemy. This can seem erratic. (That said, even
when the worst enemy changes, "you've traded with our worst enemies" remains
true.) I've considered halving the memory, but that could drop a -3 penalty to -1 due to
rounding, which seems a bit much.
See also 130f prevents stop-trading demands when relations toward the player are already
almost as bad as toward the worst enemy.
When picking the worst enemy, civs with whom Worst enemy chosen only based on attitude.
the AI is at peace are only considered when the
AI isn't at war with anyone. Exception: Dogpile
wars (e.g. on request of another civ) have no
impact on worst enemy.
Enemy trade memory is increased more when Whether the worst enemy is a war enemy doesn't
the AI is at war with the worst enemy than when affect enemy trade memory.
they're at peace.
Trades with a war enemy increase enemy trade Only trades with the worst enemy count as
memory even if that war enemy is not the worst enemy trade.
enemy, though not as much as trades with the
worst enemy do.
Rationale Trades with a war enemy are more likely to harm the AI than trades with some cold-
war foe.
See also 552 increases the AI trade value of military tech.
148 changes the relations threshold for becoming worst enemies.
130d changes some rules regarding vassal agreements and worst enemies.
406
The Dawn of Civilization mod takes geographical distance into account when
choosing worst enemies. Git commit (not always properly updating cached worst
enemies I think)
Payments in peace deals (between two parties or Peace deals don't count for trade memory.
brokered by a third party) increase enemy trade
memory (but not fair-trade memory). Exception:
Civs don't count enemy trade memory if they like
the civ with whom peace has been made
(Pleased attitude).
Payments in two-party peace deals don't count
fully for enemy trade memory.
Rationale Don't want players to bypass enemy trade penalties by piggybacking regular trades
on (brokered) peace deals. It makes sense to me that a civ gets upset when its worst
enemy is paid for peace.
407
Razing results in 0 memory only if a city has 0 memory for razing cities with 0 culture – no
neither produced any culture nor population. matter the size.
(That means, 0 memory is only possible when
auto-razing – but the converse is not true.)
Rationale A city can develop for quite some time, growing population, constructing a Granary,
without producing any culture, and the AI should not be indifferent about losing such a
city. I still want 0 raze memory for cities that have really just been founded (not much
different from attacking a Settler) or that have been founded in awful terrain (can't
blame the new owner for razing that).
See also Kek-Mod marks cities that will auto-raze on the map (Git commit). While my change
makes it a little bit more important to know whether a city will auto-raze, I still don't
find it important enough.
The AI isn't upset about a nuked friend if the The AI only checks whether it's at least Cautious
owner of the nuke is or used to be a friend that toward the victim.
has itself been nuked at least as badly.
Rationale Don't hate both sides of a nuclear war if it's just tit for tat.
AdvCiv K-Mod
AI doesn't disband nukes when in financial As far as I can tell, nukes are disbanded before
trouble unless no units other than cargo units most other units. BtS tried to save expensive
remain. units, which is fine in the case of nukes, but
K-Mod focuses on XP, which is generally better,
but fails for nukes.
130r All AI diplo memory decays; see the table in the Dynamic Diplomacy chapter.
See also 130y counts less declared-war memory in certain situations.
130o deals with memory about tribute demands.
AdvCiv BtS
The more incidents of a kind the AI remembers, The probability of decreasing the momery count
the faster it tends to forget each of them. For does not depend on the current memory count.
example, a single declaration of war is, in the So three
expected case, completely forgotten 150 turns
after it ends; two declarations after 75+150 turns,
three after 50+75+150 etc.
Tech trade memory (“shared discoveries”, “fear
you're becoming too advanced”) is exempt from
this change.
Rationale At least before the late game, there should generally be a route to reconciliation
(though it doesn't always have to be worth following).
See also 553: Changes to the “shared discoveries” modifier
408
All decay probabilities, contact delays and The various AI memory values are decremented
contact probabilities are moderately adjusted to each turn, each with its own probability from
game speed. For contact probabilities, the Civ4LeaderHeadInfos.xml. The probabilities
adjustment is especially small and doesn't apply are the unaffected by the game speed setting.
at all to peace offers and join-war requests. After contacting a human player, the contact
delay prevents the AI from contacting the same
human player with the same type of request. Not
speed-adjusted.
Rationale Help requests – a pretty common type of AI request – should not really be made more
frequently on slower speed settings; they should match the research speed. Other
requests, e.g. for joining a war or enacting an embargo, should match the pace of
diplomacy, which is not nearly as much affected by game speed. A moderate
adjustment seems like a good compromise. Decreased contact probabilities at slow
game speed settings could make the AI too slow to respond to game state changes
such as someone starting to trade with an enemy, so this adjustment is very slight and
exempts war-related diplomacy.
Decay speed: If the contact frequency is reduced, then individual requests should
arguably be remembered longer so that the typical number of active diplo modifiers is
unaffected by game speed; at least, there shouldn't be fewer active modifiers on
slower game speed. And a granted help request shouldn't be forgotten as fast on
slower game speed settings because the gifted technology took longer to research.
Another (minor?) reason for slowing down the decay rates: Even without any
adjustment to the contact probabilities, I don't think the AI would contact human
players e.g. three times more often on Marathon than on Normal speed. Apart from a
successful dice roll and expired delay, certain other conditions need to be true for
each specific request. For example, an AI civ can only make so many help requests in
a row until it becomes too advanced to receive further help.
On the other hand, an argument against slower decay on slower speed: Some diplo
memory, e.g. “you declared war on us”, isn't affected by contact delays. Still, I think
declarations of war don't happen as often (in terms of game turns) on slower speed as
on Normal speed, so (moderately) slower decay shouldn't lead to problems with
penalties stacking up too much.
Tbd. Not sure about that last paragraph above; maybe the decay of war-related AI memory
shouldn't be speed-adjusted.
Config Added tags “iAI...Percent” to Civ4GameSpeedInfos.xml
(inspired by this Civ 4 Reimagined Git commit)
See also 130k factors game speed into state counter (e.g. “years of peace”) increments.
130p: Remembered trades (“fair and forthright”, enemy trade) don't use the
MemoryDecay system. The remembered trade values match the game speed
because e.g. techs have higher cost and thus higher trade value on slower game
speed settings.
CFC post of mine about game speed adjustment of diplo parameters; and another
post (after the 1st quote box). Discussion specifically about Open Borders contact
delay.
Transformed the independence bonus into a A liberated colony is forever +10 grateful to its old
memory-based bonus to let it decay. It's treated homeland.
as 10 memory decaying at a rate of -1 every 30
turns on average (Normal speed).
Rationale To be consistent with the "everything decays" paradigm.
409
War success decays by 3% each turn; that's a War success doesn't decay; only reset to 0 when
reduction to 75% after 10 turns. It's still set to 0 at a war ends.
the end of a war.
Rationale In long wars, initial successes tend to have too much weight.
Tbd. Initial successes should perhaps be ignored entirely, or decay very quickly because
they're often owed to surprise and thus not a good estimate for the future course of
the war.
Resetting war success at the end of a war isn't smart because war could break out
again just 10 turns later, but 0 war success while at peace might be assumed by some
of the code, so I'm not sure how easy it would be to change this.
See also UWAI remembers the overall outcome of a war before war success is reset.
Reduced the war success value counted for conquered cities from 25 (BBAI) to 22. Was 10 in BtS.
Rationale 25 is more than 6 times the 4 points of war success counted for a successful attack. A
string of successful attacks (failed attacks counting 3 points for the defender) is quite
a feat, can easily be more indicative of how a war is going than the conquest of a city
(any city).
Tbd. Well, it's hard to say, should probably let the DLL adjust war success values based on
the circumstances ...
Config AI_Variables_GlobalDefines.xml
No decay of declared-war memory while the war No decay of either memory type ever.
lasts. Same goes for war-on-friend memory while
at war with a partner.
Rationale Plausible that forgiveness can't happen while the transgression is ongoing. Also, war-
on-us memory was decaying too fast without this restriction.
Recently-canceled memory (about OB, DP and No recently-canceled memory about DP and
VVA) can only decay half (from 2 down to 1) VVA. AI often willing to sign OB right after a war
while at war. ends.
See also 130p introduces recently-canceled memory for DP and 143 for VVA. 130j counts
memory at a finer granularity, which is why canceling a deal sets recently-canceled
memory to 2.
Rationale AI shouldn't generally be willing to sign agreements right after a war ends.
"You stopped trading with us" (MEMORY_STOPPED_ When a team agrees to an embargo, the invisible
TRADING) is remembered for 60 turns on MEMORY_STOPPED_TRADING_RECENT count is
average, same as "You negotiated a trade incremented and lasts for an average 25 turns.
embargo," and neither of these decay while there Additionally, the MEMORY_STOPPED_TRADING
is recent stopped-trading memory count is permanently increased, leading to the
(MEMORY_STOPPED_TRADING_RECENT). relations penalty.
Rationale The relations penalty shouldn't disappear while the embargo is still in effect.
See also 130f makes MEMORY_STOPPED_TRADING_RECENT decay a bit faster than in BtS.
410
When a human player accepts an AI request for The relations effect, including the explanation
war aid, this is remembered as "You agreed to text, is implemented, but disabled in
come to our aid in wartime." for 100 turns on Civ4LeaderHeadInfos.xml. The duration is set
average (on Normal speed). to 150 turns on average.
The bonus is suspended when the human civ
isn't sharing any war with the AI civ and the AI civ
is fighting at least one war.
Rationale The thankless help requests bother some players; military assistance shouldn't be
treated as a matter of course – that's what defensive pacts are for. Perhaps the
original developers felt that the shared-war bonus is enough reward for a declaration
of war, but now that the shared-war bonus is harder to get (change 130m), it should
be OK to reward the granted request directly. 150 turns seems a bit much though.
Config Can be disabled in Civ4LeaderHeadInfos.xml, by setting the
MEMORY_ACCEPTED_JOIN_WAR MemoryAttitudePercent to 0 for the “default” AI leader
(added by change advc.xmldefault).
See also 130m should make the timing of help requests more predictable.
104i (UWAI) makes the target of a joint war refuse to talk as in BtS, thus preventing
the hired civ from making peace immediately.
Accepting a join-war requests from Gandhi No relations penalty for denying a join-war
results in the same relations boost as from the request by Gandhi.
other AI leaders.
Rationale Gandhi's specialty is that he doesn't resent denied requests – which may fit well
enough with his ideas about self-sufficiency. If there were also no consequences for
accepting his requests, then they might as well be disabled. But I see no problem with
him being grateful for help, even military aid.
Tbd. The contact frequency is a different question. Gandhi generally asks for handouts too
often.
130t Diplo penalty for Defensive Pact based on relations toward third party
See also 130p makes the AI refuse a DP if recently canceled, and exempts DP from enemy
trade and fair trade diplo.
AdvCiv BtS
The relations penalty from an AI civ X toward a No penalty if X has a DP with Y; attitude doesn't
civ Y for having a defensive pact with a rival Z of matter.
X is based on the attitude of X toward Z. There is
no penalty if the attitude is one higher than the
DeclareWarThem threshold, or when X also has
a DP with Z, or when X is too weak to attack Z
regardless of the DP.
The DeclareWarThem threshold is at Annoyed for
e.g. Darius, at Cautious for e.g. Hannibal and at
Pleased for e.g. Julius Caesar. (And at Friendly
for Catherine, but this is no different from
Pleased in this case because I'm using the
threshold plus 1, and Friendly is the highest
possible attitude.)
411
Rationale BtS doesn't properly factor DP into enemy trade diplo, and I think it's better to have all
the negative DP diplo in one place anyway. A DP of Y with both X and Z shouldn't
satisfy X and Z unless they like each other. In this constellation, Y threatens war on X
if X should attack Z, which should offend X. Y also promises to protect X; but this is
covered by the DP relations bonus (no change to that).
As for the threshold, I've considered using the DefensivePactRefuse threshold from
Civ4LeaderheadInfos.xml, which is Cautious for some leaders, but a leader that is
quick to sign a DP shouldn't necessarily be forgiving about a rival DP. (The opposite
could be true: these leaders think that DPs are important, and are therefore worried
about rival DPs.)
Warmongers tend to have high DeclareWarThem thresholds (easy to convince to
declare war). These leaders should be bothered most by DPs.
AI refuses to sign a DP without OB: "Surely, you must be joking."
Rationale How are you going to defend us without entering our borders??
AI refuses to sign DP when no rivals remain. Refuses when no other teams remain.
Rationale Probably an oversight; should've been changed when vassal agreements were
introduced in Warlords.
Credits crullerdonut reported the issue in this CFC post.
Anger about rival peace vassals works the same see 130w
way as anger about defensive pacts.
Rationale Voluntary vassal agreements are much like defensive pacts.
See also About capitulated vassals, see 130w.
130v Masters are held responsible for their cap. vassals; cap. vassals as zombies
See also K-Mod disables vassal-master attitude sharing; UWAI disregards capitulated vassals
as war targets; 130d makes capitulated vassals ineligible as worst enemies. 130t
412
bases the "vassals to your empire" penalty on attitude in the case of peace vassals,
and 130w penalizes expansionism through vassals and conquests. 130y and 130h
reduce war-based diplo penalties for vassals, recognizing that vassals don't have a
choice in starting wars. 099c prevents master cities from flipping to a vassal, and 025
reduces the culture spread of capitulated vassals. 143b prevents capitulated vassals
from building nukes. 014 makes capitulated vassals ineligible for team votes, stops
them from pursuing victory and from building great wonders. kekm.25 prevents
capitulated vassals from defying resolutions. 112b changes conditions for capitulation.
130f lets capitulated vassals agree to embargoes for free. 036 (gold available for
trade based on attitude) disregards the attitude of capitulated vassals. 033 stops
capitulated vassals from training Privateers.
CFC discussion about the relationship between capitulated vassals and their masters:
link
Tbd. I'm considering to turn capitulated vassals into voluntary vassals after some time;
perhaps after 30-40 turns. Would only need to implement a popup asking the master
to sign the new agreement or else free the vassal. A capitulated vassal that reaches
the territory and population threshold should then also turn into a voluntary vassal.
Some way for a master to free (itself from) a voluntary vassal would also be nice.
Capitulated vassals should perhaps only be allowed to trade tech with their masters.
Or just prevent them from brokering to other civs. That said, the AI currently keeps its
vassals (capitulated ones too) at arm's length tech-wise; that might have to be
changed if vassals can't trade or broker.
AdvCiv BtS
If a capitulated vassal Actions of a vassal don't reflect on the master,
but civs are generally upset about "rivals" being
• razes a (holy) city;
vassals to the master's "empire", and vassals are
• trades with someone or someone's enemy; possible war targets. Prior to K-Mod, the AI
attitude toward the master was generally lowered
• has OB with someone's enemy; or
based on the attitude toward the vassal.
• nukes someone (but not just someone's friend)
half of the resulting relations modifier is applied
to the vassal, and half to the master.
Relations penalties about shared borders are
also shared between vassal and master.
In team games, the penalties apply to the leader
of the master team.
Rationale My thinking is that there shouldn't be grudges against capitulated vassals because
they're basically dead already. This opens up a loophole: A human master could let
vassals do the dirty work (razing), or use them as buffers against shared-border
anger. BtS attitude averaging would fix this issue, but would also punish the master
for e.g. the vassal's religion and any bad deeds prior to the vassal agreement.
The change about nukes is obsolete because 143b now prevents capitulated vassals
from having nukes.
Vassals are always Friendly toward their master, Voluntary vassals are Friendly toward their
and capitulated vassals share the master's master except when deciding whether to break
attitude toward rivals, but their attitude can be at free. The attitude of and toward capitulated
best Cautious. AI civs project their attitude towardvassals is computed normally but rarely matters.
a civ onto the capitulated vassals of that civ.
Sometimes a (capitulated) vassal has a much
This does not apply when a vassal is deciding
413
whether to break free. more positive attitude toward another civ than its
master, and will trade away technologies that the
Masters are Pleased toward their capitulated
master wouldn't trade.
vassals, and capitulated vassals are Pleased
toward fellow vassals with the same master.
Vassals never grant gifts to rivals and never ask
When a vassal grants a gift to a rival or receives
rivals for gifts. When deciding whether to grant a
one, a peace treaty is signed between the master
gift to its master (no matter if capitulated), the
and the rival. Thus a civ with multiple vassals can
vassal checks its actual attitude (what the
sometimes be kept at peace indefinitely.
attitude would be if it weren't for the vassal
treaty). Capitulated vassals with few cities left tend to
found cities in marginal spots because the
Capitulated vassals are slightly reluctant to found additional expenses (esp. for number of cities
cities, especially on other continents. and civics) are small. The additional maintenance
for the master isn't taken into account.
AI Spies are reluctant to attack a rival's AI doesn't attack it's own vassals (still the case in
capitulated vassals. AdvCiv).
Rationale Given my other changes, the attitude of and toward capitulated vassals really doesn't
matter anymore, and showing them, as is often the case, Annoyed toward their
master is misleading. I'm still showing the actual relations value (e.g. "Friendly (-2)")
and modifiers because they do matter again if a vassal breaks free.
If vassals are supposed to be zombies, they shouldn't be relevant for tech trading, and
they generally shouldn't undermine the master's foreign policy. Until v0.85, I had
capitulated vassals share the master's attitude toward other civs, but this made it too
easy for a human player to dictate civics and siphon gold from vassals with AI
masters; now they're at best Cautious toward rivals.
Civs that can't declare wars can't sign peace Apart from tribute and gift requests, vassals sign
treaties at all. Their wars end without a peace a peace treaty when their master ends a war (I
treaty. This applies to both types of vassals and think). Perhaps also in other situations that I can't
when a game option prevents war. Exception: A think of.
passed force-peace diplo vote will still result in
peace treaties for vassals.
Rationale It's enough for the master to have a peace treaty. If a vassal agreements ends within
10 turns of that – fair enough, the vassal shouldn't be bound by the master's treaties
anymore (this argument doesn't apply to diplo votes). This change also makes sure
that a master can't somehow be forced into a peace treaty via its vassal.
Added a trade denial reason “We don't truly like you that much” for cases in which the true attitude
is decisive for trade denial, doesn't pass the denial threshold whereas the forced attitude would
pass it.
See also Only used for ctr so far; and I'm not sure it'll ever matter there.
Capitulated vassals are not shown on the The Glance tab shows relations between all living
"Glance" tab of the Foreign Advisor. (non-minor) civs.
Rationale The Glance tab gets quite crowded in large games, and capitulated vassals don't
have interesting relations because they follow their masters in matters of diplomacy.
Human espionage weight against vassal set to 0 No automatic changes to human espionage
after accepting capitulation. weights ever.
Rationale Easy to forget, and cases in which a player would want to continue espionage against
his/her capitulated vassal should be extremely rare. I'm not making the same change
for voluntary vassals because these agreements are often fleeting.
414
AdvCiv K-Mod
Capitulated vassals support all resolutions Team members of the Secretary-General (SG)
proposed by their master. support all resolutions. Civs Friendly toward the
SG support some proposals, but not all (non-
proliferation, force-civics).
Rationale Since all votes are cast simultaneously, vassals can't always vote along with their
master – they don't know how the master is going to vote.
See also kekm.25 allows vassals to support the master in repealing resolutions (which requires
them to vote "No" on the master's proposal).
415
Rationale Not fair to give a penalty based on military power only to civs that control a vassal. A
civ that just conquers all cities isn't less threatening. Since I don't want to remove the
vassal penalty, I'm adding a counterpart that penalizes conquered cities. In any case,
penalizing military power isn't good because that hardly affects human civs.
The personality-based term means that e.g. Genghis Khan won't easily get upset
about expansionism, which is consistent with his own behavior and his first-
impressions bonus with other warmongers. Moreover, I don't want all leaders to
increase the penalty synchronously because, then, conquering a single city could
have a big negative impact on relations overall; the personality factor makes sure that
the overall effect changes smoothly.
Power ratio is factored in because it doesn't help if small civs stop trading with the
expansionists – this mostly hurts the small civs.
As razing doesn't remove tile culture, this penalty can't be circumvented by razing
(and razing carries its own diplo penalties too).
I've considered ignoring cities culturally owned by an enemy (war enemy or worst
enemy) of the AI civ that opposes expansionism, but concluded that this shouldn't
make a (big) difference; territorial expansion needs to be opposed even if it has
happened at the expense of an enemy.
See also Without 099 (culture of dead civs stays in the game), this change wouldn't really work
because cities conquered from eliminated civs wouldn't count.
CFC post explaining why I've increased the expansionism penalty (though not its
upper limit) a bit in AdvCiv 1.01.
Tbd. Should perhaps be reduced if the AI civ that opposes expansionism has conquered
much more territory. Can seem a bit hypocritical the way it is now.
130x Ideological relations modifiers (religion, civic) take longer to attain the higher they go
See also 130n dynamically adjusts these modifiers to the popularity of the ideology in question,
and slows down different-religion penalties.
148 lowers the limits for the positive ideological modifiers for many AI leaders.
AdvCiv BtS
The time-based same-religion and favorite-civic They increase by one every 10 turns.
modifiers increase by one after 10 turns, by one
more after 11 turns, then by one more after 12
turns etc.
Rationale Since the modifiers have tighter limits now, I feel that they should also grow a bit more
slowlys, so that they don't become too quick to max out. Making them grow more
slowly initially could frustrate players, so lets try a non-linear progression.
130y Lower diplo penalties for wars involving vassals, DP or seeing little action
AdvCiv BtS
416
When making peace, the declared-war relations The declared-war penalty is solely based on the
penalty is reduced (but not beyond -2) if the other number of declarations of war; only the
side has had very little war success, namely less (unimportant) hidden "this war is going badly"
than 0.3 times the equivalent of capturing a city penalty is based on war success.
times the era number (0 for Ancient; i.e. full
penalty for early attacks on Workers).
The penalty is also reduced if either side is a When declaring war on a master civ, war against
capitulated vassal. And a capitulated vassal the vassal civs is implied, and the aggressor gets
reduces its declared-war penalties when it the full (never decaying) -3 "You declared war on
regains its independence. us" from each vassal, even if the war takes place
entirely in the master's territory, and ends up
If a vassal is freed because its master has
freeing a capitulated vassal. Likewise, when a
capitulated to a third civ, the third civ
master declares war, its vassals suffer a -3
automatically makes peace with the vassal, but
relations penalty.
without signing a peace treaty.
When a civ capitulates, the vassals of that civ are
If the third civ doesn't have much war success
freed. They remain at war with the master of their
against the freed vassal, and the free vassal had
former master, and the former master declares
been a capitulated vassal, the third civs gains +2
war on the former vassal.
"You've granted us independence" from the freed
vassal.
Rationale Shouldn't hold civs fully accountable for declarations of war if these declarations were
enforced by the vassal system, especially not for capitulated vassals. The change
should make it easier to free vassals and have a cooperative relationship with them
henceforth.
I'm factoring in war success because vassals should not be happy about being
liberated when that involves killing most of their units or taking away their cities.
The reduced penalty for non-vassals practically only applies to wars where neither
side sent any units or an invader changed its mind in the face of tough defenses. Not
plausible for such wars to have long running repercussions.
See also 130h disables war-on-friend penalties for attacking master/vassal alliances; sha
reduces "war spoils our relations" penalty if there is little war success.
Tbd. Should perhaps also add "granted us independence" memory when the master is
eliminated.
A DoW caused by honoring a DP leads to only a Full relations penalty (-3).
-2 relations penalty from the civ that triggered the
DP. (No change to "war on friend" penalties.)
Rationale Diplo penalties for fulfilling a DP seem justifiable, or at least not wrong enough to
change radically. I'm just reducing the penalty a bit.
Tbd. Should probably not assign war-on-friend penalties when war is triggered by a
defensive pact, and perhaps not for wars declared by capitulated vassals either.
417
An AI leader may decide to gift a tech to any non- Only human civs can benefit from this. Pleased
vassal civ that has fallen behind and that the AI attitude is required, Friendly and difficulty don't
leader is at least Pleased with. Friendly relations, matter. (Although a low difficulty makes the AI
a low difficulty setting and a high Diplo victory easier to please.)
stage increase the probability of such a gift.
The choice of the tech is biased toward low The tech chosen uniformly at random.
research cost.
(No change to the AI routine for gifting tech to
vassals.)
See also 112 deals with tech gifts between vassal and master. The gifted tech is also chosen
randomly based on cost in that context.
The part that takes into account the difficulty level is based on 250a.
Rationale Especially with SPaH, it's not so unlikely for experienced players to trigger this AI
behavior, and I don't think those players would want the AI to help them compete. So
one could either disable the help routine for medium and high difficulty settings, or
extend it so that AI civs can benefit too. I've done the latter because it can actually
make sense for an AI civ to help a weaker partner; humans do that too sometimes.
Tbd. Should perhaps ask for gold in exchange if the recipient happens to have some.
418
Tbd. Oxford in the capital shouldn't always be the best choice; that needs to be addressed
by a balance change.
National Epic is probably still not given enough priority.
Discourage Moai Statues and Lighthouse in citiesThe AI evaluation only looks at the quality of the
with decent unworked land tiles. (through water tiles.
CvCityAI::AI_buildingSeaYieldChangeWeigh
t)
Rationale The AI was still too quick to construct the Moais in general.
AI tech evaluation: Reduced the value assigned K-Mod: Already reduced; I'm reducing it more.
to units whose resource requirements aren't
met. E.g. to make the AI less inclined to
research Horseback Riding when it doesn't have
a Horse.
AI switches state religion probabilistically based Current state religion is counted as having
on the ratio of the utility of the new religion to the between +33% and +50% utility to create inertia
utility of the current one. Increased attraction to and avoid revolutions. However, once another
AP. religion reaches higher utility despite this bonus,
the AI switches immediately, leading to occasional
back and forth switches as cities are conquered
and lost again.
The algorithm for AI civics changes should now The inertia mechanism has the opposite effect
handle negative utility values correctly. when dealing with negative utility values.
Negative values probably don't occur though (nor
in AdvCiv I think).
Rationale The values of religions can fluctuate when two religions spread in parallel or when city
owners change repeatedly in a war. Probabilistic switching means that the AI tends to
wait for some turns when the one religion isn't far better than the other.
I had implemented the same thing for civics but removed it again; see my post here in
the K-Mod subforum (the "Update" part under No. 1).
Credits The change for negative utility values is inspired by a similar change in "RoM: A New
Dawn" by koshling. SourceForge revision: link
Tbd. Can currently only switch religion every 15 turns unless Spiritual (see calls to
AI_setReligionTimer) and civics every 20 turns. Would be better to lower the per-
turn probability of switching based on the turns elapsed since the latest switch.
See also 001r fixes a bug that had caused the AI to switch civics too readily.
The AI only starts a revolution if it has enough During anarchy, civs have 0 income and
gold in the treasury to prevent the strike counter expenses except that gold deals still need to be
from reaching 2 during anarchy. paid. This means that anarchy leads to a strike
when a civ has no gold in its treasury. If anarchy
lasts only one turn, the strike has no immediate
effect, but multiple turns of anarchy lead to
disbanded units. Moreover, the strike turn
counter is never reset, so once there has been a
strike, even a single turn of anarchy can lead to
disbanding.
419
Rationale I've thought about suspending gold deals during anarchy, but then what about the civ
that is supposed to receive gold? For a human player, it could be confusing if an AI civ
pays no gold during anarchy. If gold is received without having been payed, then this
could exploited in multiplayer (team) games.
Perhaps the strike counter should be reset or counted backwards (probabilistically?)
when there is no strike; but then a single turn of strike now and then would have no
negative consequences at all.
See also 132b: Vassals with a human master reluctant to switch civics.
133: Gold-per-turn deals are canceled when broke
AdvCiv Vanilla Civ 4
Extended the AI evaluation of the Pyramids Just counts a fraction of the AI civics value for
ability. In particular, the current Government civic each unlocked civic. A tiny fraction, considering
is taken into account. that building and civics values aren't on the same
scale.
K-Mod 1.46 note: “compare to current civics!”
Rationale Was greatly underrated and the AI was building the Pyramids very late (late Classical
era usually). Actually had to make the AI underrate the Pyramids again by a factor of
more than two after some tests. In BtS, they're something that human civs without
much land and mediocre terrain can reliably fall back on so long as they have decent
food sources; not good for balance to let the AI build them aggressively.
See also This CFC post noting that good wonders are not being prioritized by the AI might refer
to the Pyramids. I suppose the BtS AI builds them a bit sooner than K-Mod through
non-intelligent factors (flavor, building focus, culture).
Reduced the tech value counted for buildings when an AI civ hasn't founded a second city yet and
the population of the capital hasn't grown beyond size 3.
Don't count tech value for potential domestic trade routes when having only 1 city.
The AI assumes that it is not geographically isolated when more than 25% of its continent remains
unexplored. Consequently, naval exploration is not prioritized in the very early game on account of
being isolated.
So long as the AI isn't sure whether it is isolated (no one met and 30 turns not yet passed), the
values counted for military units are reduced.
Reduced the utility counted for working water when the average city population is small.
Rationale Mostly to prevent the AI from overestimating Fishing and Sailing in the very early
game. Apart from Lighthouse, an early discovery of Sailing can lead the AI to waste
time on a Galley or to construct Moai Statues in the capital.
Swordsman and Legionary have Attack City as For all Swordsman units, the default is Attack,
their default AI type. Non-default AI types are non-default Attack City and Reserve. The earliest
Attack and Reserve. non-siege unit with default AI type Attack City is
Maceman, the next one Grenadier.
The default AI type seems to matter mostly when
the AI evaluates units that it can't train yet. Will
then, for each AI type of the new unit, compare
the new unit with the best current unit that has
the matching default AI type.
Rationale The main advantage of Swordsmen over Axemen and other early units is that
Swordsmen are better at attacking (AI) cities held by Archers.
See also 907a renames Praetorian to Legionary.
420
Battleship has the (non-default) AI type Escort. Destroyer is the only late-game unit with Escort
AI type. I don't think the Escort type is required
for accompanying cargo ships, but if more escort
ships are needed, the AI will only train ships with
the Escort AI type to fill the ranks.
Rationale Battleships don't come much later than Destroyers and aren't that much more
expensive. They can handle enemy Battleships, and a mix of Destroyers and
Battleships can stand up to the endgame ships (Missile Cruiser, Stealth Destroyer)
and air attacks.
See also 905a removes the Escort AI type from Caravel.
Most aspects of the tech utility calculation of an The BtS and K-Mod code, for the most part,
Ai civ that scale with the civ's current number of accounts only for current cities.
cities assume up to one extra city when the civ
has a settler ready or is training one and has a
planned city site.
Rationale No particular reason not to look ahead with tech evaluations. One city is easy to
predict. Should be relevant mainly in the early game.
The evaluation of an extra trade route granted by a technology takes into account all planned city
sites (regardless of whether settlers are coming up).
Rationale The AI is sometimes very slow to discover Currency.
Tbd. Currency still seems to be underrated (and Code of laws overrated).
AI building evaluation takes into account Special commerce modifiers are evaluated by
Bureaucracy when evaluating special commerce taking the modifier times the current base rate of
modifiers. And some value is added to account the respective special commerce type. K-Mod
for future increases of the city's base commerce. increases the result to account for possible future
weight increases (slider position), and accounts
for future growth when evaluating base yield
modifiers – but not for special commerce
modifiers.
Rationale The AI had tended to omit the Education tech entirely.
AdvCiv BtS
Ancient technologies and Horseback Riding have 8, 16, 24, ...
an asset value of 6, Classical techs 12, Medieval
18, Renaissance 24, Industrial 30, Modern and
Future 36.
The Infantry unit has an asset value of 4. 3 for Infantry but e.g. 4 for SAM Infantry.
The total asset value of a civ is computed as 2
per citizen, 1 per land tile, up to 48 per
technology, 1 to 5(?) per non-wonder building,
16(?) per great wonder, 8(?) per national wonder.
For units, the asset value usually corresponds to
the square root of its power, rounded down;
though e.g. not for Infantry.
See also 130p uses asset totals for The total is used only for deciding whether an AI
computing trade-based relations civ asks for a free technology or offers one.
modifiers.
421
Rationale BtS asset values are heavily skewed toward technologies. E.g. early technologies
cost only 60 research and count as 8 assets, whereas 4 population (also worth 8
assets) cost at least 88 food and 8 Archers cost 280 production. This is probably
intentional: when the human player gets ahead technologically, the AI is supposed to
ask for help even if it has more units and citizens. It was just a bit too extreme, at least
for the purposes of 130p.
Horseback Riding being treated as an Ancient tech might be deliberate (*shrug*).
Tbd. The asset values for buildings look crazy; e.g. 1 for Drydock but 2 for Barracks and 3
for Lighthouse. Hard to say how the original developers came up with these.
When evaluating the Great Lighthouse, check BtS only considers the currently owned coastal
planned city sites to estimate how many coastal cities, K-Mod adds a projection based only on the
cities there might be in the medium term. map size.
Rationale Just a little tweak.
131b AI weights in Civ4TechInfos.xml, Civ4CivicInfos.xml
AdvCiv BtS
Negative AI weight for Feudalism, Sailing. And All weights are 0 in BtS and K-Mod. AI weights
slightly increased the cost of Iron Working. are added to the utility values computed in AI
tech evaluation. The intention was probably to
give non-DLL modders a way to bring the AI to
research techs with novel abilities.
Rationale In test games before releasing v0.93, half of the AI civs were researching Iron
Working right after Bronze Working, and Feudalism was practically always researched
before Machinery. This is out of step with the historical development and, more
importantly, makes these techs unattractive to research for human players as they're
easy to get in trade.
In testing with v1.0, Iron Working isn't as popular anymore; not sure why. So I've set
the AI weight for Iron Working back to 0. Usually some civs go for Iron Working very
early – I suppose civs that lack both Copper and Horse –, while others delay it until
the late Classical era (if they can't trade for it). I guess that's OK.
I've already done some work on Sailing (see 131 above), but the AI is still to fond of it.
Tbd. This is a temporary measure. Not sure how to fix this more permanently though.
Longbowman and Serfdom really are very useful for the AI.
The AI weight should arguably be multiplied by the number of cities in the DLL in order
to match the scale of the tech utility values. Currently, a non-zero AI weight for a late
tech would have less impact on a map that gives civs a lot of room to expand.
Shouldn't be much of a problem for early/ midgame techs because civs can't expand
that quickly.
See also 174: Misc. tech cost changes
Slight negative weight for Bureaucracy
Rationale The AI evaluation is pretty precise, the civic is just too powerful. Don't want every AI
civ in Bureaucracy almost all the time.
422
AdvCiv BtS
Only buildings with defense, XP and war Some buildings with production abilities also
weariness abilities contribute (a little) to the have power values, e.g. Forge.
military power value (power graph) of a civ.
Rationale Counting some military power for buildings seems fair enough in general, may help a
little to deter the AI (and humans) from attacking difficult targets. Production abilities
are reflected by the production curve though and both UWAI and K-Mod's
AI_startWarVal function take the production curve into account. (Arguably, they should
also take into account XP abilities, but, so far, they don't.)
Config iPower tag in Civ4UnitInfos.xml. Note that the DLL does not scale those values
according to the game progress; therefore, a late-game building like the Pentagon,
contemporary with e.g. power-22 Infantry units, needs to have a high power value to
have any noticeable impact. It would be better to let the DLL compute a power value
from the various militarily relevant building abilities and adjust that value to the game
progress, but this isn't worth the implementation effort (in particular, updating the
caches at CvPlayer and CvArea would take some effort).
See also This CFC post by made me aware that the Great Wall's power value is too high –
especially since 310 usually disables the Great General ability.
423
other side will suspect bad intentions, and (somewhat) in case (b) because the Spy
owner lacks familiarity with the target civic/ religion.
Why not allow all civics? Don't want that many options on the diplo screen. Also
seems far-fetched to switch someone to, say, Vassalage in the Modern era, when no
civ in the game has been in Vassalage for 500 years. Assume civs to be somewhat
flexible in their religion civics and economics. These are also the columns with the
isolationist civics Mercantilism, State Property and Theocracy.
Config New tag bCanAlwaysForce in Civ4CivicInfos.xml.
The force-religion espionage mission requires theThe target religion has to be present in any one
target religion to be present in the city where the city.
mission is executed.
Rationale More plausible this way; don't think it matters much for game balance or AI behavior.
Increased the impact of the number of cities with K-Mod already adjusts the mission cost but rarely
the target religion on the mission cost. increases it by more than 100%.
Increased the base cost of force-religion and
force-civic by 25%.
The AI doesn't use the force-religion mission if The AI uses the mission even if just 1 city has the
the target religion has few adherents (same target religion. The affected civ usually switches
threshold as the "too few of our people follow that back to its former religion after 5 turns.
faith" response).
Rationale Being forced to convert from a widespread religion into one with just a single city can
be very painful. I've considered allowing only major religions as the target religion, but
a cost increase and a change to AI behavior should suffice.
Config Partly in Civ4EspionageMissionInfos.xml
Tbd. The number of religious cities should be factored into the mission cost modifier, not
the base cost, because the UI shows a breakdown of the modifier, i.e. the impact of
the city count could then be displayed by CvGameTextMgr::setEspionageCostHelp.
Same for the cost increase when the Spy owner doesn't run the target civic or religion.
When asked to change civics or religion, the AI Based only on city counts, both of the AI civ and
predicts the losses from anarchy based on the the human who's asking for the change. Can
goods-produced (production) and GNP (gold + underestimate the cost by a factor of 10 in the
research; 004s) curves. late game.
Increase the multiplier for the difference between The cost of running a bad civic is also
the current and the new AI civic value. underestimated by a factor of 10.
Rationale The human cities shouldn't play a role, and the AI city count could well stay the same
during the second half of the game, but the cost of anarchy doesn't.
Tbd. The AI should charge extra or refuse when asked to switch out of a hurry-production
civic by a player who may well be about to declare war. Or perhaps the change-civics
attitude threshold already covers that wariness …
Different tack: Tack a peace treaty onto change-civics and change-religion trades.
132b
AI vassals are reluctant to switch civics if their Vassal/master status doesn't affect civic choices.
master is human.
The diplo bonus from sharing a religion with the
master factors into the religion choice of the
vassal.
Rationale Humans tend to ask vassals to adopt certain civics; switching back and forth doesn't
424
help either side.
132c Switching to a state religion requires at least one city with that religion; doesn't suffice
if another team member has a city.
Rationale No special need for team members to align their state religions. Major religions are
also determined based on per-civ city counts, and not per-team.
Rationale The problem of lingering tribute may have been introduced by BBAI, which replaced
BtS/Warlords custom code for deal cancelation with calls to AI_considerOffer.
K-Mod has mostly repaired this (deals from non-vassal tribute demands and gifts do
get canceled), but missed a spot.
When deciding whether to cancel a resource Trade value is checked every turn, but not denial
trade, all trade-denial conditions are checked. conditions like those based on attitude. There's a
special clause that cancels deals with the worst
enemy of an AI civ.
Rationale I think this was the intended behavior from the beginning, but a bit awkward to
implement. (Comment by karadoc in CvPlayerAI.cpp: "getTradeDenial is not
equipped to consider deal cancelation properly.")
The denial check also cancels deals that no longer make sense for the other side, e.g.
when a player imports Rice and later settles on a Rice resource.
AdvCiv K-Mod
The tolerance for continuing resource deals when10% in BtS, 25% in K-Mod; doesn't change over
the trade values have become uneven starts at time.
50% and decreases to 20% over time.
Even if the tolerance is exceeded, deals with
human players aren't necessarily canceled. A
cancellation probability is computed based on the
ratio of the trade values, the absolute difference
of the trade values in relation to the AI civ's total
per-turn commerce, the game speed setting and
the number of civs that the human player is in
contact with.
Rationale The changes to AI resource evaluation (change 036) lead to more fluctuation in trade
values; hence the increased tolerance and randomness
Credits xyx and Bestban made me aware of problems with the formulas I had used in AdvCiv
0.96e and earlier. CFC link
See also Relies on code written for 036.
155 allows the AI to cancel deals with members of its own team.
AdvCiv BtS
425
When an AI civ cancels several resource deals A separate popup for each canceled deal.
with a human civ at once, only one renegotiation
popup is shown. That popup lists the trade items
of all canceled deals.
Rationale Mainly to make sure that the human player is aware of all canceled deals when
renegotiating.
See also Of some importance for 074 (show must-be-joking resources on the trade table if
they've just been canceled).
If an AI-AI resource deal is canceled, the AI Depending on the AI personalities, regardless of
immediately tries to make a new deal. cancelation, a resource deal between two AI civs
is considered every 1-5 turns on average.
Rationale Interrupted resource deals can lead to some back and forth in the city management of
the AI. Not sure how harmful that is, but better to avoid it. Should also lead to more
stable trade relations that are easier to keep track of for human players.
When a vassal agreement ends, all remaining Deals with a minimum duration can't be canceled
deals between vassal and master can be until the 10 turns are over, regardless of the
canceled by either side (turns-to-cancel set to 0). vassal agreement. This includes resource gifts to
the vassal.
Rationale A minor issue. They shouldn't be forced to continue free resource deliveries. For
players, it can be confusing to see free resource trades continue between two AI civs
that no longer have a vassal agreement.
AI cancels Open Borders, Defensive Pact and AI cancels these agreements immediately when
Permanent Alliance when AI attitude drops below the other side becomes its worst enemy.
the thresholds for signing the respective Otherwise, AI attitude doesn't lead to cancelation
agreements. Cancellation is delayed with a per- (though other considerations may). Borders can
turn probability except when the other side has remain open indefinitely despite Annoyed
become the AI civ's worst enemy. attitude.
Rationale I think the original idea was that deals get canceled when their attitude threshold isn't
met anymore; they just didn't get the implementation right.
The delay is supposed to give the other side time to amend relations before canceling
OB. (Once OB are canceled, it's difficult to get them back because the "brought us
together" diplo bonus is lost.)
The AI cancels gold-per-turn (GPT) deals when The per-player GPT limits apply only when
its total payments to a player exceed the limits negotiating deals, i.e. the AI will never cancel a
that apply during deal negotiation. deal on this account.
See also CFC post describing how the AI GPT limits can be circumvented by “subsidizing” an
AI civ with a GPT gift for 10 turns. Note that the same trick isn't applicable for gold
paid as a lump sum – because the AI doesn't subtract cash received from cash paid
(whereas the AI does consider the balance of mutual GPT payments).
036 lets the AI evaluate the usefulness of resources – arguably making the GPT limits
dispensable –, and relaxes the GPT limits. Still: I don't want the relaxed limits to be
circumvented.
(Not an AI change:) When a civ doesn't have A civ that can no longer pay for gold-per-turn
enough gold to pay for an active gold-per-turn deals (typically after losing cities at war) will go
deal, not even after (force-)increasing the gold into strike. The recipient keeps receiving the gold
slider to 100%, the gold-per-turn deal gets even if it isn't paid. The AI will cancel gold-per-
canceled by the game rules. turn deals, but only once they're no longer too
recent to cancel.
426
Rationale It's not uncommon for small civs in the late game to pay a large portion of their budget
for imported resources. When a big (human) civ quickly takes cities from such a small
civ, the effect of the subsequent strike can be noticeable and confusing. It's also
illogical that the gold keeps getting received without getting paid. I don't see a credible
way how this new rule could be abused (i.e. to cancel war reparations).
See also This situation might be exceedingly rare if it weren't for the changes to AI resource
trades (036).
427
As for AI personalities, I'm setting lower Rand values for leaders whose historical
counterparts have actually sued or peace. Higher Rand values for especially dogged
personalities. Higher Delay for some leaders to ensure that they don't appear to be
groveling by asking for peace repeatedly.
See also K-Mod has introduced a similar discount for other AI offers. A good idea; without such
an incentive, the AI might as well not contact human civs at all. See the 2nd page of
the K-Mod chapter.
CFC thread about the lack of AI peace offers in BtS. And another.
Humans can't currently receive multiple peace offers in one turn. Moving AI diplomacy
to the start of the human turns (see Tbd. under 001e) would fix this.
Tbd. In networked multiplayer, the peace offer sometimes seems to get through without
checking at-war status. I haven't seen this lead to any problem, but I'm not sure what's
going on there.
UWAI sends a capitulation offer as soon as the AI becomes willing to capitulate. I
don't think this totally obsoletes the capitulation Civ4lert, but it would be nice if the
alert could be suppressed when a capitulation popup has just been shown.
AI peace offers can come with a discount. No discount, no adverse consequences for
However, if a peace offer is rejected, AI war utility rejection.
is slightly increased (by up to 4 depending on the
AI leader's contact delay value) until the contact
timer is back at 0, i.e. for 8 to 20 turns.
The AI adds to capitulation offers whatever trade When offering capitulation, no reparations are
items it is willing to give based on war utility. offered.
See also K-Mod has introduced a similar discount for other AI offers. A good idea; without such
an incentive, the AI might as well not contact human civs at all. See the 2nd page of
the K-Mod chapter.
Tbd. Could add an AI memory type with a -1 relations modifier to communicate the effect of
a rejected peace offer more clearly. But I can't come up with a snappy phrase for the
explanation text; “You rejected our peace offer.” is too lame.
134b (Disabled) No discount if recently begged
AdvCiv K-Mod
The AI offers no discounts to civs that have recently asked The AI doesn't grant gift requests by civs that have recently
for a gift. asked for a gift, but discounts aren't affected by gift requests.
I'm afraid it's usually more profitable to ask for gifts all the
time than to wait for discounts. If so, this change would
mostly disable discounts, which isn't what I want. (I want to
disincentivize periodic gift requests.)
Rationale An attempt to disincentivize gift requests by the clock. Some players set alerts for this every 25 turns; see
e.g. this CFC thread.
428
AdvCiv BtS
135a Resource bubbles
If a player activates resource bubbles in Hotseat,Resource bubbles are deactivated at the end of
they remain active until a player deactivates each human turn. Other map layers (e.g. yield
them. display) are not reset.
Rationale The BtS behavior is annoying if all players want to play with resource bubbles.
Otherwise, the players could still agree not to activate them, or one player flicks them
on and the next one flicks them off.
Tbd. The proper solution might be to remember each player's active layers at end of turn,
and restore them at the beginning of the next turn of that player. Same for player
options and BUG options, which are currently shared by all players. Could store layers
and options in savegames, but storing them in non-serialized data members of
CvPlayer would already be an improvement.
See also 004m increases the default zoom distance (also reset each turn in Hotseat).
135b MoreCiv4lerts in Hotseat
AdvCiv BUG
Added per-player memory to the BUG alerts in MoreCiv4lerts fire every turn in Hotseat;
the MoreCiv4lerts package. (The most useful unusable.
ones, like tech trades, are in that package.)
Rationale The first package of alerts seems to have been implemented with multiplayer in mind
but not the "More" ones.
This might also be fixed in the BUG main branch (see this commit).
Tbd. Don't know if the alerts also work for networked multiplayer.
See also 106c also fixes issues with Civ4lerts.
106b always opens the Event Log when there is a new message in Hotseat.
135c Debug tools in multiplayer
AdvCiv BtS
429
Can use WorldBuilder (WB) and Debug mode in WB is always available in singleplayer; Debug
multiplayer if ENABLE_DEBUG_TOOLS_MULTIPLAYER is mode (Ctrl+Z) requires cheats to be enabled
set in GlobalDefines_devel.xml. (I guess all through CivilizationIV.ini (code "chipotle"). In
players should set it if multiple PCs are involved.) multiplayer, both WB and Debug mode are
In networked multiplayer (i.e. anything except blocked through a cheats-enabled check outside
Hotseat), "chipotle" needs to be set as the game the SDK and several checks inside the SDK,
name under "Host Game" in addition to the XML presumably to make certain that cheating is
switch. The text on the large flag button will then impossible.
say "cheats enabled" in order to make sure that
no player can secretly cheat. The cheat code in
CivilizationIV.ini doesn't affect multiplayer.
Entering the WB makes network games go out of
sync (OOS) immediately; will have to save and
reload afterwards.
If the game name is “chipotle”, only players with When testing multiplayer on a single machine,
even slot id numbers create autosaves. both players try to write to the same autosave
file, leading to annoying error popups.
If a player changes the game name to “chipotle”
through the in-game menu (“Game Details”), an
announcement informs all players that debug
tools have been enabled.
Rationale Debug tools are indispensable for multiplayer testing. Not sure if the OOS issue with
the WB can be fixed; could just be a side-effect of my hack to make the WB
accessible.
Still missing: Python console (impossible?)
Autosaves: Don't know how to check if both instances run on the same machine, so
I'm assuming that the game name “chipotle” is only used for such test games.
See also 127 allows enabling AI Auto Play in multiplayer.
001n fixes OOS errors.
007 describes how OOS errors can be debugged on a single PC; and there's a short
guide about the various log files.
To get rid of the cheat level checks in the CvGameTextMgr class more easily, I've split the
setPlotHelp member function into several subroutines and made some changes to const
qualifiers. That could make it a bit difficult to merge this change into another mod.
135d In multiplayer games, the Settings tab (Victory screen) shows the game end turn only
if it's different from the default (500 on Normal speed).
Rationale Tidiness.
430
The game checks at the end of each (human or Circumnavigation is checked during each team's
AI) player's turn if that player has circum- turn, not during the player turns. In BtS, the team
navigated the globe. Thus, if, through a map turns happened all in a row, i.e. without
trade, two players meet the circumnavigation intervening player turns, at the start of a game
conditions on the same turn, only that player is turn. In K-Mod, team turns and player turns are
rewarded on whose turn the map trade is interleaved, i.e. circumnavigation gets checked for
completed. In a human-AI map trade, the human team X right before the players on team X take
always wins because trades involving humans their turns. That means, when two players satisfy
are always completed on a human turn. This the circumnavigation condition through a map
was also the case in BtS (but not in K-Mod). The trade, the player on whose turn the trade is
extra movement still applies to to a whole team. completed misses out (always the human when
it's a human-AI trade). That player even misses
out if it has completed circumnavigation through
So long as no one has achieved
unit movement earlier on the same turn (before
circumnavigation, the AI refuses to trade its map
making the map trade).
if it can train Caravels. ("We have our reasons.")
If it can't train Caravels but the other side can, Whether an AI is willing to trade it's map depends
the AI charges twice as much for its map. entirely on the leader's attitude threshold.
Rationale The K-Mod timing leads to the trap sketched on the upper right. Checking at end of
turn instead puts the AI at a bit of a disadvantage because human-AI trades can't be
completed on an AI turn. That said, the AI suggests map trades to human civs
relatively rarely, and never with an intention of completing circumnavigation, so the
change doesn't really hurt the AI.
The trade refusal should make it harder for a human to steal circumnavigation from an
AI that is already close.
136b AI doesn't pester human with unattractive map trades
AdvCiv BtS
The AI proposes no trades to a human civ where The AI occasionally asks human civs to
the human side receives only the AI map when exchange maps even if the AI map has no value
the human value of that map is 5 gold or less. to the human.
Changed the rounding of AI trade values to Trade values are rounded to a multiple of 10.
multiples of 5. Makes the implementation of the
above change a bit easier.
The AI refuses to accept trades with a value of
less than 10 (the equivalent of 5 gold).
Rationale These map trades are pointless distractions.
Config The rounding change is implemented in GlobalDefines_advc.xml.
AdvCiv K-Mod
No low-value map trades between AI civs either. I think K-Mod added calls to AI_counterPropose
to AI deal negotiation. That function will usually
insert the map of one side into the deal.
Rationale Going through all tiles on the map is slightly costly (though not nearly as costly as
CvPlot::updateRouteSymbol for a human player's map).
137 Default/ recommended player counts; map dimensions; help text for difficulty levels
AdvCiv BtS
431
On the Custom Game screen, the dropdown When the world size is changed, some player
menu for the sea level includes recommended slots are automatically opened or closed in order
changes to the number of players. ("+x% players to match the recommended number of players.
recommended") No such thing happens when the sea level is
changed.
Rationale Having the proper number of civs is imo pretty important, and sea level has a big
impact on this. The recommendations, if followed, should lead to about the same
number of cities per civ as with Normal sea level.
Recommendations weren't my first choice; I had wanted slots to be opened and closed automatically
when the sea level changes. This can't be done because the Custom Screen isn't part of the SDK. When
slots are opened/closed in response to a world size change, it's possible (through a hack) to also factor in
sea level, but then the sea level needs to be configured before the world size, which isn't what players
normally do.
Changed the default player number for Default player counts are Normal - 7, Large - 9
Standard-size maps to 8 (+1), Large maps to 11 and Huge - 11.
(+2) and for Huge maps to 16 (+5).
Config Civ4WorldInfos.xml
Also reduced the STARTING_DISTANCE_PERCENT parameter through
GlobalDefines_advc.xml to match the increased player density. Can't expect
starting sites to be as far apart anymore.
See also The number of resources per player increases more slowly with the default player
count than the number of tiles. This is because 129 places fewer resources per tile
when there are many eligible tiles.
140 adjusts various map size modifiers to match the new player count
recommendations.
031 fixes an issue in the formula for the target distance between starting sites.
Increased the normal land area (Normal sea The normal land area is 22%, the aspect ratio
level) by 1 percentage point, decreased map seems to be aimed at 8:5. (It varies quite a bit
dimensions, aiming at an aspect ratio of ca. 7:5 between world sizes because the width and
(slightly higher on larger map sizes, slightly lower height need to be multiples of 4.) The numbers of
on smaller map sizes) and at a number of map tiles per civ on (maps that don't override
tiles per civ (assuming the AdvCiv default civ getGridSize) are:
counts, see above) that increases slightly with Duel: 480
each world size. Tiny: 555
These changes don't affect all map scripts Small: 512
equally. Pangaea, (Custom) Continents, Inland Standard: 624
Sea, Ice Age and (sometimes) Shuffle set their Large: 740
own land-sea ratio. The changes to grid Huge: 931
dimensions don't affect scripts that override the
getGridSize function.
See also This change has become tightly coupled with 165 , which tweaks the dimensions of
some individual map scripts.
129 makes some tweaks to the calculation of per-tile latitude values. That subject is
related to map aspect ratios. Change 129 also slightly decreases the density of
resources on larger maps.
432
Rationale It's strange that Firaxis used a land-sea ratio of only 22%, much smaller than the 28 to
29% on Earth. My best bet is that this low ratio worked better with the Fractal
algorithm, which was, apparently, ported from Civ 3. Perhaps they also were more
willing to adjust the land-sea ratio than the map dimensions or the default player count
when aiming at the proper amount of land per player. Anyway, those are my reasons
for not increasing the land-sea ratio further. Smaller maps would move the tropics and
polar circles too close together. That's also why I use slightly smaller aspect ratios for
the smaller map sizes.
I don't think there's a compelling reason for the ca. 8:5 (golden) aspect ratio.
Considering that latitude values are computed linearly, i.e. without the increasing
north-south stretching that most modern map projections apply, a 1:1 aspect ratio (like
the Mercator projection) would make the most sense to me, combined with the bias
against placing land near the poles that most map scripts exhibit. The only reason for
using a higher aspect ratio, to me, is that people are used to world maps being oblong
– and that the space reserved for the minimap on the HUD is closer to 2:1 than to 1:1.
As for the default player counts, BtS gives each player far more space on the larger
maps than on the smaller maps. That should not be the default because it leads to
very different – in my opinion boring – gameplay on large maps. There should be a bit
more land per player as the map size increases because resources are placed less
densely on larger maps, i.e. cities tend to be farther apart. I'd also like there to be a
(very) slightly higher number of cities per player on larger maps – because I think that
corresponds better to player expectations, and because larger maps tend to have
bulkier continents and thus more potential for conflict; not necessary to put the civs all
that close together to get some early-game AI warfare.
With the 8 players on the Standard size, as a baseline, should usually lead to an AI-
initiated war before 1 AD. It's important that the default settings lead to some military
action because AI war planning is the biggest single contribution of AdvCiv. Since
UWAI decides mostly rationally whether to start war preparations, the space for
peaceful expansion is a big factor in the timing of warfare.
The choice for a low player count on Huge maps may have been made for
performance reasons; much less of a problem with current hardware and the more
optimized code.
Some tweaks to improve support for aspect ratios less than 1.5: ...
The minimap doesn't show black bars to the sides; instead, the whole panel gets adjusted to the
map's aspect ratio.
See also 092 enlarges the minimap panel, especially its height.
When zooming out all the way in Globe view, the Earth no longer morphs as much into a spherical
form.
Config XML\Misc\CIV4DetailManager.xml
Rationale At low aspect ratio, the final stage of morphing abruptly compresses the map
vertically. That looks a bit awkward.
The Fractal agorithm uses internal dimensions that approximate the map's dimensions more
closely. (The internal dimensions have to be powers of 2; so the internal aspect ratio is going to be
either 2:1 or 1:1.)
Rationale Should lead to fewer rounding errors. Not sure if the internal dimensions are relevant
for anything else.
433
Map width and height are multiples of 2. This Multiples of 4, which corresponds to a “cell” size
does not seem to result in any graphical artifacts. of 4x4 tiles per cell. I think those cells are
relevant for the graphics engine.
Config The cell size is still set in Civ4TerrainSettings.xml, but the map sizes set in
Civ4WorldInfos.xml no longer (fully) conform to it, and the DLL ignores the cell size
and instead simply multiplies the dimensions loaded from Civ4WorldInfos by 2 – or by
4 when a map script defines its own dimensions (for compatibility with map scripts not
included in AdvCiv).
Rationale It's important to get the map size right, so that, with the default player count, at least
for the most frequently used map scripts, incentives for warfare between civs arise at
just the right time, namely, when the Barbarian threat tends to subside and still clearly
before the Medieval era – the game mustn't just skip over (classically) ancient
warfare. On the other hand, players mustn't get boxed in too frequently. Especially for
human players, early war should normally be an option, not an imperative. Ideally, I'd
like each civ to be able to found 5-point-something cities near its starting site; enough
to stay competitive into the midgame but not the endgame.
The multiples-of-4 restriction really it made more difficult to get this right.
See also 910 changes the years-per-turn formula – in order to align tech progress better with
the real time line.
Tbd. Should perhaps decrease the years per turn in the early game a bit (and increase
tech costs accordingly) to make pre-Medieval warfare a less delicate goal to achieve.
AdvCiv K-Mod
Rewrote the English and German help text for The help text for the sea level and map size
each difficulty and speed setting and [unused] for settings doesn't seem to be shown anywhere.
each map size and sea level setting. Help text for difficulty and game speed settings is
shown on the final screen ("Snapshot") of the
"Play Now" dialog chain.
Some of the info is misleading, e.g. it says that
Monarch difficulty makes the AI "much smarter"
or that Marathon has an entire game's worth of
turns in every era.
Rationale I imagine that most players of this mod (wisely) never use "Play Now", but players that
do use it might actually believe the info provided in the help text.
My texts about the difficulty settings are a bit clunky but at least somewhat informative
and not highly misleading (I hope).
Quests with requirements that scale with the map Quest requirements scale based on the default
size (i.e. pretty much all quests?) are based on player count; 2 (Duel) to 11 (Huge) in BtS.
the map size's building class prereq. modifier. The building class prereq. modifier is used e.g.
for the Library requirement of Oxford University.
Except for the Blessed Sea quest, which is based
It's between +0% (Duel) and +75% (Huge).
on iTargetNumCities as in K-Mod.
See also 154 rounds to the nearest integer when applying the building class prereq. modifier;
this is also done for quest requirements.
CFC post (last quote box)
434
Rationale Now that the default player counts are increased (by a lot on Huge maps), the BtS
scaling gets totally out of whack. It was already too sensitive to map size in BtS, and
it's a bad idea in general because putting more players on a map gives each player
fewer cities and thus makes it harder to fulfill quest requirements.
The building class prereq. modifier seems like a natural fit for this purpose.
Config All quests with a map-size adjustment (except Blessed Sea) now call a function
worldSizeTarget in CvRandomEventInterface.py. The formula can be adjusted
there.
435
Rationale Evacuating units without defensive bonuses and badly injured units seems like a clear
improvement. Units with high defensive bonuses can be expected to cause losses to
the attacker even when badly outnumbered; might, in particular, draw out the
attacker's siege units.
It's important that a Stack of Doom can't scare away all defenders from several cities,
and settle for peace when the evacuated defenders gather for a last stand. Sounds
fairly realistic, but, given the other dynamics of the game, would make conquests too
cheap.
Fixes the "meatgrinder" loophole, which was still on the BBAI to-do list when the mod
was discontinued.
Config AI_EVACUATION_THRESH in GlobalDefines_advc.xml
See also 107 (more offensive Area AI) could help reclaim evacuated cities.
159 tweaks the AI stack strength evaluation, which is the basis for evacuation
decisions.
The AI tries not to leave behind more than 4 units (but there is no hard limit).
Rationale A small group of well-fortified defenders should be enough to force the attacker to use
siege units; larger groups aren't worth sacrificing.
Credits Reported about the AI sometimes leaving sizable stacks of defenders behind; e.g. by
Cruiser76: CFC post
The safety check at the start of the AI turn
sequence anticipates promotions and units in
production that will appear at the end of the turn.
When deciding whether to let a Great Person join There is some code presumably with the same
a city or construct/ hurry a building there, the AI intention, but it only checks for hostile units inside
skips all cities that are seriously threatened by the potential target city – where none can exist.
hostile units.
Credits Prompted by this CFC post by Elkad.
After each attack by an AI unit, the unit owner checks if the attack has provided relief to any nearby
threatened city – by repeating the safety check for that city. (This will matter very rarely.)
Reduced AI trade value for evacuating cities. The tactical situation does not factor into the AI
trade value of a city.
Rationale The AI should be more willing to give a city away when it thinks that it can't hold onto
it, and the recipient (which may or may not be the civ about to conquer the city)
should be less willing to pay for such a city.
See also ctr deals with other changes to city trade value.
The AI stations ships only in cities that, for the BtS stations ships in cities that are either
moment, appear safe from conquest. Also prefersthreatened by no hostile units at all or by fewer
to use such safe cities for upgrading ships. units than the ship's current tile. Some idle ships
are used for guarding resources and patrol, but
If no city looks safe, idle ships are kept at sea.
the rest is moved into some city even if none are
safe.
Upgrade cities are chosen only based on
proximity, safety doesn't matter.
See also In K-Mod, an interaction between a K-Mod and a BBAI change causes idle ships to be
stationed in the nearest city regardless of danger. 001s deals with that issue and
similar ones.
436
Rationale The careless positioning of ships can hurt the AI greatly against savvy players.
Tbd. Should perhaps use a greater maximal range when checking for potential attackers, is
currently 3 tiles. Embarked attackers are counted but could be outside this range (still.
able to reach the city).
Rather than just flagging cities as safe or evacuating at the start of a turn, a scalar
safety rating should be (pre-)computed.
While gathering forces for a naval landing, the AI currently loads units into cargo as
soon as they reach a tile with a ship; then the units stay in cargo for several turns.
This is a needless risk.
See also This change doesn't cover threats from civs that the AI isn't at war with, i.e. surprise
attacks on the AI navy on the same turn that war is declared. 162 addresses these.
advc.ctr reduces the trade value of cities based on their safety/ evacuating status.
The AI only spends Great People (super No such safety checks, neither in the BtS code
specialist, special building, hurry production, for Great generals nor in the K-Mod code for the
Great Artwork) on cities that, at the moment, other Great Person types.
appear safe.
Credits Elkad made me aware of the problem in this CFC post.
437
maps or maps without world-wrap. What leads to high distance maintenance is mostly
a high number of cities, and if a map has lots of space for each civ, civs shouldn't be
punished for filling that space.
Flat maps are known as a trick for reducing distance maintenance; on high difficulty
settings, AI civs pay much less for city maintenance than human civs, and thus the AI
civs benefit less from additional maintenance reduction.
I'm not sure how to set the distance maintenance multiplier in XML; that multiplier and
the one based on map diameter cancel each other out to an extent. Usually, BtS
adjusts too strongly to map size, so I've reduced the step from one map size to the
next a bit.
Tbd. Not sure if DistanceMaintenancePercent in Civ4WorldInfo.xml should be
changed as well. Currently 50% for Duel and increases in steps of 5 to 100% for
Huge. This is countered by the maxPlotDistance formula, but only partly I think.
See also The Tides of War mod also changes the maxPlotDistance formula; this Kek-Mod Git
commit merges that formula into K-Mod. I haven't looked at it in detail, but I think I'm
good with my own formula.
The maintenance distance (from nearest There is an XML parameter
government center) is now capped at around 25 MAX_DISTANCE_CITY_MAINTENANCE, but this only
on Normal settings; lower cap on smaller maps serves as a weight on maintenance costs; there
(lower maxPlotDistance), higher cap on larger is no actual limit on the distance or the cost.
maps (higher maxPlotDistance).
Rationale If a city is very far away from a government center, it shouldn't matter how far away
exactly. The BtS cost punishes (very) remote colonies too much.
Config The distance cap is tied to MAX_DISTANCE_CITY_MAINTENANCE (in
GlobalDefines.xml); changing that value will also change the cap.
The map-size multiplier for number-of-cities 45% on Duel, 20% on Huge, steps of 5.
maintenance is 42% on Duel and decreases in
steps of 4 to 22% on Huge. It gets multiplied by a
Sea level and initial player count don't matter,
(hardcoded) factor that slightly increases
maintenance on crowded maps (more players
initially than the Custom Game screen
recommends based on map size and sea level)
and slightly decreases maintenance on sparse
maps.
See also Prior to AdvCiv 0.97, I had decreased the modifier in steps of 3. CFC discussion about
that. Also addresses the crowdedness factor.
advc.exp.1 deals with number-of-cities maintenance for very large empires.
Rationale Steps of 5 percentage points would be OK if Duel was at 100%; as it is, the ratio e.g.
between Small (35%) and Large (25%) is too large. Or perhaps it would also work if
only 9 civs were placed on a Large map, however:
See also 137 changes the default number of civs per map size.
Can draft 2 units per turn on Duel-size and Tiny 1 on Duel, 2 on Tiny, 3 on Small and Standard, 4
maps, 3 on Small, Standard and Large, and 4 on on Large, 5 on Huge.
Huge.
Reduced the number of free bonuses from 5 on Standard, 6 on Large, 7 on Huge.
national wonders (Broadway, Rock'n'Roll,
Hollywood) by 1 on Standard, Large and Huge
maps.
438
War weariness multiplier 137% on Duel, 150% on Duel, decreasing in steps of 20 to 50%
decreasing in steps of 12.5 to 75% on Huge. on Huge.
Trade profit multiplier 70% on Duel, decreasing in 80% on Duel, decreasing in steps of 10 to 30%
steps of 7.5 to 33% on Huge. on Huge.
Rationale As above; don't expect the average number of cities per civ to be that much higher on
larger maps than on smaller ones.
Tbd. Corporation maintenance decreases rapidly with increasing map size: 400% on Duel,
50% on Huge. That's probably not ideal.
The six national wonders with prerequisite The map-size multipliers are 4/4 on Duel and
buildings require 4 buildings on Duel-size and Tiny, 5/4 on Small (no change), 6/4 on Standard,
Tiny maps, 5 on Small (times 10/8 percent), 6 on 7/4 on Large and 8/4 on Huge, always rounded
Standard (11/8 rounded up), 6 on Large (12/8) down.
and 7 on Huge (14/8 rounded up).
Cathedrals and the Statue of Zeus require 3 Consequently, Cathedral and Statue of Zeus,
Temples/ Monuments on Small maps. which have a base requirement of 2 buildings,
require only 2 buildings on Small maps.
Rationale Oxford University is almost indispensable for competing in the Industrial era, and e.g.
on a Large map with 11 civs (now the default number), it's difficult to acquire
peacefully 7 cities where a University makes sense.
The change to Cathedrals and Statue of Zeus is just a side-effect.
See also 310 gives the Great Wall a (base) requirement of 1 Wall.
Config The base numbers of prereq. buildings are set in Civ4BuildingInfos.xml, but I
didn't change these. The map-size modifiers are in Civ4WorldInfo.xml. The change
to the rounding behavior is in the DLL (CvPlayer.cpp).
Tbd. Would prefer abilities that scale with the number of buildings, e.g. "Oxford University:
+10-15% research (based on map size) per University up to a maximum of 60%". No
required number of buildings necessary then.
439
Tbd. Gifted military units should only boost relations when the AI has an immediate need
for military aid. The relations bonus should probably also be capped; seems
exploitable.
Comment by karadoc in CvUnit::gift:
'It would nice if there was some way this could also reduce "you refused to help us
during war time", and stuff like that. But I think that would probably require some
additional AI memory.'
I don't think this is worth the effort, but perhaps gifted units should count for "you gave
us help" instead of "fair trade".
Imp. Knoedel has implemented a new memory type for his Sunset of Civilization mod:
Git commit
That looks very basic. The main thing of interest would be his iUnitValue formula.
142 Master gets a happiness bonus only from the first peace vassal
AdvCiv BtS
The master of a vassal civ receives a happiness Each vassal, capitulated or not, provides +1
bonus only from voluntary vassals, and only the happiness in all cities of the master.
first one counts, i.e. at most +1.
Rationale In large games, the stacking happiness bonus, combined with the free luxury
resources from vassals, can let master civs ignore happiness altogether. I also don't
like that the bonus applies even if just one city is left; this provides an incentive to
keep tiny vassals around, which lead to some oddities in global diplomacy (despite my
efforts to fix such issues). Also, oppression of capitulated vassals is hardly a point of
pride. Should perhaps remove the bonus entirely, but for voluntary vassals "We
influence other civilizations" makes some sense, and these vassals are harder to get.
The anger at the vassal side seems sensible (though unimportant) and can't stack.
Change 130 and related changes (see under 130v) remove several disadvantages of
vassal agreements for the master, so, as far as game balance goes, I don't think a
happiness bonus is needed at all.
440
When a vassal cancels a vassal agreement for No memory about canceled vassal agreements.
no particular reason (i.e. vassal feels safe or When a capitulated vassal breaks free, it often
powerful enough on its own), the (AI) master signs a VVA with the same master on the same
remembers this for, on average, 20 turns, and turn. When a voluntary vassal is near the power
refuses to sign a VVA during that time. When the threshold for a VVA, the agreement can flicker on
agreement is canceled because the master and off every few turns.
hasn't protected the vassal, including the case
where a capitulated vassal breaks free after
losing too much territory, the vassal remembers
this for 30 turns (on average), and refuses
another VVA. (Whether the master or the vassal
remembers is only relevant when the master is
human.)
Rationale The flickering isn't only goofy, it also means that war preparations against a former
vassal can easily get interrupted by a new VVA, which is frustrating. Also, some
mechanism is needed to keep a vassal independent for a while when the master has
failed to protected it.
143b Cancelation and nukes
VVA canceled also after being nuked repeatedly. Only lost territory counts (and only for capitulated
The threshold is randomized; usually, the vassal vassals).
doesn't break away until more than half of its
cities have been hit. Doesn't cancel if the master
has SDI and the vassal does not.
Master's SDI protects vassal. SDI is a team project, but doesn't protect vassal
teams.
Vassal cancels VVA if it has any nukes unless
master has SDI and vassal doesn't: "doing fine Vassal's nukes factor into its power rating, but a
on our own." single nuke doesn't usually make a difference.
Capitulated vassals don't build nukes. When a Vassals don't hold back on anything.
team capitulates, all it's nukes are scrapped.
Nukes can't be gifted (between any civs). Can gift nukes to circumvent the diplo penalties.
Rationale SDI is supposed to be an array of space-based lasers. Should be able to intercept
any nukes that the SDI owner wants to intercept.
Vassals that are powerful enough to build nukes should stand on their own.
See also 130v makes the master responsible for nukes fired by a capitulated vassal (obsolete
now that vassals can't have nukes).
112 cancels VVA when near victory and stops capitulated vassals from pursuing
victory.
Tbd. A cancelation condition based on present population vs. population when signed
might be better.
May want to scrap other units upon capitulation too, probabilistically. E.g. when
France surrendered to the Third Reich, the French navy was partly scuttled.
441
See also 130v exempts vassals from this change and prevents vassals from granting gifts to
rivals or to a disliked master.
130o deals with memory about tribute demands. Clears recent-demand memory
(which is also relevant for gift requests) when war is declared on an AI civ.
104m: Some gift requests are triggered during war planning.
AdvCiv BtS
Without considering any specifics, the AI refuses The only randomized aspect of the AI response to
gift requests with a leader-specific probability. a gift request is the decay of recent-demand
That probability is based on ContactRand: memory: The request is refused if the AI still
CONTACT_GIVE_HELP and between 5% (Gandhi) remembers an earlier request (or tribute demand).
and 32% (Sitting Bull, Montezuma). I'm capping So, the first request is handled without
the probability at 50% for Tokugawa, otherwise randomness, and if a previous request is far
he'd always refuse. enough in the past, it's very likely forgotten (the
expected time to forget is 20 turns).
Requests are always refused while preparing CONTACT_GIVE_HELP determines only how
war against the player (no change). frequently an AI leader offers a gift to human civs
that have fallen behind.
Rationale Shouldn't be able to use requests to determine reliably if the AI is preparing war. It's
semi-decidable now – if a request is granted, then the AI certainly isn't plotting. That
said, they might start on the very next turn ...
In BtS, CONTACT_GIVE_HELP is irrelevant for experienced players; it's nice to give this
an actual use.
Memory about requests and rejected demands is Can decrease on any turn. AI may grant gifts
not decreased while there is a peace treaty when there is already a peace treaty.
between the two civs. Gift requests are rejected
during a peace treaty unless the AI remembers
receiving a gift from the player (and that case the
peace treaty may well result from a gift to the AI).
Likewise, the AI won't ask for a gift during peace
treaty unless the human player (i.e. the proxy AI)
remembers having received one or when fewer
than 4 turns of peace remain. Will only ask for
tribute during a peace treaty if it's about to expire
(1 turns remaining).
Rationale To increase the time in between granted requests. A bit too easy in BtS to keep a
Pleased AI from planning war: can reliably sign a peace treaty about every 25 turns,
which leaves just 15 turns in between, which can sometimes be bridged by asking the
AI to attack a third party (which results in a peace treaty; see change 146). My change
makes this tactic unsustainable.
Could argue that "begging for peace" shouldn't ever be a tactic. I like that it makes
Pleased attitude relevant even for warlike leaders. Think of it as a Reinsurance Treaty.
I don't like that this is something only humans can use.
(Could alternatively merge Kek-Mod's one-sided peace treaties. Though
communicating those to the player could be a problem.)
AdvCiv K-Mod
AI refuses gift request if planning war against the Only refuses if already planning war against the
player, and refuses with a high probability if war player. (In BtS, the AI doesn't take the resulting
utility is positive (but not yet planning war). peace treaty into account at all; grants request
regardless of war plans.)
442
AdvCiv BtS
When asking for a gift, the AI asks for the tech The requested tech is chosen uniformly at
that it needs most, with a bias for cheap tech. random.
Rationale Which tech the AI asks for doesn't have to be unpredictable; no need for any random
element (though the AI function that I'm using now, AI_bestTech, does have a
random element). If cost is ignored, the most useful tech tends to be expensive, and I
don't want the AI to ask for expensive tech all the time. On the other hand, the AI
shouldn't ask for cheap tech often because this makes the decision of the human
player too easy. Hence tech cost is given some weight but not full weight.
When asking for tribute, the AI is likely (threefold The demanded tech is chosen uniformly at
increased probability) to demand the tech that it random from among those techs that at least two
needs most, though techs that no other civ civs know.
knows yet remain off-limits.
Rationale Not quite the same procedure as for gifts because I wanted to keep the exception for
cutting-edge tech; picking (with certainty) the most useful tech that is known to at least
two civs would've been a bit awkward to implement because of the signature of the
CvPlayerAI::AI_techVal function.
Is the exception really a good idea? Maybe yes: The civ that receives tribute remains
a threat in the medium or long term, so yielding to that civ an edge in (military) tech is
rarely going to be prudent.
Gifts requests granted by human player are 200 turns
remembered for (on average) 150 turns.
Rationale/ For 130r, I've thought a bit about and experimented with the memory decay for
See also declared wars, and ended up setting it to 150. I don't think granted gifts should be
remembered longer than declared wars.
Config MEMORY_GIVE_HELP (LEADER_DEFAULTS) in Civ4LeaderHeadInfos.xml.
Tbd. Ideally, the duration would depend on the trade value of the gift, how harmful it was to
the human player (tech gifts normally are pretty painless) and how badly the AI had
needed the gift.
AdvCiv BBAI
Contact probability for AI-to-human pleas for help By up to a factor of 30. A similar change, which
can be increased at most by a factor of 5 when increases the frequency of AI-AI tech trade
the AI is behind in tech. offers, was toned down (a lot) by K-Mod.
See also This old SVN revision makes clear that the BBAI increase was intentional, i.e. that the
goal had not been, conversely, to prevent the AI from asking for help when actually
ahead in tech. (The very stark increase when far behind may still have been
unintended.)
Rationale Stop-gap change. Maybe this should have much less impact and should go both ways
(i.e. less likely to ask when doing OK in tech). Or perhaps jdog5000 mostly did get it
right and the AI should pretty much immediately ask for help when starting to fall
behind.
145 No diplo bonus from accepted favorite civic/ religion if no longer in that civic/ religion
AdvCiv BtS
443
The diplo bonus from having accepted an AI The bonus lasts for an expected 100 turns,
civ's religion or favorite civic decays much faster regardless of whether the player keeps the civic/
if the human civ isn't presently in that civic or religion. Can switch out after 5 turns.
religion, or if the AI civ is no longer in the civic or
religion.
Likewise, the penalty for refusing the fav. civic/
religion decays faster if the human civ is now in
that civic/ religion, or if the AI civ has switched
out of it.
Rationale Switching right back is a bit cheap, especially with the Spiritual trait. Until v0.95, the
relations modifier was suspended instead of decaying faster, but I think that made it
too unattractive to accept AI requests.
See also Part of the Dynamic Diplomacy changes.
444
Rationale Shouldn't get -4 relations from a single city choked city; this can easily happen in BtS,
even in the late game. I generally don't like when high culture leads to painful diplo
penalties.
This change reduces border tensions a bit overall, and the following change should
even that out:
When an AI civ steals tiles from a neighbor that There's only a diplo penalty for stealing tiles from
the AI civ can't work because they're too far away the AI, not vice versa.
from its cities, then the AI civ is slightly upset
The weight for stolen tiles is 3.
about this. The multiplier for those tiles is 5,
whereas the multiplier for tiles stolen from the
AI civ is 8. Both weights are multiplied by a
percentage based on the size of the AI civ's
territory and the map size; this multiplier
decreases as more territory is acquired and
tends to be near 50% by the end of the Classical
era.
The weight for the length of the border shared If the border is longer than 7 tiles, a flat penalty of
with another civ (no matter if tiles are stolen) is 5. 40 is counted. In the end, the total penalty is
The result is capped at 40, and no border tiles divided by 100 and multiplied by the AI leader's
are counted if the border length is less than 5 CloseBordersAttitudeChange value (between
tiles. 1 and 4; no change).
Rationale Count unworkable tiles because I don't want change 099b (culture decay in foreign
city radii) to reduce border tensions. Should also encourage civs to put at least
enough effort into culture to prevent a no man's land that no civ can work (which is
implausible at peacetime). Makes sense to me that the AI is annoyed by not being
able to work the tiles that it owns and is inclined to remedy this by conquering the
cities near those tiles.
All the formulas take into account the total size of the territory because, to a civ that
has only 2 cities, 4 lost tiles should be a big deal, but not to a civ with 10 cities.
I've shifted some weight from the common border penalty to stolen tiles because,
when neither side loses tiles, there really shouldn't be much bad blood. The BtS
formula is also too abrupt (0 or 40).
Tbd. Perhaps let the relations penalty increase sublinearly with the weighted sum of stolen
tiles. Easy enough to do in CvPlayerAI::AI_updateCloseBorderAttitude by e.g.
exponentiating iPercent in the end with 0.7 and then times 3, but maybe a penalty of
1 or 2 already happens much more easily than -3 or -4 (this would be the goal).
Stolen tiles with a bonus resource are counted Every stolen tile counts as 1 tile.
double.
Tbd. Should make the value counted per tile fractional and take into account yields as well.
Perhaps there is already a suitable tile evaluation function in the CvCityAI or
CvPlayerAI class.
445
At a relations value of 4, the AI becomes Friendly at 10, Pleased at 3, Annoyed at -3,
Pleased, at -2 Annoyed, at -9 Furious, at 9 Furious at -10. On Noble difficulty and above, all
Friendly. Players receive no relations penalty relations suffer a penalty of -1. On Chieftain,
from any of the difficulty settings. On the lowest humans get +1 relations from AI civs and on
three difficulty settings, humans receive relations Settler +2.
bonuses ("a first impression ...") of 3, 2 and 1
respectively.
Rationale In effect, this makes Friendly 2 easier. A distance of 7 between Pleased and Friendly
was too much considering that most AI civs are already very unlikely to start a war at
Pleased and are willing to trade tech. The additional benefits of Friendly aren't that
great. Until AdvCiv 1.0, I had kept the Friendly threshold at 10, making it (in effect)
only one lower than in BtS, and I had increased the Furious threshold (in effect) by 1,
setting it to -8. This way, Pleased and Annoyed attitude had intervals of equal length,
as in BtS. I eventually decided that this is not an important property to uphold and
that, on the contrary, a longer interval for Annoyed makes more sense because
negative modifiers are easier to stack up than positive ones – mainly through
declarations of war. Various changes to relations modifiers in the mod make it
considerably harder than in BtS to improve relations well beyond the Pleased
threshold.
As for flipping the sign of the difficulty-based modifier, the benefit is that the player
sees the "A first impression ..." line much less in the game. It was a bit silly to tell the
player that he/she is making a bad first impression everywhere.
The downside is that players have to relearn the thresholds that might be familiar from
BULL.
See also About important changes that make positive relations modifiers harder to get, see the
Dynamic Diplomacy chapter.
The Show Hidden Attitude mod makes the BtS relations penalty from difficulty visible
to the player (and is also included in BULL).
There's a bullet in the WIP section that links to several CFC posts (prior to AdvCiv 1.0)
pointing out that Friendly relations are too difficult to attain (and too rare between AI
civs).
Config The attitude thresholds can be set in GlobalDefines_advc.xml.
Friendly attitude causes the AI to vote for +8 relations needed for a victory vote.
someone in a victory vote; Pleased is not
enough.
Rationale Seeing that Friendly attitude, in effect, starts at +8, this doesn't really change
anything. A happy coincidence because it's much more intuitive to require Friendly
relations than yet another threshold slightly lower than Friendly.
See also 115b: AI won't vote for victory when itself at victory stage 4.
AI civs have a +0.3 bonus to "first impression" No diplomatic handicaps for human players,
relations (cf. 130b) on difficulty settings lower though the AI-specific portion of the "first
than Prince. From Prince to Deity, the bonus impression" modifier (i.e. from peace weight and
increases from 0.4 to 0.9. warmonger respect) is more often positive than
negative.
446
Rationale This was a bit of an accident. Until v0.93, I had assumed that the BtS relations penalty
(-1) applied only to human-AI relations, and I had meant to replace this with a +1
bonus on AI-AI relations. Now that diplomacy overall is balanced around the inter-AI
bonus, I'm finding it a bit difficult to remove it entirely; I don't like when AI leaders are
Annoyed at each other from the beginning.
Relations bonuses from "fair and forthright" trade are generally easier to attain for
humans than for the AI, and some relations bonuses tied to AI requests are only
available to humans. This is evened out by relations penalties for rejected requests,
but not entirely, one could argue. Let's say that the AI bonus makes up for these
asymmetries.
See also 250d removes a few minor advantages that the AI receives through the difficulty level.
The time-based relations modifier for having the The limit is between 1 (Willem) and 7 (Ashoka,
same state religion has an upper limit between 1 Zara Yaqob).
and 6, depending on the AI leader. I've left all
limits of 3 or less unchanged and reduced all
limits above 4 by one. As for leaders with a BtS
limit of exactly 4, I've reduced the limit to 3 for
about half of those AI leaders so that, overall, the
average limit has decreased by ca. 0.5.
Similarly, I've reduced the limits for the time- The limit is between 1 (Saladin – Theocracy) and
based “wisely chosen civics” modifier by ca. 0.5 6 (Gandhi – Universal Suffrage, Mao, Stalin –
on average, reducing all limits greater than 4 by both State Property).
one and also almost all limits that were exactly 4,
the exceptions being Lincoln (Emancipation),
Mansa Musa (Free Market), Washington (Free
Speech) and Willem (Free Religion).
Rationale To match the decrease of the threshold for Friendly attitude, i.e. so that the new
threshold doesn't make too many AI leaders very easy to befriend through a shared
religion (or civic, less of a concern). It's generally desirable to reduce modifiers that
have almost no rational basis.
For simplicity, I've changed almost exactly half of the leaders. When I had to choose
among leaders with an equally high limit, I decided based on historical and gameplay
considerations; e.g. Lincoln being a strong proponent of Emancipation, also
internationally, is (somewhat) credible, Roosevelt (or anyone really) promoting
Mercantilism much less so.
See also Related CFC post (1st spoiler box)
130n adjusts the time-based ideological modifiers dynamically based on their
popularity.
See the WIP section (toward the end) for a note about overhauling AI personalities for
gameplay and historicity. In contrast, the changes implemented here are mostly
across the board in order to make them easy to adapt to (“ideological modifiers don't
go as high as in BtS anymore” – simple enough).
Tbd. Limits for religious civics should be reduced if the state religion doesn't match.
Shouldn't get a net relations bonus for sharing, say, Organized Religion with
Suryavarman and running a different religion.
To become the worst enemy of an AI civ despite Annoyed attitude is the only prerequisite.
not being at war, the total relations value needs
to be at least 1 worse than the threshold for
Annoyed attitude.
447
Rationale Going from Cautious attitude to being the worst enemy just through a 1-point
decrease in relations is too abrupt and can lead to too many changes in worst enemy
status, especially during the first two eras. Perhaps the worst-enemy threshold should
even be 2 lower than Annoyed, but, seeing that this is a post-v1.00 change, I want to
play it safe.
See also Rank hate easily leads to Annoyed attitude in the early game. 130c may make
flickering between -2 and -1 more common.
130d changes some rules regarding vassal agreements and worst enemies; 130p
prefers war enemies as worst enemies.
Config GlobalDefines_advc.xml
448
Replay and on-screen announcement indicate Religion changes are logged and announced, as
when a civ renounces its state religion, i.e. are civics changes to Free Religion.
switches to no state religion.
Rationale Can also switch to no religion without adopting Free Religion, and that's worth
logging.
See also 151 below
150b Results of diplo votes
Record successful UN and Apostolic Palace Replay only shows the vote tally for and against,
proposals including targets (e.g. the name of the without naming the proposal.
city to be reassigned), the civ who made the
proposal and the vote tally.
Rationale Since I'm including the name of the Secretary-General/ AP Resident when recording
proposals, there should be no need to record the Secretary-General elections.
151 Message about changed religion or civic indicates the earlier civic or religion
449
When a worker build, pillage, bombard or air When a group of units is ordered to execute a
bomb mission is completed by a group of (non- mission, then as many units as possible execute
automated) human units, if the group has no the mission. If all units use up all their movement
further missions queued, any units with available points this way, then (no change in AdvCiv) unit
moves are split into a separate group and that cycling continues with a different group;
group is either immediately selected (if the otherwise, the whole group remains selected.
mission has just been ordered) or included in the
When a group completes its mission at a time
unit (group) cycle.
when it isn't selected (multi-turn move or worker
For missions not listed above, in particular for build; queued orders), then the group does not
move-to missions, groups that have available get selected through unit cycling, even if some
moves are included in the unit cycle even if not units still have available moves.
all units are able to move. Such groups are not
No change: Units in automated groups, groups
split up however, and the whole group gets
with multiple queued missions and worker groups
selected when it comes up in the cycle.
on a route-to mission will begin with the next task
even if not all units in the group have available
moves. However, a unit will never move to a
different tile ahead of the whole group (as this
would cause the group to split).
Credits Proposed at CFC by Leoreth: post (item 1, last part of item 3)
Rationale The goal is to make sure that the player is aware of unspent movement points and to
help him or her spend those points by selecting a sensible set of units. However, the
game must not split up large groups that the player may want to keep intact.
Aside: There is a distinction between selecting units (yellow frame on the UI) and
forming a group. Technically, the currently selected units are stored in a
CvSelectionGroup object (CvDLLInterfaceIFaceBase::getSelectionList; group
id 0), but that group gets overwritten as soon as a different unit becomes selected. As
soon as a player gives an order (skip will do) to the current selection, those units form
a persistent (CvSelection-) group.
It's preferable not to directly split up human groups and instead to just select a subset.
That said, a player who doesn't want to move the selected subset (and therefore
probably doesn't want to split the group), is probably going to order the selected
subset to skip its turn, thereby splitting the group. So it doesn't make a big difference,
and I do split them up directly because it's easier to implement.
For build, pillage, bomb(ard), it seems fairly likely that the player will want to give
orders to any units with movement points left, and those groups are unlikely to be very
large or, if they are, the split is likely going to be uneven (only so many units can
bombard or pillage a tile).
For movement (including attacks), groups can be arbitrarily complex and it may well
be that the player wants to keep the group together in one tile. (See also Leoreth's
arguments linked above.)
Queued missions already work pretty well in BtS; e.g. when ordering a group of
workers to first build a Mine and then a Road, no worker turns can get wasted in
between the two builds. If group automation and group route-to were allowed to break
up the group, then the easiest implementation would be to split the group
(permanently) as soon as automation or the route-to mission starts. It's easy enough
for the player to do that manually for these high-level commands; and perhaps there
can be reasons for wanting to keep a group of workers in a single tile.
Tbd. Maybe there really are no good reasons for group route-to or group automation and
groups should be force-split upon those commands.
450
See also Smarter order of execution for group missions: 004c
When a human group of attackers (regardless of All selected units advance.
the Stack Attack option) destroys the final enemy
K-Mod has fixed a BtS problem with Gunships
defender, only the most recent attacker moves
(which can't capture cities) getting left behind
into the defending tile. The remaining units split
after a successful group attack against a city.
up into one group with units that still have moves
left and another without moves left. Unit cycling
will normally continue with the former group if the
most recent attacker is out of moves.
When an attack into a non-adjacent tile is
ordered, then this change does not prevent all
selected units from moving into a tile adjacent to
the enemy. From that adjacent tile, only one
attacker will advance.
Credits Proposed at CFC by Leoreth: post (item 2)
Rationale Often, the best play is to split the victorious stack between its original tile and the
target tile so that no (potentially damaged) units are left exposed. The BtS behavior
makes the Stack Attack option pretty much unusable in some situations, and, when
group attacking one by one, it's also easy to miss the point when there is just one
defender left and to move all remaining attackers by accident.
Splitting units with remaining moves from units that (probably) have fought should
often be a welcome convenience (though there can be cases where it's undesirable).
Sending only one attacker forward when attacking across one or several intermediate
tiles sounds reasonable, but probably would be unexpected when the attack
comprises a multi-turn move. And, with the Stack Attack option, everyone will have to
move. So this would get pretty inconsistent. Also seems a bit difficult to implement.
See also 004c may interrupt group missions upon air interception.
451
Show a button to the left of the big flag button Unit cycling can be forced only through the
(i.e. at the right end of the command area) that hotkeys W (I guess for “let the current selection
cycles to the next group of units that needs wait”), Num5 or Enter. (Enter will instead end the
orders. The button shows the icon of that group's turn when the End Turn button flashes red.) The
head unit and a dot indicator in green if that unit backslash key (^ on German keyboards) cycles
still has all its moves available and yellow backwards.
otherwise. Right-clicking the button cycles to the
group preceding currently selected group (if any)
in the cycle, i.e. normally the most recently
selected group before the current selection.
When no group needs orders and none is Pressing a unit cycling hotkey will unselect all
selected, the unit cycling button disappears. If units if the unit cycle is complete.
one or multiple units are selected and none need
orders, the unit cycling button shows the icon of
the head of the current selection with a white dot
if that unit has moves left and with a red dot
otherwise, and causes all units to become
unselected when clicked (left or right).
Rationale Experienced players need this fairly frequently, and, judging by questions posted on
CFC, some are unaware of the keyboard shortcuts (the Enter shortcut seems to be
less widely known than W), keep forgetting them or are even unaware after years of
playing that unit cycling can be forced. Also, any player will sometimes, maybe by
accident, select a unit that already has orders and whose orders they don't want to
change, and, without knowing the unit cycling shortcuts, they'll be at a loss as to how
to continue with the unit cycle (see this post in the thread linked above). And some
few players prefer to control the game entirely through the mouse.
It's also preculiar that the game allows players to disable automatic unit cycling but
doesn't provide any visible UI support for manual unit cyclic.
I don't know (yet) if showing the icon of the next unit in the cycle is really helpful, but
it's an intuitive way of communicating the functionality of the button. The overlayed
dots make the button look just like the unit buttons listing units in the same tile as the
current selection. Also, the dot is usually green, which matches the color of the End
Turn button so long as the unit cycle isn't complete. That and the placement to the left
of the End Turn button communicate that cycling through units that need orders is part
of the turn sequence. The city cycling arrows from BUG are also located nearby, and
cities that need production orders are shown as building buttons (when playing with
minimized popups) – albeit at the right edge of the screen.
On low resolutions, the command area can be filled with promotion buttons. In that
case, there is still enough room for the unit cycling button in between a vertical
scrollbar and the big flag. That's also where the production filter buttons are placed
when the city screen is up.
I didn't want to show unit cycling as a command button (“Wait” command) because it's
just the point of cycling away that it does not give the current selection any command
for the time being.
The right-click behavior is a bit obscure, but, if one is aware, right-click to go
backwards feels pretty natural. The other reasonable behavior I can think of (which
I've tested and left as a comment in CvDLLWidgetData.cpp) is to focus the camera on
the next group without changing the current selection. Neither of these functions are
really needed, but going backwards seems a bit more useful and lets the button cover
all unit cycling commands that BtS allows through hotkeys.
452
Tbd. Could show in the button's hover text how many groups still need orders. Will have to
play with the button enabled for a while to figure out what extra info, if any, would be
nice to have in the hover text.
Config The button can be disabled through the BUG menu (“General” tab). In the same
place, a second button for worker cycling can be enabled (see below).
See also The deselection behavior is based on the unselect-all global control implemented by
change 088.
Disabled by default: Underneath the (all-) unit Worker cycling is available through the slash key
cycling button, a worker cycling button is shown if (# on German keyboards).
there is any group that contains a Worker or
Workboat unit that needs orders. Clicking the
button will select the next such group in the unit
cycle. The button doesn't have any right-click
behavior. If both unit cycling buttons would refer
to the same group, i.e. if the next unit in the
overall unit cycle is also a worker, the worker
cycling button is not shown.
Rationale To give the player a choice in how to proceed in the unit cycle, and so that all unit
cycling commands available through shortcuts are represented by a virtual button.
(There are also shortcuts for cycling through individual units in the current selection
group, but that can already be emulated by clicking through the buttons in the unit list.
It's also a bit of a different feature and not widely used I think.)
Testing will show if this is really useful or if players would perhaps prefer some other
choice.
Going backwards in the worker cycle isn't implemented. Wouldn't be difficult to do, but
I don't think I want to bother with this. Therefore no right-click behavior.
Similarly, it might be nice to exclude non-worker units from the unit cycle controlled by
the upper button when the worker cycling button is enabled, but I'm not going to
implement that. (I also don't really think that cycling through all units is dispensable,
and I wouldn't want to add a third button.)
Tbd. Perhaps add a button for triggering auto-missions (missions of automated units and of
units with queued orders). There isn't really room for such a button in addition to the
two unit cycling buttons though. I guess two choices could be added to the current
BUG dropdown menu: One for just the auto-missions button and one for unit cycling
plus auto-missions (never mind the combination of worker cycling plus auto-missions).
Anticipating which unit will have moves after auto-missions is too difficult to do, so the
button icon shouldn't show any unit graphic. It could show a variant of the Automate
button graphic with the big yellow dot in the middle edited out (because that dot
represents the currently selected unit, which is not going to have an auto-missions).
The hover text could show the Ctrl+A shortcut.
Note that K-Mod triggers auto-missions when the unit cycle wraps around. I think this
only happens when the last group that needs orders is either given orders or when the
players tries to cycle away from that group (using a hotkey). I think BtS triggers auto-
missions as soon as a player cycles manually to another unit.
453
Tbd. Hardly tested.
AdvCiv BtS
Trades proposed to the AI by a member of its The AI accepts gift requests ("sure would come
team are considered with more goodwill than in handy") and gifts from team members. Can't
trades proposed by members of other teams, but even ask the AI to offer a trade.
still rejected if they're very uneven.
The AI can reject gift requests by a teammate. It Always accepts gift requests and doesn't
remembers granted requests and forgets them remember them; i.e. the human can ask as
twice as fast a gift requests from non-members. frequently as he/she likes. (Whereas the AI
remembers both granted and rejected requests
The diplo text for a gift request to a team member
from non-members and refuses to consider
is still "sure would come in handy."
further requests while still remembering an earlier
one.)
Rationale Don't want the AI to behave like a puppet in human-AI teams. Should feel more like
playing together with another human being, and these have their own opinions and
tend to behave not entirely selflessly.
Kept the special diplo text because gift requests to team members still get a special
treatment (e.g. forgotten faster).
AdvCiv Unofficial Patch
A human can't offer to an AI teammate to switch Can offer this to the AI. Not sure if the AI
civics or religion. appreciates it in any way. Probably a bug.
Rationale The AI can't judge whether it benefits from a human civics or religion change.
AdvCiv BtS/BUG
In team games, team membership is color-coded BUG adds an option for grouping vassals with
on the scoreboard: Civs belonging to the same their masters (enabled by default in AdvCiv), but
team (and also their vassals) have their score there's no way to indicate team membership on
shown in the text color of the (master) team the scoreboard. Scores are always shown in
leader. white.
Rationale Hard to tell which team is doing well when team membership isn't shown.
Config Can be disabled through the “Scores” tab of the BUG menu (option “Color-Code
Teams”).
Tbd. The colored scores can be a bit difficult to read. Perhaps Kek-Mod's "option to add
team number to BUG scoreboard" is a bit better (Git commits 1 2)? It's very low-key
when disabled, so I could also offer it alongside the color-coding option.
See also 004v: Other changes to scoreboard text.
AdvCiv BtS
Teammates cause Emancipation anger when not Teammates are exempt from causing
all members of a team are in Emancipation. Emancipation anger.
Rationale Seems a bit more intuitive.
454
When multiple members of a team are The research cost modifier of a team is increased
researching the same technology, their research by 50 percentage points per member beyond the
modifiers are decreased by 10 percentage first (still the case in AdvCiv), but whether the
points. team members are researching the same
technology isn't a factor.
The AI disregards the research goal of
teammates; may or may not choose the same When an AI civ needs to select a tech to
tech. research, it always picks one that another team
member is already researching.
Rationale The BtS mechanism (teams basically always research one tech at a time) is OK, but
the penalty should result in more interesting decisions.
Config Can be tweaked or disabled in GlobalDefines_advc.xml.
See also 910 shows a breakdown of research modifiers in tech hover text.
AdvCiv BtS/ K-Mod
In multiplayer games, the "you have discovered" The tech splash screen is never shown in
sound is played when a tech is discovered by a networked multiplayer games (still true in
teammate. Otherwise, the tech quote is played. AdvCiv). BtS always plays the “you have
discovered sound” along with the message about
any newly discovered tech. K-Mod instead
always plays the tech quote. (Comment in the
code: “the 'MP' sound is boring.”) It looks like
BUG had already been playing the tech quotes
(through XML changes; K-Mod through the DLL).
Rationale Want to give the “you have discovered” sound some use. Should make it easier to
distinguish between own discoveries and those of teammates – now that the
members of a team usually research different technologies each.
455
In the calculation of the total commerce rates of a Each city counts its commerce rates, already
player, when rounding errors add up to at least 1 adjusted to the slider percentages – but not yet
commerce, that total error (rounded down to an including gold expenses, at times-100 precision,
integer; typically to 1) gets added to the i.e. with only minor rounding errors. The total
commerce rate(s) that contribute(s) the most to commerce rates (gold, research, espionage –
the total error. total culture isn't really relevant; cf. 004p) are
Note that the rounding errors corrected this way computed by summing up the per-city rates and
are typically the result of splitting the base dividing each rate by 100, rounding toward
commerce rate according to the special negative infinity. This can result in a rounding
commerce sliders, but, through science and gold error (of usually at most 1 commerce) to the
buildings combined with specialists, rounding disadvantage of the player. Whether that's the
errors can even occur when running 100% case is somewhat unpredictable and will depend
research or 100% gold. on the specific slider percentages. That said, in
the early game, so long as there are no Libraries,
it's very predictable – at 100% research or 0%
research, no rounding error will occur, at all other
positions of the research slider, there will
normally be a rounding error. Even once there
are Libraries (but no Markets), 0% research
incurs no rounding error. The early game is when
the rounding error hurts the most.
Rationale For numbers that appear on the UI, I generally want to stick to the BtS rule of always
rounding down. Special commerce is already treated differently in by being counted at
times 100 precision, so I feel that eliminating this rounding error is fair game.
Tbd. There are still several strong reasons for using binary research: Not committing to a
tech sooner than necessary; waiting for tech diffusion multipliers to increase or for
Libraries to be constructed; temporarily building up a gold reserve for trade
opportunities or random events. On the other hand, partial progress toward a tech has
no benefit (unless one is trying to trade for the tech).
I think there'll have to be a penalty for extreme slider positions (like in or akin to Alpha
Centauri) or for adjusting sliders. Don't know how that should work in detail.
456
Rationale Having the code in a separate class made it easier to experiment with the data
structure. Normally, no strength value is remembered for the vast majority of tiles, so I
suspected that a vector would lead to unnecessary CPU cache misses. In tests, a
hash map was only slightly faster, so it seems that there wasn't much of a problem,
but at least there appears to be a small improvement now.
For human civs, I see only one potential out-of-sync issue (in the cost function of the
pathfinder), and karadoc had already worked around that, so disabling updates of
human strength memory seems to have been an abundance-of-caution decision.
I don't know why it was partially disabled for minor civs; perhaps just an ad-hoc
decision.
I've kept Barbarian strength memory enabled; will usually matter for Barbarians that
emerge in the same region of the map, so it's plausible enough that they would share
information. And getting Barbarians to avoid well-defended cities is a sensible goal.
See also 300 lets Barbarians use an “activity” map in addition to strength memory. The activity
map steers Barbarians away from cities near which Barbarian units have recently
been defeated.
457
When evaluating the defensive strength of a Both the offensive and defensive evaluation sum
stack, the AI adds some extra value based on the up strength values computed for the individual
sheer size of the stack. units.
Rationale It seems that the CvPlayerAI::AI_local...Strength functions don't take into
account at all that the combat rules (strongest defender comes forward) generally
favor the defender (so long as no collateral damage is involved). It's OK to
underestimate the defender's advantage (let the AI err on the side of taking action),
but I don't think the defender's advantage should be ignored completely, especially not
for medium-size and large stacks.
458
The AI considers hiring another AI civ for war DeclareWarTradeRand is 40 for all leaders
with a per-turn probability of p for each potential except Pacal, whose DWTR value is 60.
hireling computed as follows: Regardless of DWTR, the BtS formulas result in
p(t) = 10 / (DWTR + 10 * min{10,t}), p=1 when the war is 0 turns old. For DWTR=40, p
is 1/(t+1) for the next three turns, and, for t=4 to
where t is the number of turns spent at war and t=10 gradually decreases to 1/40.
DWTR is DeclareWarTradeRand in
Civ4LeaderHeadInfos.xml. For DWTR=40,
this results in a probability of 1/4 when a war has
just started (0 turns spent at war), 1/5 on the
next turn etc. down to a lower bound of 1/14
after 10 turns spent at war.
Rationale I'm not sure if the guaranteed check after 0 turns was intended. If so, then perhaps
the checks on subsequent turns were made probabilistic only for performance
reasons – the number of (hireling, war target) pairs grows quadratically with the
number of civs. That said, most of the pairs are usually eliminated by attitude checks
(attitude toward the sponsor and toward the target), so I'm not too worried about
performance. The BtS probability seems too high to me in the beginning and to low
later on. Pacal's value may well be an accident.
Tbd. Considering to set leader-specific DWTR values so that some leaders tend to wait and
see before bringing in help (DWTR=60), some hardly ever do (DWTR=80 or even
100) and some take all the help they can get asap (DWTR=20). Proud and miserly
leaders would get a high DWTR, and profligate leaders a low one. I'm finding it difficult
to fit the leaders into these categories though. Tentative:
3xDWTR=20: Huayna Capac, Louis, Justinian
11xDWTR=40: Hannibal, Suryavarman, Mansa Musa, Hatshepsut, Hammurabi,
Montezuma, Saladin, Churchill, De Gaulle, Roosevelt, Augustus Caesar
14xDWTR=50: Cyrus, Brennus, Julius Caesar, Willem, Pericles, Pacal, Catherine,
Washington, Joao, Boudica, Frederick, Bismarck, Wang Kon, Peter
6xDWTR=80: Alexander, Shaka, Genghis Khan, Qin Shi Huang, Gandhi, Kublai Khan,
2xDWTR=100: Tokugawa, Sitting Bull
16xDWTR=60: the rest
459
Rationale See this CFC thread, and maybe also this one.
I wasn't quite happy with this change from the start. A border (in the sea) is very much
not an obstacle, so the loss of movement points is implausible. I also don't like that
naval invasions and bombardment from coastal waters (i.e. when the two war parties
share a land border) are affected by this. Fast deployment is the only reason to use
navies in a land war.
In testing, I also found it easy to forget about the change. It does what it was
supposed to do, i.e. grant the defender an extra turn for attacks on unescorted
transports, but that just comes up so rarely.
460
Tbd. Have ships that unload units outside a friendly city or fort spend all movement points
and maintain a connection between the ship and its cargo for another turn, depicted
by the UI as some sort of overlay and labeled as “disembarking”. When a
disembarking ship is destroyed some or all of its cargo is destroyed as well. The idea
is to expose the transported units to naval attacks for another turn without making
them invulnerable to attacks by land and without slowing down unopposed landings.
Will have to make sure that the AI considers naval attacks on ships that are unloading
before considering land attacks on the disembarking units. Amphibic units should
probably be exempt, i.e. debark instantly and perhaps even with full moves.
Alternatively, some super-light version of zones of control might work, e.g. “Transport
ships can't unload next to a hostile ship with equal or higher strength (unless they
have full moves?)” or, disregarding ships in cities: “Transport ships can't unload next
to a water tile with a hostile unit (unless they have full moves?).” Such a rule is more
plausible than the current one based on border crossings, should be easier to
remember and doesn't affect naval bombardment in land wars (nor transportation if
only one side has ships). Would require some work on the AI though – escorts will
have to decide whether to attack defending ships (possibly leaving the transports
unguarded), transports have to decide whether to wait for a landing spot to be cleared
or to find a different one, and CvUnitAI::AI_guardCoast should at least show an
effort to protect the AI's coast against surprise landings.
Another idea: Rename the Sea Patrol mission to “Guard Coast” (“Patrol Coast”?), let it
trigger also when an enemy transport attempts to unload cargo and, to make the
mission more useful, let the guardian attack any targets that it can see and reach, i.e.
remove the rule that restricts the automated attacks to adjacent tiles. If an enemy unit
in the Fog of War blocks the automated attack, then it gets canceled once that enemy
becomes visible. The UI should highlight the affected area (akin to the Blockade
mission). Could let holding, say, Ctrl while clicking the Guard Coast button restrict the
automated attacks to transports, and holding Alt restrict them to pillagers. Would
require some new AI code – a function for evaluating the utility of guarding at a
particular tile (how many tiles will be protected? that aren't already sufficiently covered
by other guardians? how valuable is it to protect those? how safe will the guardian be
from enemy attacks?). Will want to pre-compute, once per turn, which players, if any,
are might attempt a naval landing and how big that risk is; how many tiles per land
area are worth guarding at all (making use of the Shelf class added by change 300);
how many warships should protect each land tile (I guess none if there are clearly too
interdict a naval invasion); whether any transports likely carrying naval invaders are
already visible (may also want to let guardians make occasional recon moves to
improve spotting of enemy transports). Then a special (high-priority) routine at
CvUnitAI that checks whether an incoming group of transports can be engaged
directly, or if guardians should instead be repositioned to (better) cover the likely
landing site. In other words, lots of work to get the AI to protect its coast. And of
course AI naval invaders will have to anticipate triggered attacks …
A bit of work for this has already been done through improved UI (change 004k) and
AI support (028b) for Sea Patrol under the BtS rules. Although the patrolling unit
would have to be the attacker if the range is increased, so much of that revised code
would have to be revisited.
461
See also 010 disables capturing of workers on the same turn as declaring war.
164 makes the Blitz promotion easier to access; that promotion is helpful for
destroying unescorted cargo ships before they can unload.
098 changes the rules for culture spread across water. A similar rule change could
allow borders to spread farther onto water, making it more difficult to reach the shore
on the same turn as declaring war.
Realism Invictus has a similar mechanism: CFC post (2nd quote box)
163 Teleported (“bumped”) units have all their movement points spent
AdvCiv BtS/K-Mod
When a unit is moved because the rules don't The movement points of the unit are unaffected
allow it to occupy its current tile – i.e. mostly by the forced move. K-Mod deletes all missions
when Open Borders are canceled –, all queued for that unit, but doesn't de-automate it
movement points of the unit are spent, its and doesn't wake it up; e.g. a Scout that was
automation is removed (e.g. if it was set to auto- fortified in foreign territory will continue to fortify
explore) and it is woken up so that it'll ask for after getting teleported and won't ask for new
orders on the next turn. orders.
Exception: AI units that find themselves in a tile
with units that they can't peacefully coexist with
don't lose their movement points.
Rationale Don't want players to use teleportation as a means of re-deploying units; can't prevent
this entirely, but using up movement points is a start. It's also more plausible that even
a forced move costs movement points.
The wake-up and de-automation are just usability improvements.
I've made an exception for the AI because, otherwise, an AI invasion could be delayed
by up to two turns by placing a single unit on the tile that the AI stack will cross the
border from. The teleport then pre-empts the DoW move and moves the AI stack to a
non-enemy tile. Depending on the surroundings, that tile may not be adjacent to the
border. Without the exception, the interfering unit could even be moved away before
the AI stack gets to attack it.
See also 046 makes minor changes to the selection of the tile that a bumped unit teleports to.
ctr fixes an issue with units getting bumped out spuriously after liberating a city under
occupation, and wakes up human units after tile ownership changes that don't lead to
bumping.
AdvCiv BtS
Then Blitz promotion requires Military Science Military Science and Combat III. (K-Mod had
(no change) and either Combat III or Drill I. allowed Drill III as an alternative requirement.)
Rationale Want to make Blitz ships (Destroyers, Battleships, Submarines) more common
because these make it easier to intercept an (unescorted) naval invasion; cf. 162.
Tbd. Or perhaps requiring Drill II would a good compromise.
462
Units with more than 1 move and paratroopers No special clause for paratroopers, and the unit
can receive the Blitz promotion if they also have type needs to have more than 1 move, i.e.
the proper combat class (Mounted, Armored, Morale doesn't help.
Helicopter or Naval; no change). The extra move
can come from the Morale promotion.
Tbd. This still doesn't allow Paratroopers and Gunpowder units with a Great Warlord to
receive Blitz because Gunpowder units aren't allowed to have Blitz. I'm reluctant to
change this because Mechanized Infantry could become too similar to Tank if it's
allowed to have Blitz. Not sure how to solve this problem.
Blitz allows units to make one extra attack per The number of attacks is only limited by the
turn. number of movement points. E.g. a Destroyer
could make 7 attacks per turn or (depending on
promotions) even more.
Rationale Blitz Destroyers are too goofy and also a bit too powerful; can't have that if Blitz is
accessible for level-3 units.
463
Rationale So that the default player counts result in a about the same amount of space for
peaceful expansion on all these maps. Those with uninhabited continents (e.g. Terra)
should, in my opinion, have more room once these continents become reachable, but
less room initially (compared with e.g. Pangaea). I'm not sure if it's the land ratio or
perhaps the resource placement, but the Old World in Terra isn't usually very crowded
with the default grid size and player count. “Earth-type map = huge” may be true
about scenarios (because the coastlines become unrecognizable at smaller sizes),
but shouldn't matter for randomized scripts.
I haven't adjusted any scripts that start with a letter before “F” because I want Fractal
to be on top of the list on the Custom Game screen. The ordering can't be modded
and the script names can't really be changed (see below).
Instead of adjusting the grid sizes, one could add player count recommendations to the map description
(in fact I had done this for a few maps until AdvCiv 0.95), but such recommendations are only shown
under “Play Now”, so most players never see them. As for adding a recommendation on the Custom
Game screen: The displayed map name ("Terra") is the name of the map script file, and changing this file
name (to e.g. "Terra - extra players recommended") would result in a second map, listed in addition to
Terra. I've tried adding a dummy drop-down menu with a single choice, but apparently at least 2 choices
need to be given. Such a menu would also be easy to miss because the default menus (which all maps
have) are displayed first.
Config Through copies of the respective map scripts in AdvCiv\PrivateMaps. and a new
Python function named getNumPlotsPercent that the DLL attempts to call on map
scripts.
Aside: My understanding is that placing modified BtS map scripts in the PublicMaps
folder lets the game remember (through CivilizationIV.ini) the most recently
played map even when no mod or a different mod is loaded. However, the
PrivateMaps get listed at the very top of the Custom game screen, and I don't want
(only) the non-BtS scripts on top. I've been careful only to modify BtS scripts that I
think are worth playing; in particular, Fractal should be at the very top – it's the script I
use most in tests. Scenarios (for what it's worth; AdvCiv has none) in PublicMaps also
get shown on the BtS scenario selection screen when no mod is loaded. (CFC thread
on the subject; “We the People” Git issue)
Tbd. Could put copies of various scripts in the PublicMaps folder; those in PrivateMaps
would still be listed on top. Not how the two folders were intended to be used, but the
effect on the INI file really isn't important.
Rationale
464
AdvCiv BtS
When an AI leader gets to choose which religion Chooses uniformly at random.
to found ("Choose Religions" game option) and
the favorite isn't available (already founded or
none specified), that leader chooses the religion
with the cheapest tech requirement.
Rationale If the preference of the leader can't be matched, at least try to match the game year
by picking religions in chronological order.
AdvCiv K-Mod
While preparing war against a civ, AI missiona- War plans don't affect AI religion spread.
ries tend to avoid spreading religions to the war
target. No religion spread when war is imminent.
Tbd. Merge parts of CvPlayerAI::AI_missionaryValue and CvUnitAI::
AI_spreadReligion into a single target evaluation function. Not an easy task
because they implement the same ideas differently and the results aren't on the same
scale.
For the three early religions, reduced the impact K-Mod has tweaked this part of the AI, making
of randomness, turn number and city count on the AI less interested in founding religions in the
the religion tech evaluation; instead considering very early game. Tends to found religions around
happiness needed in cities (i.e. in the capital) andthe same time as the AdvCiv code – albeit for
the need for border expansion (in the 2nd city, less rational reasons. BtS often founds religions
though the capital will also help). As a result, an so early that, even when starting with Mysticism,
AI civ will usually go for a religion tech around thegoing straight for Polytheism or Meditation is a
time that it founds a 2nd city. (AI flavor values still gamble for human players.
play a big role too.)
Rationale The rational time for founding Hinduism or Buddhism is, in my estimation, when the
Holy City becomes useful for expanding the borders of the second city or when the
capital nears its happiness cap. That usually leaves enough time for researching
worker techs and Bronze Working. If the AI is too aggressive about founding religions,
then experienced human players won't ever consider founding one; that's the state of
affairs in BtS.
The overall timing is already pretty good in K-Mod, but arguably too random, and not
always in the best interest of the AI.
Once one or two of the early three religions are Such a multiplier already exists, but not
taken, the AI prioritzes getting an early religion specifically for the early religions, and I don't
significantly more. think it has a strong impact.
Rationale So that it doesn't become too easy for human players to monopolize the early
religions. If a human player goes straight for a religion, the AI will somewhat match
that pace.
Increased the impact of favorite AI religions on Favorite religion doesn't seem to have much of
the evaluation of religion techs a bit. an impact, at least not in K-Mod.
Rationale The K-Mod (BtS?) behavior is a bit counterintuitive; I would've expected favorite
religions to matter more.
AI leaders with a favorite religion try harder to AI already avoids founding non-favorite religions,
avoid founding other religions. In particular, they but that doesn't outweigh the affinity for the
try to avoid bee-lining to their favorite religion favorite religion when a tech path will likely found
when that will likely result in founding a different both.
religion first.
465
Rationale Bee-lining to Theology or Divine Right just generally isn't smart and puts the AI
leaders with the respective feavorite religions at too much of a disadvantage. And if
they adopt another religion first, it gets really bad. Aggressive founding of the late
religions by the AI also takes that option away from human players.
See also 192 (civic evaluation of unlimited Artists from Caste System) affects the typical
founding date of Confucianism.
The AI estimate of the probability of winning a Based on the ratio of (known) civs that can
tech race assumes that races are somewhat currently research the contested tech to the total
harder to win when there are many (known or number of civs. I.e. the probability doesn't
unknown) other civs on the map. decrease in larger games
Rationale Relevant for the evaluation of religion techs.
466
So long as a particular religion hasn't spread to Once a turn, each city makes a spread religion
any cities of a player, the per-city spread roll for each connected Holy City.
probability gets adjusted to the number of cities
K-Mod has reduced the impact of (air) distance on
owned by that player: more likely to spread if
the spread probability. There's K-Mod code
that player has few cities, less likely if the player
commented out (was apparently under
has many cities.
consideration) that increases the spread
probability so long as a religion has spread to at
most two cities in the world; this would affect both
domestic and foreign spread.
Rationale To make foreign religion spread a bit less dependent on the recipient's city count. To
make an early trade connection more rewarding and to give civs that are boxed in a
better shot at receiving religion spread.
Perhaps a somewhat needless complication; but, then, the spread formula is pretty
complicated anyway.
The success probability of missionaries starts at Same in BtS except that the decrement per
100% and decreases by 10 points for each present religion is 1/9 for rival cities and 1/11 for
religion already present in the city. This is friendly cities. K-Mod disabled the distinction
equivalent to the K-Mod behavior for cities of size between friendly and rival cities and added a
10. population factor that made success a bit more
likely in larger cities.
Rationale It's not intuitively clear whether large cities should be easier or more difficult to
convert. Just establishing a community of indetermined size ought to be easier in a
larger city, but converting a particular portion of the population ought to be easier in a
smaller city. Converting large cities first tends to be the better choice anyway, so
making large cities easier to convert doesn't make the gameplay more interesting.
The K-Mod code was apparently intended to produce smaller success probabilities;
the actual probabilities seem to be the result of a bug – which I haven't fixed (well, I
did replace it with simpler equivalent code) because I don't think smaller success
probabilities would play better. karadoc lived happily with the bug for the next 7 years
(i.e. until he stopped working on the mod), so he might agree.
See also Git commits introducing the bug: 1 2 3
CFC post by me with screenshots of an Excel table showing the BtS and K-Mod
probabilities; in a spoiler box inside the “Religions” spoiler box.
467
Calendar research cost reduced by 1/7.
Rationale Essentially just unlocks Plantations. It's good that there is a bit of a barrier as
Plantations make happiness much less of an issue for some civs and thus make
Monarchy much less attractive, – but I don't think the speed bump should be this tall.
The old cost was the same as Construction, now the same as Alphabet and
Aesthetics.
Tbd. Move Chichen Itza to Calendar, rename it to Temple of Kukulcan (ToK), move
Mausoleum of Mausolos to Monarchy, give ToK a milpa-themed ability that benefits
cities in the jungle. Mesoamerican agriculture seems like a major omission in the
game, and I don't think the original ability will be missed. Perhaps cleanest to
introduce a new improvement, “Milpa”, using graphics of the Realism Invictus Slash-
And-Burn Farm, requires Jungle, +2 food (i.e. 1 after subtracting the Jungle food
penalty), +1 production, maybe 4 turns to build (6 on hills?), can connect Corn (total
net yield +5 food, +1 production?). I don't think irrigation should matter (jungle is wet
anyway) and the Jungle health penalty should remain – the Maya may have
struggled, at times, with the tropical Chagas disease, and a cap on population density
seems appropriate for shifting cultivation. Would be nice to represent slash-and-burn
more explicitly – through a “Swidden” (or Milpa) improvement that alternates with a
“Fallow” improvement, but that gets either too fiddly or too difficult to implement well.
Even for the simple proposed effect, one should go through feature-bad-health and
feature-yield-penalty checks in the code to find places where the current AI
categorically assumes that Jungle is bad. The AI evaluation of ToK should be
straightforward: count Jungle tiles around current cities and planned city sites. And
perhaps don't chop Jungle while ToK is already under construction. Or is there an
even simpler way to represent jungle agriculture? The current concept feels much like
a Maya unique building, but, then, that's the only way to connect this temple with an
agricultural ability. Or do something else with this wonder entirely? Also not sure about
the yields. Just a lot of food will lead to a lot of specialists; that doesn't seem fitting for
the Maya. Commerce vs. production is hard to say. They did erect a lot of
monuments.
(This is all only tangentially related to the tech cost of Calendar. 300 might still be
appropriate after an overhaul of Chichen Itza – seeing that the Mausoleum is a decent
wonder too, albeit not synergistic with Plantation.)
178 Changes to Apostolic Palace (AP) and United Nations (UN) votes
See also kekm.25 allows AP war votes against voting members.
130f allows embargo votes to sever recent deals.
Tbd. Several gameplay changes, most importantly to the membership rules. The only thing
done so far (apart from kekm.25): A temporary adjustment of the City AI evaluation of
the AP as a vote source. Assigns 0 value when the state religion is shared by no other
civ. Will have to replace that with code estimating the potential for spreading the AP
religion after/ while building the AP. (Don't want to force an AI civ that has just founded
Christianity to spread that religion around before being allowed to build the AP.)
Some players really hate the AP victory. The change to the membership rules will
address this.
See also 115b only counts vote source utility when aiming at a religious victory; that'll also have
to change.
AdvCiv BtS
468
UN and AP don't require Diplo victory to be Can't build AP and UN when Diplo victory is
enabled, but the victory votes do. disabled.
Rationale The AI can handle this. Disabling Diplo victory without disabling all votes is requested
on the CFC forums from time to time (two examples). Seems like players generally
don't dislike voting, just the victory votes, either for reasons of game balance/ fairness
(mostly AP) or because they find it irrational that the AI civs will vote for a rival's
victory. That said, some non-victory AP votes appear to be problematic in multiplayer
(the RtR mod disables them; see under "Miscellaneous" here); will have to disable
them through XML then.
Config Can be reverted through Civ4BuildingInfos.xml. Individual votes can be disabled
through Civ4VoteInfos.xml (though this may break savegame compatibility).
The "None" option in the popup that asks the Not even the Civilopedia explains this as far as I
player to select a resolution explains that this will can tell.
trigger an early election. (Unless the vote cycle is
ending either way.)
Rationale The early-election mechanism is OK, but needs to be communicated to the player.
The force-peace vote requires a non-vassal full The voting member can be a vassal and, then,
member to be at war with a non-vassal voting the master of that vassal will be forced to make
member. peace even if it isn't itself a voting member.
Rationale Shouldn't compel a civ that has no vote in the matter.
469
Rationale +2 production is clearly too powerful, and it doesn't really help that every civ benefits.
Turns Monasteries and Temples into highly desirable buildings. Those buildings are
generally underpowered, but a wonder making them almost overpowered through an
effect that has nothing to do with the primary functions of religious buildings (culture,
happiness) is a cure worse than the disease. Also distracts completely from the more
interesting AP ability – the votes.
Seeing that the AP has an unattractive tech requirement, I do think that it needs to be
buffed a little to remain worth considering for human players. Reducing the production
cost should be helpful; it's a fairly expensive wonder considering that there is no
resource-based discount. But I don't see a lot of leeway for lowering the cost without
making the wonder feel strangely cheap. I've considered adding another ability, one
that only benefits the AP owner, e.g. +3 or +4 espionage from religious buildings, but
the AP already has too much text and too much complexity. The specialists are quite
low-key in terms of complexity and can actually be useful when having just founded
Christianity. In most situations, they don't make the wonder much better, unfortunately.
I've removed a specialist from the Shrines in order to avoid making Priests (feel like
they're) too abundant in the midgame. Priest slots at Shrines are mostly anti-
synergetic, no real loss.
470
Config Civ4BuildingInfos.xml
471
Display don't take into account resources based on the tech available to the tile owner.
unrevealed to the active (human) player.
See also CFC post pointing out that the Yield Display gives away unrevealed resources.
001i: Other info leaks; see the “see also” box there.
Rationale One can still spot improved Copper and Iron on flat tiles because a Mine wouldn't be
allowed there otherwise. That can't be helped I think, and it's not all that difficult to
figure out and, more importantly, fairly easy to spot. In contrast, the info leak for all
owned tiles is easy to fix, obscure and annoying to take advantage of – will have to
scan all revealed owned tiles for a production icon (so long as the owner has Iron
Working and the human player doesn't – which is often the case) or, when playing
without Yield Display, mouse over all revealed owned tiles. I guess an alternative
solution would be to reveal all resources on owned tiles – not a serious consideration;
for starters, it would be very confusing for players who are unaware of the info leak.
183 Effects of forts; rules for city defense modifiers outside of owner's borders.
See also 124 deals with the effect of forts on the trade network.
121: worker AI changes for forts.
AdvCiv BtS
Open Borders allow sea and air units to move Only non-rival sea and air units are allowed in,
through foreign forts, even if the fort owner is a i.e. only units of the fort owner's team or that
rival. team's master or vassals.
Rationale Streamline the rules by making forts more similar to cities. Disallowing naval
movement is also inconsistent with forts allowing rival naval trade to pass through (a
rule that, admittedly, rarely ever matters). Air capacity is counted per team, so that's
not much of an issue (and surely no more of an issue than in cities). One problem:
Unlike a city, a fort can easily be pillaged by its owner (if that were disallowed, the
owner would still have to be allowed to replace the fort with another improvement).
Pillaging a fort could allow a human player to trap a stack of foreign AI transports in a
lake or small inland sea. (Air and sea units inside a fort get bumped out when it's
pillaged; that's OK.) Easier to pull off than through canceled Open Borders – but still
seems like a pretty elusive scenario.
See also 046 makes teleported sea units less likely to end up in lakes.
advc.pf: The fort rule change has made the team-based pathfinding code a bit easier
to write.
I've replaced CvPlot::isCity(bool,TeamTypes) with separate functions (members
of CvTeam and CvUnit) for various aspects of cities, e.g. CvTeam::isCityDefense.
Most of those refactoring changes are tagged with just “advc”.
Tbd. If AI units trapped in a lake ever become a problem in an actual game, perhaps I can
get the AI to unload its transports.
The rules for fighting within the borders of a third party (that is a rival of both war
parties) could use work. Basically such fighting shouldn't be allowed; not plausible.
Can only rebase aircraft to a revealed fort or city. Can find forts and cities in the fog of war by
When a fort gets replaced or destroyed, it is hovering with the cursor in Rebase mode. Other
removed from all players' maps regardless of fog than that, forts are subject to fog-of-war rules
of war. (like all other terrain improvements).
Also address some other info leaks, e.g. the
472
Fortify action recommendation.
Rationale These info leaks get more problematic when Open Borders allow aircraft to enter rival
forts. With the info leaks closed, destroyed forts can't be secret – otherwise aircraft
would be able to move to tiles where a fort had once existed.
Units in an unowned fort tile benefit from all Unowned forts grant +25% tile defense; the other
defensive advantages of forts. defensive advantages are tied to the acts-as-city
ability and apply only to non-rival units: City
defense modifiers (e.g. Archer; also: City Raider
promotion on the flipside), immune to Flank
Attack, immune to targeted attack (Ballista
Elephant).
Rationale Counterintuitive that the 25% apply but not the other defensive abilities. Arguably a
relic from Warlords when the defensive modifier was the only ability. Workers being
allowed to build forts on unowned tiles also seems like a bit of a relic. If the defense
modifier on unowned tiles were taken away, there would be no point in building
unowned forts at all. Through city razing, forts could still end up without an owner
though, and then it would be rather strange that units can't get any use out of an
abandoned fort.
Tbd. Disallow forts building on unowned tiles? Then players wouldn't have to wonder
whether such forts can function as ports or air base (they cannot). Forts that end up
unowned through razing could still grant defensive benefits.
See also 119 prevents chopping on unowned tiles.
Units defending in cities or forts of a third party Units defending in proper cities of a third party –
are treated as city defenders only if that third but not in forts – are treated as city defenders.
party is also at war with the attacker – Open
Borders alone aren't enough.
Rationale To resolve the inconsistency between cities and forts, and part of an effort to make
warfare in third-party territory less unrealistic. In particular, the culture defense modifier
represents (in my book) the support from the local populace and a boost to morale for
defending people's homes – not at all appropriate when the attacker isn't at war with
the city owner.
Tbd. Ultimately, I think I'd like to disallow attacks in the territory of a neutral third party
entirely. Ordering such an attack should bring up a popup asking to declare war on the
third party.
184 Military happiness only from units of the same team or vassal/master
AdvCiv BtS
A city that fears for its safety or that is under Any (non-hostile) units cause military happiness
Hereditary Rule can receive happiness from and count as culture garrisons; even units owned
military units only if those units belong to the by the player that is trying to flip a city can count
same team as the city or to a vassal or master of as culture garrison against the flip chance.
that team.
Only units of the same team as the city owner
count toward culture garrison strength.
Rationale Comes up rarely, but highly counterintuitive when it does. Arguably an oversight
(already in Vanilla Civ 4).
473
185 Changes for mods with modified era progression; tagged with “advc.erai” in the code.
AdvCiv BtS/ BBAI/ K-Mod
Changed some AI code that made use of Era numbers (0 for Ancient, 6 for Future) are
absolute era numbers or era differences in order used pretty commonly in AI code as a coarse
to make it work better for mod-mods with more or measure of the game progress or the
fewer eras than BtS/AdvCiv. technological progress of a particular player or
team. Usually, AI modders have used ratios
involving the current era number and the total
number of eras. Such code can be expected to
work (somewhat) well in a mod-mod with a
different total number of eras. In some cases,
however, only the current era number is used, or
a difference between the current era number and
some threshold or target value.
Rationale I'm aware of only one AdvCiv mod-mod with a different era count – “These Fractured
States of America” (CFC thread), and development didn't get very far on that. There
are plans for a merge of Greek World with AdvCiv (CFC post). So these AI changes
might matter; they should have no effect in AdvCiv itself.
Config Some of the AI code (in the DLL) relies on era ratios. Most of that code is scattered,
so mod-modders can't easily change anything about it (the new function
CvEraInfo::normalizeEraNum covers only a few cases). Hopefully no changes are
necessary. Other AI code uses functions AI_getCurrEra to map era numbers
encountered in a game to the BtS era numbers (between 0 and 6) that the bulk of the
AI code was written for. All the AI_getCurrEra functions ultimately call
CvPlayerAI::AI_getCurrEraFactor. However, it shouldn't be necessary to modify
that function either because it uses era numbers set in Civ4EraInfos.xml. That XML
file also designates some special eras, for example the era (if any) during which the AI
can expect oceangoing transports to become available. Mod-modders should review
those XML settings. They're documented in Civ4GameInfoSchema.xml. (Setting
those special eras in GlobalDefines.xml would've been a bit cleaner, but I wanted to
put all the era-related AI customizations in a single place.)
Credits In part based on this Kek-Mod Git commit. (A small part of that commit has been
adopted directly under id kekm.36.) I've revised a lot more code than
DarkLunaPhantom, but that may have been mainly older AdvCiv code. About half of
the BtS/K-Mod code modified by Kek-Mod I've left alone. Some of it merely replaces
code that was already based on the total number of eras with a call to a normalization
function. That's cleaner I guess, but usually not quite equivalent and, to me, not worth
the risk of breaking something. In other cases, I think it's better to keep using absolute
era numbers. Hard to say sometimes. I expect that a mod with fewer eras is still going
to give players enough time to settle the whole world, so the eras are going to last
longer than the BtS eras. The mod could achieve that through additional techs – or
through higher tech costs. On the bottom line, I would expect some statistics, e.g. tile
yields, to develop within a more narrow span than in BtS when there are fewer eras.
474
095: Option for wide city bars (only the first half will trigger hover text however)
Credits Based on BULL
AdvCiv BULL
Adopted everything from BULL except the "Base Options for everything: health, happiness, hurry/
Values" and "Base Production" info. No options draft help, trade routes, commerce yield, culture
except for the building list (icons/ names/ turns, GP turns, specialist display, building list.
disabled) and those listed above under “see
also.” Endeavored to make the formatting more
compact and more self-explanatory. Minor
innovations: Larger specialist icons; buildings
sorted alphabetically; showing output of
production processes (e.g. Wealth) and showing
stored production (chopping, overflow).
See also Requested only once I think: CFC post (2nd bullet)
Rationale Mostly for completeness' sake; to bring AdvCiv closer to having strictly better UI
support nthan BULL. And I guess players used to consulting the city bar hover text
would miss the BULL improvements sorely – the BtS text misses some obvious
conveniences.
The Base Values/ production stuff is too obscure in my opinion.
186b “Zoom City Details” merged from BULL
AdvCiv K-Mod/ BULL
The city bar help is shown when hovering over K-Mod had not merged this from BULL. In BULL,
the city details button of a choose-production the help text on the Domestic Advisor is shown
popup or a city name on the Domestic Advisor. when hovering over the examine-city button and
Not optional. there is an option to disable it.
Rationale Hover text on the Domestic Advisor gets left-aligned and then obscures then examine-
city button and part of the city name. That's pretty annoying when one is trying to click
on the examine-city button – will have to hit it blindly through the hover text overlay.
This is much less of a problem when attaching the hover text to the city name. May
still take a little bit of getting used to because the cursor will usually be moved across
the city name before clicking on an examine-city button. Hopefully, an option will not
be needed this way. Having the city bar help for every city in one place should be a
significant upside.
475
garrisons) and a city.
061 makes unit help (in the tile hover text) more compact.
476
190b Show custom map options
The values of custom map options are listed on BtS doesn't show custom map options anywhere
the Settings tab (Victory screen) if they differ once the game has started. No way to tell what
from the default. For example, normally, the options were after loading a savegame.
"Cylindrical" (world wrap) is not listed because
that's the default value, but "Toroidal" gets listed.
190c More info about unmet players
Show the initial player count and whether civs Once a game has started (or after loading a
and leaders have been assigned randomly. For savegame), the number of players that haven't
players whose civ or leader has been set yet been met can only be determined by
manually (as opposed to randomly), show that revealing the map. (Well, there are some
civ and leader information even for players that information leaks in BtS; most of which should be
haven't yet been met. fixed in AdvCiv; cf. 077 – Demographics tab.)
Tbd. When playing with the R&F option, the RiseFall component should keep track of
players met by previously active players and show the civs and leaders of those
players on the Settings tab even if they were randomly chosen.
Ignore BUG options for showing civs or leaders In multiplayer games, human rivals are shown on
on the scoreboard if that info would give away the scoreboard even if they haven't been met.
the Random civ or leader of an unmet human The color of the display name gives away the civ
rival. Don't use player colors either. of the rival even if that rival is playing a random
civ. BUG options for showing the leader name
will also give away the leader.
K-Mod already ignores the BUG option that gives
away the leader name (regardless of whether the
leader was already revealed on the Staging
Room screen); doesn't protect the civ name.
Rationale Seems more interesting to keep this information concealed. Provides an incentive for
choosing random civs and leaders, but, in a competitive match, it is probably still far
better to pick a strong leader by hand. I also don't think it's vital to know that a human
rival has e.g. randomly received Tokugawa. So I don't see a balance or fairness
problem with this, and K-Mod had already gone down this road a bit.
477
Rationale Leaders of the same civ have similar personalities for the most part, so, for
maximizing variation in AI behavior, favoring civs with multiple leaders isn't all that
helpful. The main advantage is arguably that humans will receive a greater variety
of traits. (One could argue that repetitive human traits can be prevented by
restarting. I think many players don't like restarting.) The main argument I see
against a bias, apart from simplicity, is that a uniform selection among civs leads to
the greatest variation in unique units and buildings. This is also an argument
against using a greater bias when selecting human civs than for AI civs.
See also Implementation based on 190c
Tbd. BUG option to reRandomizeCivsAndLeaders (CvInitCore) when regenerating the
map. Can use CvPlayer::changeCiv, changeLeader for that. However, the
current randomization code only handles players that have both their civ and
leader set to “Random”. It also bails on various edge-case conditions.
Synchronization: CvGame should pass a random number from CvGame::getSRand
to reRandomizeCivsAndLeaders to avoid including CvGame.h. in
CvInitCore.cpp.
The AdvCiv randomization code also bails when a mod-mod contains any leaders
playable only by the AI or only by humans. This was somehow (don't remember
how) awkward to implement.
478
Tbd. As a K-Mod comment already points out, the BtS code is pretty bad. Should check
for each city whether it can benefit from the specific specialist.
See also 171: Also relevant for the AI evaluation of Code of Laws, and thus affects the
typical founding date of Confucianism. That's what prompted me to make this
change – the AI had been researching Code of Laws, in no small part, for the
religion, but what actually makes it useful early on is the specialists.
131: Misc. changes to AI civic evaluation
194-199 unassigned
479
to Oracle, Great Lighthouse, Parthenon, Statue of Zeus, Mausoleum of Maussolos, Sistine Chapel,
Academy, Sid's Sushi and Civilized Jewelers.
Config These are all XML changes (Civ4BuildingInfos.xml, Civ4CorporationInfos.xml).
Rationale The wonder culture changes aren't a big deal, but they're quite visible and some
players may actually have some of the wonder culture rates memorized. This really
shouldn't be necessary; should be possible to balance things under the hood (which
also helps rein in culture spread from non-building sources). Well – one could of
course take the total culture rate of a city to, say, the power of 0.8 and times a
normalization factor, however, the K-Mod culture spread formula is actually fairly
elegant and almost simple; I'd rather not use such a crude device. Instead, I'm leaving
it at a small tweak to the “free” base culture rate along with my culture decay
mechanism (see under “see also”). This probably doesn't fully offset the K-Mod
changes to culture spread, so ...
I don't think karadoc has stated a rationale for his building culture changes; the
changelog does say, specifically about the religion culture change to Sistine Chapel
“culture is more powerful now; so this building needed to be nerfed.”
I see a problem mainly with wonders dominating border disputes in the early game.
Since tile culture accumulates turn by turn, I don't think any midgame and late-game
culture sources are problematic – unless they work as multipliers. So I'm leaving the
K-Mod changes to Free Speech and Sistine Chapel in place, and partly the changes
to Ancient and Classical wonders, also taking into account the overall power level of
the respective wonders.
(Midgame wonders not having much impact on borders and, for that matter, Culture
victory, is not a good state of affairs. However, substantially increasing post-Classical
wonder culture rates would be a bit outside of the scope of AdvCiv – and should be
accompanied by a change to the 1000-year culture doubling rule.)
I had been meaning to leave the change to Cathedral (only 40% culture rate, only 240
cost) in place because making Culture victory less dependent on religion seemed like
a noble goal. However, I haven't found enough decent measures to balance out all the
ways in which K-Mod hampers Culture victory. I also think that taking 10 percentage
points away merely inches away from religion as the central element of Culture
victories, and a 40% modifier isn't used anywhere else so far.
See also 908b decreases the culture rate of the Creative trait and the Incan Terrace.
201 increases the culture rate of the Great Wall.
251: Removes the culture rate modifier that K-Mod adds to Colosseum. And is
concerned with the balancing Culture and Space victory.
099b: Decay of tile culture, especially on “stolen” workable tiles.
098 increases the base rate of culture spread from cities a little bit. (And changes the
culture doubling rule, but I've reverted that change again, leaving it commented out in
the code.)
172 makes culture from city religions non-cumulative.
Increase the culture rate of Cristo Redentor from 5 to 6.
Rationale To match Statue of Liberty. I don't think players know culture rates of late-game
wonders by heart, so making things a bit less arbitrary should have no downside.
National Park, Red Cross and all Corporate Headquarters have 0 culture rate instead of 2 or
(National Park) 3.
Rationale Streamlining. Those culture rates are negligible in the late game. I guess they were
implemented with a rule in mind that all national wonders produce a bit of culture. I
don't think players will notice or mind if that rule isn't followed in the late game.
480
210 Additional Civ4lerts
See also 135b makes MoreCiv4lerts work in Hotseat
106c prevents Civ4lerts from triggering after loading a savegame
106d changes the default settings for BUG alerts and disables some alert triggers.
127 suspends alert updates during AI Auto Play
071 shows a message when first meeting a rival; configurable on the “Alerts” tab.
ctr adds a city trade alert
I'm not adding a second Alert tab to the BUG menu for the new alerts – the BUG menu is already
huge. Instead, I'm removing BUG alerts to make room; some aren't really useful in a mod like
AdvCiv, others are made obsolete by the new alerts.
Disabled although the space isn't needed yet: "peace treaty", "pending border expansion". I don't
see how the latter could be useful, and the former is subsumed by the "willing to talk" alert.
And I've made the Reminder options a bit more compact.
Tbd. Get rid of the "willing to sign Open Borders" and voluntary vassal alerts. Instead
simply have the AI contact humans right away when it becomes willing (the turn on
which a human discovers Writing will need special treatment). Merge the Permanent
Alliance, voluntary vassal and capitulation alerts in order to make more room.
"<team1> has signed|canceled Open Borders with <team2>."
"You have gained|lost access to a source of <bonus> (now <n> sources)."
"The peace treaty between <team1> and <team2> has ended."
"<team1> is willing to make peace with <team2>."
"Can now|no longer access demographics about <civ>."
"<team1> has discovered <tech> [(trade from <team2>)]. [Obsoleted wonders: …]"
(Try merging this with the tech trade alert. Should then also stop reporting “will no
longer trade” and add a willing-to-talk check like the one for city trades [ctr].)
"<team1> is willing to stop trading with <team2>."
(But what about embargoes that the AI would agree to if the player didn't have any
deals with the target?)
"5 turns have passed since the last revolution; it's again possible to change civics."
"<leader> can be convinced to convert to <religion>."
"The enemy has been spotted near <city>." (Currently, the game reports the same
enemy time and again; should work better as a Civ4lert that remembers which enemy
units had already been visible on the previous turn. Sentry [004l] already works this
way.)
“Temporary [anger_icon] has subsided in <city>.” (idea by CFC user BaneFire)
“The borders of the <civ> Empire have expanded./ Tiles have flipped from <civ1> to
<civ2> control.” (With an indicator bubble. Covering any tile ownership change not
covered by city border expansion and city-founded announcements.)
and possibly:
"A tile near <city1> has flipped to <city2>." (How to describe the tile?)
"<leader1> is now [e.g.]furious toward y (was annoyed)."
“Can cancel this deal with <leader>: you're receiving <item list1> for <item list2>.”
"<leader> has constructed a <building>|the <national wonder> in <city>." (cf. 045)
"You|<leader> have|has overtaken <leader>|you in military power."
"The military power of <leader> has increased substantially over the last 10 turns."
481
(probably too noisy)
"The effect of our counterespionage mission against <leader> has ended."
(requested here under item 11, 4th bullet point)
(A message about enemy counterespionage ending would be difficult because we
only learn that "enemy spies appear to be extra vigilant to our espionage efforts," but
not whose spies, and the durations can overlap.)
"<leader> has acquired the <wonder> of <city>." (The Tbd. under 106 would be
preferable, but an alert that is checked at the end of turn would be easier to
implement.)
Should store AdvCiv4lerts data in savegames. Not challenging to do; just add virtual
read and write functions, call them from CvPlayer and disable the check calls from
Python upon loading a savegame. Actually, it would be best to move the
implementation entirely into the DLL; there's no reason for involving Python. Moving
the original (BUG) Civ4lerts into the DLL would be a much taller order. Don't need to
do that though; I don't think storing the AdvCiv4lerts data in savegames will make any
observable difference, so there won't be an apparent inconsistency with the BUG
alerts.
210a War trades (= hired war/sponsored war/joint war)
See also The RevolutionDCM mod also has such an alert, but I didn't know this when I
implemented the alert for AdvCiv.
UWAI uses a different procedure than BtS/ K-Mod to decide whether to entertain joint-
war offers (but this alert works in any case).
152 shows currently offered war trades on the Glance tab.
AdvCiv BUG/ K-Mod
Triggers when an AI civ becomes willing to No alert about this, but BUG shows a fist icon on
declare war on another civ at the player's the scoreboard when a civ is unwilling to declare
request. war on account of "having too much on [their]
hands." Prior to v1.46, K-Mod did not show this
Shown in the "Trade" column of the BUG Alerts
icon (not even as an option). K-Mod 1.46 reverts
tab; enabled by default.
to the BUG behavior (icon enabled by default).
Removed the "Victory" alerts to make room.
Rationale The K-Mod 1.45 approach (no UI support for joint wars) certainly wasn't ideal, and
bothered some players greatly. With UWAI, “too much on ours hands” doesn#t say
much, so a scoreboard icon or alert specifically for that isn't useful.
The victory alerts seem useful only in HoF games.
Config Can also show an alert when the AI stops being willing to declare war:
ALERT_ON_NO_LONGER_WAR_TRADE in GlobalDefines_advc.xml.
The fist icon can still be added to the scoreboard string (letter 'M') and will work as in
K-Mod if UWAI is disabled – with one small modification: No indicator is shown next to
civs that are already at war; it's obvious that they have “enough on their hands.”
UWAI rejects war trades when already in a war AI refuses war trades when it is in any war,
and the new target is not at war with the sponsor regardless of other circumstances. (This is still
and farther away than the closest current war the case when UWAI is disabled.)
enemy: "We have enough on our hands right
now."
Rationale Need to reduce the amount of messages produced by this alert. War against an
additional target rarely makes sense; the hired AI civ isn't going to send units.
If UWAI is disabled (legacy AI option), then an No alert; just the scoreboard indicator.
482
alert is also shown when the AI will respond “we
have enough on our hands” to any war trade and
when the AI no longer gives such a response.
Rationale An alert seems more convenient; this way one doesn't have to keep an eye on the
scoreboard. The scoreboard indicator may still be useful in addition so that players
don't have to remember which rivals are currently preparing for war.
210b Revolts
Triggers when revolt probability changes from 0 The only way to learn about changes in revolt
to greater than 0 in a city, or when occupation probability is to check the city screen each turn.
(from conquest or revolt) ends in a city unless the
The Pacification alert triggers when occupation
city also needs orders.
ends in a city; the pending version when
Shown in the "City" column, taking the spot if the occupation is about to end. Without the alert,
BUG "Pacification/ Pending" alert. there is no notification about ending occupation,
although a conquered city will ask for production
Until v0.94, the alert also triggered when the
orders when occupation ends (unless the new
revolt chance became 0.
owner has already put something in the queue).
Rationale Now that revolts play a more prominent role (see 099c), an alert is direly needed. The
Pacification alert seems fairly unimportant to me, but I've still included it with the new
alert. Though not the "pending" option; I don't see why one would want that.
No pacification alert when the city also needs orders; seems superfluous then.
210c City founded alert removed
When a foreign city is founded in a tile that is The description says that the alert is triggered
revealed to the player, the game shows a when "a rival founds a city," but I think it also
message about this to the player. No option to works for vassal cities (which aren't rivals).
disable this. No messages about cities founded K-Mod prevented the alert from showing cities
in unrevealed tiles. founded in unrevealed tiles and set it to disabled
by default.
Rationale AdvCiv sticks with the K-Mod principle that unrevealed cities should be secret. No
need for an optional alert then. Frees up space for a new alert (see Tbd. under 210).
See also 106: City-founded messages in replays
ctr: City trade alert messages
210d Third-party resource trades
Triggers when a civ starts or stops trading a Resource trades are public knowledge and can
strategic resource to another civ, and when a civ be looked up on the Foreign Advisor screen.
starts trading any resource to a civ that it was
The BUG Resource Trade alert triggers when an
previously not trading any resources to, or when
AI civ becomes willing to trade a resource to the
the only resource trade between two civs is
player or stops being willing (106 disables the
canceled.
latter part).
Rationale Was helpful for testing 036. Triggers way too often when all started and ended
resource trades are reported. Reporting only strategic resources and the first and last
trade is OK, but not quite as interesting as I thought it would be.
Config Disabled by default. Can be enabled from the BUG menu, Alerts tab, column Trading.
There's also a debug mode for reporting all resource trades, but that can only be
enabled in the DLL (AdvCiv4lerts.cpp).
Tbd. Perhaps this alert should only cover strategic resources; the current scope is a bit
complicated.
483
A "third party" checkbox for an alert about inter-AI tech trades (cf. Tbd. under 210)
could be placed in the same column of the BUG menu.
484
kekm.22 rounds the difficulty setting in multiplayer to the integer nearest to the
average.
126 prevents civs from continuing research paths that start at free tech whose
requirements aren't met (e.g. can't go from free Pottery to Archery when missing the
Wheel).
The new SPaH option takes the spot of No City Razing (NCR) on the Custom Game screen; NCR
moves to the bottom.
SPaH can't be used in scenarios because the Base Points box isn't available on the Custom
Scenario screen.
See also 250c changes the default start points on the Custom Game screen, and increases the
start turn based on the number of start points.
Tbd. Not sure if the default start points are appropriate for later-era starts.
SPaH suppresses the difficulty adjustment of AI start points.
Rationale When playing with SPaH, any free initial items and any AI head start in terms of initial
items should be covered by the start points configured for the AI.
See also 250c disables free AI tech from difficulty setting when using (any) Advanced Start
option.
485
(Just restating what's already described in the
SPaH chapter)
SPaH gives the human civs normal starts with There is no SPaH option; all civs, human and AI,
e.g. a Settler and Warrior/ Scout in the Ancient receive the same number of start points.
era, and Advanced Starts to the AI. If less than
10000 start points are entered, all AI civs get the
same number of points (flat distribution).
Otherwise, if a 5- or 6-digit number is entered,
the AI civs receive unequal amounts of points.
The first 4 digits determine the max number of
points. This is assigned to the AI civ in the
bottommost slot. The last two digits are
interpreted as a percentage of the max. The
resulting min number is for the AI civ in the
topmost slot. The others receive values in
between min and max, linearly distributed and
slightly randomized.
The AI start points can be reviewed on the
Settings tab of the Victory Screen.
Tbd. The unequal distribution is linear between max and min, but also based on pairs that
tend to have similar point values. Originally, this was supposed to make the
assignment of start plots easier. The human civ and the bottommost AI civ were
placed first, and the other civs were evenly distributed in between. This doesn't
generalize well for multiplayer, so I've abandoned it. Given the current start-plot
assignment algorithm, it would be conceptually simpler to use a linear distribution
without pairs.
Config The randomization of start points is configurable in GlobalDefines_advc.xml.
SPaH is factored into the game-end score. More Game-end score doesn't account for Advanced
specifically, the difficulty factor, normally between Start.
0 and 90 (see 250a), is increased based on the
start point distribution. For example, a Noble
game has normally a difficulty of 30; with 1000
start points for every AI civ, that difficulty is
increased by 20, which results in the same score
as a Monarch game without SPaH.
Rationale The end-score function has numerous issues, but I think players still care about it a
little bit as a rough indicator of how well they did. So, the formula doesn't have to be
perfect, but, if start points work as a handicap, they should be accounted for
somehow.
I haven't thought about scoring in multiplayer games – not important enough to worry
about.
AdvCiv BtS
Default number of start points for Ancient-era 600
start set to 400.
Rationale I want this default for SPaH. For regular Advanced Start, 600-800 would be better
(considering that 250c increases start point costs), but this can't be set dynamically.
250c Changes to (regular) Advanced Start
486
No impact of difficulty setting on the human start Extra start points for human civs on low difficulty
points. settings (150% on Settler), reduced start points
on high difficulty (75% on Deity).
AI start point bonuses increased to Set to
Prince 125% 110%
Monarch 145% 120%
Emperor 175% 135%
Immortal 210% 150%
Deity 270% 170%
(and they're actually applied). but aren't applied because of a bug.
AI start point penalty added on difficulty levels
below Noble.
Rationale Want to reduce the number of modifiers that affect start points. Instead of giving
human civs fewer points on higher difficulty settings and AI civs more, I'm giving the AI
civs a lot more. This is also to account for the free AI tech that is no longer granted in
Advanced Start (see below).
The higher amount of start points for human civs on Prince and above is countered by
an increased point cost for units, buildings and cities (see below).
Credits I had at first forgotten (not bothered?) to add an AI penalty on the low levels; added
them after seeing this Kek-Mod commit.
No free initial items in Advanced Start except for No free units, but free technologies from the
the technologies of previous eras when starting difficulty setting are granted in addition to start
in the Classical era or later and civ-specific tech points.
when starting in the Ancient era.
Rationale Shouldn't treat free (AI) tech differently than free units. Obviously, free tech from
earlier eras needs to be granted, so my solution isn't entirely consistent either.
Charge 1.5 start points per production (units, The ratio is 1 for 1. 1 Food (population) costs 1.5
buildings, cities). start points though.
1.5 start points per 1 culture. 1 culture costs 2.5 start points.
Revealing a tile costs 1 start point plus 1 per 2 * (100 + 3 * number of revealed tiles) / 100
every 25 revealed tiles. Advanced Start normally rounded down, i.e. 5 initially.
reveals at least 50 tiles upfront. Although AdvCiv
doesn't count these fully, the cost normally starts
at 2.
Can't reveal Ocean tiles that aren't adjacent to Can reveal any tile that isn't adjacent to a
Coast when starting in Renaissance or earlier. previously revealed tile (no change).
Start point cost for routes and improvements E.g. a Mine costs 24 start points, a Farm 30.
reduced to 67%.
Techs cost 1 start point per research point (no
change).
487
Rationale Units seemed extremely cheap compared with tech. It's not that dangerous because
units can only be placed in cities, and each city has a limit of two military units; still,
makes lots of Workers and Settlers a too obvious choice. 1 start point essentially
corresponds to 1 gold, so 1.5 per 1 production is still a bargain. Should perhaps be 2
for 1 – not sure if there's a good reason to make techs relatively unattractive during
Advanced Start. Similarly, 1 revealed tile per 2 start points is still pretty expensive;
seems better to buy Settlers and found later than to pay some 50 points extra for
revealing the surroundings of a potential city site.
A Mine for 24 is too expensive when a Worker costs 60. Now Workers are at 90 and
Mines at 16.
With cheaper visibility, it could make sense to reveal a diagonal across the entire map
under the BtS rules. That would spoil all the surprises, so I'm prohibiting the oceans
from being revealed.
2 culture per 3 start points is still expensive – except for the first border pop, which I
don't want to turn into a complete no-brainer.
Config Costs for culture, revealed tiles and Worker builds are set in
GlobalDefines_advc.xml.
Start points shown on the Custom Game screen Shown points are adjusted to game era, game
are only auto-adjusted to match the start era. speed (silently) and world size. The impact of
world size is minor; the multiplier is between 80%
All start point costs are reduced based on game
and 120%.
speed.
Rationale A large world isn't necessarily less crowded than a small one. The BtS auto-
adjustment is generally problematic because it overwrites any start point value that
the player may have already entered. Also gets in the way of 250b – don't want the
player handicap to increase with the world size.
The silent game speed adjustment can be a bit confusing – the player ends up with a
start point budget that differs from the value shown on the Custom Game screen. I
think it's a bit more elegant to change the costs instead. Makes no functional
difference (apart from rounding).
Dawn-of-Man Screen always shown. The "since Dawn-of-Man only shown for normal start, i.e.
time immemorial" text and initial techs are only non-Advanced in the Ancient era.
shown when starting in the Ancient era.
While in Advanced Start, players can only infer
While in Advanced Start, scoreboard help text their leader from the text color or by using
shows the player's leader. keyboard shortcuts to access Advisor Screens or
Civ Description (Alt+D).
Rationale Players need to know their civ and leader upfront, especially if it was set to Random
on the Custom Game screen.
The initial techs are meaningless when starting in a later era.
The start turn is based on the number of start The start turn only depends on the start era.
points, more specifically, the maximum and the
mean of the start point distribution. Only applies
when starting in the Ancient era (and only when
the average of mean and maximum is greater
than 500).
Example: If everyone receives 750 points
(max=mean=750) on Normal speed, Emperor
difficulty, then the start turn is 20, i.e. 1880 B.C.
488
Rationale Should match the historical time line better, and, in the case of SPaH, gives the
impression that some of the AI civs have been on the map since 4000 BC, whereas
the human civs are late arrivals.
Config INCREASE_START_TURN in GlobalDefines_advc
No free food when population is added to a city Whenever the population of a city is increased in
through Advanced Start. Advanced Start, half of the city's food store gets
filled. 0 food in newly placed cities.
Rationale Perhaps the free food was supposed to make Granary useful in Advanced Start? But
then the cost for increasing population should also be based on the present food store
(and it isn't). Anyway, the rule is too obscure; no one expects free food when adding
population. If adding population isn't powerful enough, one could always adjust
ADVANCED_START_POPULATION_COST, but 1.5 points per 1 food seems fine now that 1
production also costs 1.5 points.
Credits Kek-Mod (Git commit 1 2)
The Imperialistic trait reduces the point cost for The Imperialistic trait reduces the point cost for
placing cities except for the first city. Settlers but not for cities. Civs are forced to place
at least one city before they can buy Settlers.
When not in Advanced Start, the Imperialistic trait
only increases the production invested in
Settlers, not food. Thus, the production bonus is
closer to 25% in the early game than to 50%.
Rationale Inconsistent to apply the bonus to Settlers and not to cities. No bonus for the first city
because, in non-Advanced Start games, Imperialistic leaders don't get an advantage
from the initial Settler either.
I'm OK with the 50% bonus (rather than e.g. 25%) because Imperialistic is a fairly
weak trait.
Credits Kek-Mod (Git commit); I've only added the exception for the first city.
The AI doesn't spend start points on culture in its The AI expands the borders of every city that it
capital unless it has a lot of points to spend. places.
Rationale The border pop is normally a good investment but not really needed in the capital
(although it's so cheap that this was barely worth changing).
Credits Afforess (RoM: A New Dawn mod); SourceForge revision: link
Tbd. Afforess makes some other changes in the Advanced Start AI code. I think these are
mostly for dealing with very high numbers of start points, say, more than 10 000. A lot
of magic numbers in his code that would probably have to be adjusted to AdvCiv.
Either way, one thing that needs to be fixed: The AI currently places improvements (in
CvPlayerAI::AI_advancedStartPlaceCity) before purchasing any techs. Should
instead only reserve some points for improvements at first (could use the current code
for that; just don't actually buy the improvements) and select and place them after
purchasing tech.
Add “can't be removed” warning to building Add visibility, add city and add culture have such
buttons and to tech tree button in Advanced warnings. Units, improvements, routes and
Start. population don't – and can be removed
throughright click.
Rationale Not obvious that buildings and tech can't be removed. (Could probably allow some of
them to be removed, but I'm not going to bother with that.)
489
Tbd. Should mention somewhere in help text that removal works through right click.
Loading screen hint?
Units that the AI purchases for exploration during Units purchased for exploration receive the
an Advanced Start receive the UnitAIType default UnitAIType. For Warriors, that's “Attack”.
“Explore”. Other units receive “City Defense” if Consequently, the Warriors aren't used for
the city where the unit gets placed doesn't have a exploration but, at best, for patrols, and usually
city defender yet. they just guard the capital.
Rationale It's embarassing when the AI fails to clear goody huts close to its capital.
Credits The city defense part is from the MNAI mod (Git commit)
When an improvement is placed on top of an The old improvement is replaced without any
existing improvement, the start point cost of the refund. The Advanced Start interface also allows
old improvement is refunded. removing an improvement; in that case, the cost
is refunded.
Credits From the MNAI mod (Git commit), which labels this as a bugfix. Fair enough; the
original behavior is inconsistent. Also adopted this fix for a potential issue with
outdated city circles after revealing tiles in Advanced Start.
250d AI unit supply and upgrade cost not affected by game era
The AI advantages that are the same for all The per-era modifier increases most of the AI
difficulty settings, namely the discounts on unit advantages with each passing era.
supply and upgrade cost, are unaffected by the
AI game progress modifier (per-era modifier in
BtS, per game turn since change 251).
Rationale I wanted to apply the AI supply cost modifier to the gold paid for Pacifism (change
912b). The era progression complicates this. And perhaps AI upgrades also happen a
bit too swiftly in the late game on Emperor and above.
It's also conceptually simpler to have these two AI modifiers apply regardless of
difficulty, i.e. also regardless of the per-era modifier (which does depend on difficulty).
Look at them as an acknowledgment that the AI needs to have far more units than a
human player in order to guard its cities.
Note that AI upgrade costs still decrease over the course of a game (on Prince
difficulty or higher) because the upgrade cost is computed based on unit production
cost, and AI discounts on unit production increase as the game progresses.
See also 251 exempts all AI gold costs from game progress adjustments.
250e Fewer AI freebies, especially units.
On Emperor difficulty and Immortal, the AI 2 Scouts; same as on Deity.
receives 1 free Scout.
Rationale To make Scouts more attractive for human civs; especially the initial Scout from
Hunting. I don't think extra AI exploration units are a good way to ramp up the
difficulty. Also note that, on Monarch, most AI civs don't start with Hunting and thus get
0 free Scouts. 0 to 2 is quite a jump when going from Monarch to Emperor.
As for the extra Scout on Deity, it's worth noting that the AI won't use its free Archers
for exploration.
See also 031d: AI exploration behavior in the early game
490
On Monarch difficulty, AI civs that start with Monarch AI civs without Hunting receive two
Archery but without Hunting receive an Archer as Archers, one for defense, one for exploration.
defensive unit and a Warrior as exploration unit. Those with Hunting receive an Archer and a
Those that start with Hunting receive a Scout Scout.
instead of the Warrior.
Rationale A Scout is arguably less valuable than a second Archer, and starting with Hunting
shouldn't be a disadvantage.
On Immortal difficulty, the AI starts with 2 free 3 on Immortal, 4 on Deity.
Archers (same as on Emperor) and on Deity with
3 free Archers.
On Immortal, Barbarian cities start with 3 4, same as on Deity.
defenders.
Rationale That many initial defenders just seem pointless to me.
See also The table in the chapter about the SPaH option lists the AI freebies for each difficulty
setting.
No free Agriculture for the AI on any difficulty Free Agriculture on Immortal (in addition to
level. Hunting and Archery) and on Deity (in addition to
Hunting, Archery and The Wheel).
Rationale It seems that the jump in difficulty from Emperor to Immortal is a bit too big in general;
especially the first one and a half eras are tense, the player is easily boxed in. With
the No Slavery option (912d) enabled, it seems very difficult to persevere on a
continent shared with a single AI civ.
Taking away a free tech seems like the best way to slow AI expansion down a little.
Agriculture has the potential of speeding up a second AI settler considerably; I think
The Wheel (on Deity) is a less explosive freebie, rather steering the AI toward early
Pottery and Cottages, i.e. toward playing a long game.
See also I guess changes to map sizes (137, 165), starting positions (027) and AI behavior
have made it considerably more difficult to establish at least four decent cities in the
early game. Converting AI worker speed increases into a human worker speed
decrease (251) may also have had the (unintended) effect of hampering the early
development of human civs more than that of AI civs.
CFC post of mine (the long paragraph in the middle) about the state of Immortal and
Deity in AdvCiv 0.99 (i.e. before the Agriculture change, but after the Deity Settler
change), linking to two other relevant threads.
No second free Settler unit for the AI civs on The second Settler means that the AI head start
Deity. I.e. the AI starting units are the same as on on Deity is much greater than the (already
Immortal except for an extra Archer. substantial) head start on Immortal. For a
challenge in between Immortal and Deity, BtS
players sometimes remove the second Settler;
that custom difficulty level is sometimes referred
to as “Demigod” (that had also been the name of
an official difficulty level in Civ 3).
See also The Deity research rate set by 251 is adjusted to this change.
491
Rationale With the second Settler unit, Deity wasn't really playable on a normal map with the
default player count as the human player was immediately boxed in.
I'm not sure if Deity is now a reasonable difficulty to play on in AdvCiv. (Ultimately, i.e.
after some more balance changes, I hope that even the most competent players
would be able to find a challenge on Immortal, if not Emperor. Deity would then just
serve as a demonstration of what happens if the AI advantages are increased beyond
Immortal.)
Tbd. Insert a difficulty “God Emperor” in between Emperor and Immortal, and boot Settler?
The total number of levels should stay the same for replay compatibility (see 106i).
I've created a Git branch for God Emperor.
492
lower than in BtS, e.g. just 5% on Emperor (at the Modern era, AI production costs on Emperor
game start). are only about 70% of the normal cost.
The AI discounts for wonders are the the same At game start, the AI receives no production
as for other buildings and units. (Except for a 5% discounts on wonders. The per-era discounts do
production discount on Prince difficulty that apply to wonders.
doesn't apply to wonders.)
The modifier for human city growth only affects The AI city growth threshold is decreased by 5%
the base threshold (20 food) for growing a city. on Monarch, 10% on Emperor, 15% on Immortal
That threshold increases by 2 food per and 20% on Deity; same in AdvCiv.
population regardless of the difficulty setting. The
AI growth modifier works as in BtS, i.e. it also
applies to the extra food from population.
The production (and Advanced Start) cost of For each 1 food that the initial city growth
Settlers is partly affected by the growth modifier threshold differs from 20, the cost for a Settler is
(as in BtS) and half affected by the production adjusted by 5%. Production modifiers don't apply.
modifier. This results e.g. in a cost of 130 on
Deity.
The GP thresholds of the AI are adjusted by the
same percentages as the city growth thresholds.
On the lowest two difficulty levels, human
production costs and growth and GP thresholds
are lowered. Free happiness and health on
Settler difficulty lowered by 1; now the same as
on Chieftain.
Rationale To reduce overcrowding of the map on the high difficulty levels and to match the
increased research costs. If only research becomes more expensive as the difficulty
level increases, the game balance skews toward warfare in a similar way as on
Marathon speed. Perhaps Noble difficulty (on Normal speed) makes it a bit too
rewarding to focus on research, but the human research cost modifier on Deity (now
160%) would definitely be too high without a production cost penalty, and on Emperor
(125%) arguably also.
Similarly, the human costs for growing cities and GP need to match research costs to
an extent. The game speed settings, for comparison, have growth and GP modifiers
too, and also modify Worker speed (see below), Cottage growth, culture level
thresholds, chopping production, hurry production and GP effects. I don't see a need
for making all these values dependent on difficulty; it's actually fine if chopping and
Slavery become less efficient on the high difficulty levels.
Building production costs don't get adjusted as much as unit (and project) production
because the full adjustment would make too many buildings categorically unusable on
Immortal and Deity. Buildings tend to provide predictable but slow returns, which isn't
good enough on the highest difficulty levels. Also, keeping relatively high AI discounts
on (non-wonder) buildings isn't much of a problem; won't contribute much to Stack of
Doom problems.
No production/ growth/ GP penalties on the medium difficulty levels because a small
(say 5%) increase would be barely noticeable due to rounding (see next blue box).
Given the lower AI production discounts, exempting wonders should no longer be
necessary. I'm only doing it on Prince to differentiate Prince from Monarch; these two
levels would otherwise have the same AI production discounts (5%).
The human growth penalty is applied only to the base food needed for growth
because I want to keep the formula for the food per population simple (2 food per
493
population, same as the food consumption). For the AI, simplicity isn't so relevant, and
a growth bonus that applies also to the food per population helps the AI in the
midgame and late game.
The GP discounts and penalties make the high difficulty levels harder and more unfair
than in BtS. Changes to the per-era modifier (see below) might even this out.
Config I've added tags TrainPercent (for units), ConstructPercent (for buildings, incl.
wonders) and CreatePercent (for projects, incl. world projects) to
Civ4HandicapInfos.xml. These apply to all civs that play at the respective handicap
(AI civs play at Noble unless a scenario gives them a different handicap).
For GP and growth thresholds, I've added GPThresholdPercent and
BaseGrowthThresholdPercent (for all civs) and AIGPThresholdPercent (for AI
civs).
See also Since these modifier changes don't affect Barbarians, change 300 decreases the
Barbarian activity on the high levels a bit.
101 gives AI-owned cities a somewhat smaller revolt chance. This stacks the game a
bit further in favor of the AI (but I don't think it's a significant factor overall).
Tbd. I'm not sure if the Processes (e.g. Wealth) need to be difficulty-adjusted. When both
research costs and production costs increase with the difficulty level, one would think
that the conversion rate between them can stay the same. But I think there's still a
problem of buildings becoming less attractive as the difficulty level increases, and the
processes are generally recognized as more efficient than buildings, so perhaps
something like 100% Prince, 90% Monarch, 80% Emperor, 75% Immortal, 70% Deity,
maybe coupled with a 20%(?) boost at Computers. Perhaps not good to punish
players for running out of things to produce in the endgame.
City maintenance and unit cost modifiers increased a bit on difficulty settings below Emperor. Free
wins against Barbarians reduced by 1, meaning that Noble is now the highest difficulty level with a
free win (was Prince in BtS). Slightly reduced tech costs on Noble difficulty to keep the pace of the
game the same.
Rationale/ 708: Aimed mainly at experienced players that combine a medium difficulty level with
See also the R&F game option or some other special-challenge game option.
Since AI civs plays on (player handicap) Noble difficulty, this change hurts them a little
and thus makes it a little easier to compete with them on (game handicap) Emperor
and above. Shouldn't make a big difference though – due to the AI discounts on
Emperor and above, AI expenses should still be pretty painless. Hopefully, a single
free win on Noble is still enough to keep the AI out of trouble in the very early game.
Unlike the other human production penalties, No modifiers for human project costs. The AI
those for team projects only apply on Immortal modifiers for projects are equal to those for other
and Deity difficulty. On Emperor and below, the types of city production.
AI receives higher team project discounts instead
(the same as in BtS or similar).
Rationale Don't want to make Space victory even more grueling than in BtS. See
CultureLevelPercent below about balancing Space and Culture victory.
Human worker build times are increased by 10% Human workers aren't affected by the difficulty
on Emperor, 15% on Immortal and 20% on Deity. setting. The AI work rate bonus is 10% on Prince,
The resulting build times are rounded down to to 20 on Monarch, 50 on Emperor, 75 on Immortal,
a multiple of 50 before modifiers from game 100 on Deity. Build times aren't affected by
speed and start era are applied. The AI work rate difficulty. Since the base build times (e.g. 200
bonus is 5% on Prince and increases in steps of time units for Road) are a multiple of the work
5 percentage points to 25% on Deity. rate of the Worker unit (100), even a 1% build
494
time penalty results in at least one extra Worker
turn for all builds.
Rationale In the very early game, build times should somewhat match research times, especially
for human civs. Otherwise, civs that don't receive any free worker tech can become
unplayable and players can't afford to research any other techs. Also, the very fast AI
work rates in BtS can help the AI get ahead too fast and could provide an extra
incentive for attacking AI Workers.
Later on, quick AI build times mostly mean that the AI quickly improves and routes
every tile, which looks ugly and rather unintelligent.
Given the way that the number of build turns is calculated, a work rate penalty would
result in an extra turn for everything; something smoother is needed so that e.g Road
can still be built in 2 turns, but Farm may require an extra turn. The build time increase
with rounding, albeit complicated, accomplishes that. Work rate bonuses are fine in
this regard.
Config New XML tag BuildTimePercent in Civ4HandicapInfos.xml
Human production and research costs and GP Human production costs and GP thresholds are
thresholds are rounded to the nearest multiple of only modified by game speed and these
5. modifiers usually result in multiples of 5, though
e.g. an Archer costs 37 production on Epic
speed. The research cost modifier from difficulty
can result in odd research costs.
Rationale Easier to remember and calculate. The game balance isn't so delicate that +/-2
production will make a big difference.
The AI discounts on production costs, research Whenever an AI civ enters a new era, its
costs and city growth thresholds increase by 1 discounts on production costs, city growth,
percentage point every 100 turns on Prince expenses (inflation, civic upkeep, unit cost, unit
difficulty, every 50 turns on Monarch, every 33 supply), unit upgrades and war weariness are
turns on Emperor, every 25 turns on Immortal increased by (multiplicative) 1% on Prince, 2%
and every 20 turns on Deity. If the game doesn't on Monarch, 3% on Emperor, 4% on Immortal
start on turn 0, these increments are applied and 5% on Deity.
retroactively, i.e. the current game turn is
decisive, not the number of elapsed game turns.
Also, the numbers are adjusted to the game
speed setting (to VictoryDelayPercent to be
specific). These increments based on the game
turn replace the BtS per-era modifiers.
See also 250d: AI unit supply and upgrade costs are independent of the game progress.
Rationale The per-era mechanism is self-reinforcing because the sooner an AI civ reaches a
new era, the sooner it benefits from increased discounts; such snowball effects are
undesirable. Using the game era instead of civ era would also be problematic
because of possible human manipulation, and any average gets distorted by vassals/
small civs. The game-turn-based mechanism doesn't have these problems and works
more smoothly. One potential issue is that high-difficulty games tend to reach the
endgame eras earlier than low-difficulty games, meaning that the game progress
adjustment may not take full effect. However, the current difficulty-based research
cost increases seem to be quite effective at giving games across all difficulty levels a
similar length.
Now that AI research costs are affected by the difficulty setting, it's conceptually
simpler to adjust the AI research cost to the game progress than to adjust the various
expenses. Also, lower expenses have side-effects on the civics that the AI chooses
495
and how many units it trains. As for war weariness, I don't think that's an issue for the
AI even in the late game. As for GP thresholds, I worry that progressively lower
thresholds would draw too much attention to the AI discounts (as every GP birth is
announced).
Additive modifiers seem a bit simpler to me than multiplicative ones and lead to fewer
rounding artifacts.
I'm not sure if these changes lead to higher or lower AI bonuses overall. For example,
if an Immortal game reaches the Modern era by turn 350, the AI growth (threshold)
modifier is now (85-350/25)%=71%; in BtS it's 85%*(100-5*4)%=68%, but also 71%
just before entering the Modern era. It seems that the BtS effect is generally a bit
greater. This should be evened out by the new GP threshold discounts/ penalties.
Config I've renamed AIPerEraModifier in Civ4HandicapInfos.xml to
AIHandicapIncrementTurns and changed its semantics, so it's not possible to return
to the BtS mechanism through XML.
(Human) civic upkeep increased on all difficulty The civic upkeep modifier is 5 to 10 percentage
levels below Monarch; now the same progressionpoints smaller than the inflation modifier. On
as inflation. Monarch and all levels above, the inflation
modifier is 100%.
Rationale Civic upkeep is generally too insignificant.
See also 570 deals with other changes to expenses.
Config CivicUpkeepPercent in Civ4HandicapInfos.xml
The AI civic upkeep and unit cost modifiers on 60%
Deity are 75%.
Rationale Don't want the Deity AI to favor high-upkeep civics and don't want to encourage it to
train very large armies.
Config AIUnitCostPercent and AICivicUpkeepPercent in Civ4HandicapInfos.xml
On Monarch and above, culture level thresholds Culture level thresholds are only adjusted to
(except “Fledgling”) are adjusted to the game's game speed and the “No Espionage” option
difficulty level. (disabled by change 309).
Rationale If tech costs are increased, then the Legendary culture threshold will also have to be
increased (though I guess not as much?) to keep Space and Culture victory balanced.
No special adjustment for the AI; I reckon that the other AI advantages give the AI a
sufficient edge when it comes to Culture victory, and explicitly making a victory
condition easier for the AI would be (perceived as) a new quality of AI “cheating.”
Tbd. Not sure if the base value of 50000 (set in Civ4CultureLevelInfos.xml) is well-
balanced. The tech cost changes under 910 have made Space victories costlier, but
K-Mod has nerfed various important culture sources; so perhaps it's OK. In any case,
I'd like to keep it at 50000 and instead nerf or boost the available sources of culture.
See also 252 removes the speed adjustment for the victory delay after the launch of a
Spaceship.
Config CultureLevelPercent in Civ4HandicapInfos.xml
See also 126 adjusts the culture level thresholds to the game's start era.
AdvCiv K-Mod
Great Work (“culture bomb”) culture increases by Starts at 0 culture in the Ancient era, then
700 per era (of the owner of the Great Artist), increases by 800 per era. (4000 flat in BtS, i.e.
beginning with the Ancient era. regardless of the era.)
496
And hover text for the Great Work button shows K-Mod has changed the ability text in Civilopedia,
the culture per era. but the action button only shows the total culture
based on the current era.
Rationale The K-Mod change is apparently aimed at border spread, and it's probably true that
4000 culture in the Ancient era is – perhaps not overpowered compared with, say, an
Academy – but not well-balanced and not enjoyable to play against. However, when
focusing on a Culture victory by the midgame, the reduced culture is quite an
impediment. While, in my opinion (from a game designer's point of view), teching to
the Modern era should be the standard approach when playing at a challenging
difficulty level, teching only to the Industrial era should also be worth considering. I
think the K-Mod progression hurts that approach a bit too much. (Making settled Great
Artists a more worthwhile alternative would be noble goal, but I don't think it's close
even with the K-Mod progression.) Starting at 0 culture in the Ancient era also seems
wrong to me for mod-mods (in BtS/ AdvCiv, an Ancient Great Artist is impossible to
obtain).
Config iGreatWorkCulture of UNIT_ARTIST in Civ4UnitInfos.xml.
Tbd. Shouldn't be tied directly to the owner's era but to something smoother, like the other
Great Person effects. Because, so far (and in BtS), players don't need to plan for era
transitions and don't need to be aware which techs will trigger them. I'd rather keep it
this way than clutter the UI with easily visible info about tech eras.
Should announce clture bombs in revealed cities (also in observer mode): “The Great
Artist Homer has dedicated his masterpiece to the city of Beshbalik.” With a Great
Work button icon, perhaps a sound too (or play that only for the city owner).
AdvCiv BtS
Decreased the base threshold (Prince difficulty The threshold is 50k on Normal speed, three
and below) for Legendary culture a bit – except times as much on Marathon, 1.5 times on Epic
on Quick speed, where the threshold is now and 0.5 times on Quick speed.
about 2/3 of the Normal-speed threshold. Also
increased the thresholds for all other culture
levels on Quick speed.
See also Discussion with crullerdonut about Culture victory (starting after the 5th quote box)
910 increases late-game tech costs and reduces research rates
Rationale Given the current tech costs and research modifiers in AdvCiv and the +1 research to
specialists at Scientific Method, the rate of tech discoveries in the late-game should
be about 75% of the BtS rate. The typical culture modifier when going for a Culture
victory in BtS is 100 to 150 from 2 to 3 Cathedrals, 100 from Free Speech, 50 from
Broadcast Tower; that's 250 to 300%. In AdvCiv, that modifier is 80 to 120(*) plus 50
plus 50 = 180 to 220%, i.e. ca. 72% of the BtS rate.
This sounds almost well balanced assuming that research is the bottleneck for a
Space victory – and assuming that Culture vs. Space is fairly well balanced in BtS, i.e.
that researching all the techs that a Culture victory doesn't require tends to take a
player focused on a Space victory about as long as it takes a Culture-focused player
to accumulate 50k culture after cranking up the culture slider.
The main factor that does seem to make Culture victory more difficult overall in
AdvCiv than in BtS is that UWAI makes it more difficult to avert late-game wars
through diplomacy; that may make it unviable to deprioritize research at the end of
Renaissance. Civilized Jewelers at Corporation can't make up for that (not sure if it's
worthwhile for a Culture victory at all).
I would prefer to balance this out by slapping +25% culture on some secular building
497
(making Culture victory a bit less dependent on religions), like K-Mod did with
Colosseum – but Colosseum really shouldn't be a source of culture; don't want to blur
the distinction between amphitheaters and theaters. Another candidate is Market, but
that's also strenuous, and, since capitals usually construct a Market before long, it
would further increase the culture pressure from capitals, which already seems rather
too great. Theater would be the most intuitive place, but then the building should
either not grant flat culture or be a good deal more expensive. Either change would
make Theater far less attractive in recently conquered cities.
For lack of a better alternative, I'm adjusting the Legendary threshold. The difficulty
adjustment already means that 50k is no longer a number that players can rely on, so
I don't feel too bad about this.
(*) In AdvCiv 1.0, I've restored the Cathedrals to 50%. The calculation above doesn't
take into account that religious culture from Sistine Chapel no longer doubles and that
Great Artist culture is only 3500 (after an adjustment on my part, would've been 3200
in K-Mod) unless the player techs into the Modern era. Moreover, if the player stops
teching at the onset of the Industrial era (which I'd like to remain a consideration), the
+50% culture from Broadcast Tower also can't be counted.
Quick speed: All the speed-adjustments relevant for producing city culture seem to
use a multiplier of 67%, and the CFC posts that I was able to find on that topic paint
Quick-speed Culture victory as a rather cheap way of winning. Seems that Firaxis
went with 50% simply because that results in more aesthetically pleasing (and
perhaps more easily remembered) numbers.
Apart from Legendary, culture levels on Marathon All culture level thresholds are fully adjusted to
use the same modifier as unit production, i.e. the Marathon tech costs, i.e. three times as high as
thresholds are only twice as high as on Normal on Normal speed.
speed. Legendary uses a 225% adjustment.
See also 252 decreases the tech cost modifier to 250%, meaning that culture level thresholds
had to decrease to at most 250% of the Normal-speed thresholds.
CFC post of mine (toward the end) arguing that it takes way too long for borders to
pop on Marathon. This also made the modified (908b) Creative trait especially
powerful on Marathon.
Tbd. Not sure about the Legendary threshold. 200% would seem to boost Culture victory
too much, but 225% smoothens the progression a bit and, more importantly,
compensates for the high building production costs on Marathon. Jorunkun calls
Culture victory a dominant Marathon strategy already with the full speed adjustment
(CFC post).
Config Through Civ4CultureLevelInfos.xml, except that the Creative traits gets scaled
accordingly through CvGame::freeCityCultureFromTrait and
CvGameTextMgr::parseTraits.
498
130p: AI memory about trades
Tbd. Should war weariness (WW) be adjusted somehow? I would tend to slow down decay
on slower game speed, but players seem to find WW already more painful on
Marathon than on Normal speed solely – I'm guessing – because Marathon
encourages constant warfare.
AdvCiv BtS
Tech costs on Marathon speed are taken times 300% greater tech costs and pretty much
2.5. All other 300% speed modifiers are also everything else except unit production and
reduced to 250%. Game year progression Golden Ages. I.e. twice as slow as Epic speed.
adjusted accordingly.
Config Civ4GameSpeedInfos.xml – not all too difficult to revert; I've left the older (AdvCiv
1.06) game year progression (cf. 910) in place as a comment.
Rationale Twice as slow as Epic – which is only 1.5 times slower than Normal speed – was an
extreme decision when patch 1.52 added Marathon speed. I don't doubt that some
players wanted something substantially slower than Epic speed, but I don't think it had
to be this slow. 1.5 times slower than Epic speed might have been about right – that
would be 225%. As usually, I'm splitting the difference between what I think is right
and what BtS does. (Also, perhaps through faster diplomacy and faster consolidation
of territory, tech progress on Marathon seems faster than the 250% would suggest.)
The bigger issue than just taking forever and giving military strategies all the time in
the world is that BtS makes buildings 50% more expensive than units. This makes
most buildings pretty clearly bad investments. I'm reducing that gap to 25%. That's still
bad; buildings really can't afford any cost increase relative to units. But I don't want to
change the nature of Marathon entirely by giving unit production the same modifier as
building production and tech costs.
I don't really think Marathon fans will mind losing 250 of the 1500 turns (one sixth).
They're still very long games.
See also Related CFC posts: 1 (end of post) | 2 (paragraph starting with “Regarding Marathon”)
See 251 about Marathon culture level thresholds.
Only moderate speed adjustment for victory The victory delay after launching a Spaceship
delay. gets fully adjusted to the game speed setting.
The Victory Delay modifier in XML also gets used
for misc. speed adjustments, also in K-Mod code
(e.g. Global Warming, AI for Culture victory).
Sometimes the Growth modifier is used instead
(e.g. for Advanced Start points).
Config All uses of the Victory Delay and Growth modifiers (Civ4GameSpeedInfos.xml) that
don't actually deal with the Spaceship or population growth have been replaced by
CvGame::getSpeedPercent, which uses the tech cost modifier (iResearchPercent
in XML). For the diplo vote interval, a new modifier has been added to XML.
See also CFC post (after the 5th quote box) arguing against this change.
Rationale Waiting for the Spaceship to arrive is imo excrutiatingly boring already on Normal
speed. My best bet as to why the poster linked to above finds that acceptable is that
Marathon speed requires a lot of patience in general – i.e. there are bigger problems.
Well, I'm addressing those as well.
I was going to remove the speed adjustment entirely, but then realized that this would
make extra SS Thrusters and Engines a bad investment most of the time on Marathon
speed. (And if players don't bother with those, then the victory countdown may not
499
even be shorter than with a speed adjustment.) Making those components a bit less
worthwhile should be OK – players go for them most of the time on Normal speed.
Random event probabilities are (moderately) No such adjustment, i.e. a lot more random
adjusted to the game speed setting. events occur throughout a Marathon game than
throughout a Normal game.
Config Dedicated modifier in Civ4GameSpeedInfos.xml
Rationale The bulk of the events have an economical effect, which should be fully adjusted to
game speed. Few deal with warfare, which should, generally, not be speed-adjusted.
A fair number deal with diplomacy, which should be partly adjusted. And “how things
worked in BtS” always carries some inertia.
Credits Inspired by Civ 4 Reimagined (Git commit)
297 (unassigned)
500
298 Tweaks to opportunistic AI attacks (AI_anyAttack)
AdvCiv BtS
Non-lethal units do not go out of their way to Sometimes, individual siege units move into
attack weaker enemy units – unless there are enemy lines in order to make some attack with
lethal units nearby that might finish the job. high survival odds.
Rationale Even when a non-lethal attack is safe, the attacker is likely to be vulnerable to
counterattacks; not worth it.
Credits CFC user eXalted reported the problem and provided a savegame: here
May change may not have fully fixed the problem; this report (under “questionable
attacks by AI units “) if probably younger than my change.
501
Barbarian activity reaches its peak when 54% a Barbarian activity peaks shortly after they first
continent are owned by civs (or Barbarian cities). appear, typically around turn 50.
With Raging Barbarians, the activity peak is a
little later.
The difficulty setting determines on which turn Barbarians can't appear until there are 1.5 cities
Barbarians first appear. I've very slightly per civ. Thus, the early start turns set for high
increased the start turn set there for Noble difficulty settings through XML have practically no
difficulty and above, but, on high difficulty effect.
settings, they still appear quite early, e.g. after 20
turns on Immortal. They initially appear only in
small numbers though.
Rationale Since Barbarians start slowly, the 1.5-cities rules isn't needed anymore.
I had used 67% until AdvCiv 0.98. That may have matched the time line for the “age of
migration” better, but, considering the higher default player count (137), often resulted
in no sense of urgency while founding a 2nd and 3rd city and made it undesirable to
produce Warriors while growing the capital to size 3. (It's often better to grow to size 3
even if another Warrior isn't needed anytime soon, but it feels bad to produce
unnecessary units.) Before AdvCiv 1.04, I had used 56%, then 52% and 54% in
AdvCiv 1.05 (which, however, has also tweaked the Barbarian start turn and the
conditions for aggressive behavior, see below).
Initially, I had aimed at a gradual increase of Barbarian activity until the early centuries
AD, which coincides with the Migration Period in Europe and the Sixteen Kingdoms in
China. I have since then come to think that it's better for gameplay to have Barbarian
activity recede in the last centuries BC to let the focus shift to warfare between civs. I
think changes to the placement of starting sites (027), in addition to the increased
default player counts (137), have also made it difficult to keep the Barbarians relevant
in the late Classical era; there just isn't enough unobserved space on the map.
Moreover, the lack of Barbarian activity around the time when the civs found their
second and third city gave the civs too few incentives to produce military units, let
alone research Archery, and it was more different from BtS than it needed to be.
That being said, if players configure more sparsely populated maps or if some starting
sites randomly end up being spaced far apart, Barbarians can still get quite fierce in
the early centuries AD, more so than in BtS I think.
The degree of aggressiveness in the behavior of Barbarians have essentially four patterns of
Barbarian units is, apart from city counts, also behavior: (i) One reserved for the Raging
based on randomness, more specifically on a Barbarians option, which causes them to seek
hash value of a unit's “birthmark” – i.e. the out civ cities and form stacks as soon as
behavior stays consistent over the lifetime of a Barbarian units start appearing; (ii) a similar, but
unit so long as no further cities are founded or not quite as aggressive, behavior that is used
razed. As a result of the random element, once the average city count per player (the
aggressive behavior can generally be Barbarians themselves count too, perhaps by
encountered earlier than in BtS. The average city accident) exceeds three; (iii) opportunistic,
counts exclude Barbarians and (in most cases) uncoordinated attacks on cities and
also exclude cities on different continents. improvements, triggered by an average city count
of 2; and (iv) patrols of unowned land, trying to
With Raging Barbarians, most units use their
avoid cities – used when (non-Ranging)
highest level of aggression only as the average
Barbarians first appear (which requires an
city count approaches two (i.e. when a second
average city count of 1.5).
city has been founded by most civs).
502
Rationale To make the changes in behavior more smooth. Can feel like fighting the Borg in BtS
when they all suddenly decide to flock to cities.
Counting only continental cities should make the Barbarian behavior more appropriate
for the local state of development. Probably mostly relevant for the highest difficulty
settings that inevitably cause human players to lag behind initially and the SPaH
game option.
See also 250e reduces the AI freebies on the highest difficulty levels, so the change to the
calculation of the average city count may no longer be justified.
Barbarian ships are created for each continental Barbarian ships are created for each water body;
shelf, i.e. the ring of coastal tiles surrounding usually, there is only one large water body.
each land mass (or enclosed in the case of
inland seas).
Rationale To prevent neglected shores on one continent from affecting Barbarian activity on the
shores of another continent, and to prevent Barbarian ships from piling up near
remote islands (as they sometimes do in BtS).
Tbd. When a shelf is interrupted by sea Ice, Barbarian ships can stile accumulate in
between Ice tiles. Need to treat such pockets as separate shelves (akin to what 030
does). As a temporary solution, no Barbarian ships are placed if the total size of a
shelf is far greater than the number of tiles where a Barbarian ship can legally appear.
(Disabled) When playing with Raging Barbarians The game never tells the player on which turn
(RB), the Barbarian start turn is shown on the Barbarians start appearing.
Settings tab of the Victory Screen.
Rationale When starting in a later era or using SPaH, the game doesn't start on turn 0, and it's
difficult to tell how many turns have passed.
Update (v0.94): Not crucial to know because even Raging Barbarians start appearing
gradually. And after the turn on which Barbarians could theoretically first appear
(based on the difficulty setting), it may take another 10 or 20 turns until a unit actually
enters visibility, so the turn number can be misleading.
See also 251 shows the game start turn on the Settings tab if it isn't turn 0.
503
When computing the target number of Barbarian All land tiles count equally, and water tiles count
land units and cities per continent, half of the only for sea units.
coastal water tiles in the surrounding shelf also
count, and non-habitable tiles are disregarded. I
refer to tiles as “habitable” if they have a positive
natural food yield when ignoring hill yield
changes.
Barbarian units can't appear on non-habitable Tile yields have no impact on Barbarian unit
tiles. On “non-arable” tiles, i.e. tiles with a yield placement.
sum of 1 or 1.5 (counting commerce as 0.5),
Barbarians are far less likely to appear than on
tiles with higher yields. I'm computing the yield
sum twice, once including and once excluding
features, and take the minimum. This way, all
Tundra and Jungle without (revealed) resources
is treated as non-arable.
Civ units only prevent Barbarians from appearing Barbarians can't appear in a 5x5-tile square
on visible tiles. surrounding each civ unit ("fogbusting" range).
Visibility practically doesn't matter.
Animals only appear on tiles with a positive food A passable tile not visible to any civ is chosen at
yield or freshwater. random, then an animal suitable for that tile's
terrain is chosen.
Rationale Want Barbarians to work as a corrective for starting positions that have much room for
expansion. To this end, fogbusting needs to be nerfed, and decent tiles need to be
distinguished from bad tiles.
It's also rather implausible that large numbers of Barbarians would appear in the polar
region or desert. The early civilizations were frequently raided by pastoralists from
marginal (but not desertic) lands, which is why I'm not distinguishing between e.g.
Plains, Grassland and Flood Plains.
“Habitable” tiles: Until AdvCiv 0.97, those were tiles with a positive final food yield
(including terrain, features, hills, improvements). That was nice and simple, but I think
Plains Hill not spawning Barbarians is counterintuitive and treating Tundra Hill
differently than flat Tundra is also dubious.
“Arable” tiles had included river Tundra until AdvCiv 1.0; that seemed like a bit of a
gotcha.
Animals: A problem in Earth scenarios; the Sahara gets filled up with Lions. One could
look at this as a representation of the harsh conditions there, making the desert
difficult to explore, but, ultimately, the lion-filled Sahara looks too silly, and the Sahara
lions prevent animals from spawning elsewhere.
See also Change 304 also affects the per-tile placement probabilities, and the yield-based
changes are implemented based on that.
Barbarian creation rate adjusted to game speed. Target number of Barbarian units and per-turn
The target number of Barbarians per continent creation rate are independent of game speed.
(upper bound) remains independent of game Barbarians start appearing in roughly the same
speed. Barbarians start appearing at a slightly year on all later game speed settings (i.e. on a
earlier year on slower game speed settings (but later turn on slower settings).
still on a later turn than on faster settings).
504
Rationale On Epic and Marathon, it takes civs longer to train units, but Barbarians are
(re-)placed just as quickly as on Normal and Quick. As a result, Barbarians are much
harder to deal with on Marathon than on the other game speed settings.
I think letting Barbarians appear a little earlier (than in BtS) on slower game speed
settings plays a bit better because the civs get done exploring ther immediate
surroundings earlier and are then ready to guard the capital and the site for the
second cities from Barbarians (which, initially, only wander about aimlessly).
The creation rate still does not take into account how densely or sparsely the civs are
placed. It's plausible that more Barbarians appear when there is room for them (and
they make such games less boring), and I want to allow players to create games with
extra tough Barbarians by placing civs far apart.
See also CFC post (paragraph starting with “Regarding Marathon”) where I argue that the
Marathon adjustment should be closer to the unit production modifier than to the tech
cost modifier. AdvCiv 1.07 indeed moves closer to the unit production modifier.
The creation rate of Barbarian cities increases Static creation rate configured in XML.
slightly with the game era.
No Barbarian units are created on continents Plenty of Barbarian units are created on
without civ cities (nor in the surrounding waters), continents without cities because these
but Barbarian cities appear earlier on such continents have 100% unowned tiles. While
continents and more densely than in BtS. Barbarian units are created independently for
each continent, cities are placed globally, and the
If a continent (or shelf) becomes very densely
game prefers to place them on continents with
populated with Barbarian units, the game starts
civ cities.
culling them. The greater the density, the higher
the per-turn probability of removing a unit. The The game might eventually remove Barbarian
Barbarian AI never disbands units for financial units through strike, and the Barbarian AI can
reasons, and Barbarians are immune to strikes. disband units. Not sure how frequently that
happens; perhaps not at all.
Rationale Want terrae incognitae to look more like in Colonization, i.e. with lots of Barbarian
cities but not so many units. The cities actually produce too many units, hence the
scrapping mechanism; it's also a general safeguard against implausibly large
Barbarian stacks. Could interpret the removed units as a result of Barbarian infighting.
Disbanding based on finances isn't good because it may leave high concentrations in
some areas, and because Barbarians aren't supposed to have an overarching
economy.
Tbd. Barbarians can currently be removed from tiles visible to a player, which is a bit
jarring. Should show a message then, e.g. "A Barbarian Galley has been destroyed as
a result of infighting." Can't simply exclude visible tiles from removal: In one game, for
example, Barbarian Galleys kept spawning around an uninhabited continent and
moved from there to an inhabited continent. In such a case, naval stacks of arbitrary
size can form on visible tiles.
Or simply program the Barbarian AI not to move into overcrowded non-city tiles.
Barbarian units are never upgraded. Upgrades are possible using commerce from
Barbarian cities but seem to happen rarely
because resource requirements are checked
when upgrading; cf.
505
Rationale Don't want a Barbarian economy. Outdated units are still killed eventually, either in
combat or removed by the scrapping mechanism above. A mixed bunch of Barbarian
units is more flavorful than a uniformly upgraded army; I imagine that Barbarians
acquire sophisticated weapons from the civs (through trade) but also continue making
their traditional weapons.
It can happen that civs keep trained and spawned Barbarians on a continent in check,
thus preventing scrapping, but don't attack (all) the Barbarian cities. Then, early-game
garrisons will remain unupgraded indefinitely, which starts looking weird once the
Barbarians reach Gunpowder. Too rare to worry about.
Some tweaks to the probability distribution of Unit AI types for units produced in Barbarian cities.
Overall higher probability for offensive AI types, and reduced probability for types that are already
overrepresented in the city.
Rationale Mainly to slow down the accumulation of Barbarian defenders in cities that the civs
have trouble conquering. Barbarian cities with large garrisons are implausible and,
before long, prevent Barbarian units from being created in more interesting places.
Fixed two BtS bugs that lead to Barbarian cities being placed either in completely arbitrary
locations (like an ice island without seafood), or in ideal locations (as far as the AI is able to figure
those out).
See also Thread on CFC
Barbarians avoid approaching civ cities on With RB, the Barbarians usually seek out cities
continents with more Barbarian cities than civ right away. Without RB, only the number of civ
cities. cities is decisive, not the ratio of civ cities to
Barbarian cities.
Rationale New World Barbarians shouldn't immediately attack colonies. Now only turn
aggressive when half the continent is colonized.
Barbarians that look for a city to attack ignore the Barbarians have a per-landmass target city like
per-landmass target city of the Barbarian player all other players. Units looking for a city to attack
unless there is at least one Barbarian city on the try to either attack that city directly or to capture
landmass. nearby cities.
Rationale I haven't looked into the details, but I expect that computing a target city for a player
without local cities would have a pretty arbitrary result that would lead to arbitrary (and
possibly unfair to the owner of the target city) Barbarian behavior.
Not sure what else the target city is used for, so it seems safer not to just set it to NULL
for landmasses without Barbarian cities.
The above is obsolete. As of v0.99, Barbarians don't have a per-continent target city
at all.
See also The “More Naval AI” mod increases the impact of randomness on the choice of
Barbarian target cities. (Git commit)
For Barbarian units, the survival odds threshold for attacking from within a Barbarian city (“leave
attack”) is halved.
Rationale When an AI civ brings an inadequate attack stack to a Barbarian city, there is often a
lengthy standoff (since they can't make peace). This change may help a bit. That said,
Barbarian Archers will often have near-0 odds, so I doubt that this change will make a
big difference.
506
AI civs use (at most) small stacks of a couple of Normal choke behavior against Barbarian cities.
units to “choke” (pillage, block tiles from being Sizable stacks may camp indefinitely next to a
improved or worked) Barbarian cities that are too Barbarian city on a hill defended by a few
well defended for an attack Archers. (Whereas, against an enemy civ, a
peace treaty will often break the stalemate.)
Tbd. Perhaps Barbarian cities shouldn't be choked at all; I don't think they rely on improved
tiles much. The main benefit that I see is that the (quite aggressive) Barbarian tactical
AI may launch premature sorties; so choking might help keep the Barbarian unit count
in check.
I'm also not sure if the choke routine is the only code responsible for standoffs at
Barbarian cities.
Barbarian Workers don't connect cities with Barbarian Workers build road networks between
roads, chop fewer Forests and prioritize Barbarian cities and builds lots of Cottages.
production.
Barbarian cities can't trade along rivers, coast Once they obtain the required techs, the
and ocean tiles unless they own those tiles. Barbarians get to trade along unowned tiles just
(This change doesn't apply to savegames like every civ.
created before AdvCiv 1.05.)
Rationale A road network makes it look like a Barbarian empire, but it's supposed to look like
independent cities. Cottages are nice for pillaging, but don't make much sense for the
Barbarians. Chopping: Don't want players to discover a deforested New World.
See also Kek-Mod has made a similar change (Git commit 1, 2, 3); haven't merged it because I
still want Barbarians to build some Cottages.
Brief CFC post about the water trade change.
Tbd. Barbarian Workers still tend to gather in a single city once all tiles are improved.
If RB is enabled, AI civs assign fewer units to The AI defends its cities against Raging
guard cities unless threatened militarily by Barbarians but doesn't defend crucial
another civ. New AI routine for guarding high- improvements.
yield improvements against Barbarians.
Often allows Barbarians to move onto Mines or
onto improvements across a river, negating the
25% combat bonus that the AI gets against
Barbarians on all difficulty levels.
Rationale Also frees up units for guarding future city sites, which is similar enough to human
fogbusting.
Tbd. Doesn't help much. Early on, when it matters most, the AI still needs most of its
defenders to protect its cities, and doesn't reliably identify the most precarious
improvements. Would be better to move from the city onto a threatened improvement
only when a Barbarian unit approaches. Need to be careful not to expose AI cities to
Barbarian or human attacks though.
See also 315 gives Scouts a defensive bonus against Barbarians and allows them to guard city
sites.
The AI only guards proper city sites, i.e. tiles that Willing to guard any tile with a positive found
it is presently willing to settle. value. Found values are 0 near tiles that the AI
currently wants to settle, so the guarded tiles are
either proper city sites or sites in an area not
currently worth settling (too remote or too
marginal).
507
Rationale Don't want the AI to guard remote city sites because this rarely helps the AI civ and
may help other civs (by keeping away Barbarians).
See also 031d encourages the AI to keep its exploration units somewhat close to its current
and planned cities. This should make the AI a bit more resilient against Barbarians.
AI may guard a tile adjacent to a proper city site ifOnly city sites can be guarded.
that tile has a higher defensive bonus or visibility.
Rationale The main point of guarding city sites is fogbusting; should prefer hills and forest/jungle
for that. Also avoids telegraphing to humans where exactly the AI is going to settle.
AdvCiv K-Mod
AI Workers avoid tiles adjacent to a Barbarian AI Workers avoid tiles at a hostile border even if
border only if there is a concrete danger. those tiles aren't immediately threatened (as far
as I understand the code).
Rationale A single Barbarian city isn't very likely to disturb Workers or pillage improvements.
And it can take the AI a long time to conquer a neighboring Barbarian city; don't want
to leave tiles unimproved during that time.
AdvCiv BtS
AI civs are more willing to target Barbarian cities AI civs hardly ever conquer Barbarian cities on
on other landmasses when there is nothing else landmasses where they don't have their capital.
to do or when it doesn't take much effort.
Tbd. The AI still attacks Barbarian cities too rarely, even on the same landmass. Just
doesn't have enough city attackers at peacetime. May have to increase the probability
of training city attackers based on number and attractiveness of Barbarian cities,
perhaps through an AI strategy flag for fighting Barbarians/ Minor civs and/ or by
setting the per-Area target city to a non-civ city (currently happens rarely, if ever).
And the AI needs to be more reluctant to attack remote Barbarian cities. (Once this is
fixed, the AI may no longer have to be extra reluctant to raze Barbarian cities; see
116.)
For Barbarian cities on other landmasses, code for preparing and executing small-
scale naval landings is needed. Warfare between civs on maps like Archipelago could
also benefit from this.
AdvCiv K-Mod/BtS
Barbarians raze cities based on the difference In K-Mod, the 10% probability applies regardless
between the city owner's era (1 for Ancient, 2 of population, but closeness to other Barbarian
Classical ...) and the city's population. The cities can reduce the probability.
difference is multiplied with RazeCityProb
BtS used the same procedure for Barbarians as
=10%, the base probability for Barbarian razing. for AI civs, just with 10% increased probability.
I.e., Barbarians only raze Ancient and Classical There were some fairness clauses to prevent
cities when they have to (size < 2), and can raze razing in the early game.
size-2 in the Medieval era and up to size-3 in
Renaissance. I'm capping the era number at
Renaissance.
Rationale Closeness shouldn't matter; different Barbarian cities aren't supposed to cooperate.
Want razing only for flavor reasons; balance-wise, losing a city to Barbarians
temporarily is already big setback.
Config RazeCityProb is in Civ4LeaderHeadInfos.xml.
Decreased the number of tiles per Barbarian land unit and animal on the highest difficulty levels a
bit.
508
See also To match the increased production costs that 251 imposes on the civs.
Barbarians can't suffer from nor cause war I don't think Barbarians are in any way exempt
weariness. from war weariness; it's just unlikely that civs will
incur substantial military losses in Barbarian
territory, so it's rarely going to matter.
Credits Inspired by the (closed-source) BASE mod (v6.3B).
301 Early Spearman fix, no spawning of units older than the previous era
The game creates Barbarian units with resource Only the techs for trading the resource
requirements only once the Barbarians have the requirements are checked, i.e. Mining for Copper
tech that reveals the required resources. This or Iron in the case of Spearman.
only affects Spearman, which now requires
Bronze Working.
Moreover, Barbarian units requiring a resource The same Barbarian units appear on all
can only appear on continents where at least one continents, and the game only checks if the
civ has access to that resource (or where a Barbarians could work the necessary resources,
Barbarian city has access to it). not if they're actually available anywhere.
(Until patch 2.13, Barbarian Spearmen didn't
appear at all.)
Rationale Early Barbarian Spearmen were probably not intended by the BtS developers. The
Bronze Working requirement should make Chariots more useful against Raging
Barbarians.
Barbarian access to resources that don't exist on a continent is highly implausible. It's
also a game balance problem when starting in the Classical or Medieval era. In BtS,
the Barbarians then immediately get horse, bronze and iron units while it usually takes
the AI civs some 50 turns to hook up a military resource.
See also CFC post explaining that I didn't get the implementation of this change right until
AdvCiv 1.0.
The game only creates Barbarian units from the The unit to be created is chosen uniformly at
game's current or previous tech era, i.e. no more random from among the allowed units, including
Archers in the Medieval era. Spearman is treated those from all earlier eras. Obsoletion isn't
as a Classical-era unit because of its resource checked.
requirement. Warriors already stop appearing
once the Barbarians get access to Swordsman.
Rationale Ancient Barbarian units become a pointless distraction at some point.
Archers and Horse Archers have a higher (see above)
probability of being placed than units that require
a metal resource. And tech diffusion of Archery
(once the Barbarians have Hunting) and
Horseback Riding (once they have Animal
Husbandry) happens a bit faster than for other
tech.
509
Rationale With the K-Mod changes to Barbarian tech diffusion, Archers appear not long before
Axemen and Spearmen. This change gives Archers more visibility again and should
make Spearman and Chariot more attractive as anti-Barbarian units. Moreover, in
games where the Barbarians still have space toward the end of the Classical era, their
units seem too well equipped on average. (By the Medieval era, it's fine for all
Barbarians to use metallic armor.)
Barbarian Horse Archers aren't really a thing. By the time that the Barbarians get
them, there is normally little if any land left unclaimed and Barbarian city garrisons
tend to have grown to a size that precludes Barbarian unit placement. This change
may help a little bit with that.
Config The expedited tech diffusion is based on Military flavor (Civ4TechInfos.xml) being 8
or greater. I didn't change the flavor values; Archery and Horseback Riding happened
to already have high military flavor and no other relevant tech does. SO this is a
kludge; could add a new flavor type “FLAVOR_BARBARIAN“ for a more proper and
flexible implementation.
See also CFC post (4th paragraph) suggesting to lower the probability of metal-based spawns.
Horse Archers are only placed in open terrain Apart from land vs. water, local terrain has no
that mustn't be surrounded by too much bad impact on the type of Barbarian unit that gets
health (Jungle, Flood Plains). placed.
Rationale Don't want to complicate things too much, but Horse Archers appearing in the jungle
belt (which may well be one of the few places where Barbarians can still appear by
the time that the Barbarians acquire Hortseback Riding) is jarring.
302 Tech diffusion only from civs sharing an area with Barbarians
Barbarians get research only from civs they Barbarians receive research based on the ratio of
share a landmass with. The specific conditions civs alive that have a given tech to the total
(for a shared landmass) change as the game number of civs alive.
progresses. For the first 100 turns, any Barbarian
land unit on a landmass with a civ city suffices (or
a ship on the surrounding coast), later on, a
single Barbarian city isn't necessarily enough.
See CvTeam.cpp for details. The intention is that
research of New World Barbarians stops once
they're driven out of the Old World.
Update (v0.93): Barbarian research is now only
slowed down when they don't share a landmass
with a civ. (Because Longbowman is arguably a
better representation of American Indians than
Archer.)
Rationale Want the research of New World Barbarians to stop once they're (nearly) eliminated in
the Old World. That way, the New World will usually only have Classical-era Barbarian
units, and occasionally Medieval.
See also 300: Barbarian aggressiveness now escalates based only on local cities (not those on
other landmasses)
kekm.28 grants Barbarians some initial tech in Advanced Start games.
Tbd. If I really want New World Barbarians to have Longbows, I could give Barbarians more
original research capacity (they already have a little, maybe by accident) and give the
Barbarian leader a flavor value that matches the flavor of Feudalism.
303 Never build culture, can't build cultural buildings, found value considers only inner ring
510
See also 003n simplifies some AI code for Barbarians, e.g. just sets espionage and culture
weights to 0.
Barbarians never build culture. Can only build the Can build all mundane buildings except: religious
following buildings: Barracks, Granary, and research buildings, Theater, Security
Lighthouse, Walls, Forge, Stable, Aqueduct, Bureau, Int. Agency and Broadcast Tower.
Colosseum and Bunker. Can expand its borders through Monument (or
Castle); not sure how often they actually do that.
The K-Mod Barbarians immediately expand their
borders by building culture if they have the Music
tech.
Rationale Want each Barbarian city to appear as an independent entity. If they expand their
borders as in K-Mod, the borders can easily touch, and then Barbarian cities appear
like a unified empire.
Aqueduct, Colosseum: Want Barbarians to occasionally have populous cities (think
Tenochtitlan); for that they need all the health and happiness they can get.
See also Important for the New World because change 300 places Barbarian cities more
densely on uninhabited continents. 300 also prevents Barbarians from building a road
network.
Config Buildings are disabled through Civ4CivilizationInfos.xml.
Only the inner ring is taken into account when All 21 tiles in the city radius are considered.
placing Barbarian cities.
K-Mod: There is already some special code for
And some minor adjustments to the computation Barbarian found values.
of Barbarian found values.
Rationale Since Barbarian borders never expand, it doesn't make sense to consider the outer
ring. I also like that this makes Barbarian city sites distinct from normal city sites, and
a bit weaker overall.
See also 300 fixes Barbarian city placement bugs.
Barbarian city placement treats all resources as Resource evaluation as if the Barbarians were a
having equal trade value. proper civilization, i.e. high value for strategic
resources like Iron or Marble.
Rationale Barbarians blocking strategic resources isn't good for gameplay: Civs that lack Iron
aren't in a good position to conquer an Iron source claimed by the Barbarians.
Barbarians near Marble are strange because the Barbarians obviously won't use that
resource.
See also CFC post with an attached screenshot that shows a Barbarian city with Marble as the
only resource in the city radius.
304 Changes to prevent concentrated, predictable placement of Barbarians
synchRandPlot rewritten: If no maximal number Picks tiles at random until it finds one that
of trials is given (iTimeout parameter), then satisfies the criteria, or gives up after 100 trials.
CvMap::syncRandPlot is guaranteed to return a
tile when there is at least one satisfying the
selection criteria. syncRandPlot then returns the
number of valid tiles as well.
511
Rationale Don't want to place a Barbarian unit on every turn (or every other turn) in the same
tile, so a probabilistic failure to return a tile is good. However, the probability for failure
is too high in BtS and shouldn't depend on the map dimensions – if a chance of failure
is desired (it is; see 3rd blue box below), then it should be based on the proportion of
valid tiles in the target area, not world-wide.
Pass a tile weight distribution to synchRandPlot Chooses uniformly at random from among the
(and to Shelf::randomPlot) that gets used for valid tiles; no weights. To make tiles with
giving each valid tile a probability equal to its particular characteristics less likely, one can only
weight relative to the sum of all weights. re-roll them a fixed number of times.
(NB: None of the changes dependent on
placement weights apply to Animals.)
See also Change 300 uses this mechanism to make Barbarian placement in nonarable tiles
less likely. Had used two re-rolls until AdvCiv 1.0, which had the (undesirable) effect of
making placement on arable tiles very unlikely so long as the portion of nonarable
tiles among all valid tiles was small – and not unlikely enough when the portion of
nonarable tiles was large. For example, when 30% of the valid tiles are nonarable, the
chance rolling a nonarable tile three times in a row is only 2.7%. If 70% are nonarable,
the chance of three successes is 34.3%. With the weighted choice method, if we give
arable tiles 5 times greater weight than nonarable tiles, we get a 7.9% chance of
choosing a nonarable tile from among 30% and a 31.8% chance from among 70%.
Rationale Also needed for the change described below ...
Barbarian units are less likely to appear near tiles All valid tiles have the same probability of
where a Barbarian unit was recently killed or spawning a Barbarian unit; the mechanism is
created. memoryless.
Rationale Mostly to avoid excessive and predictable Barbarian activity in a small unguarded
region of the map. Can be too difficult to get such situations under control (for human
and AI civs) and it feels unnatural.
See also 312 provides GG points from Barbarians and thus makes XP farming a potential game
balance issue.
Tbd. Arguably, the target number of Barbarians for each continent (or shelf) should also be
adjusted based on recent kills. That is, if Barbarians get killed off quickly, the creation
rate should decrease. The change above only shifts the Barbarian activity around
within a continent.
When only a small number of tiles remain where The iTimeout parameter in BtS has a similar
a Barbarian unit could be placed, then the game effect – of causing Barbarian placement to be
may probabilistically not place that unit. The skipped when few eligible tiles remain.
probability is based on the number of eligible
tiles, the target number of Barbarian units on the
continent (upper limit) and on the relative
placement weight (see above) of a tile chosen at
random from among the eligible tiles.
Rationale Some mechanism like that is needed, otherwise, Barbarian (re-)appearance can
become too predictable.
512
Patrolling Barbarians take try to avoid (to an Terrain does not affect patrolling Barbarians.
extent) tiles with a small placement weight, i.e. They mainly steer clear of owned tiles. Target
tiles with poor yields or where Barbarians were cities are chosen through the same procedure
recently killed or placed. The placement weight is that AI civs use, i.e. based on how well-
also taken into account for choosing a target city developed the city is and how nearby. Strength
to attack. memory (about garrisons spotted when the city
was last visible to the Barbarians) is also taken
into account.
Rationale Just to reinforce the changes to Barbarian placement a little.
See also 102 makes patrolling units (including non-Animal Barbarians) more likely to move in a
consistent direction.
158: Changes to AI strength memory
Barbarian cities are slightly less likely to occur on Barbarian cities can appear again and again on
landmasses where Barbarian cities were landmasses that civs don't want to settle.
destroyed previously.
305 Barbarian Work Boats
Barbarian cities can build Work Boats, and tend Can't build Work Boats. Usually build Worker
to build them early, i.e. after producing 1 or 2 after 15 turns.
military units. Build Workers a bit later than in
BtS, especially in coastal cities.
Rationale To allow Barbarian cities to grow more population. The original developers had
perhaps been worried that Work Boats would distract Barbarian cities too much from
building military units. To make up for that distraction, I have Barbarian cities build
Workers later.
306 Units spawned on Galleys, Barbarian naval AI
See also The Mongoose SDK PirateMod works similarly but hasn't been merged; I only learned
about this mod component after implementing my own changes.
905a increases the speed of Galley but keeps Barbarian Galleys at 2 moves through
the Disorganized promotion.
Barbarian land units can be placed aboard ships Barbarian land units can only be placed on land
in the fog of far. If there is no such ship, the land tiles, and their AI does not allow them to enter
units are placed on land tiles instead; the total cargo units. Created cargo units only harass
number of Barbarians placed is the same either cities and patrol. Units produced in Barbarian
way. Barbarian ships with cargo target a nearby cities, however, can undertake naval assaults,
city with a naval assault, though the units can which is why naval assaults do happen in BtS,
also be dropped along the way to the target. but very rarely.
Once unloaded, the ships switch back from
assault mode to "attack" mode, which works as in
BtS: Harass a city for a while, then move on and
patrol.
Ships on patrol seek out unobserved tiles where
they can receive new cargo.
Rationale Should make Barbarian sea units more interesting and harder to ignore; allows them
to interact with civs that don't have worked sea tiles.
Tbd. When a Barbarian ship has been on the map for a long period of time, say, 20 turns, it
should stop patrolling and just blockade a city; can get annoying if a player just can't
build a ship for lack of a coastal city.
513
See also 102 makes AI units on patrol more likely to move in a consistent direction.
Damaged Barbarian units gradually heal by Apart from hitpoints received from a received
resting for a turn from time to time promotion, Barbarian units heal only in cities or
(probabilistically). when they can heal fully in one turn. Near civ
cities, badly damaged Barbarian units never
attempt to heal. If they're too weak to make an
attack, they may patrol indefinitely.
Rationale If the civs fail to finish a Barbarian unit off, it should eventually do the smart thing and
heal.
Reduced the cost of Metal Casting (MC), MC is almost 4 times as expensive as its
increased the cost of Optics and (a tiny bit) prerequisite Bronze Working and about two thirds
Machinery. as expensive as Machinery, the tech that MC
leads to. In Warlords, Trireme was at Sailing with
Bronze Working (BW) as an additional
requirement, BtS moved Trireme to Metal
Casting.
See also CFC discussion
The Close to Home multiplayer mod also reduces the cost of Metal Casting.
Rationale To make Trireme easier to access. Also to make Metal Casting more attractive to
research (as opposed to discovered via Great Person or Oracle) in general; earlier
access to an Engineer via Forge is also a plus.
Can't reduce the cost drastically because that area of the tech tree is quite sparse.
Specifically, I don't want to shorten the path to Machinery (a Medieval-era tech) too
much. The path to Optics (via Machinery) is also problematic. Machinery is already an
expensive tech; can't just shift beakers there from MC. Optics had some leeway for a
cost increase though.
Don't want to move Trireme to BW because that tech already does too much (until
such a time that Slavery is moved away; cf. 912d) and because rams were an
essential feature of triremes and did require exactly what the MC tech represents:
casting molds that weren't developed until the first millennium BC. Converting MC into
a copper smelting tech would be too big a change at this time (and, if big changes
ever become a consideration, then there might still be better ways to nerf BW).
307 Post-Medieval Barbarians
514
Barbarian units can be created by the game in all Can only receive and train Warrior, Archer,
eras. Barbarians can receive and train Spearman, Axeman, Swordsman, Horse Archer,
Musketman, Cavalry, Anti-Tank and SAM Longbow, Maceman, Galley. No Barbarian units
Infantry. created by the game in Renaissance and
Cannot train Rifleman, Grenadier, Paratrooper, beyond. Can train Rifleman, Grenadier and
Frigate. As of v0.94, Musketman is the only post- Frigate.
Medieval unit that Barbarians can receive or
train.
Barbarians can't receive cities in Renaissance Barbarian cities still appear in the Industrial era.
and beyond.
Starting from Renaissance, Barbarian research In BtS, Barbarian research always ignores tech
ignores tech prerequisites. prereqs, i.e. Barbarians can research e.g. Pottery
and the Wheel simultaneously. K-Mod has
The Raging Barbarians option creates more changed this, so that Barbarians only make
Barbarian units in later eras: the tiles-per-unit progress on techs that they could research if they
divisor is reduced to 60% in the Ancient era, were a civ.
52.5% in Classical, 45% in Medieval, 37.5% in
RB reduces the divisor to 50% in all eras.
Renaissance, 30% in Industrial, 22.5% in Modern
and 15% in Future (relative to the divisor without
RB).
Rationale Gunpowder units mostly for Terra and similar maps – on normal maps, there is
typically no land left for post-Medieval Barbarians to appear on. Therefore the reduced
divisor for later eras with RB; so that RB players get to see the occasional post-
Medieval Barbarian.
Muskets are supposed to represent natives that have acquired firearms (through trade
or as spoils). Until v0.94, Barbarian Cavalry and (as a fairly ineffective type of infantry)
Anti-Tank and SAM were also allowed. I'm reverting this because Cavalry practically
never appears (requires a local Horse resource to train), and because advanced
weapons like bazookas and MANPADS are jarring in the hands of the Barbarians.
Would have to create custom units for the Barbarians to represent adequately e.g.
mounted post-Columbian Amerindians or Daesh insurgents.
Don't want Barbarians with firearms to be on par with properly trained armies, hence
no Rifle, Grenadier and Frigate.
No Pikeman: Two Medieval Barbarian units (Longbow, Mace) are enough, and I want
mounted units to be effective against Barbarians, especially Cuirs/ Conquistadores.
Barbarian research ignoring tech prereqs allows Barbarians to catch up quickly once
colonies are founded. By the time New World Barbarians turn aggressive, they'll
typically have Muskets. Interestingly, Chronis seems to have had the same idea years
before me (though I haven't checked if he implemented it in the same way).
No Barbarian cities past Renaissance: Seems more realistic, and enough cities are
created in the New World during the early eras.
See also 302 stops Barbarian research if they stop sharing a continent with any civ.
301 lets Barbarians only build units that some civ on the same continent can build.
kekm.6 disables Barbarian Spies.
Marines (or is it Infantry?) as free defensive units Machine Gun as free defensive unit.
in Modern-era starts.
Rationale Can't use Machine Guns to prevent Barbarians from pillaging.
308 Tech costs adjusted to Barbarian settings
515
Increased tech costs for all civs in games with Raging Barbarians in the Classical in Medieval era.
Slightly decreased Ancient and Classical tech costs for all civs in game without Barbarians.
Rationale RB forces the civs to dedicate resources into fighting Barbarians, and as a result,
global research tends to lag behind the historical time line.
516
Animals aren't removed from landmasses without Once the game stops creating animals, it
civ cities (unless the landmass gets too crowded removes one animal per turn from each
with units; change 300). landmass.
Rationale Buffalo flavor for the New World. Once colonized, the animals will start disappearing.
Animals may peacefully enter unowned tiles with Unless an animal attacks, it can't enter unowned
━ a resource if that resource requires a tech to tiles with resources or improvements.
be revealed or
━ an improvement unless it's a goody hut.
May always enter unowned tiles through an
attack (no change).
Rationale The resource avoidance can give away hidden resources; no fun to keep track of this.
Could simply always allow animals to enter resources – it's not like this prevents
players from settling near those resources –, but predators coexisting peacefully with
herbivorous resources could seem strange to some players.
Improvement: I don't think this ever occurs, but animals reclaiming abandoned
structures could be flavorful. Don't want them to block goody huts though.
310 Great Wall reworked, balance changes to Great Lighthouse and Colossus
Config Can be reverted in CIV4BuildingInfos.xml. The abilities that require a game option
are handled by the DLL. That can be disabled in XML by setting the
bConditionalAbilities element to 0 for the Great Wall. Then the Great Wall will
always have whichever abilities are set in XML.
The Great Wall (TGW):
cost 300, Cost 150,
req. Masonry, 2 Walls (1 on Duel and Tiny world Masonry, no prereq. buildings,
size, 3 on Huge),
obs. with Corporation, no obsoletion,
2 Great Merchant points, 2 Great Spy points, [Great Engineer in Warlords]
4 culture, 2 culture,
abilities based on game settings: abilities (ii) and (iii) regardless of settings.
i. +1 trade route in cities on the same continent
except when playing with Raging Barbarians
(RB). This ability is based on a "global trade
routes" ability that was already in the game but
unused. Now restricted to cities on the same
continent.
ii. Prevents Barbarians from entering your
borders on this continent (no change) except
when playing with No Barbarians.
iii.+100% emergence of Great Generals within
owner's borders (no change) if playing with RB
or No Barbarians. I.e. TGW doesn't have this
ability anymore under normal settings.
Can be built on Ancient and earlier starts.
Can be built on Classical and earlier starts.
Rationale A strangely cheap wonder in BtS considering that it represents (arguably) the most
massive building on Earth. Can be costlier now that Barbarian activity peaks later (and
OK to allow it with Classical era start). Removing the GG ability under normal settings
keeps the rules complexity in check (wouldn't be a problem wrt. game balance).
Trade route flavor: One purpose of the Chinese Great Wall was to protect traders.
517
Some segments protected a portion of the Silk Road. Similar to Castles providing an
extra trade route. GM points go along with this, but the goal is also to make the
espionage system easier to avoid for players who wish to avoid it.
A nice side-effect of the Wall prereq. is that Protective leaders get an implicit discount
on TGW. Also makes sure that TGW can't be built before founding a second city –
players should analyze whether they're exposed to Barbarian attacks before deciding
to build TGW.
The Archery req. is to make Archery a bit better, and to make Masonry less cluttered
visually; TGW still requires Masonry for the prereq. Walls. I believe this makes some
sense historically as well – walls (with flanking towers) are much more useful with
effective projectiles. (But this doesn't explain why ordinary Walls don't require
Archery.)
I've removed this requirement in AdvCiv 1.05 because, through changes in that
update and some earlier ones, the Barbarian activity peak has moved from the early
centuries AD to the 1st millennium BC. So the Great Wall needs to be available earlier
again. Moreover, one important purpose of the Archer unit is to fend off Barbarians,
and this conflicts with the Great Wall effect.
Culture rate: Don't want it to be curiously small, but also don't want to speed up border
expansion much because, as soon as that happens, the Great Wall graphic stops
aligning with the cultural borders.
See also Without 140, which changes the formulas for the number of prerequisite buildings,
only 1 Wall would be required on Standard-size maps.
131c decreases the military power value of TGW.
911a adds a Spy specialist slot to Courthouse in order to enable an early Great Spy.
The 3D graphic for the Great Wall on the main Along the full length of the owner's cultural
map is not shown along borders with other civs borders on the same landmass as the Great Wall
and not along unhabitable tiles. Tiles that are city except at the coast.
only adjacent to unhabitable tiles and border tiles
are also excluded.
Config GREAT_WALL_GRAPHIC_MODE in GlobalDefines_advc.xml
Rationale If the Great Wall isn't constructed in the early game, the graphic can get very long in
BtS. Since the (primary effect of) the wall helps only against Barbarians, which don't
normally enter from the territory of another civ, it makes sense to me to omit civ-to-civ
borders. If this means that no wall segments are shown at all, then that's also OK with
me.
The last condition for placing a wall segment is supposed to prevent Gaza-like strips
of tiles enclosed between Great Wall and some other type of frontier or obstacle.
See also “Habitable” tiles are tiles with 0 nature yield when hill yield changes are ignored; same
as for Barbarian placement (300).
Credits I took the idea for the implementation from Leoreth (link). I also took a look at the
Dawn of Civilization code, but it wasn't easily portable.
The Great Lighthouse (GLH):
cost 250; cost 200 in BtS, 300 in K-Mod;
obs. with Astronomy obs. with Corporation
Rationale Too powerful in BtS, at least compared with most other wonders. And I don't like that
this ancient wonder becomes most effective in renaissance (with Astronomy). I meant
to nerf this later on (along with other balance changes), but with TGW obsolete at
Corporation, GLH obsoletion needs to be moved right away.
The Colossus:
518
cost 250 (as in K-Mod); cost 150 in BtS, 250 in K-Mod;
obs. with Chemistry. obs. with Astronomy.
Rationale Don't want both Colossus and GLH obsolete at Astronomy. The K-Mod cost increase
seems reasonable; it's an extraordinarily cheap wonder in BtS.
Tbd. Perhaps Forge should be nerfed instead – if Forges weren't spammed everywhere,
Colossus wouldn't be such a small investment.
Versailles
generates Great Spy points Great Merchant points
Rationale Compensation for the change to the Great Wall. Rather symbolic as Versailles is a
much later and less useful wonder than the Great Wall.
311 Uprising events
AdvCiv BtS
Place 2 units in the Ancient era, 3 in the Classical 1 to 6 units depending on the map size; era
era, 4 in the Medieval era. The era of the player doesn't matter.
for whom the event has triggered counts.
Rationale 4 Vedic Archers on a Standard-size map is too many. And of course the map size
should have no bearing on the number of units.
See also My initial formula had created 5 units in the Medieval era. That was still too many it
appears (and, on a Standard-size map, it's actually more than in BtS): CFC post
The units can only be placed on tiles that are Adjacent to that player's borders.
exactly two tiles away from the borders of the
player for whom the event has triggered.
Rationale To give the player more time to rally troops. Ideally, a player with a reasonable military
should never lose a city to an uprising event (losing one or several defending units is
already more punishing than most contemporary events).
See also The CFC post linked above.
Vedic Aryans can't trigger for any player until at Polytheism
least one civ knows Priesthood.
Credits From BUFFY version 003.
312 XP from Barbarians counts half for Great General
XP from combat against Barbarians counts 50%, XP from Barbarian combat never counts for GG.
rounded down, toward Great Generals (GG).
Rounding down means that 1 XP (i.e. after
combat with very one-sided odds or withdrawal)
doesn't count at all toward GG. Units that already
have 10 XP can't gain further XP from Barbarians
(no change), and thus can't contribute to a GG
either.
XP multiplier for attacking Barbarians reduced to XP multipliers are 4 when attacking and 2 when
3; no change when defending against defending. Can expect to gain 2 XP from
Barbarians. Thus, can't hope to gain more than 1 attacking a Barbarian unit even at 95% odds.
XP (0 GG points) by fighting a Barbarian unit at
odds above 90%.
Upper limit for XP gain per combat set to 6. Can gain up to 10 XP from a single attack.
Consequently, can gain at most 3 GG points per
Barbarian combat.
519
None of these changes apply to Animals.
Rationale As an extra incentive for fighting Barbarians rather than (completely) preventing them
from being placed through fogbusting. It's also not plausible that wars against
Barbarians should produce no GG. Ancient China had plenty of GG that only fought
against peoples that Civ would represent as Barbarians. I'd like to give players a
(fighting) chance to get a GG without starting a war.
The original developers must've been worried about Barbarian XP farming, and for
good reason. Having Barbarians respawn in some cul-de-sac isn't difficult. Can be
worthwhile to exploit just for getting units to 10 XP; which is why I think some
restrictions were needed regardless of GG points.
Tbd. Farming may still be feasible; is a 15% risk of losing a unit worth 2 XP and 1 GG
point? Could be, especially if it's an outdated unit …
Reduce upper bound for per-combat XP to 5 (2 GG points)?
Perhaps apply the XP restrictions to all combat; would like to reduce combat XP in
general in order to lower the stakes in combat.
See also 304 makes Barbarian units less likely to be placed in tiles where Barbarian units were
previously created or destroyed. This should at least prevent XP farming from having
any major impact on the game balance.
520
The combat penalty that animals receive is:
difficulty vs. human vs. AI difficulty vs. human vs. AI
Settler -60% (-100%) -25% (-50%) Settler -70% (-110%) -40% (-65%)
on all difficulty on all difficulty
Chieftain -45% (-75%) Chieftain -60% (-90%)
settings settings
Warlord -30% (-50%) Warlord -50% (-70%)
Noble -25% (-35%) Noble -40% (-50%)
Prince -20% (-25%) Prince -30% (-35%)
Monarch -15% (-20%) Monarch -20% (-25%)
Emperor -10% (-15%) Emperor -10% (-15%)
Immortal -5% (-10%) Immortal -5% (-10%)
Deity 0% (0%) Deity 0% (0%)
The numbers in parentheses include the penalty
for Barbarians, which, as in BtS, also applies to
Animals.
Rationale The total penalty against AI units and the penalties against humans on the medium
difficulty settings seemed needlessly high to me. Losing an exploration unit now and
then won't hurt the AI much and could help delay the first contact between far-flung
civs.
521
Rationale The main goal is to make huts discovered via Caravels or Galleons more rewarding,
and thus also give Explorers a better use. And some of the free techs granted in BtS
are too powerful in the early game – I guess that's why players commonly play without
goody huts.
I'm tying the adjustment factor to the game turn rather than e.g. era because I don't
want players to wait for an era transition before entering a goody hut. That's also the
reason for the flat effects during the first 50 turns. Gold doesn't have any use in the
very early game, so players might decide to let a hut "grow" before entering it.
The power-law function is supposed to mirror the overall economic growth, which is
superlinear. I'm freezing the effects on turn 250 because I don't think that industrial
civilizations can gain that much from visiting or raiding Bronze Age (or Chalcolithic)
villages. "Times 10" is a nice and simple maximal effect (and one can kind of tell that
the maximum is reached when a multiple of 10 gold is payed out).
Config Start turn, peak turn and maximal multiplier are set in GlobalDefines_advc.xml.
The Low gold outcome grants between 15 and The Low gold outcome is between 20 and 60
45 gold, High gold 25 and 85 gold. Replaced one gold, High between 20 and 120. Low is the more
High gold outcome on Chieftain, Noble, Prince likely outcome on the medium and high difficulty
and Emperor with a different outcome, meaning setting; e.g. on Monarch, Low is four times as
that Monarch is the highest difficulty level on likely as High. Emperor is the highest level on
which High gold is possible. The speed which High gold is still possible. The amount of
adjustment is based on the training cost modifier, gold is fully adjusted to game speed, i.e. tripled
i.e. only 200% on Marathon. Other than that, the on Marathon.
gold payout during the first 50 turns is as in BtS.
By turn 250, the payout is multiplied by ten (after
being multiplied by the training cost modifier).
Rationale Overall, I want to weaken the effects of goody huts. It's interesting to give players
some random freebies in addition to their guaranteed starting units and techs, but the
number of huts that each civ gets varies a lot (and tends to favorscivs that are already
advantaged by having a lot of space to expand), so strong goodies are pretty bad for
game balance. They also steer early exploration too much and into regions too far
from the capitals (cf. rationale for 031d). Huts can also be disabled entirely and many
players actually do so, so it's not necessary to make everyone happy. But my
impression is that even the players who like to play with huts enabled find them too
consequential.
A free Scout or Warrior is worth 15 production and is immediately useful. Can't really
weaken those outcomes. Gold only becomes useful when a second city has been
founded, but is then difficult to come by for the first era of the game, so an expected
payout of 30 gold seems fair. The High gold outcome should perhaps only occur on
“casual” difficulty levels; for now I've only removed it entirely from Emperor upward –
and reduced the payout.
Marathon games tend to be played on larger maps with more huts per civ, hence the
smaller speed-adjustment factor than in BtS.
522
During the first 50 turns, goody huts grant 23 to When the Tech outcome is rolled, the hut grants
61 progress toward a tech. The tech is directly a free tech regardless of that tech's cost. The
discovered only if that progress is enough to tech is chosen uniformly at random from among
cover at least 80% of the (remaining) tech cost. those currently researchable techs that are
The granted progress is adjusted to the game flagged as bGoody in Civ4TechInfos.xml. No
speed and game turn in the same way as gold game speed or progress adjustment, but tech
(see above). costs increase with the game speed and
The tech is chosen uniformly at random from all progress. That said, the only post-Classical
bGoody techs are Music and Astronomy, so the
pre-Industrial techs that the civ entering the
Village is able to research, including the currently only way to benefit significantly from huts across
researched tech. the ocean is by reaching them in between Optics
and Astronomy, and even then it's a long shot.
Note about a K-Mod change (from the summary
in the K-Mod thread): “Free technology bonuses
from goody huts are now allowed without settling
a city first.”
Rationale Would like the tech outcome to be about as powerful as the Low gold outcome. Need
to bear in mind that research can be more immediately useful, but can also be of no
use anytime soon or go to waste when a tech is already nearly discovered. Going a
bit higher with the research would seem fair, but perhaps not quite as high as I've set
it. I don't want huts to never grant a whole tech, so I don't feel I can go much lower
with the research boost.
I guess the bGoody techs were chosen based on whether a "primitive" civilization
could plausibly possess them. I don't think this works for Astronomy, which unlocks
Galleon and Observatory, nor for most other post-Ancient techs. Tech progress
somewhat gets around this plausibility issue by merely suggesting that the primitives
contribute to the discovery, maybe like modern astronomers employing knowledge
from ancient Babylonian records. Such contributions strain credibility for techs like
Radio, so I've taken the Industrial and Modern techs off limits.
Config bAllGoodyTechs flag in Civ4EraInfos.xml. If that flag is not set, then techs from the
era can only be obtained from a goody hut if they're set to bGoody in
Civ4TechInfo.xml. I.e. it's also possible to revert to the BtS system by setting
bAllGoodyTechs to 0 for all eras.
Tbd. Should perhaps also adjust the outcome to the map size. Tech costs are higher on
larger maps (e.g. 100% on Duel, 130% on Standard), and the current payout is going
to grant a full tech only rarely on large maps, particularly on high difficulty settings.
Then again, one could argue that larger maps have more huts and therefore each hut
should provide less research than on smaller maps, if anything.
Might also want to adjust to game era; see 910.
Outcomes that can't be scaled up in a Regardless of the game progress, the Map
straightforward way, namely Map, XP, Heal and outcome reveals a randomized subset of tiles
Scout, get a chance of being "upgraded" if they within a radius of 4, XP grants 5 XP points, Heal
occur later than turn 50. The upgrade probability heals the unit entering the Village and Scout
reaches 100% around turn 160. For Map, XP and grants a free Scout.
Heal, an upgrade means that another positive
outcome is chosen at random and both are
applied. For the Scout outcome, the upgrade is a
free Worker instead of the free Scout.
523
Rationale These four are pretty worthless when triggered by an Explorer; can't have so many
dud outcomes. A higher amount of XP wouldn't help (not needed on an Explorer) and
would be too similar to a Great Warlord.
A free Scout seems out of place when that unit is already obsolete; better to replace
that outcome entirely than to roll an additional one. In Renaissance, a free Worker is
not as valuable as tech progress or gold, but it should work well enough as a conso-
lation prize.
The Warrior outcome produces a free unit Always produces a Warrior.
chosen based on combat strength and
randomness from among those pre-Industrial
combat units that don't require resources and for
which the Barbarians have all the prerequisite
techs, i.e. Warrior, Archer, Longbow or
Musketman. (The same procedure is used when
playing with "No Barbarians" as that option does
not prevent the Barbarians from discovering
tech.)
The types of hostile units (Barbarians outcome) Hostiles are always Warriors. The Weak
are also chosen as above. The lower bound for Barbarians outcome usually spawns 1 or 2
the number of hostile units (iMinBarbarians) Warriors and Strong 2 to 4, though as many as 8
increases a little over time, but there's also an are possible.
upper bound of 2 + iMinBarbarians.
A non-hostile free unit has a chance of receiving The free Warrior starts with 0 XP and without any
up to two free promotions. Each of the two promotions.
promotions is assigned with a probability equal to
half the upgrade probability (see Scout above). If
a promotion is assigned, the specific promotion is
chosen randomly from Combat1, Guerilla1,
Guerilla2, Woodsman1, Woodsman2 and Cover.
The surrounding terrain also factors into the
selection of the promotion.
Rationale Choosing the unit based on the game era would be simpler, but then Barbarian
Archers would appear too early (even if game era minus 1 was used).
In Renaissance, the received unit will usually have to be upgraded in order to be
useful; the free promotions should make such an upgrade worth considering. I've
picked promotions with a "native" flavor. The selection algorithm is pretty complicated,
but I don't think players need to worry about that.
See also 302 curbs Barbarian research when civs don't share a continent with Barbarians. (But
this doesn't apply when playing with "No Barbarians".)
Allow Hostiles 1 tile closer to a city than in BtS, Hostile villagers can't be encountered anywhere
but check for cities of any player, not just the one near a city of the player who enters the Village.
who entered the Tribal Village.
Rationale Can be unfair to third parties, perhaps this just wasn't taken into account by Firaxis.
On the other hand, the range of the city check is so big that humans rarely encounter
them on difficulty levels that let the AI start with a free Scout.
Hostile villagers don't attack injured units for 1 If more than one Hostile is created, they normally
turn. manage to kill the unit that entered the village by
attacking all at once.
524
Rationale To give the civ unit a chance to escape if it survives the first attack. Too punishing
otherwise.
Tbd. I've also implemented an alternative idea (commented out in CvPlayer::
receiveGoody): The Hostiles outcome restores 1 movement point for the unit that
entered the village – so that it can escape (at least from some of the Barbarians) right
away. Might be a better solution than the one I've gone with.
The Worker outcome can't occur until turn 20 (on Only the Warrior outcome has such a restriction,
Normal speed). presumably to prevent a super early rush. The
Worker outcome can't occur on Prince difficulty
Halved the probability of the Settler outcome on
and higher (no change).
Chieftain and Settler difficulty and set it to 0 on
Warlord.
Rationale I think novice players should play on Noble difficulty, but, for a R&F game, it could
make sense to go down to Warlord, so that difficulty setting shouldn't have grossly
unbalanced goodies.
Config The Settler changes are implemented through CivHandicapInfo.xml.
Increased the probability of the Tech outcome at For most difficulty settings, Gold is three times as
the expense of the Gold outcomes so that Gold islikely as Tech.
only slightly more likely than Tech.
Rationale The Tech outcome is more interesting than Gold. Now that their power level is similar,
Tech can be awarded more frequently. However, I still want civs to receive at least one
(Low) Gold outcome more often than not so that they don't need to immediately adjust
their research slider after founding a second city.
Config Through Civ4HandicapInfo.xml
Increased the size of the Tribal Village 3D model on the map.
Rationale They're hard to spot on Forest tiles. I've also tried a more reddish, saturated color, but
the increased size seems sufficient and a color change alone doesn't help because
the BtS-size huts barely poke out of the trees.
See also By now, I've added a Tribal Village "bubble" to the Resource layer (change 004z), so
the size of the 3D model isn't so relevant anymore.
Config Through XML\ArtCiv4ArtDefines_Improvement.xml
Tribal villages are placed when starting in the Only when starting in the Ancient or Classical
Ancient, Classical or Medieval era (unless era.
diabled through game options).
Rationale Now that the effects scale, I don't see a reason to place huts in the Classical era but
not in the Medieval era. In both cases, the human player starts with a single
exploration unit. I like the huts as rewards for discovering unclaimed continents. When
starting in Renaissance though, this is too easy as Caravels are available from the
beginning.
The minimal distance between two Tribal Villages Tribal villages need to be at least 4 tiles apart.
gets adjusted to the feature grain value of the The feature grain value depends on the map size
map size. and affects the size of clusters of terrain features.
It's -1 for Duel and Tiny size and +1 for Large and
Huge size. It doesn't affect Tribal Villages, which
technically are terrain improvements.
Rationale Space them out more when there is more space. Didn't want to add an improvement
grain value just for this purpose.
525
Config The base value for the minimal distance between Tribal Villages is set through
iGoodyRange in Civ4ImprovementInfos.xml, the feature grain in
Civ4WorldInfos.xml. AdvCiv doesn't modify any of those values.
526
See also 314 makes overseas goody huts discovered in Renaissance more rewarding.
AdvCiv BtS
The move-all-terrain ability prevents Gunship The "cannot capture cities" ability prevents
from capturing Workers. Explorer can capture Gunship (and any other unit that can't capture
Barbarian Workers. cities) from capturing Workers.
Rationale To give Explorer another potential use: steal Barbarian workers for nearby colonies.
Though I'm not sure that it's possible to sneak up on Barbarian workers.
315c Scout gets +100% combat strength against all Barbarians, not just against Animals.
The AI may use Scouts and other exploration units to guard city sites (i.e. for
fogbusting) when there is nothing to explore.
Rationale Warrior is still the better unit against Barbarians (as it should be) in every regard
except mobility: greater benefit from combat promotions due to greater base strength;
can attack pillagers; +25% city defense.
315d Cap on early Scouts from huts
Recon units entering a hut can't get the Scout Scouts can beget more Scouts, and, in the first
outcome if their owner already has two or more 20 or so turns, it's not so rare to end up with a
exploration units. total of three Scouts when starting with a Scout.
Here someone reported three Scouts in a row for
a total of four.
Rationale The third Scout is a weak outcome, and no fun because the map gets explored too
fast.
315e Huts within 3 tiles of the edge of a non-wrapping map can't yield the reveal-map
outcome.
Rationale The reveal-map outcome is weak in any case. When one direction is blocked, it gets
too weak I think.
527
Config Disabled in CvPlot.cpp (calculateNatureYield, isConnectRiverSegments)
500b Demand better protection
Anger from lack of protection computed based on Any one military land unit (except Recon,
the defensive strength of the local units and Helicopter; based on the MilitaryHappiness
population size. A single weak unit doesn't flag in XML) suffices to avoid "We demand
always suffice to avoid "We demand better military protection".
military protection".
A city requires a total defensive strength equal to
at least its population. Defensive strength is
computed as combat strength increased by
defensive modifiers (e.g. from Archer, Wall,
Garrison promotion – but not from culture-based
defense). For units that can't receive defensive
modifiers, none are counted.
Note that, so long as far for safety is the only
cause of fractional anger in the city, i.e. in the
early game, rounding will make e.g. a Warrior
fully sufficient still at size 5 (not 2 or 3 as one
would expect from its defensive strength of 2.5).
The anger is proportional to the lacking defensive
strength; e.g. an almost sufficient garrison will
lead to just 1 anger.
Recon and Helicopter units count if they have a
positive culture garrison value (i.e. Explorer as
per change 315b, Gunship).
Rationale Requiring just any military unit becomes a pretty nonsensical rule by the Medieval era.
Can either abolish it, or change it so that credible garrisons are required.
Not sure if unit health should matter. I think it would create unnecessary distraction if a
city, e.g. after a Barbarian attack, would clamor for better protection for a couple of
turns. Likewise, bombardment damage to city defense and fortification bonus
shouldn't matter. Fear-for-safety anger isn't supposed to punish players whose cities
come close to being conquered (that risk is punishment enough), it's supposed to
punish careless/ precarious precautions before the city actually comes under threat.
Counting Walls and Castle buffs those buildings a little. Counting promotions has the
side benefit of encouraging promotions at peacetime.
Config Disabled through DEMAND_BETTER_PROTECTION in GlobalDefines_advc. Can also
enable a penalty for outdated units there and tweak the defensive strength target. if
this change is enabled, one may want to disable change 500c, which attempts to
solve the same problem in a less comprehensive way. On the other hand, keeping
garrisons at the proper strength could become annoying in the late game, so perhaps
the two changes complement each other.
528
See also Defensive strength is already used for revolt probabilities; see 101. However, tile
defensive doesn't count for revolt probabilities and unit health does count.
CFC post by me laying out rationales and explaining why I'm not quite happy with this
change.
The mod component Scaling Garrison Unhappiness by Imp. Knoedel uses culture
garrison values instead of defensive strength. (But in my estimation, culture garrison
strength increases too slowly over the course of a game, and it's another value to be
displayed by the UI.)
Tbd. Defense from obsolete buildings shouldn't count. Will have to add a data member
CvCity::m_iNonObsoleteBuildingDefense for this because building defense is
cached in m_iBuildingDefense.
Need to show "Garrison strength x.x, population: y" in help text when there is anger.
Otherwise it's too difficult to learn.
Performance was slightly problematic until I disabled the check for outdated units.
Should check sometime if there is still any issue now. If so, then the result of
CvCity::getNoMilitaryPercentAnger should be cached. That cache will have to be
updated once per turn (sufficient for dealing with defensive buildings and unit
obsoletion); and in CvUnit::setXY, CvCity::setPopulation ; and after assigning a
promotion.
I've been thinking about making unit upgrades mandatory (if not upgraded in time,
units refuse to fight with outdated equipment and defect). Then this change will be
important because otherwise players could try to play around unit obsoletion (e.g.
don't get Hunting so that Warriors can be trained indefinitely) so that they don't have
to upgrade their city garrisons.
500c Nationalism tech disables “we fear for our safety” anger
Rationale Same as for 500b; this is a much simpler solution that players don't even have to be
aware of. Good enough to prevent pre-gunpowder garrisons in the Industrial era.
See also I've posted briefly about this change here on CFC (end of the post).
529
AI gives tech away cheaper (or expects to get it Tech trade value is independent of how well the
cheaper) when the receiving side is less involved civs are doing. (Vassals can receive free
advanced and powerful than the giving side; tech from an AI master if they're behind, but that's
charges more if the receiving side is more not a matter of trade value.)
advanced/ powerful. The effect is small in the
BBAI and K-Mod let AI civs that are falling behind
early game and increases as the game
technologically check for tech trades more
progresses.
frequently (no change in AdvCiv).
Exception: Doesn't apply to vassal-master Vassals charge less from their master for
relationships, i.e. vassals don't expect to get resources, trade embargoes and civic/religion
tech from their master at a discount. changes. Tech trades are unaffected by vassal/
master relation.
Rationale A little extra catch-up mechanism. Also, when dealing with a backwards civ, it's
smarter to be generous than to insist on a square deal.
For vassal-master, the basic idea in BtS is that the master can trade favorably with the
vassal. Don't want to turn this upside down.
It's important to keep the effect small in the early game because it'll otherwise make
bee-lining to expensive low-utility techs like Aesthetics or Compass even more
powerful on the highest difficulty levels.
550b AI doesn't make bad offers for human tech
AdvCiv K-Mod
The AI doesn't propose or counter-propose any The AI can (counter-)propose trades that are up
trade to a human civ that gives tech to the AI civ to 300% in its own favor.
and is more than 50% in favor of the AI civ.
The AI always offers something when proposing May offer nothing at all.
a trade.
Rationale I used to accept bad AI offers for tech because I believed that they're due to partial
research progress of the AI. That can be the case but often isn't; so it's a bit of a trap.
Tbd. The AI probably shouldn't contact players with bad non-tech deals either.
550c Changes to tech monopoly thresholds ("don't want to trade just yet")
AdvCiv BtS
AI is more willing to trade tech if it has contact AI willingness to trade a tech is based on the
with few civs and still hasn't met most civs. percentage of known civs (excluding itself) that
already know the tech.
E.g. if an AI civ knows only one civ, the AI civ If the AI knows only one civ, the AI will hardly
acts as if 40% of the other known civs already ever trade (unless Friendly) because the
knew the tech (when in fact it's 0%). percentage is either 100%, meaning the other civ
already knows the tech, or 0%, meaning the AI
tries to monopolize the tech.
Rationale This should make civs on small continents fare better.
530
The AI leader-specific thresholds for monopolies TechTradeKnownPercent is only adjusted for
(TechTradeKnownPercent; between 0 and 100) techs that the AI wants to monopolize badly, in
are randomly increased or decreased by up to 15 particular military techs. There's no random
points. This random adjustment is applied once component.
per game to each tech separately, i.e. it's not the
same for all techs, and can't be manipulated
through repeated trade requests by a human
player.
Rationale The BtS monopoly thresholds are a bit too predictable in some cases, especially when
there are just two or three civs on a continent. And e.g. Pleased Tokugawa never
trading anything useful is depressing.
Tbd. Perhaps the issues with small continents are already taken care of by the change
above; not sure if the randomization is still needed.
AI considers the unique unit and building of the Only looks at the default units and buildings that
prospective recipient of a tech when computing a a tech unlocks when computing the tech
monopoly value. monopoly value.
Rationale A small tweak. Taking into account more specific information can't hurt.
550d Tech costs reduced if tech trading disabled
When the "No Tech Trading" option is checked "No Tech Trading" doesn't affect research speed,
on the Custom game screen, tech costs are and such games tend to lag behind the historical
decreased based on the default player count of time line.
the map for all eras except Ancient and Future.
The research bonus is the highest for Medieval
and Renaissance tech.
Rationale A lower bonus in the early game because tech trading doesn't become available until
the middle of the Classical era even if it's enabled. A lower bonus after Renaissance
because tech progress tends to get more disparate the longer the games lasts, and
so fewer and fewer tech trades happen.
Config Can be adjusted or disabled through GlobalDefines_advc.xml.
Tbd. Would be unnecessary if there was a proper tech diffusion system to replace tech
trading.
See also 910 makes various adjustments to tech costs based on game options.
CFC post laying out the formula for my no-tech-trading modifier: link
550e Era threshold for "fear you're becoming too advanced" based on the recipient's era
AdvCiv K-Mod
531
When a civ receives a tech in trade, all third Tech-received memory leads to "We fear you are
parties who know the recipient increase their becoming too advanced" (as in BtS). K-Mod adds
received-tech memory about the recipient (as in the two exceptions. In the second one, game era
BtS), except when (as in K-Mod) the recipient (averaged over all civs) is decisive, not the
had already researched 2/3 of the tech, or when recipient's era.
the era number of the tech is at least 2 lower
than the era number of the recipient. E.g. when a
civ is in the Medieval era and receives Archery,
no tech-received memory is increased.
The recipient's tech-received memory (for
"You've shared your discoveries") is also not
increased when one of the exceptions above
applies.
Rationale K-Mod comment in CvDeal::startTrade: "This is to prevent the AI from being
crippled by human players selling them lots of tech scraps."
Good reason, but this also affects human players receiving tech. Humans need to be
able to tell whether a trade is going to count, and the game era is unknown early on,
and tedious to determine later on.
I've extended the exceptions to "shared discoveries" because that's also exploitable in
BtS.
Insignificant tech trades (2/3 progress or 2 eras Techs can't be traded on the same turn on which
behind; see above) are unaffected by the no- they've been received in trade.
brokering game option. Regardless of the
brokering option, such techs can be passed
along on the same turn that they've been
When the AI has already 50% or more progress
received.
toward a tech, it refuses to accept that tech in
The AI does not reject any tech trades on trade when "No Tech Brokering" is enabled: "We
account of the no-brokering option. would have nothing to gain."
Insignificant tech can also be traded immediately The tech brokering restrictions apply to all techs
when it's received through some mechanism that a civ doesn't discover through its own
other than trade, e.g. the Internet or after the research or Great People.
creation of a colonial vassal.
Rationale Removing the 1-turn delay made it much easier to implement the change to "no
brokering". Also makes sense to treat techs that are traded when 2/3 complete the
same way as techs discovered entirely independently.
See also Tech received through the Internet is actually not subject to any trade restrictions in
BtS; kekm.31 removes that inconsistency.
532
The target amount of gold that the AI tries to Based on civ size, leader flavor and units
keep in its treasury can be increased beyond the needing upgrades.
BtS value depending on the potential for tech
trades.
When the an AI civ checks for possible tech AI-AI tech trades are always tech-for-tech. One
trades with another AI civ, if it doesn't find a tech- side can offer gold in addition or multiple techs,
for-tech trade, then the first AI civ tries buying the but just gold for tech isn't possible.
tech that it is currently researching for gold (if the
second AI civ knows that tech).
Rationale Should help against AI civs falling far behind in tech. On the flip side, it means extra
gold for the tech leader. That said, the AI doesn't pay very well for tech, especially
when it has fallen behind (see 550a, 551).
The portion of its treasury that the AI is willing to Based on civ size, finances, gold previously
trade to a human player is tied to the research traded (all still the case in AdvCiv).
progress of the AI. The portion is maximal when
the AI has researched 75% of a tech and minimal
at 25%.
Rationale Should make it more likely that a somewhat fair gold-for-tech trade is possible when
the BUG gold alert triggers.
533
Made the AI more likely to take into account When the AI chooses a tech to research, it
possible tech trades when choosing a tech to decides randomly whether or not to take into
research. Tech trades now matter, typically, for account possible tech trades. The probability is
about every third research decision. The equal to the contact probability for AI tech trades,
probability is still personality-based. which is between 5% (Tokugawa) and 100%
(Mansa Musa); 20% for about 20 of the AI
leaders; i.e. typically, tech trades are taken into
account for every fifth research decision.
Also increased the utility value counted per K-Mod 1.46 had already increased the utility
possible tech trade. value counted per possible tech trade.
Rationale To make it a bit harder for human players to take advantage of unpopular techs like
Aesthetics. Mustn't take this change too far though 8see rationale under 550g).
534
Rationale The BtS weights seem to be aimed at military techs, especially nuclear war, and
Space victory. I think this should be (and is at least in part) handled by the DLL; don't
want an AI civ that isn't aiming at a Space victory to pay extra for e.g. Genetics.
I'm keeping the modifiers for military tech and I'm adding a few more, but not for pre-
Medieval tech as pre-Medieval AI warfare is fairly rare. There is also
CvTeamAI::AI_getTechMonopolyValue, which makes the AI not "want to start
trading away this technology just yet," but if the AI still agrees to the trade, I want
there to be an extra high penalty if it's a trade with someone's worst enemy.
Tbd. +10% trade value is not going to affect the enemy trade penalty much. Perhaps 130p
should give the AI trade modifier some extra weight when recording trade values
(peacetimeTradeValue).
Config CIV4TechInfos.xml
groundbr XML options for a research rate penalty when breaking new ground
(disabled by default)
Credits Based on the getSpreadResearchModifier function in “Dawn of Civilization”
Rationale As a rubberband. I don't really think AdvCiv needs this; mainly for mod-mods.
See also Discussion in the AdvCiv thread, on and off over several pages, starting with this
suggestion by Cruiser76.
Config See TechDiffusion_GlobalDefines.xml. The comments there also describe how
the penalty is computed.
Tbd. I don't think the AI takes research penalties into account when choosing its research.
535
The city count in the formula for number-of-cities BtS counts vassal cities fully but caps the total at
maintenance counts vassal cities half (as in 4 to 8 cities (depending on the difficulty level) –
K-Mod) and is capped at a map-size-based i.e. vassal cities often don't matter at all. K-Mod
upper bound between 22 (Tiny) to 25 (Huge). halves the vassal city count and entirely removes
the upper bound on the total city count in order
to, as the changelog says, “weaken the power of
huge civs.”
Credits Elkad made me aware that, without a cap, city maintenance makes Domination
victories on Huge maps too difficult and incentivizes city razing. CFC post
More recent CFC post by me (penultimate spoiler box)
CFC post by drewisfat that calls the K-Mod change (well, he seems to attribute it to
me) “insane.”
Config MAX_CITY_COUNT_FOR_MAINTENANCE in GlobalDefines_advc.xml.
Rationale If I just restore the BtS cap, it'll (again) be far too easy, for large civs and in general, to
max out the research slider, but the K-Mod change is too extreme to leave it alone. A
cap around 40 would be enough to ensure that (decent) conquered cities can pay for
themselves, but still leads to number-of-cities maintenance costs that are ca. 5 times
higher than in BtS when aiming at Domination on a Huge map.
A slightly better formula (for game balance) would take the city count to a power
slightly below 1, e.g. 0.9, instead of capping the city count. Or some other soft-cap
mechanism. See the second half of this CFC post of mine. However, opinions seem to
differ on whether costs should simply grow quadratically as in K-Mod; so players may
want to customize the formula, and a complicated formula would make that more
difficult.
See also 140 adjusts number-of-cities maintenance to the crowdedness of the map.
Tbd. Number-of-cities maintenance isn't the best tool for increasing the expenses of large
civs. I surmise that it was intended only for pacing early-game expansion. I'd like to
get rid of number-of-cities maintenance entirely; it's a clunky and slightly confusing
concept. I hope that a fixed cost per city, 2 gold perhaps, or a bit less, say 5/3, would
work well enough. Part of that cost should be paid by the capital in order to encourage
a Courthouse there, or more generally, government centers should pay a
maintenance cost for the number of cities in their vicinity (Voronoi cell).
To increase expenses, civic upkeep should be increased, especially for civics in the
Medium and High upkeep class. Ideally in a way that takes into account how spread
out the population is; that could avoid punishing small cities that are mostly intended
to claim resources. On that note, population should have a greater impact on distance
maintenance. The Organized trait may have to be tweaked if civic upkeep is increased
substantially.
The trade route commerce fomula also needs work. There's generally too much trade
route commerce in the midgame and late game, and coastal cities aren't rewarded
enough. (Related CFC post – see item 4.)
Inflation should be replaced with even higher costs for city population and civics and
increased maintenance costs for units starting sometime in Renaissance (when units
begin representing increasingly large numbers of soldiers. Also, air missions should
have a small gold cost.
(I've more detailed notes about all that, but no definitive proposal.)
536
advc.exp.2 Reduce effect of unique buildings on city maintenance
AdvCiv BtS
Ikhanda reduces city maintenance by 15% and 20%, 75% respectively.
Rathaus by 70%.
Credits Suggested here (last quote box) by CFC user AllTheLand.
See also CFC thread rating Ikhanda as one of the best unique buildings.
CFC thread with praises (from reputable players) for Rathaus.
exp1 (see above) reintroduces a cap on city maintenance – but still a much higher
one than in BtS.
908b weakens Terrace; a precedent for weakening powerful unique buildings.
Rationale These buildings aren't really problematic, but, compared with other unique buildings,
they're already quite good in BtS, and the K-Mod increase to city maintenance makes
them significantly more effective. Moreover, AdvCiv makes various changes that slow
the pace of games on high difficulty levels and make it more difficult to decide games
early on; those changes also make midgame buildings more useful. When the mod
creates a problem, it's best to address it in some way, even if it's only a minor
problem. Players tend to have limited tolerance for mods making any part of the game
worse.
The Ikhanda already had an unusual modifier (I can't think of any other 20% modifier
in the whole game), so giving an unusual modifier also to Rathaus doesn't worry me
too much.
537
the maintenance formula leaves colony maintenance as high as in BtS for faraway
colonies – so that there can still be an incentive for liberation – but reduces
maintenance a lot in colonies close to the capital.
538
Tbd. The AI still doesn't disperse its units in order to avoid nuke attacks.
I'd like to further increase the probability of surviving multiple nukes. One could use a
negative base damage value to this end, but would give tiles with one or a few units a
chance of sustaining no damage to units at all, which seems strange. Units not getting
damaged, in my mind, does not mean that the nuke wasn't well aimed (or the target
information inaccurate), but that the units stacked in the tile are too far dispersed to hit
them all. Such a model really only make sense when a nuke affects a single tile – and
I think that would be better for game balance too. In the interest of reusing exiting AI
code, I'd then try to use a formula that uses a base damage value of 100 when only a
single unit is affected (guaranteeing the unit's destruction) and that adds a (single) die
roll when there are multiple affected units, reducing the base value (to 0 and below)
while increasing the maximal value of the die as the number of units is increased.
Surrounding tiles could still be affected in a minor way, e.g. through destroyed
improvements.
Nuking a city with significant culture of a third party should result in a relations penalty.
Will have to implement that as a new type of AI memory (“You nuked your citizens!”)
because the two existing nuke memory types don't quite fit. I don't think a warning on
the UI is needed (would then, to be consistent, also have to warn about partner civs
that will be upset). AI code added to CvPlayerAI::AI_nukePlotValue would be nice
to have, both for the nuked-citizens and the nuked-friends penalties, i.e. all the
diplomatic fallout.
See also Deity K-Mod game won by double nuking AI city garrisons: CFC thread
AdvCiv BtS
The SDI has an interception chance of 60% (i.e. 75% chance (i.e. 37.5% for Tactical Nukes),
30% for Tactical Nukes) and costs 1500 costs 1000 production.
production (on normal settings), sped up by
Aluminum as in BtS.
Rationale Too much of a no-brainer once nukes become a threat and Aluminum is available, and
makes ICBMs too much worse than Tactical Nukes overall. The AI isn't aware either
that relying on ICBMs is a bad idea. Also, the high interception chance can easily lead
to five or more ICBMs intercepted in a row. Which is how independent random trials
work, but I think players expect that they'll be able to “force” a couple of ICBMs past it,
and, at 75% odds, this goes very badly too often – I feel.
I don't want to change the SDI much, however, because it'll always be unrealistic – if I
make players relearn some element of play, I'd like it to be something sensible. 60%
still means that interception is more likely to succeed than to fail.
Config Civ4ProjectInfos.xml
The nuke target value is reduced based on the Nuke interception is not taken into account when
enemy interception probability (including the deciding whether and where to attack with nukes,
evasion chance). The interception probability has and the UI only shows the evasion chance (in the
less impact if all current and plausible future unit help text of Tactical Nuke).
enemies have a high interception probability.
When hovering in Nuke Mode, help text shows
the interception probability (if greater than zero).
Rationale Hover text: Easy to forget about the SDI, and it's not totally obvious how interception
chance and evasion chance interact.
See also 004c shows the interception chance against air missions.
539
Tbd. The cursor color in Nuke Mode leaks information about tile ownership in the fog of
war. What to do? Require active visibility on all affected tiles? This would also
eliminate the implausible recon visibility while the nuke explodes. It's also not
plausible that a nuke fired without the latest recon info would be just as damaging,
especially to units. Or introduce a canNukeAt check that works based on revealed
ownership and allow for accidental declaration of war upon execution of the nuke
mission? Ultimately, ICBM should move to Satellites, and then the Satellites ability
could also lift the fog of war when it comes to tile ownership. Putting this effect at
Rocketry (the current ICBM tech) would be less elegant.
An announcement summarizes the damage Only announces that a nuke has exploded and
inflicted by nuke explosions: Destroyed and where. The nuke grants visibility for its owner, but
damaged units, destroyed buildings (only if only while the nuke animation is playing, so the
visible), lost population, destroyed improvements nuke owner may be able to glimpse some of the
and features. damage. Fallout shows where improvements and
features have been cleared, but this doesn't tell
players which improvements and features were
destroyed.
See also 045 hides the 3D models of buildings in rival cities.
Rationale For a player who knows the rules for nuke explosions, the destroyed buildings would
seem like the most relevant information not provided by BtS. That is, only for the
owner of an affected city. However, the nuke rules aren't necessarily that widely
known, specifically how units get damaged. The AdvCiv changes to the damage
distribution make it all the more important to be more transparent about the effects of
nukes.
Tbd. The announcement might be too detailed. Perhaps improvement and feature
destruction shouldn't be included (already isn't included for third parties) and perhaps
destroyed and damaged units should never be listed (even if the number is small),
only counted. Even for the city owner, the details could be annoying – it's not so rare
that a bunch of cities get nuked in a row.
Would be nice to announce destroyed nuke units separately as they're especially
expensive.
Academy, Military Academy and Scotland Yard Great Wonders (incl. Shrines and corp. HQs),
are immune to nuke damage. Bunkers and Bomb Shelter are immunte.
Rationale Seems a bit too punishing to remove GP buildings, and consistent with Shrines and
settled GP not to remove them. Ironworks getting destroyed is also brutal, but can't
plausibly be protected either.
Regular bunkers cannot plausibly withstand a nuclear explosion, but, given the ability
of Bunker, it may well represent air raid shelters. While those aren't a sufficient
protection against a nuke, it's plausible enough that they wouldn't be utterly destroyed.
Credits Idea from Dawn of Civilization
Tbd. Would prefer to let nukes destroy obsolete wonders and settled GP. Will need to
announce those effects though. Obsolete wonders also shouldn't be immune to
capture-city damage.
Bomb Shelter should be renamed to “Fallout Shelter.”
AI uses air recon along its coast. Based on BBAI AI seems to use air recon only on rival cities.
code for (human) auto-recon.
Rationale Could reveal enemy submarines. Not enough to properly defend against Tactical
Nukes, but the BtS AI doesn't even seem to try.
540
See also A bugfix in CvUnitAI::AI_exploreAirPlotValue is tagged with “advc.001”.
Treat preparations for “total” war the same as ongoing or imminent “total” war in
CvPlayerAI::AI_nukeWeight.
AdvCiv K-Mod
AI willing to build the Manhattan Project unless it AI considers the Manhattan Project only when in
looks like it will win the game anyway, the Dagger or Crush strategy, or when close to a
Conquest victory.
Rationale The AI shouldn't take risks with nukes when it's winning anyway (Conquest, or
crushing its current war opponents).
AI less worried (divisor 3) about attitude of AI civs The K-Mod AI checks the attitude of all rival civs;
that aren't (prospective) war enemies when divisor is 2. Utility for nuke access is a constant.
deciding whether to build the Manhattan Project.
Not worried at all about unlocking nukes for rivals
that are about to win the game (victory stage 4).
Utility value for gaining access to nukes takes
into account the number of civs in the game.
Somewhat more sophisticated logic for figuring
out who is on track to winning. May go for the
Manhattan Project when feeling existentially
threatened (but not when already losing a war –
too late by then). As for war plans, only a “total” Any war ongoing or planned can encourage the
war in preparation can encourage the Manhattan Manhattan project.
Project.
Rationale A K-Mod comment says that it should be up to the human player to decide whether
he/she wants nukes in the game. I don't agree with that, but I mustn't make the AI so
willing that some AI builds Manhattan most of the time; or at least not until the game is
about to end.
Generally, I'd like the AI to unlock nukes when a disliked civ is about to win the game.
Tweaks to AI nuke weight: Incentivize getting a The overall nuke weight determines how willing
first nuke when having none. Take into account an AI civ is to produce nuke units.
personal espionage weight, war probability at
As for personality, only the peace weight value
Cautious attitude and favorite civic
matters.
(Environmentalism) too.
Rationale All the Cold War leaders have high espionage weights.
Added a high-priority rule to the City AI for producing at least a small nuclear arsenal as soon as
nukes become available.
Rationale It takes the BtS/ K-Mod AI too long to produce its first nukes, which make a big
difference for deterrence both in gameplay and story terms.
541
Revised the calculation of the AI weight for This weight factors into the evaluation of target
nuking civilian targets: Enemy war successes tiles for nukes, specifically whether to focus on
increase the weight only if the war is going very, hitting military units or on damaging the enemy's
very badly. Decreased weight when a war should economy. If no tile is deemed sufficiently
be easy to win judging from the power ratio. valuable, then no nuke is launched. The weight is
Leader's personal raze-city weight taken into computed from the war success rating, attitude
account. Reduced impact of attitude. (Estimated) and memory of enemy nuke attacks. The
number of enemy nuke taken into account Conquest victory strategy also increases the
(potential for retaliation). The number of enemy weight.
nukes also affects the threshold that potential
target tiles need to pass in order to be nuked by
the AI.
Rationale See comments in the code (CvPlayerAI::AI_nuke...DestructionWeight).
Tbd. My estimate of enemy nukes uses the exact number obscured by random noise.
Perhaps a similar statistic could be made available to human players so that this
wouldn't be a cheat. For example, the number of nukes per rival could be shown on
the Military Advisor under the minimap (and in the scoreboard tooltip of the power
ratio) in intervals “1 to 4”, “5 to 9”, “10 to 16”, “17 to 24” etc. (i.e. the more nukes a
rival has, the less precise becomes the information).
Alternatively, the intel ratio planned for change 082 could also apply to nukes (would
still be a cheat).
Substantially reduced the impact of buildings on City buildings seem to dominate the AI
the AI choice whether and where to attack with calculations, at least when no large garrison is
nukes – by taking into account the chance of present.
buildings surviving a nuke explosion intact.
Tbd. May have to dial up other factors to avoid making the AI too shy about using nukes.
Let's see about that ...
AI doesn't disband nukes when in financial As far as I can tell, nukes are disbanded before
trouble unless the only other remaining units are most other units. BtS tried to save expensive
cargo units. units, which is fine in the case of nukes, but
K-Mod focuses on XP, which is generally better,
but fails for nukes.
542
Adjust the meltdown probability to game speed. Not affected by game speed.
Rationale For balance – to match the higher re-construction cost and amortization time; for
immersion – nuclear disasters shouldn't be more common on slower game speed.
Show the meltdown probability in help text. Omit Help text always shows a “small” chance of a
the ability in help text for the city building list nuclear meltdown.
when the Nuclear Plant isn't providing the city
with power.
See also Based on kekm.5.
Increased the meltdown chance to 0.7 permille. 0.5 permille.
Rationale I did some math (see below), but ultimately went by intuition. The BtS probability
seems a bit too small now that meltdowns are less disastrous (K-Mod change) and
can't happen when the Nuclear Plant is superseded by another power source (Kek-
Mod). On the other hand, games tend to last longer with AdvCiv than with K-Mod ...
On Normal speed, there are 125 turns left in 1955 (turn 375), but games hardly ever
last that long. A more typical end date for a peaceful AdvCiv game is 2005 (turn 425),
i.e. just T=50 turns of nuclear power. If p is the meltdown probability and one assumes
(for simplicity) a constant number N of nuclear plants throughout the T turns, then the
total number M of meltdowns is distributed binomially with success probability p and
N*T trials and thus an expected value of EM = p*N*T. Aim at EM=1 (Chernobyl), then
N as a function of p becomes N(p) = 1/(50*p). Table:
p N
1/2500 50
1/2000 40 (BtS)
1/1500 30
1/1250 25
1/1000 20
1/750 15
1/500 10
A Standard size map only has about 50 cities in the late game. Considering that some
civs will reach Fission extra late or never and that one (big) civ may build Three
Gorges, N=10 might be a realistic assumption for an all-AI game. In this human game,
there were 33 Nuclear Plans at game end, which seems unusually high, – but half of
those are out of order due to another power source.
However, if the meltdown probability is greatly increased, then long games on larger
maps could end up with a high total number of meltdowns, and already an expected
M=1 on Standard size can easily result in multiple meltdowns. You'd think that, after
the first one or two meltdowns, people would so something to secure those plants or
else abandon them ...
A map size adjustment could be justified by arguing that a single Nuclear Plant
represents several plants on smaller maps, but it would still make Nuclear Plants less
useful on smaller maps than on larger maps, which is counterintuitive.
Looking at it from the point of view of a single plant, the chance d of dying to a
meltdown over a 50-turn span is 1-(1-p)^50, i.e.
p d
1/2500 1.9%
1/2000 2.5% (BtS)
1/1500 3.3%
1/1250 3.9%
1/1000 4.9%
1/750 6.5%
1/500 9.5%
543
At some point, it becomes implausible that someone would construct such a time
bomb.
See also In the 4th bullet from the end, this post mentions an experiment to assess the proper
meltdown chance. (Better to stick to the math though.)
700 Rise & Fall game option; see chapter Rise & Fall. Id 700: the fundamentals. Other ids
only for code outside the R&F classes. Except for those highlighted in blue, all
changes in the following are only relevant if R&F is enabled.
Rationale For the term "intermediate period": Ancient Egyptian periodization (Wikipedia).
Config The number of chapters, interlude length and scoring delay are configurable through
GlobalDefines_advc.xml.
Tbd. Earth1000AD scenario not currently supported. During initialization, CvPlayer::
verifyAlive kills all civs because no cities have been created yet. I don't see how
the R&F code causes this, but apparently, it does. Also, the unequal AI handicaps
aren't currently supported by R&F. Would have to store the AI handicap (in RFChapter
and in savegame) before human takeover and restore it when AI control resumes.
Should perhaps factor game settings other than difficulty into the Rise score, in
particular the number and length of chapters. For now, my assumption is that a higher
number of chapters implies a lower number of turns per chapter, which makes it
harder to maximize the chapter score, and that this about cancels out.
Credits Inspired by board games like Peloponnesian War and History of the World (both from
1991) and Kael's Assimilation mod (which is included in Fall From Heaven II and
RoM).
544
See also Since R&F scoring is partially based on victory stages, it somewhat hinges on change
115, which revises the computation of those stages.
044 autosaves at the start of the active player's turn. R&F does so too, but the exact
timing is a bit different.
701 "Require complete kills" option replaced by the R&F option
AdvCiv BtS
When the last city of a civ is captured, all its When "Require Complete Kills" is checked, units
remaining units are removed, and the civ is remain in the game when the final city is
eliminated; there is no option for changing this captured. A civ is only eliminated when all of its
behavior. units are killed and all cities captured.
The option was added by patch 1.61, apparently
mainly for mods, specifically Jon Shafer's “Battle
for East Asia”.
Rationale I had already disabled the complete-kills option (for the reasons stated below) before
adding the R&F option. Removed it entirely now because it's easier to replace a game
option than to add a new one (while maintaining savegame compatibility).
Too much of a hassle to keep the complete-kills option in mind for all the AI code. I
doubt that the WL, BtS, BBAI and K-Mod code can really handle it either, especially in
team games when some team members still have cities and others don't. Not sure if
this option was ever intended to be more than a gimmick. You even need to kill every
enemy Spy (or since BtS: hope that the Spy kills itself somehow).
Now, in principle, the AI still needs to be able to handle civs without cities because a
human player could decide to never found a city. Through Advanced or later-era start,
the player could even have a sizable army, not to mention scenarios. I'm trying to
have the game at least not crash in such cases, but it's not really supported.
(Barbarians don't necessarily have cities either, but get special treatment in most of
the AI code; this works.)
Tbd. Instead of just removing the units, remove some, turn some into Barbarians and turn
some over to any teammates or (war) allies that the dead civ might have had before
its demise. This is more plausible and doesn't create issues for the AI.
Rise & Fall option not visible on the Staging Room screen.
Rationale Not multiplayer-compatible.
545
704 Changes to Dawn of Man (DoM) screen
Tbd. Adjust the layout so that the traits can be spelled out. Could be adopted from History
Rewritten, but I've made my own mockup, which I like better.
Show the screen at the start of each chapter.
Tbd. In the later chapters, the DoM can appear with a few seconds delay. Seems like the
EXE is too busy with something else. Perhaps this wouldn't happen if I'd launch the
popup earlier.
See also 004j: DoM screen shown after regenerating map
004x shows a choose-civics popup after the DoM screen when starting in a later era.
AdvCiv BtS
Heading of the DoM screen says "The Dawn of "Dawn of Man"
Civilization".
Rationale Perhaps they were thinking of Kubrick's "2001", which shows a subtitle "The Dawn of
Man"; but that is followed by a scene with apes ...
705 Rules and AI changes to prevent self-collusion (helping a civ from the previous
chapter that hasn't been scored yet, or one about to be taken over)
In addition to the AI behavior described in the R&F chapter:
The AI is a bit more lenient in pre-Currency tech trades – accepts if it receives only 90% of what
the player receives.
If UWAI is enabled, the AI refuses to talk when war utility is 20 or greater.
Rationale During a chapter, the player should (ideally) only have to consider the interests of
his/her current civ. The AI changes described above (and in the R&F chapter)
combined with intermediate periods can't completely prevent self-collusion but make it
much less relevant.
Restrictions don't apply to civs that the player is probably not going to want to play in
the next chapter..
Trade acceptance: With R&F, it can be extra annoying when the AI refuses to trade
two techs of (almost) equal value, but won't accept a 2 for 1 either because this would
already favor the AI too much.
War utility threshold: Don't want players to bypass trade restrictions through
reparations.
Would be nice to give the player more feedback, e.g. a grayed-out "gift" button, or the
AI responding "you're being too generous" when an offer is too good, but these things
seem almost impossible to implement. I did manage to get the AI to say "no thanks" to
gifts.
546
Tbd. Perhaps the AI should always show some leniency in pre-Currency trades, i.e.
regardless of the R&F option.
Perhaps reduce or remove the penalty for playing a civ multiple times.
Should the AI be willing to talk when all potential peace deals are too favorable for the
AI? E.g. when the AI wants the equivalent of 1000 gold and the player doesn't have
that much gold but does have some 5000-beaker technology. Currently, the AI is
willing to talk then, and that's a bit confusing. Though refusing to talk would also be
confusing I think – "How is that big technology not enough?"
The AI currently accepts certain resource trades that have a benefit for the AI side but
no benefit for the human side. For example, if the AI has 2 Rice and needs more
health, and the human has 0 Rice, the AI will accept a human non-surplus health
resource in exchange for the Rice. Such a trade could make sense for the human
player because of buildings like Granary, but, normally, it'll only help the AI. I have
some notes archived (offline) about how to fix this, but I'm not sure if it comes up often
enough to bother.
See also Help text for the gift-unit button based on 093
706 Changes related to AI Auto Play and switching the human-controlled civ
When the player "Retires", the current chapter completes on AI Auto Play. The intermediate periods
in between chapters aren't actually AI Auto Play; there simply isn't a human-controlled civ at all.
I hide some UI interface elements during intermediate periods and suppress advisor screens and
popups. This has required changes in a bunch of different places.
Rationale The player may simply want to end a chapter because he/she doesn't feel like
completing it. But retirement is mainly intended for situations when things are going
too well. The civ could then become a huge obstacle in later chapters (or just win the
game for the AI). Don't want the player to sabotage his/her own civ then.
Tbd. After retiring, the player's civ keeps the game handicap, e.g. Prince, but, since the civ
is treated as an AI, the AI modifiers from the game handicap also apply, e.g. 5% faster
training of units on Prince. This is confusing, but difficult to change because the AI
modifiers get applied in many different places. AI Auto Play without retirement applies
the AI handicap (change 127), which is consistent, however, a retired civ should
generally do rather badly because retiring is supposed to help when the player's civ
gets dangerously far ahead. Perhaps set the handicap after retiring one higher than
the game handicap (or always Monarch?) to somewhat cancel out the AI modifiers.
Known issue: When taking control of a civ via Civ Changer (Alt+Z) for debugging
purposes (in a R&F game, to be clear), all non-expired messages that that civ ever
received are displayed on the main interface. Calling CyInterface().
clearEventMessages() from ChangePlayer.py doesn't get rid of them.
See also Hinges on 127, which allows MoreCiv4lerts to work when the player takes control of
an AI civ. Also records start and end of AI Auto Play in replays, which makes it
unnecessary for R&F to record early retirement in replays.
The K-Mod code that 058 (re-)moved was messing up the interface messages sent to
AI civs (which the human player may eventually read after switching civs).
547
707 Changes to the game end sequence
No game end upon defeat; Rise score shown als "final score" in HoF, scaled up ("normalized
score") for the Dan Quayle screen.
See also 043: Uses stricter thresholds for the titles on the Dan Quayle screen.
548
number of free wins against Barbarians.
127: The difference between game handicap and player handicap is also relevant for
AI Auto Play.
CFC post by a Deity player characterizing city maintenance on Monarch and below as
being of “little to no impedance to your expansion.”
Decreased all research costs by 3% (through the DLL), in part offsetting the increased player
handicap (which implies increased research costs).
Rationale A human player with skills well above the player and game handicap always being in
charge of one civ should lead to faster research overall than one would expect from
e.g. a game on Noble difficulty (game handicap), but, then, the human player is, for
much of the game, in charge of a civ that catches up, so it would seem that the proper
cost should be somewhere between the game handicap and (increased) player
handicap.
See also 910 is more generally concerned with having the pace of research match the historical
time line (game date).
549
Rationale Don't want players to work around bad health from Jungle by keeping their borders
closed. The disease carriers are mostly insects; borders don't stop them.
When a tile with a happiness or health effect becomes accessible or inaccessible, the city's health
and happiness aren't updated until end of turn.
Rationale Too much work to make sure that updates happen whenever tile ownership, team
membership, vassal agreements or Open Borders change.
Added an XML tag HealthPercent to CvImprovementInfo so that Forest Preserve can grant
health instead of happiness. That health can be fractional and is added to health from features
(rather than being rounded separately). With AI and UI support (both of which were horrible to write
because of rounding – separately for good and bad health effects – and the possibility of muliple
cities being affected). For now the tag remains unused, but some of the new AI code is used for
evaluating the removal of Forests and the happiness ability of Forest Preserves. Negative effects
are now also supported.
Rationale Not urgent enough to change before AdvCiv version 1.0. By the time that Forest
Preserve becomes available, extra health tends to be more valuable than extra
happiness. Livability can be represented just as well through health as through
happiness. (I'd prefer to use happiness mostly for effects with a fairly direct political
dimensions, e.g. ludi at the Colosseum, luxury resources handed out as perks.)
See also Some discussion about this on CFC (1 2 3)
UI code based on 059.
055 adds an (unused) improvement ability that protects terrain features from Global
Warming.
Config It's an optional tag. See Civ4TerrainSchema.xml to find out the proper position in
Civ4ImprovementInfos.xml.
Tbd. Health is is currently overcounted; see comment in
CvCityAI::AI_healthHappyImprovementValue.
Make the Forest spread ability more predictable and more useful. Grant health instead
of happiness. CFC post (Though this more recent post in Strategy & Tips argues that
the BtS spread probability isn't far too low to be useful.)
550
Watermills are decent with Replaceable Parts but rarely useful before that (whereas, historically,
they were highly useful throughout the Middle Ages). The K-Mod change to Serfdom (+1
commerce from Farms) exacerbates this. One commerce at Machinery (also a K-Mod change) is
the least that needs to be done.
Commerce from Electricity is apparently supposed to get the shift from waterwheels to turbines
across (similar for Windmill). That's OK (electricity can be sold), but doesn't have to be so
pronounced. Electricity boosting local production is also plausible.
Never saw why Watermills should be slow to build. Perhaps originally an attempt to make Serfdom
attractive – well, that didn't work. Reducing build time is a way to make Watermill better early on
without making it too good later on.
Tbd.: Still a bit unattractive. 6 turns to build but +2 production earlier?
Lumbermill at Guilds at Guilds at Replaceable Parts
+1 commerce initially; +1 river commerce, +1 riverbank commerce,
+1 production with +1 production initially; +1 production initially;
Replaceable Parts;
5 turns to build 8 turns to build 8 turns to build
+1 production with +1 production with +1 production with
Railroad track; Railroad track; Railroad track;
doesn't remove Forest doesn't remove Forest doesn't remove Forest
The middle column is K-Mod 1.45; I'm keeping the earlier version (not shown above) and I'm
reducing the build time in order to give Lumbermill a little extra push. Also, Replaceable Parts is
just one tech away from Steam Power, which grants +50% Worker speed, but since Lumbermills
are now at Guilds, that bonus is still out of reach, so they really take a long time to build in K-Mod.
I don't think players can be incentivized to not chop all Forests along rivers; not without making
Lumbermills too strong in the late game. Therefore, I don't like the river commerce ability (not on
Forest Preserve either).
Tbd.: Want to move both Lumbermill and the +50% chopping yield (currently at Mathematics) to
Machinery eventually, and apply chopping yields only to buildings and ships (not land units).
903,904 reserved
551
Carrack 4 moves, 3 moves, 3 moves,
2 cargo, 3 cargo 2 cargo
removed AI type
"Reserve"
Navigation2 promo Only available for units Available for all sea units
that can enter ocean
Should give Galleys a use in early warfare (fast deployment), and make them better explorers. If 3
moves aren't enough to make naval deployment useful in land wars, then 4 moves with
Navigation1 should do the trick. Sea units moving twice as fast as infantrymen along roads is
reasonable from a historic pov, but 5 moves might be a bit much, also gameplay-wise. Therefore,
I'm restricting Navigation2. Makes sense that "navigation" benefits ocean-going vessels more.
4 moves for Caravel to keep it faster than the early ships. Now just as fast as Galleon, which is
also more accurate historically. Carracks, caravels and galleons could travel at 4 to 5 knots,
triremes at 2 to 3 (much faster during battle; see e.g. Olympias on Wikipedia).
3 strength for 45 production makes Trireme a viable warship (perhaps even the best) until Frigate,
which should make Triremes more worthwhile overall and might help the AI, which tended to train
too many Caravels previously. Should now train a mix of Triremes and Caravels, and use only
Triremes for protecting resources and escorting Galleys. May still train too many ships, but at least
Trireme is cheaper than Caravel. While I'm at it, the upgrade from Trireme to Privateer is a bit less
painful than to Frigate because Privateer is cheaper than Frigate, and this should make AI
privateering a bit more common.
Historically, trireme-based ships remained in use in the Baltic Sea until the 18th century, and their
usage didn't decline until the 16th century. "[The Battle of] Lepanto [1571] marks the last major
engagement in the Western world to be fought entirely or almost entirely between rowing vessels,
the galleys and galeasses that were still the direct descendants of the ancient trireme warships."
(Wikipedia)
Carrack: K-Mod had increased the cargo capacity along with the other transport ships, but I think
this takes the unit unnecessarily close to Galleon, especially now that I've increased the speed
(can't not increase Carrack speed if I increase Caravel speed). Back to 2 cargo spaces.
Tbd.: Require Optics or Astronomy for Navigation2; that's more elegant than the restriction to
oceangoing ships. Galleys with 4 moves should be more common; remove the Flanking I
requirement from Navigation I. But will then have to find another way to make Flanking I attractive,
and Trading Post will have to change.
"Explore rival territory" of Carrack should perhaps not work with military units in cargo (unless
those units somehow also have that ability).
See also: 124 assigns Galley the Explore AI type.
306 changes research costs to make Trireme a bit easier to access.
CFC post suggesting that 3-move Barbarian Galleys appear out of the blue too often.
552
requires Oil requires Oil or Uranium requires Oil or Uranium
can't attack
East Indiaman unique Frigate unique Galleon unique Galleon
5 moves 4 moves 4 moves
3 cargo 5 cargo 4 cargo
8 strength 6 strength 6 strength
bombard rate 12 can explore rival territory can explore rival territory
cost 90 cost 80 cost 80
upgrades to Destroyer upgrades to Transport upgrades to Transport
or Transport
req. Astronomy, req. Astronomy req. Astronomy
Chemistry, Iron
Privateer 5 moves 4 moves 4 moves
Frigate 5 moves 4 moves 4 moves
8 strength 8 strength 8 strength
bombard rate 12 bombard rate 8 bombard rate 8
cost 90 cost 90 cost 90
upgrades to Destroyer upgrades to Destroyer upgrades to Destroyer
req. Astronomy, req. Astronomy, req. Astronomy,
Chemistry, Iron Chemistry, Iron Chemistry, Iron
Ship of the Line 4 moves 3 moves 3 moves
10 strength 10 Strength 8 strength
+25% vs. Frigate +20% vs. Frigate +50% vs. Frigate
bombard rate 16 bombard rate 12 bombard rate 12
cost 110 cost 120 cost 120
req. Astronomy, Military req. Astronomy, Military req. Astronomy, Military
Science, Iron Science, Iron or Copper Science, Iron
Credits: CFC user vedg pointed out here that there aren't enough incentives for upgrading
Galleons and East Indiamen.
Rationale:
Transport: Having just 25% more cargo space than Galleon doesn't justify a more than 50% higher
cost. Often not worth upgrading. To balance out the lower cost, I've removed the offensive abilities,
which aren't entirely unimportant against rivals without Combustion. The unit can still "besiege"
water tiles, i.e. prevent them from being worked. The lower strength should give pre-Combustion
ships a fighting chance against besieging Transports, and shouldn't make much of a difference
against post-Combustion units. While I was at it, I removed the Uranium requirement for historical
accuracy; see this CFC discussion.
East Indiaman: Also no incentive to upgrade to Transport. On top of that, historically, East
Indiamen appeared a century later than galleons, and were usually larger than frigates. Rather
than a warlike Galleon, this is now a Frigate with cargo space. The ability to enter rival borders is
messy on cargo ships because these ships (and their cargo) don't get bumped upon declaring war
(see Tbd. under 905a). The Civilopedia states that "the East Indiaman was inevitably slower than
its descendants: the Ship of the Line and the Frigate." This appears to be nonsense: East
Indiamen were often full-rigged clippers that could sustain speeds of 10 knots, whereas ships of
the line sailed at perhaps 5 knots.
Bombard rates: 8 is the same as Catapult, far too little for ships equipped with cannons. Did not
increase Ironclad's bombard rate (12 as in BtS) because at least early ironclads weren't as heavily
armed as ships of the line.
Speed increases: Even early frigates appear to have traveled at a speed of about 10 knots; much
faster than galleons. According to Wikipedia, “a long hull-design, which relates directly to speed”
553
was characteristic for frigates. While early privateers were galleons, the Privateer unit in the game
is contemporary with Frigate and should therefore have the same speed. Ships of the line traveled
at about 5 knots, which is much slower than frigates, but rather faster than galleons and caravels.
Assuming some sort of logarithmic scale, speed 4 is justifiable. Speed 3 made it too difficult to use
Ship of the Line offensively. See also this post of mine on CFC; thanks to Pepo for pointing out that
Frigate needs to be faster.
Ship of the Line: I don't love the K-Mod change to strength; it makes Ship of the Line stronger,
which is good, but does so partly at the expense of Ironclad, which is also too weak. 120
production seems pretty clearly overcosted. I've restored the BtS Iron requirement because it
doesn't make sense from a historical point of view to require Iron for Frigate and not for Ship of the
Line. The latter requires more metal parts (cannons, cannonballs, nails(?)), and thus has more
need of a cheap metal. The K-Mod changelog says the goal was to give "ironless civs a decent
naval ship if they go for the right tech." Fair enough – but not really important. I hope my other
changes to Ship of the Line can give the unit more plausible (niche) uses.
Tbd.:
Bombard rates are still a bit too low. Ship of the Line and Ironclad need to be buffed further, and
Frigate should upgrade to Ironclad. Want to allow Transport, Destroyer and Battleship with Coal,
but with a movement speed penalty. Move Transport to Industrialism and Destroyer and Battleship
to Artillery.
Could give Frigate and Ship of the Line +1 strength to make both more effective against Privateer
and then restore Ship of the Line's 50% bonus against Frigate.
Frigate should be allowed to carry 1 “special” unit, or perhaps even a military unit, and should be
able to enter rival borders (so long as no military units are carried). Caravel and Carrack should
then upgrade exclusively to Frigate.
See also: 081 about AI changes to employ naval bombardment in land wars.
Config: Civ4UnitInfos.xml; note that East Indiaman is called NETHERLANDS_OOSTINDIEVAARDER
in that file.
Ironclad 3 moves 3 moves 2 moves
+25% Coast defense req. Steel and req. Steel and
req. Steam Power Steam Power Steam Power
Rationale: To match the increased strength of Ship of the Line. The defense ability is a bit more
flavorful than just +1 strength (and 13 would be an unusual strength value); ironclads had difficulty
sinking each other and their battles tended to be stalemates. There is no generic defensive bonus
in Civ 4 (though it would be easy enough to implement one), hence the terrain restriction. Note that
cultural borders can allow an Ironclad to enter Ocean, so the restriction is not entirely irrelevant.
Removal of the Steel requirement gives Ironclad a longer window of utility. Also, the first ironclads,
produced in 1862 for the US Civil War, were not clad in modern steel: the first steel mill in the US
based on the Bessemer process was set up in 1865.
Tbd.: Stalemates aren't always fun; if it turns out that the ability plays badly, I could still just
increase combat strength. It may also, despite the K-Mod change, still be too difficult to engage
faster ships. Even early ironclads were only a few knots slower than frigates, so speed 4 would be
justifiable; the restriction to Coast would still get across that ironclads aren't as mobile as frigates.
XML tag added for extra speed with access to a resource. Unused for now. “Access” means that
either the unit's current tile or the owner's capital has access to the resource. The tactical side of
the AI (CvUnitAI) is aware of the increased speed, but I haven't changed the strategic evaluation
(CvPlayerAI) of resources and units.
Sevopedia articles about resources now have a “Units” box instead of “Allows” so that units can be
listed in articles about resources. Buildings that require resources (none in BtS and, so far, also
554
none in AdvCiv) are placed in the “Buildings” box instead of “Allows”.
Tbd.: Should perhaps guarantee the extra move until the end of a turn if the resource was available
at the start of that turn.
Use the ability for Industrial-era ships: allow them to be trained with Coal, but make them faster
with Oil. Uranium should then be removed as an alternative requirement for Destroyer.
Rationale: Until AdvCiv 0.97, I had used this ability to represent auxiliary steam engines that were
installed on ships of the line in the early 19th century (Wikipedia), but, when I realized that Frigate
is too slow in BtS, this complication became unnecessary because, with Frigate at speed 5, Ship of
the Line can have speed 4 without any special justification.
The details of what it means that a unit has access to a resource are a little messy. The trade
network doesn't extend onto hostile tiles, but I don't want units to lose speed in hostile territory,
especially not immediately upon entering. Relying entirely on the availability in the capital could
lead to situations where a unit sits right on a resource tile in a friendly Fort or city, and still doesn't
get the movement bonus when the tile isn't connected to the capital. With the current solution, a
unit can, in theory, still lose its extra moves upon entering hostile territory, but this should be rare.
No strategic AI evaluation: I want to use this ability only for giving naval units (which are already
fast) one extra move; i.e. the significance is going to be minor.
555
requires Stealth requires Stealth requires Stealth requires Stealth
and Robotics and Robotics and Robotics
Rationale: The BtS submarines were too weak against Battleship and the role of Attack Submarine
(hunter-killer) was too narrow. Now Attack Submarine is the ordinary submarine unit for the World
Wars, and Missile Submarine a more expensive unit representing the cruise missile and ballistic
missile subs of the Cold War. First strikes match the flavor of torpedoes and invisibility well;
consistent with first strike on Stealth Destroyer. Strength 25 and 5 first strikes would have a nicer
symmetry with the 50% withdrawal ability, but that would make Submarines a bit too effective
against Destroyers, which, as anti-submarine units, get to ignore first strikes.
Increased the cost of Battleship in order to further weaken that unit against submarines. The BtS
cost is also too close to that of Destroyer.
Stealth Destroyer isn't needed as an efficient combat unit, and this would also be unrealistic. The
few stealth destroyers that have been manufactured are classified as multi-role guided missile
destroyers, and have strong anti-air and anti-submarine weapons. These additional abilities make
the Stealth Destroyer an expensive Swiss Army knife. Removed one first strike to make the
multiple first strikes of the Submarines more special. The Robotics requirement seems nonsensical
and makes the unit very difficult to access.
Credit: Dawn of Civilization lists Stealth Destroyer's submarine detection as a bugfix in its list of
features: "Stealth Destroyers detect Submarines as (presumably) intended"
See also: 028 allows Submarines and Stealth Destroyers to defend weaker visible units.
I've only skimmed through this thread (title: "Submarine Confusion"), but I think the participants
mostly agree that BtS has its two submarines confused.
164 makes the Blitz promotion easier to access (also for post-Renaissance ships).
Tbd.:
Destroyer is still a bit weak against Submarines. May have to give it an explicit combat bonus
against Submarines (instead of relying entirely on first strikes vs. first-strike immunity), or give
Submarines an Ocean attack bonus.
Would be nice to show the abilities shared by the two submarines more compactly in help text and
Civilopedia:
"Submarine (invisible, reveals Submarines, can dive under Ice, can explore rival territory)"
Lower the strength of all post-Combustion ships a bit; they don't need to be that much more
powerful than Ironclad.
Air recon shouldn't reveal Submarines so easily.
Would like to give Stealth Destroyer two missile slots, but so long as two Tactical Nukes can
eliminate any stack, this seems a bit too dangerous.
Missile Cruiser needs work. Want to move it to Rocketry, but will first have to make room by
moving the spaceflight stuff to Satellites.
556
Rationale Clearly intended to be easy to recognize as powerful even for new players,
and it worked, but this mod isn't for new players, and the unit is toxic for
game balance. Supplants all pre-Renaissance units plus Musketman.
Because it's so obvious, I'm nerfing this unit before all others.
7 strength for 40 would be fine, I think, but bland. March is a promotion that
doesn't give the unit more raw power, but is still useful, and a good fit
flavor-wise as the Roman army was known for its forced marches. (Trivia:
The BtS manual incorrectly claims that Phalanx starts with March.)
As for the name change (only in the English game text), Soren Johnson
mentioned in a Twitch video that "Praetorian" was chosen over Legion(ary)
to avoid repeating too many names from Civ3, and seemed regretful about
this. Legionary is obviously a better fit for the BtS unit, and also fits well
with my changes.
Looks like karadoc had also been considering a name change; there was a
text key commented out (now deleted) in the K-Mod game text file that
would name the unit “Legion”.
See also 131 gives Legionary Attack City as its default AI type.
CFC thread discussing overpowered unique units.
AdvCiv BtS
907c 2 moves, 3 moves
Fast Worker ignores terrain
movement costs
See also Version 3.0.0.5 of the “Rebalance the Realms” (RtR) multiplayer mod gives
Fast Worker the Mobility promotion. RealmsBeyond.net (under “Civs”). The
current version of the mod (5.1.1.0) instead replaces Fast Worker with a
“Urukku Pikeman” (urukku presumably refers to wootz steel). The Close to
Home fork of RtR also uses the Mobility promotion. The Tides of War
multiplayer mod gives Fast Worker a higher production cost.
557
Rationale Widely regarded as one of the best unique units. This is a bigger nerf than I
would like, but I really think that no pre-modern land unit should have more
than 2 moves, and it seems that the most skilled players appreciate Fast
Worker most for being able to move and chop in a single turn – an ability
that my change preserves.
Ignoring movement costs vs. Mobility makes a difference only on
Forest/Jungle Hills. Most players probably aren't aware that the movement
penalties stack in those cases, and I don't think they should be aware. Also,
free Mobility would be an even weaker ability than the one I use.
Tbd. The name “Fast Worker” doesn't fit well for the new ability, and it's a lame
name in any case. It's also not clear why India should have any such unit at
all; the reasons given in the Civilopedia are at best contrived and at worst
an offensive stereotype.
AdvCiv BtS
907d strength 4, strength 4,
Skirmisher 0-1 first strikes 1-2 first strikes
See also Recent CFC thread with some opinions on Skirmisher: link
Multiplayer balance mods: The minimalist Tides of War multiplayer mod
sets it to 0 first strikes. Rebalance the Realms adds a 40% attack penalty
against Archers. Close to Home leaves the unit as it is in BtS.
Rationale One extra strength on an early unique unit is generally too much without
any drawback. Since Archers aren't good at attacking cities, it might've
been enough to remove only the first strike chance, especially considering
that Mali already suffers from a nerf to the Financial trait (see change 908a
below); hard to say. Mali still does well in all-AI games.
558
See also Multiplayer balance mods: Tides of War gives War Chariot only 4 strength
and 2 first strikes (and no immunity); no change to Immortal. Rebalance the
Realms gives War Chariot a 25% penalty vs. Archer(y?) and new abilities
altogether to Immortal. Close to Home leaves both as in BtS.
CFC report about an AdvCiv 0.97 game on Emperor difficulty where the
player immediately conquers two neighbors with War Chariots, then agrees
with me that War Chariot and Immortal are arguably too powerful.
CFC thread about trying to beat AdvCiv 0.98 on Deity through War
Chariots. Doesn't really work, but still suggests that War Chariot is the most
effective early rusher with Quechua already nerfed at that point.
Related post where user drewisfat indirectly refers to War Chariot as “super
OP.”
CFC post (end of the post) arguing against AdvCiv nerfing Immortal, seeing
that Persia's Financial trait was already nerfed.
2010 CFC thread comparing War Chariot and Immortal
Rationale About War Chariot, there seems to be pretty broad agreement that it's
among the most powerful units, if not in multiplayer, then at least against
the AI. It's not so clear how much War Chariot should be nerfed and
whether Immortal is just as problematic.
Focusing on both units' potential as early attackers against lightly defended
AI cities, dcor's combat odds calculator (download no longer available) tells
me that a regular Chariot has 8.3% victory odds (i.e. 18.3% survival)
against a fully fortified Archer in a city with 20% culture defense. In BtS,
both War Chariot and Immortal do about 20 points better: War Chariot has
28.3% victory odds, Immortal 27%. With the changes that I've made, the
victory odds become 22.8% for War Chariot and 24.1% for Immortal. With a
Combat I promotion, both units land again around 27-28%. Do I want to
nerf War Chariot further by slapping +5 on the production cost? Can't
decide, so I'm going to leave it as in BtS.
Tbd. The Immortal should be turned into a completely different unit, namely a
Spearman (graphics from e.g. Realism Invictus) with a national unit limit.
The current stats are complicated, weird and difficult to connect with
Persian history.
559
908a +1 commerce in tiles +1 commerce in tiles with +1 commerce in tiles with
Financial with a natural yield* of at least 2 commerce. at least 2 commerce.
at least 2 commerce or
a total yield of at least 3 Faster production of
commerce. Bank
* By "natural yield" I mean the yield from terrain, feature, river and hill. Yield from improvement,
building, trait or civic is not part of the natural yield.
See also 031 and 053 reduce AI found values counted for rivers (with the Financial
trait change in mind).
Several mods, e.g. Rebalance the Realms (RtR), raise the extra yield
threshold from 2 to 3, which is easy to do through XML. The RtR fork Close
to Home preserves the threshold of 2 on water tiles.
CFC post lamenting how much the Financial trait is nerfed by AdvCiv. (As
the next post points out, Organized trait being superior to Financial would
be due to the map size and rapid military expansion; so be it.)
Reddit thread discussing the change (and arguing for a Bank discount from
Financial).
Rationale The Financial trait is easily the most potent trait in the hands of the AI, to
the point that games with several Financial leaders get far ahead of the
historical time line, and, unlike most other top-tier traits, players can't help
but exploit it. Plus, the K-Mod change to Serfdom makes Financial even
more powerful.
Tbd. The nerf perhaps goes a little bit too far. Restore the pre-1.61 building
discount? I think I'd like a discount for Market better because the Bank
discount coincides with the English unique building (Stock Exchange) and
two of the English leaders have the Financial trait. The Bank discount also
seems more powerful. On the other hand, change 911b already reduces
the base cost of Market, Bank is more flavorful given the name “Financial”,
and the Bank discount had been the designers' original intent. The patch
may have been intended both as a nerf of the Financial trait and of the
English civ – Redcoat was still a very powerful unit at that time (but no
longer is since the Warlords expansion).
Config Through a new XML tag ExtraYieldNaturalThreshold. Not very flexible,
but at least this allows mod-modders to restore the original trait effect (by
using the original ExtraYieldThreshold tag instead the new tag).
(Before v1.0, I had simply given the old tag the new semantics.)
AdvCiv BtS
908b • Cities start at Fledgling culture level
Creative (including conquered cities once
occupation ends).
• +1 culture rate in all cities. • +2 culture rate in all cities.
• Faster production of Library and • Faster production of Library,
Theater. Theater and Colosseum.
See also Chapter about changes to the culture system
560
Rationale Creative is already a powerful trait in BtS and easy to use; the changes to
the culture system make it too powerful, considering that other powerful
traits get nerfed. It's also frustrating to have a Creative leader as a
neighbor; usually not economical to compete with them for border tiles.
Just halving the culture rate bonus goes too far, so the (one-time) free
culture is supposed to compensate to an extent. Also removes the rather
pointless 5-turn waiting period until the borders of a new city expand, thus
also communicating more clearly what the Creative trait is useful for
(expanding borders). One might argue that the 5-turn delay is an important
check on the early-game access to strategic resources – but one can
always get that by settling adjacent to the resource (or even on top of it).
Not sure if the ability should really apply to conquered cities. Seems more
consistent with the old ability this way (the +2 culture per turn applies to all
cities – so long as they're not under occupation).
Tbd. Getting access to the outer ring 5 turns earlier in new and conquered cities
might be more powerful than I realize. One could exclude conquered cities
if the current ability is too powerful. If it's not powerful enough, one could
restore the discount for Colosseum. I had removed that in AdvCiv 0.99 as a
minor balance change that, in my view, turned out to be insufficient. The
flavor doesn't really fit, but at least it would give players a reason to
construct Colosseums sometimes.
Config Can restore the BtS abilities through Civ4TraitInfos.xml and
(Colosseum discount) Civ4BuildingInfos.xml. In Civ4TraitInfos.xml,
the new tag iFreeCityCulture gets displayed as “cities start at such-and-
such culture level” if the free culture is exactly equal to the threshold of a
culture level; however, it's also possible to set any amount of free city
culture.
Also reduced the culture rate of Terrace from 2 to 1.
Rationale Terrace is regarded as a light version of the Creative trait; don't want it to
become actually more powerful than the Creative trait. Also, it's arguably
the most powerful unique building in any case and the culture changes in
AdvCiv are making it even better.
See also 201 deals with other changes to building culture rates.
Hippodrome grants 1 happiness per Hippodrome: 1 happiness per 5%
10% culture; Theater and its other culture; other Theater-class buildings:
unique replacements grant 1 1 happiness per 10% culture.
happiness per 20% culture.
Colosseum and its unique 1 happiness per 20% culture.
replacements grant 1 happiness per
10% culture.
Rationale To make up for the lost production discount from the Creative trait.
Colosseum is already a pretty weak building in BtS, don't want to make it
even less appealing overall. (That said, a substantial buff would make
Temple too unappealing.)
Between Colosseum and Theater, it's more intuitive to give Colosseum the
stronger happiness ability because Colosseum is all about happiness and
Theater primarily about culture. And using the culture slider against
(temporary) problems with unhappiness feels like a pretty faithful
representation of Roman ludi. Weakening Theater a little bit doesn't hurt.
561
See also 200 reverts the K-Mod changes to Colosseum (25% culture, +20 production
cost); 251 lowers the Legendary culture threshold instead.
910 Era tech cost modifiers adjusted (increased overall). These modifiers were
added by BBAI. There's one per era, and it changes the costs of all techs in
that era. K-Mod has tweaked them, and eventually (version 1.45) tied them
to the inflation rate, a change not adopted by AdvCiv.
Rationale To match the historical dates of discovery better. E.g. Gutenberg's printing
press was invented around 1450, so the Printing Press tech shouldn't be
discovered much earlier in a typical game of Civ.
Config Set in Civ4EraInfos.xml
562
See also 251 adjusts the AI research speed based on difficulty.
140 adjusts tech costs based on map size.
308 lowers tech costs when Raging Barbarians is enabled.
550d lowers tech costs when playing without tech trading.
174, 306, 131b: Balance tweaks to some tech costs
Tbd. Perhaps reduce the travel duration of the spaceship. 10 turns is a long time
that late in the game and it's not like the spaceship launch comes as a
surprise.
AdvCiv BBAI
The era tech cost modifier is applied to the tech Applied to the every civ's research rate.
cost.
Rationale More transparent this way, as (modified) tech costs are prominently
displayed.
No research speed bonus for possessing a singleBtS grants a 20% research speed bonus for
prerequisite tech. Reduced era tech cost every known prerequisite tech, even for the first
modifiers a bit, but it seems that various AI prerequisite. (Only prerequisites represented by
changes have accelerated the AI tech pace an arrow count in this context; called “or prereqs”
enough to almost make up for the -20% in the code.) As a BBAI comment observes, “this
research, so the AdvCiv cost modifiers aren't that [effectively reduces] the cost of most techs on the
different from those in BBAI and K-Mod. tech tree [by 20%].” Not all techs because e.g.
Astronomy has no incoming arrow, and the six
techs in the very first column have no
prerequisites either. BBAI has added an XML
setting for disabling the speed bonus for the first
known prerequisite.
Rationale I want to leave the research times (turns to research) mostly unchanged
because the original developers and modders have balanced the game
around those research times. Whether a tech has an incoming arrow or
dangles in the air is a technicality that should affect neither research speed
nor cost.
Again, a tech cost adjustment is more transparent than a research speed
adjustment.
Note that research generated through the discover (“bulb”) ability of a GP is
unaffected by research rate modifiers, so turning a research rate bonus into
a tech cost discount makes bulbs more powerful. However, this is pretty
much evened out by the change to the era-based modifiers above.
Config The BBAI setting is TECH_COST_FIRST_KNOWN_PREREQ_MODIFIER in
TechDiffusion_GlobalDefines.xml.
AdvCiv BtS
563
Help text for technologies that the active player The modifier comes only from OR prereqs (see
can research shows (also on the research bar) above) and diffusion. It's not shown anywhere.
the research modifier for the given tech unless
it's 0, and a breakdown of the modifier. Since all
the static factors are now applied to the tech cost
modifier instead of the research modifier, the only
components in the breakdown are “from
diffusion” (BBAI diffusion if enabled, otherwise
the BtS research bonus from teams that already
know the tech), “from tech prereqs” (more than
one OR prereq) and “from teammate with same
research” (see 156).
Rationale Anything related to research speed is an important statistic. And need to
make players aware of change 156 (in team games).
On the research bar and the choose-research
popup, help text shows when one researchable
tech is going to speed up another. E.g.
“Priesthood – Speeds up Writing by 20%” Doesn't mention the link to Writing at all when
when Animal Husbandry already makes Writing Writing is already enabled by Animal Husbandry.
researchable. Or
“Code of Laws – Can be sped up through No reminder about possible speed-ups.
Priesthood by 20%” when Priesthood not yet
discovered.
Rationale I had at first thought that the “can be sped up” text wouldn't be needed, but
I've come to realize that it's an important reminder.
See also CFC post requesting the “can be sped up” text.
The BULL option “Speeds Up info” shows essentially the same information,
but I've written my own code because the text has to match the change in
the blue box above and the one below.
When hovering over a tech (as above), the techs Ordered by tech id, which is determined by the
enabled by that tech are listed in the following order in Civ4TechInfos.xml, i.e. arbitrary.
order:
1. Techs that will be immediately enabled before
techs that have another missing requirement.
2. Within these categories, techs are ordered by
cost (ascending).
Example:
“Mathematics – Leads to Construction, Currency “Mathematics – Leads to Music, Civil Service,
and later Calendar, Music, Civil Service” Calendar, Currency, Construction”
Tbd. Would be nice to do something similar for enabled units (also taking into
account resources?) and buildings.
Revised the years-per-turn progression to let the game reach the 2nd half of the 20th century after a
considerably smaller number of turns than in BtS and AD 1 a little later.
564
Rationale Can't keep increasing tech costs whenever the AI becomes more effective.
Another aim has been to bring down the date of the earliest wars between
civs. In terms of tension, I think it's actually fine if a first war happens well
after 100 turns (on Normal speed; though I guess it really should be closer
to 100 turns than to 150); it's mainly the displayed years that have been
bothering me.
Config Civ4GameSpeedInfos.xml. Tricky to make (further) changes – the total
turn count needs to add up to the turn limit (e.g. 500 on Normal speed)
while the year increments need to add up to 6050 (for an end date of AD
2050). I've used an Excel sheet to get this right, still took some trial an
error. I've also looked at tech discovery dates in some sample games to
come up with desired associations of turn numbers with game years.
The tech cost modifier based on map size Duel size has 100% tech cost, from there it's
increases in small increments (5 percentage +10% for each size level.
points) for the small map sizes, makes a jump
from Standard (115%) to Large (137%) and a
smaller jump from Large to Huge (150%).
Rationale Trial and error. I don't understand why Large maps lead to much higher
research rates than Standard size.
See also 140 deals with other map-size adjustments.
The map size modifier is ignored for Ancient-era Applies to all techs equally.
techs.
Rationale In the Ancient era, the map size doesn't normally affect the pace of
expansion, and the number of civs met doesn't matter yet because tech
trading doesn't become available until the Classical era.
Credits Got the idea from the BASE mod (v6.3 changelog; in German). It sounds
like BASE might also exempt Classical tech.
Tbd. Perhaps apply the modifier half (or times 75%) for Classical tech.
If tribal villages are disabled, the cost of Ancient techs is reduced by 5%.
In Always-Peace games, tech costs are increased by 5% after the Ancient era.
Tech costs are adjusted to the sea level setting (if The sea level affects the space available for
the map has one): +20% with Low sea level, cities.
-15% with High sea level.
See also 137: impact of sea level on the number of supported players.
Config Added a tag to CIV4SeaLevelInfo.xml for the sea level modifier. The tag
is called iResearch because that's how BtS usually names tech cost
modifiers.
565
Rationale So that players who want to conduct active espionage missions in the
midgame don't have to wait until Constitution. I think it's fair enough if
espionage-focused strategies only become viable toward the Industrial era,
but it doesn't hurt to enable them earlier – so long as this doesn't mean that
the espionage systems becomes more difficult to avoid for players (such as
myself) who dislike it. A concern that Courthouse may become the go-to
building for early Great Person “farms” is hopefully addressed by the
changes to Market and Grocer below.
An alternative consideration was to replace the +25% espionage at Castle
with the Spy specialist slot from Jail. Considering how late Castle becomes
available and that it's a very situational building, this would've been quite an
extra hoop to jump through.
In BtS, it was possible to get an espionage-based economy started through
an early Great Wall. This is no longer possible in AdvCiv, so the extra Spy
slot at a non-wonder building is supposed to compensate for that.
See also CFC post by drewisfat. The last paragraph (written prior to the Courthouse
change and without having played AdvCiv) argues that adopting an
espionage economy is (essentially) only ever worthwhile in the early game
due to AI spam of espionage buildings and spies in the late game. I don't
think the AdvCiv AI behaves that way. K-Mod has revised much of the
espionage AI code and AdvCiv has fixed a K-Mod bug that had caused the
AI to run the Big Espionage strategy far too often, and has made further
tweaks that discourage AI investments into espionage; cf. 120.
These changes in mind, I hope that the Spy slot at Courthouse comes early
enough to make an espionage economy a consideration sometimes.
911b - Market, Grocer 130 production cost 150
Rationale They're overcosted in BtS, but so are many buildings, in particular other
happiness buildings. I don't want to adjust too many building costs (avoid
overwhelming players with the volume of rule changes), so I'm making only
a moderate adjustment that doesn't make Temple and Colosseum look too
much worse.
The impetus for changing Market and Grocer at all is that I want to avoid
making Courthouse a superior choice for Great Person “farms.” Don't want
players to feel that they have to engage with the espionage system beyond
passive missions.
911c - Aqueduct, 90 production cost 100
Baray
Rationale It's pretty clearly overcosted in BtS – worth +2 food at best – and for an
early building that is almost iconic for the Civ series, that's more of a shame
than e.g. Customs House being (even more) overcosted. Also, this minor,
self-explanatory cost change should demand very little attention from
players who are new to AdvCiv.
A cost of 80 could also be justified (that what the Close to Home multiplayer
mod does for example), but I think 90 should be enough to make Aqueduct
worthwhile when the extra health is really needed, and I don't want it to feel
too cheap considering that aqueducts were pretty big construction efforts in
reality. (In that respect, Colosseum also feels too cheap at 80 production.)
I don't want to buff Hammam, so I'm leaving that unique building at its BtS
cost of 100.
566
912 Civics
Tbd. Lots of problematic civics …
Some projections in hover text would be helpful. E.g. number of worked
and owned Farms, Plantations and Towns for Serfdom. Related CFC post
(near the middle)
AdvCiv K-Mod BtS
912a +1 commerce from +1 commerce from
Serfdom Farm, Plantation Farm, Plantation
-1 commerce from Town -1 commerce from Town
+50% Worker speed +50% Worker speed +50% Worker speed
Medium upkeep Low upkeep Low upkeep
Rationale The switch to Emancipation is a bit too painful in the K-Mod version. At Low
upkeep, Serfdom is usually still less powerful than Slavery, but that's not a
good baseline, and, for the AI, I'd say Serfdom is more useful than Slavery
even with Medium upkeep.
See also 131b assigns a negative AI weight to Feudalism because the tech is too
popular now.
912b military cost 1 gold; military cost 0.5 gold military cost 0.2 to 1 gold
Pacifism only 0.5 gold for the AI depending on difficulty
(e.g. 0.2 on Settler, 0.5
on Noble, 1 on Deity)
Rationale It's good that K-Mod decoupled the cost from the difficulty setting because
the difficulty-based modifier was undocumented and needlessly
complicated. However, the K-Mod change made Pacifism cheaper on all
difficulty settings above Noble, and Pacifism had already been one of the
more powerful civics in BtS, even on Deity.
The AI used Pacifism rarely in K-Mod, and the AdvCiv change might've
made the civic unusable for the AI. Therefore, the AI supply cost modifier
now applies to the Pacifism cost. This should be not nearly as confusing as
the BtS approach because the human cost is always the same, and the AI
cost is simply 50% of that. Since the AI needs far more units than the
human players to guard its cities, I think it's fair to place a 50% discount on
anything that punishes a high unit count.
See also 250d makes the AI supply cost modifier truly independent of difficulty.
Git commit message about the K-Mod change to Pacifism
Civics screen shows the cost per unit without Cost per unit shown Cost per unit without
inflation (i.e. shows just 1 gold) and shows the including inflation. No inflation, no total.
current total cost (hypothetical if not currently total shown.
running Pacifism) including inflation.
912c AdvCiv BtS/K-Mod
Hereditary Rule 1 happiness per 2 military units 1 happiness per military unit
+25% happiness from resources
Low upkeep Low upkeep
Config Can restore the BtS ability in Civ4CivicInfos.xml. If iHappyPerMilitary
Unit is set to 2, the game treats it as 1 happiness per (one) military unit.
567
Rationale The BtS ability is fiddly, encourages players to train lots of Warriors and
never upgrade them (or generally to train more units than needed), makes
it too easy to grow cities without buildings and is a poor fit flavor-wise
(would fit for a military dictatorship). This ability should arguably be
removed from the game entirely, but the replacement that I have in mind
would require some other balance changes that I don't want to make at this
point.
I had to come up with a temporary solution after change 036 (AI trades
away non-surplus resources if it doesn't need them) because there were
too many civs offering happiness resources during the second third of the
game and too few civs willing to import them.
The bonus to resource happiness should make Hereditary Rule better than
Representation at least in some (rare) circumstances, namely when a civ
has a lot of luxury resources (and the matching buildings) and needs even
more happiness (due to war weariness I guess). The bonus also means
that civs can normally get 2 extra happiness out of Hereditary Rule without
making a particular effort, namely by having at least 4 luxuries and station-
ing a second unit.
912d Base yield for hurry production: 24 30
Slavery per population sacrificed.
Config XML\GameInfo\Civ4HurryInfos.xml
See also CFC post by fippy suggesting that Slavery would be reasonably well
balanced if hurry production were reduced to 20. (And here another.)
Discussion about moving Slavery to Iron Working
See 121b about how the AI uses Slavery.
160 lets Granary empty upon starvation, arguably making it a little more
powerful.
Rationale Until AdvCiv 1.05, I had instead reduced the food stored by Granary from
50% to 40%, but I've come to think that, without hurrying, Granary is a
rather weak early-game building – which is regrettable because the effect is
kind of interesting to evaluate and there are precious few attractive early-
game buildings overall. (Granary becomes useful eventually for its health
effect and for drafting.) So Granary really isn't the culprit.
The hurry production reduction is proportional to the old Granary nerf (four
fifth) and 24 isn't too odd a number. The exact number isn't terribly relevant
anyway because hurry production gets added to a city's regular production.
I didn't want to go as low as fippy proposed because AdvCiv already
weakens the Slavery playstyle through a slew of subtle balance changes. In
particular, changes 027 (starting site placement), 108 (normalization) and
129 (map generation) make food less abundant near starting locations.
More importantly, making Slavery merely “still useful in cities with little
production” would go too far for my purposes – or not far enough. Making
Slavery somewhat less powerful should be welcomed by most players, but,
beyond that, I don't think there's a middle ground for all. For me (for one),
the Slavery ability is a lost cause because it's complicated, counterintuitive
and tedious to use and an outlandish representation of ancient slave labor.
Other players are very attached to the hurry ability and see it as a core
element of Civ 4.
New game option "No Slavery" prevents human civs from adopting the Slavery civic but allows
568
cities with a Sacrificial Altar to sacrifice population regardless of civics.
Rationale See rationale above; the game is better without Slavery, but some will
strongly disagree.
Of course one could simply not use Slavery, without the need for a game
option, or use it only under special circumstances; the game option is
mostly intended to make players aware that the mod has been tested (also)
without Slavery.
Tbd. Maybe the option should also affect the AI. Bit of a shame to let the AI code
go to waste ...
A replacement civic; see future gameplay changes, specifically this file. The
Kremlin will also need a new ability eventually.
Config Can hide the “No Slavery” option in Civ4GameOptionInfos.xml.
912e AdvCiv BtS
On Quick speed, up to three civics can be changed in one Up to four.
turn of anarchy.
Credits From Civ 4 Reimagined (Git commit)
Rationale While a turn of anarchy is brutal on Quick speed, allowing nearly all civics
to be changed still seems strange.
912f AdvCiv BtS
Can set cottage growth modifiers that are not a multiple of The Emancipation ability only works
100. Negative growth still isn't possible; no growth (-100% for positive multiples of 100 because
modifier) is possible. the game counts the time that an
improvement has been worked in
whole turns. Letting a civic disable
Cottage growth causes a crash in
K-Mod AI code. (And any negative
modifiers get rounded down to 0
growth.)
Rationale Doesn't make any difference in AdvCiv, but it's an unexpected problem for
mod-mods. A downside is that this change increases the memory footprint
of a CvPlot object by 2 byte (to be able to count improvement turns at a
higher precision).
912g AdvCiv K-Mod BtS
Vassalage +2 XP +2 XP +2 XP
extra free units extra free units extra free units
-25% number-of-cities -25% number-of-cities
maintenance maintenance
No colony maintenance
High upkeep High upkeep High upkeep
569
maintenance would be a bit anti-synergistic because maritime empires
benefit especially from the Free Market extra trade route. Jails keeping
colonies in check isn't actually realistic, and having to construct Jails is
another hoop that players with colonies shouldn't have to jump through.
Both also come rather too late.
570
Use the default latitude thresholds for land Ice Custom thresholds that are higher than in BtS,
and Tundra. i.e. less Tundra and Ice.
Rationale The BtS thresholds had been too low – or at least unrealistic –, but I've already
addressed that through CvMapGeneratorUtil.py as part of advc.tsl.
Tbd. The K-Mod changelog says about “Not Too Big or Small” that “[z]ones are now more
likely to have a buffer at the north and south poles.” This buffer should perhaps be
shrunk to match the AdvCiv Tundra and Ice latitude thresholds.
“Add Plains” and “Reduce Desert” options Options “Terrain Clumping”, “Add Plains”,
removed. “Reduce Desert” added.
Rationale The plains and desert options aren't useless but pretty random (Why can't Desert be
added? What about all the other terrain types?) and thus confusing. Better to adjust
terrain frequencies through the Climate option or adding a new climate type. (In
fairness, the plains frequency can't be adjusted through climate.)
"Terrain Clumping" seems a bit less arbitrary, so I'm -tentatively- keeping that one.
Config Shouldn't be too difficult to re-enable the removed options in Mixed_Continents.py;
just commented out.
World wrap option added.
Rationale No reason why this script shouldn't have that commonplace option.
See also kekm.32 adds a world wrap option to “Not Too Big or Small”.
Mixed Continents Continents and Islands
The sea level setting is used and has “Big and Small”, “Medium and Small” and
approximately the same effect on the sea/ land “Continents and Islands” all ignore the sea level
ratio as in most other map scripts (regardless of setting.
the region-overlap setting).
“Add Water” option removed. “Continents and Islands” has an “Add Water”
option instead.
Rationale Ignoring the sea level without so informing the player is terrible. May have been an
oversight, or Sirian thought that the sea level should be controlled through keeping
the two regions separate or mixing them together (the latter results in more land). Of
course it's better to have a separate control.
Config The “Add Water” option is commented out in Mixed_Continents.py.
If the sea levels aren't fine-grained enough, more elements can be added to
Civ4SeaLevelInfo.xml. I haven't tested it, but I think the mod should be able to
handle additional sea levels. Replays will no longer be BtS compatible though (see
106i).
AdvCiv K-Mod
“Not Too Big or Small” takes the sea level into Ignores sea level. No way to adjust the land/ sea
account. ratio.
Rationale Since “Not Too Big or Small” doesn't allow regions to overlap, this change was easy
to implement; strange that karadoc hadn't done this already.
See also Kek-Mod has added an “Adjust Water Percent” option to “Not Too Big or Small”. Git
commit
571
advc.gfd GameFont display
Credits By Nightinggale, adopted without any noteworthy changes. Original mod component:
CFC link
Config Shift+Ctrl+F1 opens the GameFont display window
Rationale I use the GameFont.tga from BULL and have no plans of extending it, so I probably
won't need this, but it could be handy for mod-mods and was very easy to integrate.
test Temporary changes for debugging and testing are marked with advc.test. or
advc.tmp.
Tbd. Most of the test code should be removed eventually. Currently, there are quite a few
branches for recovering from invalid call arguments that don't ever seem to occur.
Those should be turned into assertions.
It would be nice to have a bit of a framework for unit tests. Currently, there are two
such tests (not tagged with “advc.test” but with advc.enum, advc.fract respectively)
executed in CvXMLLoadUtility::LoadPreMenuGlobals. There should arguably be a
class of tests called PreMenuTest and another called PostMenuTest and perhaps a
third class for tests that execute only when a special savegame is loaded.
I've kept a "Giant" world size setting commented out in Civ4WorldInfos.xml. I use it for tests with
more than 18 civs. It's from vincentz's 34-civ mod.
There's a test switch for Permanent Alliances in UWAIAgent.h. (They're normally difficult to test
through AI Auto Play because the preconditions are so narrow.)
Preprocessor define MONTE_CARLO_ODDS_TEST added to CombatOdds.cpp (new implementation
file, for code moved from CvGameCoreUtils.cpp). This causes each calculation of combat odds to
be verified through a randomized simulation that closely follows the procedure in CvUnit::
resolveCombat. I don't know if I've set a sufficient number of samples for those simulations; there
might be false positives. Very small inconsistencies between combat odds calculation and combat
resolution can't be found this way: It's already very slow with the current sample size; can't
increase that by orders of magnitude.
See also Found bug 001l this way.
CFC post about my test code.
003: Refactoring changes to combat odds calculations.
572
make Changes to the (GameCore) DLL compilation process are marked with advc.make.
See also GitHub repository with the MSVC03 toolkit and Windows Platform SDK recommended
for compiling the DLL (for AdvCiv, or any mod). The readme explains (to best of my
limited knowledge) how the versions in the repository differ from other versions
floating around on CFC. As for runtime performance, there seems to be no significant
difference between all those versions, so it's just a matter of which will cause
compilation errors or warnings.
(Not related to compilation, but I want to document this somewhere: I use a faster
version of Python24.dll – uploaded here by alberts2. I've seen a speed-up of about
4% in an AI Auto Play test.)
Some hints about diagnosing fastdep crashes: fastdep.exe dates back to DannyDaemonic's makefile. The
VS console will only show “fatal error” when it crashes. For diagnosing the problem, one needs to consult the depends
file in the temp_files folder for the current build target. The last .cpp file for which output has been generated was
probably handled correctly. The next one in the alphabet should be the culprit. This can be verified by running
fastdep.exe on that .cpp file from a command line; if there's no output, then that file (or I guess an included header)
is causing the crash. Beyond that, I think one can only use trial and error, i.e. revert recent changes or delete or comment
out code until the crash no longer occurs. So far, the crashes that I've encountered were arguably caused by bugs in
fastdep: One time, #include <stack> as the last include in CvMap.cpp was causing the crash (resolved by moving it
to the precompiled CvGameCoreDLL.h, which is a better place for standard headers anyway); the other time, an #if
ENABLE_XML_FILE_CACHE check (cf. 003i) in CvInfo_Civilization.cpp (cf. 003x) was the cause; inserting a
newline (which looked better too) resolved that issue.
573
Tbd. Test my own changes with the latest free “Community” edition of VS; only tested with
2010 “Express” so far (available here). I'm not going to try that anytime soon though;
too much of a hassle. If I do, these look like good install instructions. Or maybe there's
a nice free version in between 2010 and 2019, one that won't require VS2010 to be
installed in addition? VS2013?
Write a natvis file for VS 2011 onward. microsoft.com
C2C has one, but it might not be easy to port.
alberts2 is working on splitting parts of CvGameCoreDLL.dll into a new DLL to be
compiled with a modern compiler. If I adopt that change, then VS 2019 will be
required. Another idea under consideration by the C2C programmers is a second EXE
that will run in a separate process (link, more recent link).
Perhaps replace the makefile with a FASTBuild configuration file, following billw2015's
example: Git commit 1 2
Or otherwise perhaps merge the renamed configurations from Nightinggale's updated
makefile. I should test if this
Assert|Multi core compilation = Assert|Multi core compilation
looks any nicer in VS than: Assert-fast|Win32 = Assert-fast|Win32
Use the /GS option (buffer security check) for debug builds? Since MSVC05, that
option is enabled by default. Might slow the program down by a few percentage
points. Probably not worth it as accidental security violations seem pretty unlikely.
C2C is deployed with an archive containing all its dependencies and a script for
compilation. If I ever need such a thing, I could follow this “We the People” commit
(which has fewer bells and whistles than the C2C archive, I think); doesn't seem
terribly difficult.
See also This K-Mod commit may have been intended to enable whole-program optimization,
but the Og global optimizations option is actually implied by O2 and is only “global” in
the sense that “the compiler searches entire functions for common subexpressions”
(quoted from the VS2003 documentation).
BtS had used VCCLCompilerTool properties instead of a makefile:
CvGameCoreDLL.vcproj#L146
The WholeProgramOptimization property is not used for the final-release build, only
GlobalOptimizations, which corresponds to the Og option.
There's some more info about the impact of compiler options on function inlining
under advc.inl.
Variable PROJECT_Profile_CFLAGS added to Makefile.project for profiler settings.
See also Comments in Makefile.project
Minor tweak in “We the People” that avoids unnecessarily copying .pdb files: Git
commit
Not merged because it requires a Perl interpreter.
AdvCiv Nightinggale's files
_NO_DEBUG_HEAP enabled through the project Reportedly, Visual Studio 2015 and later versions
file. have this enabled by default.
WX (treat warnings as errors) added to compiler I haven't tried it, but I think compilation continues
flags in Makefile.project. after compiler warnings.
574
Rationale Could also make these settings through files that aren't shared with other
programmers (Makefile.settings, .vcxproj.user), but VS 2010 (which benefits
from _NO_DEBUG_HEAP) remains widely used by Civ 4 modders and, as for WX, it
makes sense to force all contributors to resolve compiler warnings.
_NO_DEBUG_HEAP slows down memory (de-)allocation a lot. It also pre-initializes
memory allocated on the heap, which can help in finding memory errors, but can also
conceal them. Note that the /RTC1 option (/RTCs more specifically) can similarly
reveal or obscure memory errors by pre-initializing memory on the stack (local
variables).
See also The debug heap can be useful for discovering heap corruptions like those discussed
under 003k.
Dynamically allocated memory is pre-initialized in debug builds through overloaded
operators; see a few boxes below.
Obtain the compiler warning level from /W3 is set in the makefile.
Makefile.project. Set it to /W4 there. Header
PragmaWarnings.h added that disables some
level-4 warnings that aren't appropriate for this
project. The code editor still uses /W3. (I guess –
it's not explicitly set in the .vcxproj file; /W3
should be the default.) The Windows, Boost and
std headers are also still compiled with /W3 (they
produce tons of warnings with /W4).
Rationale I wasn't sure what warnings I was missing out on, so going to level 4 and working
from there seemed like the best approach. About half a dozen of the level-4 warning
types turned out to be useful. One could add those to level 3 (which is the approach
that Nightinggale seems to be taking for “We the People”; Git commit), but who knows
which other warnings could still turn out to be useful at a later time. I doubt that
experimenting with /Wall is worth the trouble.
I don't think there's an easy way to disable individual warnings in the code editor; /W4
without exceptions would be too strict.
Tbd. I now realize that warnings can also be customized through the /w compiler option.
Perhaps better to do it that way than through a header file?
AdvCiv BtS
Instead of 0, set each 32-bit word of dynamically Dynamically allocated memory is set to 0 through
allocated memory to 0xDADADADA (-623191334 in an overloaded operator new in
decimal). Still only applies to Debug builds. CvGameCoreDLL.cpp. K-Mod disables that
behavior for non-Debug builds.
Credits Based on this Caveman2Cosmos revision by billw2015.
Rationale To make accidentally uninitialized memory distinguishable from memory that was
deliberately set to 0.
DADA... is apparently not a widely used magic debug value, but perhaps that's the
point – to distinguish it from other allocation functions.
See also 003o moves the memory management code to CvMemoryManager.cpp.
Tbd. Perhaps merge improved memory tracking code from Caveman2Cosmos. Git pull
request
AdvCiv Nightinggale's files
575
Enabled precompiled headers and jom for fast From Nightinggale's thread: “Jom can't build
Profile and Debug builds. Profile or Debug targets. This is because
Microsoft decided that symbols are written to
There are now fast configurations for all targets vc70.pdb by the compiler for each cpp file. This
and slow configurations only for Debug and means jom tries to have multiple threads write to
Release. I've removed the slow Assert config. the same file at the same time. […]
I recommend having two Release build rules,
one with jom and one without it. The reason is
that jom handles files in parallel, but they also
write output in parallel. This makes reading error
messages tricky […].”
I.e. there are fast Release and Assert
configurations, and only slow configurations for
the others.
Credits billw2015 explains here how to solve the problem with vc70.pdb by using the /Z7
compiler option.
Rationale Reading the error messages is very rarely a problem. It's nice to have a non-parallel
configuration at hand, but don't need slow versions of each. A high number of
configurations makes it slightly more fiddly to switch between configurations.
Tbd. Should perhaps also throw out the slow Release configuration.
At least on my system and with VS2010, /Z7 makes linking far slower than /Zi. Not
sure if the /DEBUG:FASTLINK option introduced by the MSVC05 linker could be used
with the EXE (I guess not) and whether it would help much.
The non-parallel “debug” configuration should use /Zi instead of /Z7. I guess a
separate build target needs to be defined to accomplish that.
Makefile target Debug-opt added for debugging crashes that result from accesses to uninitialized
memory. The respective configuration uses jom and enables assertions. Debug-opt can also be
used for inspecting optimized assembly.
Rationale Even without _NO_DEBUG_HEAP and with /RTC1, certain memory errors don't occur in a
debug build.
Optimized assembly is useful for evaluating micro-optimizations.
Config For debugging, assertions should be enabled by uncommenting the line
#PROJECT_DebugOpt_CFLAGS = /DFASSERT_ENABLE
in Makefile.project. For viewing optimized assembly, it's normally better to keep the
assertions disabled.
Use the /Ob1 compiler option for debug builds. This option allows the compiler to inline functions
with an inline keyword. In a test, this decreased the turn time with attached debugger by ca. 30%.
Specifically, the MSVC03 documentation says that /Ob1 “expands only functions marked as inline
or __inline or, in a C++ member function, defined within a class declaration.” That covers nearly all
situations in which /Ob2 can apply inline expansion, but /Ob1 seems to do so more reluctantly, i.e.
mostly only when a marker is present (and apparently __forceinline works too). The difference
could also be due to other optimization that have to be enabled along with /Ob2.
Config PROJECT_Debug_CFLAGS in Makefile.project
Can enable further optimizations as needed, e.g. /Ob2 or even /O1.
Rationale I do most of my testing under the debugger and, toward the late game, turn times do
become a bit of hindrance.
576
See also advc.fract and advc.enum use a lot of indirection. The respective classes hadn't been
used as much as now when I did the 30% test mentioned above.
Moved a small part of the CvInfo Python interface from CyInfoInterface3.cpp to
CyInfoInterface2.cpp because the former appears to have been close to exceeding the
maximal size allowed for a debug information module.
Credits This CFC post by vaxerski suggests to me that the interface file was dangerously
large.
See also kekm.34 splits one of the Python interface files for the same reason.
Flag _CODE_EDITOR added to the project file for all builds with assertions in order to make the
FAssertBounds macro work in the Visual Studio 2010 editor.
See also Comment in FAssert.h
Removed an unused debug flag from Makefile and .vcxproj: CVGAMECOREDLL_EXPORTS
Credits Adopted from this Caveman2Cosmos revision by Anq.
Compiler version: As of v0.96, AdvCiv's GameCoreDLL is compiled using the updated Visual C++
2003 Toolkit that was included with Visual Studio 2003 SP1 (from 2006). The code can still be
compiled with the original 2003 Toolkit (the one linked in the how-to-compile-a-DLL threads on
CFC). Hopefully, the updated compiler generates slightly faster code.
Since AdvCiv 0.98c, I'm compiling with version 6.0 of the Windows SDK. I had used version 7.0A
before without any noticeable problem, but 6.0 seems safer and, based on a single test, results in
slightly faster code (at least the test makes me fairly confident that 7.0A isn't faster).
Credits Got the files from alberts2, who posted them in the Caveman2Cosmos subforum.
There appears to be no official download (of just the updated compiler) on
Microsoft.com. Caveat: alberts2's download doesn't include some necessary libraries;
see list here.
I've obtained the Windows SDK from the “We the People” GitHub account (link) at
Nightinggale's recommendation here.
Meta information from the resource script (CvGameDLL.rc) is written into the DLL only when
building a final release. K-Mod had already added the mod name (I changed it to AdvCiv) and I've
added the mod version under “FileVersion”.
Rationale I don't need the meta info during development. Updating the mod version before each
final release seems feasible.
Note that resource.h is probably only needed for editing the resource script in Visual
Studio's resource editor.
Changes to header dependencies. Mostly not marked with any in-line comments.
Credits Based on Nightinggale's guide (in spoiler tags under “Fix Firaxis mess”).
Rationale Mainly to reduce compilation time. It's a trade-off: CvGameCoreDLL.h gets precompiled
(see PRECOMPILE_CFLAGS1 in Makefile), so if more headers are included there, then
compilation becomes faster overall. But a change to any of the headers in
CvGameCoreDLL.h causes the whole project to be recompiled.
Caveman2Cosmos moved almost all headers into CvGameCoreDLL.h: SVN revision
That seems unwise, at least for my purposes, as some headers do change frequently.
Also, unnecessary includes obscure the actual dependencies and might pollute
namespaces. So I've only moved headers that are unlikely to change and frequently
required (or not so frequently required but large).
577
Tbd. Perhaps use the /FI (force include) compiler option and remove all the #include
"CvGameCoreDLL.h" directives. Could argue that it's confusing to have invisibly
included headers, but that confusion already exists in the .h files, none of which
include CvGameCoreDLL.h – which works because all the .cpp files that include those
headers include CvGameCoreDLL.h beforehand.
See also 003x splits up CvInfos.h. Some of the resulting header files are included in
CvGameCoreDll.h. (In BtS, the whole CvInfos.h was included there.)
003u cleans up the object-oriented design of the AI classes to an extent, and that has
allowed me to include the various AI headers less frequently in implementation files.
AdvCiv BtS (no significant changes in K-Mod/BBAI)
Removed about 20 includes from CvGameCoreDLL.h includes about 50 commonly
CvGameCoreDLL.h and instead added them only used header files, some from the Standard
to those cpp files that need them. Library and Boost, but mostly from the Civ 4
game core. This means that all implementation
files need to be recompiled whenever one of the
headers in CvGameCoreDLL.h changes.
Removed those headers remaining in Many implementation files explicitly include
CvGameCoreDLL.h from all implementation files headers that are already included through
that had included them redundantly. CvGameCoreDLL.h.
Replaced some include directives in headers with
forward declarations.
Rationale I'm assuming that the headers remaining in CvGameCoreDLL.h will remain there
permanently.
Wrapper headers CvGamePlay.h and AICore.h added that include some frequently needed game
rule and AI classes.
Rationale To reduce the number of include statements.
Reordered the include statements in most Some patterns are discernible, like including the
implementation files a bit so that related headers class's own header file first and EXE-to-DLL
appear next to each other. interface headers last, but it's mostly haphazard.
As proposed by Nightinggale, I've moved the CvGameCoreUtils.h contains global utility
distance functions from CvGameCoreUtils.h to functions. Some of these deal with distance
CvMap.h and removed the CvMap header from computations on the game map. Those distance
CvGameCoreUtils.h. I went a bit farther by functions operate on CvMap and CvPlot objects
making them (non-static) member functions of and they're inlined for performance, meaning that
CvMap – with global wrappers for convenience. CvMap.h (which includes CvPlot.h) has to be
included in CvGameCoreUtils.h and thus,
through CvGameCoreDLL.h, in every cpp file.
Rationale The distance functions don't operate on arbitrary coordinates – they require a CvMap
object with specific dimensions for dealing with world-wrap. Tying them to a CvMap
object communicates this relationship (which isn't entirely obvious).
See also advc.pf: Moved the pathfinding functions out of CvGameCoreUtils.
Renamed BetterBTSAI.h to BBAI_Log.h.
Rationale For clarity; contains logging code that writes to BBAI.log.
Added some declarations to CvGameCoreDLL.h to make the Visual Studio Code Editor underline
fewer Boost calls.
578
Credits Based on "We the People" code by Nightinggale; e.g. from this Git commit.
Rationale Adding the Boost header paths to Visual Studio shouldn't be difficult to do, but it
seems that the (absolute, system-dependent) path will have to be stored in the
.vcxproj file, which is under source control and should therefore be fully portable.
579
Config The game option is available on all the game setup screens, disabled by default. It
applies to all players in network games (Staging Room screen) and scenarios with
fixed civs, otherwise to all players whose civ is set to “Random”.
The civ and leader preferences are set in Assets\XML\TrueStarts and documented
in Civ4TrueStartsSchema.xml. They're mostly real-world statistics because this
makes it easier to find sensible values for any civs that a mod-mod might want to add.
The True Starts code in the DLL then uses a variety of haphazard methods to match
those statistics to statistics about the map in the game and to compute a “fitness”
value for each pair of a civ and starting location.
The movement of bonus resources (referred to as “sanitization” internally) can be
disabled in GlobalDefines_advc.xml (search for “advc.tsl”). When sanitization is
disabled, the impact of resource preferences in the fitness calculation is increased.
The AUTO_REGEN_MAP setting in GlobalDefines_devel.xml combined with
MessageLog=1 in My Games\Beyond the Sword\CivilizationIV.ini can be used
to collect statistics about the frequencies at which the leaders get chosen by TS in
MPLog.txt. (Not very convenient; the log just lists the leaders chosen for the original
map and each of the re-generated maps.)
A report with breakdowns of the fitness calculations and map sanitization can only be
enabled through the DLL, see the start of CvTrueStarts.cpp.
Setting fixed map seeds can be helpful for testing; see the Config box under 027
about that and also 027b.
TS ignores the team placement options that some map scripts (e.g.
Team_Battleground) have.
Rationales For scenarios with fixed leaders and fixed starting tiles, one could argue that TS is
(for config) unnecessary (the starting locations already match the civs). However, TS can only be
available for all scenarios or for none. It does make sense for scenarios that allow
arbitrary civs. So TS might as well do something with other scenarios. This has also
been helpful for testing – getting TS to match most of the civs on Earth18Civs. For
scenarios with pre-placed cities or units, it gets too complicated for too little gain to
change the ownership of those items, so TS does nothing with such scenarios.
In network games, only the host learns which civs are set to "Random" (through a
hack that is part of change 190c) and game net messages aren't delivered until the
game is fully set up, so I can't get that info across the network in time. Letting TS
assign only some of the civs doesn't make much sense to me anyway. I'm allowing it
in non-network games because it's easy to implement for those – and because I'd like
TS to do what the game setup screens say. (On that note, “Random” civs do get
chosen randomly by TS; not at all uniformly, but based on a randomized map with
randomized starting locations.)
580
Tbd. The minor issue with network games could be resolved by doing the TS stuff at a later
(on config) point in the game initialization process, i.e. at the earliest when CvGame::
setInitialItems is through. However, at that point, the starting techs and unique
units will have to be reassigned (along, perhaps, with other stuff that I'm forgetting
about), which is troublesome to implement.
Add XML settings for adjusting the impact of various aspects of the fitness calculation
– I think players care the most about whatever aspects they're most knowledgeable
about. This might really be a fundamental flaw with this option: A player who doesn't know about African
rice might just assume that TS failed to remove a Rice resource near the Mali capital. Perhaps more
importantly, players have their own interpretations of Civ 4 maps, e.g. hills representing high elevation vs.
rugged terrain. Since TS only makes a best effort, the intentions of the designer aren't clearly commu-
nicated, and conflicts with the player's expectations don't get resolved. (It's also questionable how willing
a player would be to come around to my interpretations.)
Moved the Tundra (and Ice) belt to higher latitudes on all fractal-based map scripts and reduced
the randomness involved in Tundra extending into unusually low latitudes. Part of this change
applies also when TS is disabled. In particular, the Fractal map script may, regardless of the TS
option, generate land about 10° closer to the poles than in BtS, i.e. now at 75-80° latitude.
581
Rationale BtS had allowed Tundra as close to the equator as 44°. There's enough room at
higher latitudes when the oddly broad water bands at the poles are shrunk to a
thickness similar to Continents and Pangaea. It's rather more interesting when a
passage by ship between a continent and polar ice isn't guaranteed to be possible. I
think the thick polar water bands have also lead to unnatural (truncated) continent
shapes.
With TS, it's important to keep Tundra out of the temperate zone. Doesn't feel like
playing as France when there are Tundra tiles already within the capital's workable
radius. Temperate terrain (Grassland, Plains) may still, randomly, extend pretty far
north in some places. This is desirable for getting starting sites far enough north for
the Vikings: can be interpreted as the influence of a warm current (Gulf Stream).
Config I had to hardcode the water bands change in CvFractal.cpp because the code
exposing CvFractal to Python isn't part of the SDK.
Tundra and Ice placement are implemented in CvMapGeneratorUtil.py.
AdvCiv BtS
Per-tile latitude values can be set from Python The CvPlot class computes latitudes on the fly
and are then stored at CvPlot in the DLL. Fractal- based on the map dimensions.
based maps obtain latitude values from the DLL.
The standard terrain and feature generators in
AdvCiv doesn't currently depend on these CvMapGeneratorUtils.py have a function
changes (I think), but they apply regardless of getLatitudeAtPlot, but overriding that doesn't
whether TS is enabled. affect resource placement. To place resources
according to custom latitudes, map scripts need
to reimplement much of CvMapGenerator.cpp.
The standard implementation of
getLatitudeAtPlot assumes that the equator
runs through the center of the map. This is
inconsistent with the latitude calculation in the
DLL, which takes into account the map's top and
bottom latitude values; those values don't need
to be symmetrical.
See also 129 tweaks the latitude calculation in the DLL
Rationale I was going to use these changes for an implementation of TS as a map script instead
of a game option, and, later, for shrinking the southern hemisphere. Anyway, it's good
to ensure that Python and the DLL and the terrain generator and resource placement
all use the same latitude values.
TS adjusts the latitude limits, sea level and world The whole-Earth scenarios have latitude limits
size settings of most of the ”official” scenarios. between -90 and 90, but the northern
hemisphere is enlarged, meaning that 0 latitude
doesn't align with the equator. The other
scenarios don't have latitude values at all. The
world size is mostly already set to Huge (which is
appropriate), the sea level to Medium.
Config Through the DLL; by checking for the names of those specific scenarios. I don't want
to change the scenario files because I don't want to include them in the mod. Doing so
might suggest that the scenarios have been overhauled or that they're somehow
curated content.
See also The 2nd paragraph in this CFC post argues against including the terrestrial scenarios
with AdvCiv.
582
Rationale The scenarios are useful for testing, especially Earth18Civs. If TS can't properly place
e.g. Egypt in that scenario, then something is probably wrong with the TS heuristics.
Need to have accurate latitude values for that. The world size and sea level are
relevant for a crowdedness value that AdvCiv (AI) code uses in a few places and that
also affects the radius around the starting tiles that TS takes into account. Those
scenarios have dimensions larger than Huge random maps (and more land tiles than
such maps), so assuming Low sea level helps getting the right sense of available
space.
TS does not affect the placement of the starting locations and the assignment of players to starting
locations. (Only the assignment of civs and leaders to players.)
Rationale It's difficult to find starting locations that are at least somewhat fair (cf. the rationales
listed under change 027), and taking into account the TS fitness values (how well a
civ could match a potential starting location) already at that point would make that
task even harder. I've tried discouraging starting locations near the equator (through
the “volatility values” computed by the Starting Position Iteration algorithm) in order to
have more starting locations for the many temperate civs in the game, but this didn't
have much of an effect. I guess leaving the equatorial area (largely) empty tends to
lead to major balance problems as it gives the civs that do start in the tropics and
subtropics too much room to expand. So only a major bias against tropical starts
would get the job done – but it wouldn't be worth it.
There isn't much of a reason for TS to change the assignment of players to starting
locations. (One could perhaps make a case for assigning the starts for which high-
fitness civs were found to humans at the end.) I do like the difficulty-based assignment
(iStartingLocPercent in Civ4HandicapInfos.xml) of players to starting sites; it's
nice that TS (unlike the starting biases in Civ 6) can coexist with that handicap
mechanism.
Tbd. For those players for whom a civ was configured during game setup, it would be nice
to do what Civ 6 does, i.e. to start by assigning the available starting locations that fit
best to those fixed-civ players and to then to pick civs for any remaining starting
locations. This would be in conflict with the difficulty-based assignment; though one
could restrict the re-assignment of starting locations to players that play at the same
difficulty level. When all players have fixed civs, then TS has currently no effect at all
(except for scenarios – where those fixed assignments are ignored).
Implementation wouldn't be too difficult, it's just not clear what the behavior should be
exactly.
After a leader and civ has been assigned to every player, TS computes a fitness value for every
bonus resource tile on the map. These fitness values are based on the distances of the tile from
the civs' starting tiles and on the civs' resource preferences and the game's start era. Then “swap
utility” values are computed for pairs of resource tiles. Those utility values are based on the current
resource fitness values, the hypothetical fitness values assuming that the tiles' resources are
swapped and a disturbance value (negative utility) that accounts for how dissimilar the two
resources are, whether and how severely the swap would violate minimal distances that are
normally required between resources of the same type or class (e.g. livestock is a resource class),
distances to starting tiles, and whether swapping the resources will require a Forest or Jungle to be
added or removed. To satisfy the various resource placement requirements (e.g. terrain type,
elevation) after a swap, resources can be moved to an adjacent tile; if this is necessary, the
disturbance value is increased. Apart from minimal distances between resources, all requirements
need to be met or else the swap is disregarded.
TS then makes those swaps that have a positive utility, in descending order of utility. Each
resource can get swapped at most once.
583
Config The resource preferences are defined in Civ4TruBonusInfos.xml. Defining
preference weights in addition to start era conditions would have been a bit difficult to
implement, so the preferences are only either encouragement (a civ likes to be near a
resource type) or discouragement.
Resource swaps can be disabled through GlobalDefines_advc.xml (search for
“advc.tsl”). TS then tries harder to respect resource preferences when choosing the
civs.
Rationale Preventing historically inappropriate resources near starting tiles just by selecting the
most fitting civs seems impossible. For a few civs in the game, mainly India and
China, almost all resource types fit well enough, but, for all the European and
American civs, about a quarter of the resource types are inappropriate. Swapping e.g.
Rice with Corn or Silk with Wine barely affects the balance of a map or its natural
appearance. Not all swaps are this inconspicuous and one can argue about the best
weight for the disturbance value in the swap utility calculations, but, in principle, this
seems like a very good way of handling ill-fitting resources, allowing the civ and leader
fitness calculation to focus on other aspects.
Encouraging resources that are typical for a civ is less important to me (and is a
lesser priority in the resource fitness calculation). It might be that, for the most part,
the typical resources would manifest often enough just through the discouragement of
other resources – and that further encouragement makes starts too predictable and
repetitive. Well, the encouragement weight can be tweaked (in the DLL), but it seems
helpful to have such a mechanism (and the lists of encouraged resources in XML) in
place to begin with.
When playing with the Balanced Resources custom map option, important strategic resources (i.e.
all except Marble and Stone; Ivory isn't considered strategic) can't be swapped.
Rationale Just trying to respect the players (somewhat contradictory) wishes.
See also Based on code written for 108c (changes to Balanced Resources option).
When playing with a custom map option that is supposed to leave a continent empty, TS won't
select any New World civs. (Implemented by checking for names of map scripts and of options.)
Rationale I don't think we want New World civs in the Old World when such a distinction exists.
TS computes a fitness value for every pair of a player (with its associated starting tile) and a leader
(with its associated civ). Then it goes through the players once in a particular order and assigns to
each player the best-fit leader and its civ among those leaders and civs not already taken. After
each such assignment, the fitness values are updated (because fitness takes into account civs and
leaders already chosen for other – especially for nearby – players). The order of the players
prioritizes human players over AI players. Within those categories, AI players that start close to a
human player and players for whom it's difficult to find any fitting civ are prioritized.
These computations are fast in comparison with the Starting Position Iteration algorithm. The
slowest part is the (re-)calculation of the fitness values.
584
Rationale This Greedy algorithm is a lot more simplistic than what the Culturally Linked Starts
mod (CLS) does (“the linking is a very hard to solve optimization problem and that
your computer will need some time to find a nice solution”). I don't think optimizing the
order in which the players are processed will accomplish much. CLS is all about the
positions of the civs relative to each other, but, in the TS heuristics, the distances
between the civs are just one of several aspects of the fitness calculation.
The human experience is what matters most. At the start of a game, the human
players only see their own starting location, then they discover its surroundings and
the locations of their neighbors. Matching the historical geography of AI civs that are
farther away is less important – although it's important everywhere to avoid overtly
counterfactual characteristics.
No special priority for human players when playing with the R&F option.
See also R&F chapter
Most aspects of the fitness calculation are only based on the civ, not the leader.
Rationale Would be nice to have separate preferences for the Britons (Boudica) and Gauls
(Brennus) or to give Kublai Khan a rather Chinese start, however, each civ has only
one city list, and so the Celtic capital will be Bibracte although this city was not even
contemporary with either leader in the game. Looking at the civs as representative of
their entire history (with a special focus on the reigns of the leaders in the game) also
made it easier to gather the data for the starting preferences – we've got 52 leaders
and just 35 civs.
The one leader-specific aspect of the fitness calculation is contemporaneity, i.e. TS prefers
choosing leaders (along with their civ) that were at least remotely contemporary with other leaders
already chosen in an earlier iteration of the civ and leader selection algorithm (or locked in
manually during game setup). For each leader, a random number of other leaders is considered to
be contemporary – those leaders whose reign's starting date is the closest to that of the first
leader.
Rationale Seems a bit better than just picking a civ and later a random leader associated with
that civ. Doesn't have much impact on the fitness calculation, more like a tie-breaker.
Also, the regnal years were easy to research.
When playing with Unrestricted Leaders, the contemporaneity aspect is ignored, i.e. leaders are
chosen solely based on their civ. Then, when assigning the best-fit civ and leader, only the civ is
kept and a leader is assigned uniformly at random from among all leaders that are still available.
Rationale If we choose the leaders based on contemporaneity and unrestricted by their civs,
we'll end up with the same leaders in every game. I guess players who use
Unrestricted Leaders like random combinations of civs and leaders, so let's just give
them that.
Contemporaneity with human leaders previously chosen or leaders of the same team as the leader
under consideration is encouraged more strongly.
Rationale Not important, but if we'll have a bunch of contemporary leaders, we'll want the human
players to be part of that group, all other things equal.
Geographical latitude has a strong impact on fitness values. I.e. fitness is high if the absolute
latitude set in XML (normally the latitude of a civ's capital) is close to the absolute latitude of the
starting tile, or, put differently, differences between those latitude values are penalized. Near the
boundaries of the temperate zone, latitude differences are penalized more strongly when a
temperate civ would be placed in the subtropics or subarctic, less strongly when a subtropic or
subarctic (Vikings) civ would be placed in the temperate zone.
585
Rationale Geographical coordinates are easy to look up and latitude correlates strongly with all
sorts of climatic characteristics – on Earth and in the game. Very useful. I had even
considered implementing TS as a much simpler (and therefore also more transparent)
option – based only on latitude values.
At the edges of the temperate zone even small differences in latitude can make a
difference between Tundra or Desert being conspicuously close to a starting location
or not – which may or may not be desirable. Therefore those differences in latitude
are magnified.
The sign of the latitude values (northern vs. southern hemisphere) can't be assumed
to affect the climate, at least not in the game, so it seems best to ignore the sign in
this context.
For temperate civs, Tundra and Desert tiles, even just one of them, close to the starting tile is
explicitly discouraged (i.e. the fitness value is decreased).
Rationale Even if the latitude is close to being correct, Tundra and Desert can reach far enough
into the temperate latitudes to appear jarringly close to a (supposedly) temperate
starting location.
Tbd. Consider converting a small number of Desert or Tundra tiles to Plains during the
sanitization step (i.e. when bonus resources get swapped).
For a few civs, the latitudes set in XML differ from the latitude of their capitals by a few degrees.
Rationale This is because of geographical phenomena (e.g. the Gulf Stream) that are unlikely to
be recreated by a map script.
When playing with a Climate setting other than Temperate, the civs' target latitudes are adjusted.
Rationale For those Climate settings, the latitude values on the map don't imply the same
climate as on Earth. E.g. with a Tropical climate, the Jungle belt gets wider, so
subtropical civs like Egypt need to move farther away from the equator.
Fitness is increased when distances to civs previously chosen (especially distances to humans)
match the geographical distances between the respective civs on Earth. When the distances are
large on the map and on Earth, it doesn't matter much how large they are specifically.
Rationale So that civs tend to be adjacent to civs that they indeed were close to and interacted
with on Earth and (at least) not adjacent to civs that they had no or little contact with.
The latitude aspect already encourages that to some extent, but, here, the longitude
value and the sign of the latitude value are also taken into account.
I've considered listing (in XML) pairs of civs that had contact despite being far apart
geographically, e.g. Spain and the Aztec, but I think it's better not to place such civs
close to each other, or at least not worth the implementation effort. Most of the
colonizing civs have a preference for starting near a coast (see somewhere below);
that should already enable them to get in contact with the civs that they colonized in
history.
For each civ, a typical annual precipitation value and a value expressing how diverse the climatic
conditions in the civ's (core) territory were is set in XML. TS tries to match that data to the terrain
and features surrounding a starting tile when computing the civ fitness value. Jungle tiles are
considered to be the wettest (regardless of the underlying terrain), Desert and land Ice the driest.
Non-Jungle Plains is considered to be drier than Grassland, Tundra about the same as Plains.
Forests increase the wetness of a tile. In addition, clusters of similar tiles are assumed to have
more extreme precipitation values.
586
Rationale Precipitation data is relatively easy to find (certainly for individual cities, not so much
averages for a whole country), and precipitation is the main climatic factor not already
covered by matching geographic latitudes. I also think players have pretty uniform
notions of what (groups of) tiles are dry or wet.
Tbd. The climate variation value in XML should be renamed to precipitation variation (or
something like that) – because that's how the value is used.
The precipitation analysis splits the surroundings of a starting tile into (overlapping) regions and
computes an overall precipitation value only from a representative subset of those regions.
Whether the surroundings match the desired variation in climate is decided based on per-region
precipitation values.
Rationale An average of the per-tile precipitation values over the entire surroundings tends to be
too close to the global average. I think how players look at a starting location is that
they see e.g. a large cluster of mostly Plains and another of Plains mixed with Desert,
and that makes it seem pretty dry even if the rest of the nearby tiles are a rather wet
mix of Grassland and some Plains.
Jungle and especially Desert tiles are given a higher weight than other tiles in the calculation of
per-region precipitation values. And a few other special rules that make regions with a lot of Desert
tiles more dry and regions with a lot of Jungle or Forest tiles more wet.
Rationale Starting tiles are rarely placed inside a large desert; that can make it difficult to place
civs that should have extremely low precipitation (Egypt, Arabia, Babylon, Sumer,
Mali) frequently enough. Will have to take what we can get.
Special treatment for clusters of (coastal) Forests exist mainly for the sake of Japan,
which has unusually high precipitation for its latitude.
The highest elevation within the (core) territory of a civ is matched by the fitness evaluation to the
frequency of peaks near a starting location. Groups of adjacent peaks are assumed to be
especially high.
Rationale Highest elevation is easy to look up. One could argue that prominence should matter
more than absolute elevation, but it doesn't make a big difference for the highest
elevations. Also, a high number of high-altitude mountains should be more relevant,
but, again, the single highest elevation correlates pretty well with that.
For scenarios and for the Tectonics script, the target frequencies of peaks get adjusted based on
the overall frequency of peaks.
Rationale Generally, I don't want to adjust the civs' preferences to the map – a map script like
Oasis that has a lot of Desert should receive mostly Desert-loving civs. However, the
Firaxis scenarios use peaks very liberally to represent mountain ranges, but those
scenarios shouldn't be populated primarily by mountain-loving civs. Similarly,
Tectonics is supposed to generate earth-like maps.
A rough approximation of the portion of mountainous (i.e. rugged, rocky) land in the (core) territory
of each civ is matched by the fitness calculation to the frequency of hills near a starting location.
Rationale Such data is fairly easy to find; e.g. I've found a world map that shades countries
according to the portion of mountain terrain within their borders. Hills should not
represent absolute elevation in my opinion; e.g. an altiplano can be farmed and
therefore should be represented by flat land (surrounded by some hills).
See also 021: The terrain generator of PerfectMongoose also assumes that hills show
gradients rather than absolute elevation.
Resource preferences (see swapping of resources above) affect the civ fitness calculation.
587
Rationale Don't need to get all the resources right when choosing civs, but should at least avoid
placing a civ near numerous inappropriate resources, e.g. Spain in clusters of Silk and
Spices. This way, fewer swaps are necessary once all civs have been chosen.
The fitness calculation matches the portion of water tiles and tiles on a different landmass around a
starting tile to a target portion of such tiles set for each civ in XML.
Rationale Seems like a good predictor of how much a player will have to interact with the sea.
Shortest distance to a sea tile doesn't seem so promising; wouldn't want maritime civs
like England to always start in a coastal tile. If the 2nd or even 3rd city ends up at the
coast, that's good enough.
Most civs have a slight preference against a high number of river tiles and segments near their
starting tile, some civs have a rather strong preference against, some a strong preference for
rivers. Specifically, river crossings adjacent to surrounding tiles are counted.
Rationale The goal is to place the hydraulic civilizations near a major river or river system. This
wouldn't have to imply a high number of nearby river tiles, but measuring the lengths
of rivers is a disproportionate implementation effort. Just counting river tiles would
miss the visual effect that meandering rivers have on the player. River crossings are,
conveniently, already cached by BtS.
There aren't many major river concentrations on most maps, so most civs should
prefer not to be placed there, especially subtropical and tropical civs, so that the
(mostly subtropical) civs that really need a river have a better shot at getting one.
A total land area is set in XML for each civ. Those values vary greatly (e.g. Netherlands vs.
Russia). For civs with a very small land area, TS prefers a starting location with relatively little
space for peaceful expansion, for civs with a very great land area, starting locations with greater
space for expansion are preferred.
Rationale So that historically small civs are more likely to be boxed in a little than large civs. The
area of modern and historical countries is fairly easy to look up (though there is a
judgment call which year to use).
Some civs prefer to have more space for expansion in horizontal than in vertical direction, or vice
versa.
Rationale Not sure if this was really a good idea. In theory, a vertically stretched civs will cover
multiple climatic zones, so looking for that shape will help achieve an appropriately
diverse climate. However, Egypt doesn't actually have a diverse climate, and, even for
the Inca, I don't think the diverse climate is the result of covering a great vertical
distance – it's due to differences in elevation.
Civs with multiple leaders are slightly preferred.
Rationale Since the fitness calculation is mostly based on civs rather than leaders, such a bias
needs to be implemented explicitly. While it's more important to me to give every civ
proper representation in terms of how often they get chosen, the leader frequencies
matter too.
For most civs a small or not-so-small bias value is set in XML that increases or decreases the
fitness values for that civ. Negative biases can randomly be doubled in some games.
588
Rationale Some civs' preferences are a lot more specific – or harder to find on a Civ 4 map –
than others. Rather than endlessly tweaking how the per-civ data translates into target
properties of starting locations, the bias values can directly discourage civs that
appear too frequently and encourage those that appear too rarely. The doubling is
mainly intended for large maps; when choosing a high number of civs, those with
easy-to-meet preferences will virtually always get chosen. Doubling the bias of a civ
with a high negative bias should sometimes, randomly, take that civ pretty much off
limits entirely.
Tbd. For replayability, ideally, each civ (and leader) should be chosen with equal frequency
on Fractal and all similar maps. The status quo is far from that (for all maps). Here is a
frequency distribution from 20 Fractal maps, each with 8 civs, standard settings,
Monarch difficulty (difficulty affects the human starting location through
iStartingLocPercent in Civ4HandicapInfos.xml):
Total (per leader), human (per leader), total (per civ), human (per civ)
Russia 14 3
Stalin 7 3
Catherine 4
Peter 3
China 12 3
Qin 7 2
Mao 5 1
Khmer 11
Zulu 10 3
Maya 9 1
India 9
Ashoka 6
Gandhi 3
Spain 8 1
Greece 8
Alexander 6
Pericles 2
Aztec 7 2
Germany 7
Frederick 4
Bismarck 3
Ethiopia 6 1
Portugal 6
Inca 5 1
Persia 5
Cyrus 3
Darius 2
Carthage 4 1
Mongol 4
589
Kublai 3
Genghis 1
France 4
De Gaulle 3
Napoleon 1
Louis
HRE 3 1
Native American 3
Babylon 3
Ottoman 3 2
Suleiman 2 2
Mehmed 1
Rome 3
Augustus 2
Julius 1
England 3
Churchill 2
Victoria 1
Elizabeth
Netherlands 2 1
Mali 2
Ragnar 2
Arabia 2
America 2
Roosevelt 1
Washington 1
Lincoln
Byzantium 1
Japan 1
Celt 1
Boudica 1
Brennus
Korea
Sumer
Egypt
590
I haven't done the math, but this seems still far from a sufficient sample size, so some civs are
always going to appear too common and others too rare. (Even with leaders chosen uniformly at
random, players get some of the same leaders over and over until they've played a great many
games; see e.g. this CFC thread about Civ 6.) Moreover, I make some tweaks each time that I run
these numbers, so this is not the current state of affairs. That said, large civs like China and India
that fit well enough in multiple climate zones and tropical and "wet" subtropical civs should indeed
be expected to appear much more commonly than small temperate civs and desert civs.
Adjusting the iBias values in Civ4TruCivInfos.xml helps, but overdoing that will get a civ placed
in surroundings that don't actually match their historical geography well. Moreover, different map
scripts and world sizes lead to different civ distributions; for example, maritime civs like England
and Japan are more likely to appear on maps with smaller continents or longer coastlines than
Fractal. Larger maps tend to have larger deserts.
591
savem “Savemap” function that saves the map of an ongoing game as a Python script
Credits Courtesy of xyx (CFC thread); based on work by tywiggins (Apolyton thread)
See also See the links above for documentation and possible uses.
The description string of the exported map script is generated through DLL code from
106h.
127 disables the Ctrl+Shift+M AI Auto Play shortcut, which easy to confuse with the
key combination that I want to use for savemap.
AdvCiv xyx's savemap
Can press Alt+Shift+M at any point of a game to Needs to be invoked from the Python console.
export the map into a Python script. This shortcut
can be disabled on the BUG menu (Map tab).
Will first try to store it in \AdvCiv\PrivateMaps. Always save under My Games\Beyond the
If that location can't be written, PublicMaps Sword\PublicMaps.
under \My Games\Beyond the Sword is used.
I think most mods set NoCustomAssets=1, so it's
AdvCiv will not be able to load it from the latter
mostly just unmodded BtS that can load map
location unless NoCustomAssets is set to 0 in \
scripts from \My Games\.
AdvCiv\AdvCiv.ini.
An on-screen message says whether and where Feedback only through debug output.
the new file was created.
Old files are never overwritten (if I've Will overwrite if file names clash.
implemented that part correctly).
Regardless of the location, Civ 4 needs to be (I don't think a restart can be avoided. In
restarted before the exported script can be particular, a manual Python reload doesn't help.)
loaded.
The file name is generated from the name of the
original script or scenario, the map dimensions The file name can be entered through the Python
(not if it's a scenario) and initial player count. A console. The name of the original script, map
number between 1 and 9 is appended if a file dimensions and initial player count are saved in
with the generated name already exists in the the description string.
target location. All settings shown on the Settings
tab (Victory screen) are included in the
description string of the exported scenario. (That
string can be viewed in a text editor or through
“Play Now”.)
Tbd. Add options for using the original civs and leaders and original difficulty level to the
generated scripts. See comments in savemap.py about that. For the civs and leaders,
DLL functions added by the Change Player mod component will have to be exposed
to Python.
CvGame could keep a list of tile changes made during the normalization step and
then the generated script could reapply those changes depending on whether the
original starting sites are used. Probably too much work. As it is, if the original sites
aren't used, new sites are computed based on terrain that includes the original
normalization changes and no normalization step is performed afterwards.
Can't use savemap in networked multiplayer. The Python console also isn't normally available
in network games.
Rationale Seems like a pretty convenient way to cheat. In particular, the names of the AI leaders
are easy to find in the saved script.
592
Config Guard in savemap.py at the beginning of the savemap function.
When choosing the option to ignore the original New starting locations are generated in Python
starting sites, the selection of starting sites is left through CvMapGeneratorUtil.
entirely to the DLL. findStartingPlot.
Rationale So that StartingPositionIteration (change 027) is used.
advc.rh Modular XML loading bugfix merged from rheinig's mod (CFC link)
Credits xyx made me aware (here) of this fairly obscure mod.
From the mod's readme file:
“Some XML tables are loaded in two passes, and the code did load the second pass data into the wrong records for modular
additions. Ever wondered why the tech tree or promotion prerequisites get mucked up if you modularize them? Now you *can*
modularize those. The full list of Infos that define a second pass loader method and the values those load is:
CvTechInfo(OrPreReqs,AndPreReqs), CvPromotionInfo(PromotionPrereq,PromotionPrereqOr1,PromotionPrereqOr2),
CvCivilizationInfo(DerivativeCiv), CvImprovementInfo(ImprovementPillage,ImprovementUpgrade),
CvProjectInfo(PrereqProjects,AnyonePrereqProject), CvEventInfo(AdditionalEvents,EventTimes,ClearEvents).
Note Buildings and Units don't need to do that as their perceived self-referencing prerequisites actually refer to the respective
"Class", and those are loaded far ahead. Otherwise, this bug may well not have slipped by QA.
Update - Version 3.1.7.3 now delays pass 2 of the monolithic XML until after pass 1 of the modules has finished, too. This finally
fixes modular random events.
Changed modular XML load order:
Fixed CvXMLLoadUtility::LoadGlobalClassInfo to sort the list of files after enumerating them and before loading them. Why?
Well, before the load order was determined by the file system and essentially unpredictable. You could easily be working on
non-XML files in those directories and suddenly have units, buildings or whatever swap their IDs, thus having saved game
incompatibilities the loader couldn't catch. The sort now is case-sensitive, which is bad, but I'll leave it at that as the rules
governing the casing of returned names are deterministic and constant over any OS generation. You might still get into the
effects I mentioned if you moved from, say, Windoze 9x (urgh!) to NT (sorry, I mean XP), but does cIV even run on 9x??? ”
Rationale For mod-mods that use modular loading. The issue doesn't sound important, but,
despite the lengthy comments, the code changes are very minor.
Not merged “Major Enhancement: Incremental modular loading” — That's a bit more work to
merge and even more work to test as I don't know how modular loading is exactly
supposed to work. For what it's worth, it seems preferable to the “XML COPY” code
by MRGENIE in RoM-AND2.
Most of the non-XML bugfixes in the mod seem to have been included in the unofficial
patches. The rest I seem to have fixed myself (some 10 years later).
The minor optional rule changes and changes to help text, ultimately, aren't worth
including in AdvCiv.
See also This last item of the readme file has inspired a similar change tagged with “advc.006”:
“CyGlobalContext().getInfoTypeForString, when called with an unknown key string, formerly logged an error in
xml.log citing the last xml file loaded even if the call came from Python and had nothing to do with XML. ”
593
See also 250c also includes a couple of changes from Kek-Mod
001: My own misc. bugfixes
I've reported some minor issues with Kek-Mod changes here.
kekm.1 "Circumnavigation bonus is now always preserved when forming permanent alliance,
previously it was only when the player having it had smaller team number." (also fixed
in K-Mod 1.45)
kekm.2 "Fixed a (...) bug which caused unremovable espionage city visibility after forming
permanent alliance for all cities that the player with larger team number had visibility
of at that moment."
(As far as I understand, only kekm.26 fixes this properly.)
kekm.3 Defensive pacts despite war
AdvCiv BtS
BBAI option for defensive pacts despite war When war is declared on a civ, the defensive
enabled, and adopted a bugfix and extension pacts of that civ take effect and are then
from Kek-Mod: canceled. BBAI has an optional rule change that
leaves defensive pacts in place after taking
effect; disabled by default.
"now enable[s] defensive pacts to be signed A civ that declares war loses all its defensive
while at war." pacts. Can't sign defensive pacts while at war.
But the AI only signs a DP when sharing all wars;
cancels DP when wars are no longer shared.
And I'm allowing defensive pacts to be canceled
(0 turns to cancel) after a DoW.
Rationale May not make defensive pacts a lot more useful, but it's more plausible this way. As
for my adjustment: "We'll aid you against any further aggression, but, in your current
wars, you're on your own" doesn't sound like a typical military pact.
The immediate cancelation when no longer sharing all wars happens in
CvPlayerAI::checkCancel. If that code is removed, then 133 will handle the
cancelation, resulting in a probabilistic delay. This could give the DP ally enough time
to make peace, preserving the DP. After a test, I think a DP will rarely survive a peace
deal despite the delay, and it's cleaner to cancel the DP immediately.
See also 130y reduces the diplo penalty from DoW triggered by a DP.
104i makes the AI willing to talk with all DP allies upon making peace with one of
them.
kekm.25 allows DP votes while at war.
Tbd. What happens when A has a DP with B and C has a DP with D and A declares war on
C? I suppose they'll all be at war (that's how it works in Dawn of Civilization too); is
that desirable?
kekm.4 Can't gift cargo if it contains units that can't be gifted.
See also An addition to 123a
kekm.5 "Obsolete buildings and unused power plants (e.g. Nuclear Plant without Uranium or
in a city that also has Hydro Plant or receives power from Three Gorges Dam) cannot
trigger meltdown event anymore."
See also 652: Other rule changes to meltdowns.
kekm.6 Barbarians can't build spies.
See also 307 prevents the Barbarians from training some later-era units.
594
kekm.7 Can nuke despite neutral units; they take no damage. Additional AdvCiv changes:
Cannot nuke own units or cities, can't nuke enemy cities that have at least 10%
friendly nationality (i.e. total tile culture of the team owning the nuke and that team's
vassals or master), can't nuke enemy cities culturally owned by a neutral party, can't
nuke unrevealed tiles. Nuking any tiles with a neutral owner is disallowed, as in BtS,
but the check is now based on the revealed owner, i.e. nuking fogged tiles can now
trigger an unintended war, but hovering in Nuke mode can no longer leak info about
tile ownership in the fog of war.
Rationale Update: Probably shouldn't have adopted this. In theory, the BtS rule allows a human
player to deploy human shields that will make a nuclear war between two AI civs a
one-sided affair. But that's going to be relevant very, very rarely. I'll guess I'll be
keeping the change in place now; too unimportant to change it back and forth.
--
If the neutral units took damage (without having to declare war), this would again be
exploitable. Units in nuke range not taking damage is counterintuitive, but I don't see a
better simple solution. In the future, I'd like to restrict the effect of nukes to a single tile
(as the Close To Home mod has already done: Git commit); then it won't be so
strange anymore that only hostile units are hit because one can imagine that units of
different owners are encamped separately.
BtS and Kek-Mod allow hitting cities and unit's of one's own team. This makes it seem
all the more strange that neutral units take no damage. Best to avoid that issue by
prohibiting players from nuking their own people.
Generally, I'd prefer all wars to be declared explicitly before being allowed to launch a
nuke. Change 650 should eventually take care of that by allowing only (actively)
visible tiles to be affected. For the time being, allowing unexpected wars in the unlikely
case of outdated tile ownership in the fog of war seems preferable to an info leak
(although the leak was also of very minor significance).
Credits The issue with nuking non-enemy population in an enemy city was brought to my
attention by this post by CFC user SalvorSeldon.
See also 650: Various changes to nukes; see also Tbd. note there about diplo penalties for
nuking cities with minority cultures.
kekm.8 "Fixed bug in AI evaluation of gifted unit for the purpose of relations bonus."
Not merged "Player cannot gift combat units to third party which in war with rival with whom the
player has unbreakable (temporary or permanent) peace treaty. Also, the receiving
player now must satisfy technology requirements (both for the unit itself and for the
prerequisite resources)." [link?]
“Free units from tribal villages cannot move in their first turn. Gifted units are immobile
only if they change teams.” Git commit 1 2
These aren't restrictions that players would intuitively expect, and I'm not sure that
they're necessary. (I do think that there should be diplomatic consequences for gifting
units beyond "traded with our worst enemy.")
595
kekm.9 "Fixed how AI and worker actions treat fallout feature. Fallout had bNoImprovement
set to 1 signaling to AI that no improvements can be built there which didn't make
sense since fallout can be cleared just like forest and jungle can. This made AI far
less likely to scrub fallout (if at all) than to chop jungle although the features are
similar. Improvements can now be built directly on top of fallout and fallout will be
cleared in the process just like it is with forest and jungle.
Fixed interface and AI bug that caused the game to sometimes wrongly show an
improvement as unbuildable. Sometimes the game doesn't [realize] that an
improvement can be built. E.g. plains jungle yields 0 food so farm cannot be built as it
requires 1 food, but farm can be built there by chopping the jungle as the underlying
plains terrain yields 1 food. AI followed the same slightly flawed logic as did the
interface. My fix for fallout feature introduced many more such situations."
kekm.10 "Added verification of state religion. Player shouldn't be able to keep their state religion when
there are no cities with it anymore."
Rationale Disabled this again. I don't want to force a civ out of its religion while it may still try to
reconquer its holy city.
Config Disabled through CvPlayer::doTurn.
kekm.11 "Fixed advanced start bug with reduced unit costs. Advanced start code is bad in
general so I just fixed the immediate problem. (There was a way to get extra gold by
refunding a worker while having expansive trait.)"
kekm.12 "Removed Disorganized promotion from free barbarians boats with hidden nationality.
Hidden nationality units shouldn't be too obviously (non-)barbarian."
(But I'm not allowing Barbarians to have Privateers.)
kekm.13 "Fixed permanent alliance bug with AP/UN leader. Similar as with other permanent
alliance bugs, if AP/UN leader had higher team number than its permanent ally an
empty team would become AP/UN leader instead of the newly formed team."
Not merged "Changed condition when is a team considered AP/UN full member (and thus eligible
for election). Previously all team members had to be full members, but now at least
one is enough."
I don't have an opinion on how this should work.
kekm.14 "Set barbarian unit [gold] costs to 0. These costs don't affect barbarians directly, but
they still do influence some decisions."
Git commit
kekm.15 "Moved the code for building missiles for missile carriers outside of assault only case.
K-Mod made similar change for building planes for carriers already so I did the same
for missiles. Also fixed a bug when checking whether there are enough missiles
already." Git commit
“Fixed a bug (?) in missile production AI. Missiles for filling up missile carriers should
be built in low productivity cities and not high productivity cities.” Git commit
kekm.16 "Bomb Shelter was previously always evaluated as almost completely worthless (!!!). I
think that AI should build it as soon as possible pretty much everywhere as it is very
cheap and effective."
Git commit
596
Not merged "SDI evaluation previously ignored that nukes can quickly obliterate entire militaries
and there were some issues with estimating number of nuclear attacks."
Too much work to merge considering that the rules for nukes will have to change at
some point, and that the AI code will have to be revised afterwards.
kekm.17 "Game era calculation changed from rounding down to rounding of all players'
average era."
Git commit
Rationale I had always assumed that it worked this way, and I'm frequently referencing the
game era in AI and Barbarian code, so this should be a significant improvement.
Not merged "Added Advanced Settlers game option. When used, settlers behave similarly like in
Advanced Era starts, i.e. new cities start with more buildings and population as the
game progresses through eras. Settler era is a minimum of player's era and game era
[...]"
I want to add something like this, but I'm not quite happy with the implementation.
Looks like it could reward stockpiling Settlers, and the cost of a Settler can increase
while in production if the player or game era changes, which is a bit messy. Alternative
solutions implemented in other mods: A second Settler unit ("Colonist") with a tech
requirement in late Renaissance (which mod was that?) and Realism Invictus's
Ministries. Another idea: A production bonus for Ancient and Classical buildings from
e.g. the Steel technology.
kekm.18 "Hidden game options are now always set to their default value as they cannot be
changed or interacted with anyway and switching between mods can mess up those
options."
(But I've implemented it through CvInitCore::resetGame.)
kekm.19 "Capital cannot be moved while spaceship is underway. Reason is the fact that
capturing the capital destroys the traveling spaceship, so capital cannot be hidden in
this way after the launch."
Tbd. Would prefer to let the production cost of Palace increase over the course of a game.
This could also make it easier to move the capital in the early game when starting in
an awkward spot.
See also cdtw.6 causes the AI to move its capital when close to a Space victory.
kekm.20 "Fixed Bomb Shelter effect for non-combat units. Bomb Shelter used to reduce the
probability of nuke destroying a non-combat unit from around 80% to around 2-3%
(these probabilities are not immediately obvious and have to be calculated; exercise
is left for the reader) because someone was not careful with probabilities.
NUKE_NON_COMBAT_DEATH_THRESHOLD was probably picked so that the probability is
close to average nuke damage to combat units (which is 79%).
I changed the chance to destroy a non-combat unit to exactly 79%, and Bomb Shelter
halves that so those are now exactly the same as average damage to combat units.
NUKE_NON_COMBAT_DEATH_THRESHOLD is now unused."
Git commit, later bugfix
The formula sounds legit; just copied it.
See also advc.650 changes the damage formula for combat units, but I think everything in
DarkLunaPhantom's comment still applies.
kekm.21 "Show barbarian territory on the minimap and in the globe view."
Git commit
597
kekm.22 "Changed average handicap [in multiplayer] from round down to round."
Git commit
See also 250a bases that computation on difficulty values assigned to each handicap through
XML.
kekm.23 AdvCiv Kek-Mod
Razing: Not merged; no tile culture is removed. "Reworked how culture behaves when a city is
razed or acquired. Razing a city will now erase
Culture after trade is handled by change ctr,
(most of) its plot culture. Trading a city will
which converts only a fraction of city and tile
transfer both city and (most of) plot culture to the
culture. I've adopted the equal treatment of
new owner.
liberation and regular city trade from Kek-Mod.
Not all plot culture will be included because plot
culture is generated by different mechanisms
(e.g. trade routes and free plot culture) and
increasing and decreasing city culture doesn't
result in adding and removing the same amount
of plot culture.
I've merged this change. Cities liberated upon Also, liberated cities don't get free units just
the creation of a colonial vassal still receive the because a vassal acquired them and diplomatic
free units; that's also the case in Kek-Mod. votes resulting in changing of city ownership will
leave old owner's culture intact.
An attempt to get more consistent and sane
plot/city culture effects related to city trades."
Git commit
Rationale A single movement point spent on razing a city shouldn't be enough to ethnically (let
alone culturally) "cleanse" a region. Likewise, city ownership agreed to on paper
shouldn't instantly resolve all ethnic/ cultural conflicts in favor of the new owner.
Tbd. Razing should cause some loss of tile culture.
kekm.24 "Colonies don't inherit espionage points from parent civ anymore (this didn't seem fair
or necessary), but they do inherit EspionagePointsEver.
Colonies cannot reuse player slots anymore as this can cause weird bugs sometimes
and this is the easiest fix. Number of players can be easily increased (it already is 48)
so this is not necessary."
Git commit
I'm still allowing human players to reuse a slot when creating a colony.
Rationale The maximal civ count in AdvCiv is only 18 and increasing it comes with a
performance penalty. Reusing slots is not really compatible with the Immortal Culture
changes (I suppose culture will be set to 0 when the colonial vassal is initialized), but I
don't want to disallow colonial vassals entirely in games with 18 civs. If the player
doesn't like the result, he or she can hopefully reload a savegame. (Whereas the
player would be unable to prevent the AI from reusing a slot – if that were allowed.)
Tbd. Different approach: Store tile culture in an ArrayEnumMap<CivilizationTypes,int>.
That'll add some 15*4 byte to CvPlot and may also slow down some algorithms.
Peanuts though compared with raising the civ count. Upd.: But the same civ can be
played by several players at the same time, so it won't work quite this way.
See also 001: A couple of bugfixes pertaining to colonial vassals and the Random Personalities
option.
598
kekm.25 "Reworked resolutions. Fixed multiple bugs and inconsistencies with conditions for
proposing and defying resolutions. [...] Vassals cannot defy resolutions anymore.
Players can defy resolution assigning them a city. AI can now choose (and vote) to
repeal resolutions."
Git commit
Changed it so that only capitulated vassals are unable to defy. Voluntary vassals can
defy everything except war and peace votes (in BtS, they can defy everything, in BBAI
they can defy peace votes but not war votes). And defiance takes no effect if the
defying civ is no longer allowed to defy by the time that the vote is resolved; e.g. when
that civ has become a vassal while waiting for human votes.
Regarding a comment in CvPlayerAI::AI_diploVote about vassals and friends of
the Secretary General in repeal votes: "[O]nly important if the Secretary General
plans to vote yes. Incorporating the other case properly would be a lot of additional
work....". I've tried to do that extra work; hope I got it right (so that friends and vassals
help the Secretary General repeal resolutions).
"Human vassals are forced to vote for their master. Unless they are also a candidate
themselves."
Git commit
Only relevant for the R&F option because humans can't normally become vassals in
AdvCiv.
I'm only applying this to capitulated human vassals.
"War resolution can now be proposed against voting members (and non-members).
Defensive pacts with attackers are cancelled before implementing war resolution."
I don't think this ever works the way it's implemented in Kek-Mod.
CvGame::canDoResolution checks if all voting members – including the target! – are
able to declare war on the target. I've corrected that: Now only full members are
checked, only they declare war and only they can defy the resolution. These change
are tagged with “kekm.25/advc”. Moreover, only peace treaties of the AP leader can
block a war resolution; peace treaties of other members don't matter. (But the AI tries
to honor its promises by voting against war when there is a peace treaty.)
Rationale Shouldn't expect human players to keep track of peace treaties between AI civs, and
don't want to allow players to block war votes by signing peace treaties (e.g. by asking
for a gift). K-Mod already allowed vassal agreements to override peace treaties.
See also 130f deals with stop-trading resolutions in a similar way.
CFC thread about a BtS bug fixed by the first commit listed above.
Tbd. Looks like a human war vote target (non-full member) will now get to vote. Should be
an automatic vote against instead. That's handled by CvGame::addVoteTriggered.
Planned changes to membership rules (see 178) will address the problems with war
votes in a simpler way. And I don't think I want civs without a state religion to be
eligible targets for war votes.
599
Not merged "Religious population for votes in AP is now divided by number of religions in the city.
Defiance penalty is now given to the whole team if one team member defies a
passing resolution."
This penalizes civs too much for heaving multiple religions and might weaponize
Missionaries of non-AP religions. Also, a state religion tends to have larger
communities than a non-state religion (and a civ with a state religion not matching the
AP religion already has its votes reduced).
Not sure about the defiance penalty. If civs vote individually, then it seems that they
should also bear the consequences individually.
See also 130v makes capitulated vassals vote along with their master and places many other
restrictions on capitulated vassals.
178: My own changes to AP votes
kekm.26 Git commit
“Finally fixed the bug with espionage visibility. Adjusted CvTeam::shareItems so that
only use is enough.”
(Cf. kekm.2)
“Scaled third party counter towards new team with number of players in each team for
consistency.
Fixed bug with no tech brokering status not being preserved properly.
Espionage points of the new team and towards the new team are now sum of the old
ones instead of max.”
All this only concerns Permanent Alliances.
“Changed how multiple war declarations work. declareWar used to nest war
declarations, now they are queued to trigger defensive pacts and everything else in
the correct order.”
This may also be an improvement in other situations; hard to say. There was a bug
preventing updates of the attitude cache; fixed. The bugfix was also included in Kek-
Mod 0.25.
Not merged “Increased victory conditions for permanent alliances. Number of required spaceship
(for now) parts is multiplied by (1+0.5*(number_of_players-1)) rounded up. Number of required
cities for cultural victory is multiplied by (1+0.5*(number_of_players-1)) rounded
down.” Git commit
“Adjusted domination thresholds for permanent alliances. Minimum land percentage is
now 100*(1+n)/(3+n)+1 where n is number of players in the team. This used to be 51
for all teams. For domination population, in addition to 25% lead required, the
population of the second best team is scaled with the standard ratio of (1+0.5*(n-1))
values for both teams (with a minimum of 1), i.e. larger lead is required in the case
that the second best team has less players.” Git commit 1 2
Perhaps very sensible changes, but it's difficult to say without really having played
with Permanent Alliances. This would have to be mentioned somewhat prominently in
the main part of the manual.
Not merged “Changed how maximum distance is calculated”
See 140
Not merged “Always show Dawn of Man when beginning a new game” Git commit
Already handled by 704, 250c.
600
kekm.27 “Added OOSLogger. OOSLogger creates a file with all the data used for computing
the sync checksum when OOS is detected. Idea from Fall from Heaven 2 by Kael.
Implemented as a slight modification of the version in ExtraModMod by Terkhen.
Implemented as a BUG module.”
Git commit 1 2
The log is created in the Logs folder and named “OOSLog”. I've added a MessageLog
check (to make sure that both players are aware of the logging), fixed a few of bugs
and made some minor adjustments. These were also adopted by Kek-Mod 0.25.
Not merged “Improved OOSLogger” Git commit
Not really an improvement for my purposes.
Tbd. The log is sometimes triggered because game scores don't match. On the next time
slice, scores are updated by CvGame and back in-sync. Not sure if this is a false
positive or a problem with CvGame::setScoreDirty somehow getting called
asynchronously.
Move this mostly into the DLL? A CvGame function would be easier to keep updated
with the OOS checksum computed by CvGame. And in Python, syntax errors go
unnoticed and then parts of the log is lost when an OOS error actually occurs.
To be merged: A similar but hopefully more potent tool by Nightinggale:
Git commit
Logging of game net messages by alberts2:
SourceForge revision
kekm.28 “Barbarians also get some starting tech in advanced start. […] Techs they get in
advanced start are the average of all player's tech status after advanced start.”
Git commit
“[...] [D]on't try to give free units or advanced start points to barbarians.” Git commit
See also The rest of that second commit is covered by 250c.
Not merged “Barbarians require revealing and enabling tech for resources to be able to get units
which require those resources.” Covered by 301.
kekm.29 “Fixed a bug in target city evaluation for cities that would be autorazed.” Git commit
Obsolete; fixed differently now.
601
Not merged “[O]ption to adjust water percent in not_too_Big_or_Small. Default water percent in
not_too_Big_or_Small is 74 and sealevel options can change that by -8/0/+6. Adjust
water percent option can change that by 0/-5/-10/-15/-20/-25.” Git commit
Too extravagant.
“Added a new climate […] called Warm and is mainly characterized by less ice and
tundra. It is available for all mapscripts that use default climate system. Created by
AjmoCiv.” Git commit
Not as evocative as the other climate settings.
Not merged “Added Gigantic map size. It is larger than Huge. A lot of values in CIV4WorldInfo.xml
seem arbitrary, but I tried to preserve some kind of pattern.”
Covered by advc.test.
kekm.33 “Changed espionage costs for teams. I want costs to scale with 1+0.5(number of
members - 1), but since there are two teams (and two directions) involved, it will scale
with the square root of the ratio of those values. Idea for formula by Fran.” Git commit
(Fran must be a player at “Zulan's Civilization corner“)
In BtS, mission costs aren't adjusted to the team size at all. K-Mod 1.45 multiplies the
cost by the team size. The same handicap (+50% per team member) should apply as
for tech costs – which is what the Kek-Mod formula does.
Not merged “Changed how unit type for draft is determined. [...]” Git commit 1 2 3 4 5 6 7 8
Too much work for too little gain.
kekm.34 “Split CyCityInterface in two parts. Its size was obstructing compilation of debug DLL.
Some minor spelling corrections in changed files.” Git commit
Large Python interface files can lead to a “debug information module size exceeded”
error when compiling a Debug DLL. I've never encountered that error, but keldath has
confirmed it. I guess it's code bloat caused by the boost::python macros.
See also According to Nightinggale (CFC post), the file size limit is imposed by Boost. (So I
guess it applies throughout the GameCore codebase since Boost headers are
included in the precompiled header.)
602
kekm.35 “Changed some details of how starting locations are picked. [...]” Git commit 1 2 3 4
“Starting area picking system is changed so that it doesn't overvalue large, but very
bad areas. When picking starting location, locations with very little food (before
normalization) will be avoided if possible to avoid starting on the edge of very bad
terrain (after normalization).”
Due to 027, the choice of the starting areas normally only matters as an initial solution
for my own starting position algorithm. Still, a better initial solution is better, i.e. may
lead to a better final solution or may at least save time.
“Fixed a bug in location evaluation in case when starting location needs to be picked
again in advanced start.”
“In advanced start, the possibility of automatically exchanging starting location with a
teammember under certain conditions is now removed. (Why was that even there?)”
Merged but disabled. It seems that the BtS code doesn't have any adverse effect and
perhaps it does somehow lead to a fairer turn order in team games.
“Strengthened starting location (pre-normalization) food prerequisite.
Instead of 5x5 area, the whole standard advanced start sized area is checked for
food.”
“Changed starting location conditions to improve avoidance of bad terrain and edges
of bad terrain. If possible, only locations with large enough per plot yield average in
the advanced start sized surrounding area are considered.”
Merged except for the randomization part, which 027 already adresses (even when
Starting Position Iteration is disabled).
Not merged “Starting location picking system is now the same in every game mode. After
randomly assigning preplaced starting locations, it first picks locations for some
number of AIs depending on handicap, then for all humans and then for the rest of
AIs. Order doesn't depend on player id numbers. This is done this way because
locations picked earlier are usually better.”
Covered by 108b except perhaps for team games, but all that is a bit complicated, so
I'm not going to bother with it (again).
Not merged “Require debug mode for cheat actions and tooltips.” Git commit
Covered by 135c.
kekm.36 “Wonder list now uses player text color instead of primary color.” Git commit
“[A]dded calculation for number of non-early religions, [...] primarily for mod
compatibility.” Git commit
Not merged “Adjusted era factors in calculations [...], primarily for mod compatibility” Git commit
Addressed by advc.erai.
kekm.37 “Fixed a crash when pillaging is intercepted by sea patrol. [...]” Git commit
I don't think I ever experienced that crash, but it sounds plausible that it could happen.
603
kekm.38 “Internet now counts players and not teams. […] Internet's description and tooltip
mention civilizations, but the code used teams. I changed the code to agree with the
description because that seemed to make more sense for permanent alliances.
Additionally, each aditional team member now increases the civilization count
requirement by 1.” Git commit
The last part doesn't make sense to me, so I haven't adopted that. The alliance
already takes away one player from whom tech could spread via the Internet, so why
increase the threshold for tech spread in addition? And, depending on the total player
count, a threshold of 3 can be a lot more strict than 2.
As for balance in proper team games, in BtS, the Internet is less powerful in team
games than in non-team games, and the Kek-Mod change reverses this – because, in
team games, there is less entropy in the distribution of techs among players. E.g. in a
game with 4 teams of 2, the Internet will grant all techs that 1 of the 3 other teams
knows. I woud prefer to make the Internet just as strong in team games as in non-
team games, but there's no middle ground to be had. In particular, increasing the
threshold from 2 to 3 in games with teams of 2 would be no different from increasing it
to 4 or counting teams instead of players (as does BtS).
604
"Added CvPlayer::haveResourcesToTrain
This is used to help with AI decisions when it isn't clear which city we'll be building in."
Used in just one place so far though.
"Decreased food devalue rate. (Fast growth is more highly valued.)
bEmphasizeFood causes more optimistic evaluation of slave-whipping.
SlaveryValue re-written to use a 'devalue rate' system.
growthValue now takes into account the food cost of worked jobs.
'plotMagicValue' now (usually) assumes fully-upgraded improvements.
'Emphasise food' should work better now.
CvPlot::getYieldWithBuild bWithUp now uses full upgrade rather than 2 stages."
"AI_updateCommerceWeights now better understands focused espionage.
Having very high values on the espionage weight slider are now taken to mean that you don't want to spend
espionage on the other teams. This reduces the chance of the AI choosing to assign spies inappropriately.
Previously, having a non-zero weight against a team was taken to mean that the player wanted to [have?]
espionage points against that team - and thus espionage was more highly valued if the points were low. Now
that is only the case if the weight is above a certain threshold. The threshold is based on total weight, and
number of teams etc."
"Minor tweaks to CvCityAI::AI_buildingValue
Reduced building value of free-tech. (The evaluation for this is still just a very poor guess; but it is very
difficult to evaluate it properly. A true evaluation would require details which we currently do not take into
account.)
Reduced the value of espionage commerce multipliers."
"Many changes to AI_techUnitValue
We now use slightly more detailed war state info: bLandWar, bIsAnyAssault.
Default AI type max value weight increased from 100 to 250, but calculated weight decreased. (ie. Units that
are good at their default role will now be valued much more highly; but units that are poor will be valued
slightly lower.)
Increased max value weight for non-default types (from 100 to 150).
Adjusted most military values based on bLandwar status, as well as other strategy adjustments; such as for
ECONOMY_FOCUS.
Added an optimistic value bonus for tech which reveal required resources."
"For UNITAI_COUNTER, reduced value of attack modifier, added value for defence modifier. Reduced value
of speed. For UNITAI_CITY_DEFENSE, added value for hills defence."
"Tweaked small-city yield evaluation. Yield evaluation now assumes that cities with population < 3 will want
to grow, even if there are currently no good jobs. This helps prevent flip-flopping with food plots."
"Many changes to AI_techValue.
Disabled the random value bonuses for techs with iPathLength > 1. (Raw bonus, and bonus from wonders).
ie. techs for which not all prereqs have been met no longer get these random bonuses.
Note: This is partially to help the AI focus on real benefits; but a big reason for removing this randomness is
a technical one. [...] changing the way multi-step research paths are evaluated. Having randomness in
prereqs could upset the evaluations because the values will be used for several techs.
Decreased random wonder value.
Increased the value of gold trading.
Changed several constant values to scale with the number of cities. (These things don't necessarily have
anything to do with the number of cities. We're only multiplying by cities so that the value scales like things
which are evaluated properly.)
Moved project evaluations to a new function: AI_techProjectValue.
Increased value of civic improvements.
Decreased the value of religions.
Rewrote evaluation of bonus techs. It's now based on the average of the max tech cost and average tech
cost for currently researchable techs.
Renamed bIgnoreCost to bFreeTech, to better reflect what the argument is used for. Rescaled the return
value so that it is roughly comparable for free and non-free tech.
Renamed "tech whoring" to "tech ground-breaking", to better reflect the concept. (ie. getting the tech first, for
better trade options.) Slightly increased the value."
"Rewrote CvPlayerAI::AI_bestTech to better consider tech pathways.
605
Previously the AI would choose to beeline high-value techs within the depth limit without considering the
prerequisites at all. This sometimes led to poor choices; eg. getting stuck on very high cost prereqs, or
researching prereqs which would obsolete important bonuses. In the new system, the AI only ever chooses
techs that they can research; but adds value based on which techs follow on.
NOTE: this is a totally new system which will require some changes and balance."
I had fixed these two bugs and another one mentioned here by Mattygerst, but replaced my bugfixes with the
code karadoc released in early May 2018. I've decreased the DepthRate so that the AI is less interested in
beelining toward powerful techs. I worry that a high DepthRate makes AI tech paths too predictable.
"Minor changes to AI unit movements.
Tweaked attack threshold for AI_attackCityMove. Increased the acceptable number of ship loading turns
AI_attackCityMove
Disabled the 'smart' danger aversion in AI_pirateBlockade. (It was computationally expensive, and not
particularly effective.)"
I've written a cheaper danger check as a replacement.
606
cdtw.1 "vassals are more keen to keep [rather than raze] cities, as they can't declare war
themselves to expand"
cdtw.2 Regarding the AI choice of target city when in a Blitz or Fast-mover strategy: "when
blitzing place higher value on cities with no defense modifiers"
See also 104d always takes into account tile defense when choosing a target city.
cdtw.3 AI evaluation of tech that unlocks a process (Alphabet, Currency, Drama): "value
good processes if we already have lots of units, and are not at war with anyone".
Disabled this again after some testing. Early unit spending doesn't seem to be an
issue in K-Mod/AdvCiv.
cdtw.4 Greater willingness to switch to Police State when war weariness is painful.
cdtw.5 "if we're worried about being attacked, don't wait to sign defensive pacts"
cdtw.6 "if we're going for a space victory let's quietly relocate our capital away from the coast"
Probably bugged in LoR SDK ModMod because AI_isDoStrategy had been
confused with AI_isDoVictoryStrategy.
See also kekm.19 disallows moving the capital once the spaceship has been launched. So the
AI can only move its capital prior to launch.
cdtw.7 "if going for culture victory, build lots of fighters to avoid be[ing] blitzed"
Disabled again. I guess that's really only smart when playing with Dale's Combat Mod.
cdtw.8 "if our best city attacker is crappy, be less likely to build invaders, unless we aren't
paying support costs yet"
Disabled again; K-Mod seems to have this covered.
cdtw.9 In Unit AI, a few checks for same owner replaced by same team.
607
rom1 "% modifiers are undervalued by the AI for two reasons:
1) It only calculates its effect at the time of construction, but that discounts future increases as base research goes up
2) In the early game because this calculation only takes account of the absolute increase, not its proportion of the
civilization whole, which will be substantial early on (indeed 100% with 1 city).
We therefore apply a small boost to reflect futures, and compare to the whole and make an upward adjustment
proportional to the ratio with the civilization whole.
FUTURE - should we do this for other commerce types too? I am inclined to say no for hammers (since what you
produce with them scales with civ size, which the tech tree does not except very indirectly via progression through it).
Not sure about gold or espionage."
SVN revision
This change increases the utility assigned by the AI to buildings that increase a city's research rate. However, this
applies only when the City AI wants to focus on research buildings, which is actually never the case in K-Mod. So I'm
also adding this koshling change from the same revision:
"increased priority for economic builds,"
which makes the AI choose city production with focus on all economy buildings, including research buildings.
Removed this again; in multiple test games, it never had any effect. Looks like K-Mod
already prioritizes economic buildings sufficiently. The AdvCiv code with the change
still present: Git commit
Credits Koshling
rom2 AI doesn't reassign working plots while in anarchy as "plots return no yields anyway."
SVN revision
Reassigned working plots don't seem to be causing problems in AdvCiv, but it does
save some CPU time.
Credits Afforess
rom3 Resources can be randomly discovered only on terrain where they can normally be
placed. E.g. no Gold on Grassland.
Rationale The particular terrain restrictions for Gold, Silver and Gems are pretty nonsensical, but
slightly helpful for game balance, and should be enforced for consistency.
Credits Afforess (but merged from this SVN revision by alberts2)
See also 129 changes the terrain requirements for Gold and Silver a bit (but they still don't
make sense).
rom4 Avoid a costly canTrain calls in CvCityAI.
Credits alberts2 for Caveman2Cosmos; SVN revision
See also In part superseded by the FOR_EACH_NON_DEFAULT_PAIR macro (advc.enum)
advc.mnai Various tweaks to the behavior of AI units from the “More Naval AI” mod
608
Credits Too laborious to document those separately.
Fully or mostly merged: Git commits 1 2 3 4 5 6
Partly merged: 1 2 3 4
All by tholal.
I've scoured the whole repository. There are some more things worth adopting; the
links to those commits are scattered across the manual.
More recent changes from MNAI-U (“unofficial” continuation of MNAI) by lfgr:
12345
See also Some other changes from MNAI have different tags; will have to do a full-text search
on the manual to find them.
devolution Contributions by Erik (cf. this post and subsequent ones in the AdvCiv thread)
See also advc.make: Build optimizations
003h: A performance tweak of his that I merged from the “We The People” mod
006l: Stop-autoplay button on the failed.assertion popup, merged from “We the
People”.
Crash while exiting to desktop fixed (link).
OPT Performance tweaks; merged: Git commit
BUG Bugfixes; merged: Git commit
Also merged this correction by vedg (Igor).
And I've fixed a similar problem in CvPlayerAI::AI_techValue.
AI Misc. AI tweaks; merged Git commit 1 2
BM Benchmarking functionality added to AI Auto Play: Git commit
I've added a new shortcut Ctrl+Shift+B to avoid confusing players who just want to
watch the AI play.
Note that this measures wall clock time, not just the CPU time spent on the
Civ4BeyondSword.exe process. Measuring the latter doesn't really seem possible in
Python 2.4 (and generally difficult on Windows). That means, applications running in
parallel can significantly skew the result, especially video playback in my experience.
See also 004y adds the shortcut to the list in Civilopedia.
609
Work in progress
(Vaguely ordered by priority)
• [252, 253, 251] Evaluate the AdvCiv 1.07 changes to Marathon modifiers. Especially
uncertain about the Legendary culture threshold (change 251). Could also adjust
project creation speed a little to boost Space victory.
• [004c] Allow air units to destroy routes based on this Close to Home Git commit.
• [036] It appears that the AI will, rarely, offer free gold per turn or a resource to a
human player. Bug report 1 (after 3rd quote box) | 2 (end of post)
Conceivable that it's, in part, an issue with the human side of the trade becoming
illegal during intervening turns; if so, moving AI-to-human diplomacy to the start of the
contacted player's turn would fix that issue (and some lesser issues); if nothing else,
it would make bugs like this easier to reproduce as the AI decision would be made
right after auto-saving. See also “Tbd.” under 001e and this CFC discussion.
• [004] Don't show tick marks on progress bars when there would be 15(?) or more.
Looks too busy and isn't helpful.
• [003] Get rid of the GetCString functions at CvString and CvWString; directly use
c_str (std::string, std::wstring) instead. Firaxis seems to have used GetCString
so that the Cv... string classes could be used interchangeably with a class named
“FString” in template arguments; however, FString is not even part of the SDK, so it's
only confusing and clunky.
• [083, 099c] When not at war, not running the Alert strategy and war is not imminent,
CvUnitAI::AI_moveToStagingCity should prefer cities with a revolt chance. Could
e.g. multiply the utility value of a city by one plus ten times its revolt chance. (Ideally,
revolts should also play a small role when already at war, but “a small role” is a bit
difficult to implement because the current utility value is not on any particular scale. )
To avoid oscillation, present garrisons should be ignored when calculating the revolt
chance of the city that the unit is presently at. Related CFC post (under “Revolts”)
• [022] The AI probably adopts the Alert strategy too rarely, so maybe the paranoia
rating should be higher (which will also affect the ThirdPartyIntervention aspect of
UWAI) or the thresholds and adjustments in CvPlayerAI::AI_updateStrategyHash
smaller.
• [092] With the BUG drawing method for the list of unit icons, there might be an
occasional issue preventing large stacks from being selected. Hopefully already fixed
by the v1.06 release candidate. Bug report
• [advc.tsl] Had multiplayer games with the True Starts option go out of sync right away
a couple of times after having run a single-player game on AI Auto Play on the host
before hosting the network game. But I haven't been able to reproduce this in three
attempts, and I'm not positive that the True Starts option is the problem.
Update: Now fixed a bug with the True Starts option having had an ID that has to be
reserved for Lock Modified Assets. This might've been the cause.
• [UWAI] Keep an eye out for situations in which a human player without an army to
speak of can join a war between two militarily powerful AI civs to get a lucrative
peace deal. It's possible that the AI is estimating the military impact of humans too
610
highly in this context. Related CFC posts 1 | 2
• [004] Show the SS Part effects introduced by BtS (greater speed through engines,
thrusters, greater success probability through plating) in project help text. Perhaps
phrase it as increased mission time, failure probability when having fewer Parts than
maximally possible. Related CFC post (under “Space victory”)
• [101] Keep an eye out for game states with several cities conquered in somewhat
quick succession. Would it be OK for revolt chance to decrease more slowly after
some 40 turns? Would this reduce micromanagement, mMaybe especially on
Marathon (after about 80 turns)? Would it help, on Marathon, to discretize the time
factor a bit? Related CFC post (under “Revolts”)
• Check whether the AI can be baited with workers or other cheap or outdated units
into exposing an expensive late-game unit. Related CFC post (under “Questionable
attacks by AI units”).
• [031] Can I get the AI to place fewer cities that really bother players who think that
long-term city planning is more important than high-level players do? That seems to
be at the bottom of continued complaints about AI city placement, especially about
cities one tile away from the coast. (Though I could be wrong and there might be
some unintended AI behavior at work – however, the AI cities I see in my games look
reasonable, at least when viewed from the perspective of their owner at the time that
they are founded.) Should be possible to avoid cities that will irk players without
changing the overall approach. (Favoring quality of worked tiles over quantity is a
fundamental insight of advanced-level players; this is not a case of the AI being
programmed to be too fancy. )
Will have to run a bunch of AI Auto Play games, preferably on Huge maps, to find
inland cities that are able to work any coastal water tiles with extra yields (seafood,
Colossus, Financial trait). Then see if these are primarily caused by insufficient
exploration or by a low priority for sea access. In the former case, one consideration
is to discourage cities with – or even just adjacent to – unrevealed workable tiles.
Though getting the AI to explore more effectively would be preferable.
CFC post (I've also received a private message in the same vein.)
• [083] Keep an eye for situations in which two AI selection groups with complementary
uneven ratios of lethal to non-lethal units move near each other and could be
merged. (spqkfk has pointed this potential improvement out to me in a private
conversation.)
• [120, 120b] Consider adding a per-instance cost modifier to Spy units. Also check in
complex late-game states whether small disgruntled AI civs perform pointless attack
missions against unassailable worst enemies. Related CFC post (under “Espionage”)
The remaining issues were considered “open” prior to AdvCiv 1.0, but are fairly unlikely to
be addressed at this point. They're either not really actionable or don't bother me much.
Above, throughout the appendix, many more issues and ideas for improvements are
mentioned in “Tbd.” boxes; those never were likely to be implemented. (And I've been
maintaining a long list of small quality-of-life changes of even lower priority that I'm not
even including in this document.)
• [124] An AI leader should refuse to sign (or should cancel if already signed) Open
Borders with a leader who is the worst enemy of several other leaders that the first
leader cares about. May have to weigh the number of foreign trade routes that the
611
first leader is forgoing and the importance of (appeasing) the second leader (city
count?) with the first leader's attitude toward the third parties and their importance.
Reason for trade denial: Could use “We couldn't betray our close friends!”
(DENIAL_ATTITUDE_THEM), but probably better to add a new denial type, e.g. “You have
made powerful enemies...”
• [advc.enum] Some large classes – CvPlayerAI comes to mind first – could use a
pass of refactoring that replaces arrays with enum maps, for loops with various
macros and iterator and allows all small functions to be inlined (and not just when
whole-program optimization is used).
003t: XML loading code should also use enum maps, especially CvInfo_Unit.h.
• [UWAI] Affection cost in team games should be based on the no-war attitude
probability of the current team member, not the average of all team members.
Related discussion
Problem with this: Call locations of CvTeamAI::AI_noWarAttitudeProb should be
consistent with the behavior of UWAI's Affection::evaluate.
• [UWAI] Dial up the impact of war success on the conf... variables in InvasionGraph::
Node::step when a war has been going on for some time and has seen a lot of
fighting (high total war success). Currently, a human player attacked by an AI civ with
clearly superior power ratio (say, 150 to 200%) and superior production capacity
won't ever get a peace deal. In such a situation, the human civ may well be able to
hold onto its cities, but probably won't manage to start a counteroffensive. Even if the
AI will win such a war in the long run, it won't hurt to at least take a 10-turn break now
and then.
• [UWAI] The AI estimate of military build-up based on the power graph needs to
account for units destroyed during war somehow. Those losses do not imply that a
civ has stopped producing new units.
• [130i, 130p, 148] Some of the Dynamic Diplomacy changes have made it more
difficult to befriend AI players. Consider letting the relations modifiers from Open
Borders and Defensive Pacts increase to up to +3. As for Defensive Pacts, the AI
may then also have to be more discerning about signing them or the relations
modifier will have to be based on how threatened the AI feels and who is protecting
whom. Fair trade could be based more on the total trade value; it's still mostly based
on the difference in trade values. In AdvCiv 1.0, I've already decreased the Friendly
threshold by one more and made the mutual struggle diplo modifier some 20% more
sensitive to war successes (and thus also a bit more lasting). I still don't think this
fully solves the problem. In any case, having more ways of pleasing the AI would
make games without tech trading more interesting. CFC posts: 1 2 3 (4th paragraph)
[130i] Pleased attitude might be too difficult to reach in team games, perhaps
because of my changes to the Open Borders relations modifier. CFC post
• [130r] Exponential backoff mechanism for AI contact delay? To ensure that the AI
doesn't offer the same trade over and over. CFC post
• [UWAI] War trades might be offered too rarely. Perhaps I should relax some attitude
thresholds (CFC post), or perhaps it's already better now (since v1.0) that Friendly
attitude is easier to reach. v1.02 also tweaks the war utility threshold for the “enough
on our hands response” (but I don't think that'll make much of a difference).
612
• [131] When the player clicks an emphasis button on the city screen, the AI governor
should try hard to make a change from the current assignment that increases the
chosen emphasis. The player probably wouldn't click that button if he or she was
happy with the current assignment. CFC post (under “Citizen automation”)
• The AI should remember for each city job whether the assigned citizen was assigned
manually or by the AI governor (like in Civ 5). Citizen Automation should only apply to
the AI-assigned jobs. Disabling Citizen Automation could clear the job assignment
status, meaning that re-enabling Citizen Automation will allow the governor to assign
all jobs. CFC post – see previous bullet.
• [BM] Consider limiting the Civ4BeyondSword.exe process to a single core for
performance tests; maybe even in general if it turns out to be faster. Can try it
through the Task Manager: “Details”, context menu, “set affinity”. Programmatically:
see 2nd answer here.
• [055] Global Warming: Should the population portion of the formula be tied to
technological progress (or is it already), e.g. at least one player in the Industrial era?
Some problem with map size or speed scaling? CFC discussion play report (with
some sample numbers)
Future Tech should grant some Global Warming protection. Idea (CFC)
Perhaps add a “No Global Warming” game option.
• [200] Is the (K-Mod) Great Artwork ability too powerful when starting in a later era
(since no culture has accumulated yet)?
• [001] Check if the Ctrl+Shift+L shortcut (Civ Changer) disables the "wait at end of
turn" player option as reported here.
• [kekm.3] When a civ declares war and both sides have Defensive Pacts with
(different) third parties, then the third party that has a Pact with the aggressor should
not end up at war. Verify that this is what happens.
• [021b] PerfectMongoose: See if I can combine the PW2 and PW3 elevation maps for
the best of both worlds. Mountain ranges look strictly better with PW3, whereas PW2
produces larger and more convex continents, which tend to play better than the
Perlin noise curls.
• [077] Perhaps show info about foreign trade routes (“imports”) on the Info tab of the
Foreign Advisor screen. CFC discussion
• [312] Consider reducing the XP modifier on the attack from 4 to 3. This is already
implemented for Barbarian units. CFC post
• [031] The AI might value strategic resources too highly when it has few cities and no
prospects for expanding much; and perhaps not highly enough in the late game. The
evaluation doesn't really take into account how many cities will benefit from a
resource. See comment in AIFoundValue::nonYieldBonusValue.
• [082] The AI shouldn't embark units while gathering them for a naval assault. CFC
discussion
Might it be enough to remove the AI_load call in CvUnitAI::AI_attackCityMove under “if no land path to
enemy cities, try getting there another way” when pTargetCity is NULL? Or perhaps the loading
happens somewhere else entirely most of the time …
Potentially helpful: Git commit from MNAI
613
• [004] Some of the game text additions proposed in this post by CFC user crullerdonut
for terrain improvement should be worth implementing. I'd probably want to be a bit
more low-key, and some of it shouldn't appear only in Civilopedia. This post also
flags the lack of information about Tundra Farms.
• [UWAI] If add another game option, consider replacing "Aggressive AI (Legacy)".
(Should then also change the prefix of loading screen hints from “UWAI” to “AdvCiv”.)
• [UWAI] Too little warfare in team games? That may not be so wrong as AI teammates
aren't good at coordinating their attacks; so even when two members of one team are
on a landmass with just one member of another team, starting a war isn't a no-
brainer. Risk aversion might be a problem – if one teammate expects to gain 2 cities
and the other to lose 1, the team typically won't go to war. Could simply increase
utility from GreedForAssets artificially to get more wars going. That said, lately,
there didn't seem to be that little war fare.
• [advc.ctr] One player has reported that the AI will occasionally give away cities too
cheaply; not sure if there's really a problem.
Make some leaders extra thankful about city liberation, e.g. Gandhi. (Maybe also
some slightly less thankful.)
• [002] On certain surfaces, the Farm graphic flickers during camera movement. I
haven't checked yet whether this also occurs in BtS. The part that flickers is a flat
rectangle that seems to be related to the shadow cast by the barn. Perhaps it's too
close to the ground; or maybe I can just throw that out somehow? Even that is
difficult to do without any knowledge about .nif files ...
• [101] A couple of users report that it takes too many units or too much time to
supress revolts, especially prior to Rifling. Consider buffing Musketman. 1 (in the
middle) | 2
Perhaps foreign culture strength should be reduced a bit when the cultural owner has
been defeated.
Consider slightly adjusting foreign culture strength or revolt probability to the map
size. If there is more space to fill, there should be fewer incentives against rapid
expansion. CFC discussion
(v1.0 has addressed some of these issues, but maybe not fully – has made revolts
harder to suppress in the late game, but not easier in the early game; foreign culture
strength gets adjusted to the difficulty level of the city owner.)
• [055] Make it easier to disconnect Coal and Oil on purpose (for the sake of avoiding
health penalties and Global Warming anger/ events). Current problems: Can't discon-
nect resouces in city tiles; disconnecting Coal and Oil makes it impossible to build
Railroads; automated workers may reconnect disconnected resources. It seems that
trading a resource away works around all of these issues (not sure about Railroads),
but there isn't always a taker. Also, both trading and self-pillaging are pretty
counterintuitive plays. Might be best to add buttons somewhere for toggling Coal and
Oil on and off, e.g. on the Environment tab (Economics Advisor). Disabling a
resource that way should arguably also cancel any deals importing the respective
resource or, if impossible to cancel, notify the player of the ongoing deal. Another
idea is to turn the resource icons on the city screen into buttons that allow any
resource to be toggled on a per-city basis. Ctrl+click could affect all cities. Hover text
should arguably only mention those actions for Coal and Oil. Disabling a resource
614
could perhaps also affect tile yields, treating them as if the resource didn't exist. (But
that wouldn't work cleanly on a per-city basis.) Related CFC post (2nd spoiler box)
• [139, UWAI] Can CvCityAI::AI_updateSafety take into account remaining movement
points and turn order? Currently, when negotiating peace, the AI is equally alarmed
about units that can immediately take the city and units that will be able to do so on
their next turn. Both is alarming, but not quite the same thing.
The AI should not just care about cities that are all but certain to fall. Need another
CitySafetyTypes enumerator: CITYSAFETY_TOSSUP.
• [UWAI] The limit for what the AI is willing to pay for peace should be increased when
the tactical situation (clearly) favors the other side. Normally, it doesn't make sense to
pay much for 10 turns of peace, especially not to a human player, but it does make
sense to pay extra if it gets the AI out of a bad spot.
• [UWAI] InvasionGraph::Node::step sets its isNaval flag solely based on whether the
target city is reachable (at all) by land. Worse, UWAICache::City doesn't store
615
separate distances via land and via sea. UWAICache::City::updateDistance mustn't
just set pwd=d in the canTrainAnyCargo branch. Should instead maintain a separate
vector pairwDurationsLandOnly for distances computed assuming that
canTrainAnyCargo=false, and store an additional distance value distByLand at the
UWAICache::City object. Try encoding non-reachability through a distance value of -1.
Then Node::step could set isNaval if either there is no land-only path to the target
city (as is the case now) or if (important) WarEvalParameters::isNaval() and the
distance by sea (i.e. by any means; sea or land) is significantly shorter than the land-
only distance. Also UWAICache::City::attackPriority will have to use the land-only
distance for cities reachable by land if WarEvalParameters::isNaval() == false. Will
probably need a separate comparator UWAICache::City::byLandAttackPriority for
this.
• [UWAI] InvasionGraph::Node::resolveLossesRec seems to use costly memory
allocation.
• [UWAI] Limited war might be used too often and total war too rarely based on one
user report. My own observations are inconclusive; the AI behavior is probably not
way off.
• [130v] Now that vassals generally can't sign peace treaties and don't get a peace
treaty from city trades (advc.ctr) either, I could allow voluntary vassals to hire war
allies (as in BtS). Originally, my concern was that the vassal would force its master
into a peace treaty through change 146.
• [130m, 130w, advc.sha] Through human attacks, the AI relations bonus for "mutual
struggle" (CvPlayerAI::AI_getShareWarAttitude) can change throughout a human
turn. This can lead to an outdated AI attitude cache. Try updating the mutual-struggle
component of the cached value via CvPlayerAI::AI_changeCachedAttitude before/
after every human attack (for all war allies of the human). Also, for war enemies,
AI_getWarAttitude and, for all rivals, AI_getExpansionstAttitude, AI_getRival
VassalAttitude. (The latter two both call AI_expansionistHate.)
• [advc.sha] Perhaps bring back the relations bonus among civs in the lower half of the
scoreboard for AI leaders with rather peaceful personalities. (Based on peace-
weight? But what about Augustus?) Not during the game's start era though (ranks
change too often).
CFC discussion
• [130p] Perhaps becoming an AI civ's worst enemy by trading with the current worst
enemy shouldn't be entirely ruled out. It's not necessarily illogical. This would concern
the iAttitudeDiff formula in CvTeamAI::AI_enemyTradeResentmentFactor.
• [700] When playing with the R&F option, the "Retire" button in the Retire popup
should be labeled "End the chapter" instead.
• [UWAI] Try implementing two simulation trajectories (one slightly optimistic, one
slightly pessimistic) when performance isn't an issue, e.g. so long as there are fewer
than 100 cities in UWAICache. In the late game, outcomes tend to be clearer (greater
disparities in military power) anyway.
The constructors of MilitaryAnalyst and InvasionGraph should be the place to
implement this.
616
CFC discussion
• [130f] Peace treaties should block embargoes. I think, currently, players could ask the
AI to stop paying reparations to a third party.
• [UWAI] Should perhaps assume a higher guard ratio (in InvasionGraph::Node::step
and in ArmamentForecast.cpp – I've already tweaked the latter, but could tweak it
more by removing the current special treatment for humans entitrely) for humans
because, currently, wars against humans are usually judged by the AI as all (take
several human cities) or nothing, which takes away the nuances from AI war
evaluation. Possible side-effects: AI could become less alert about human attacks,
less willing to pay for peace, less willing to attack in the early game (when a high
guard ratio matters most). That might be OK.
• [UWAI] To (further) encourage AI civs with a very powerful military to fight multiple
wars at once: If all war enemies (current and projected) are pushovers
(UWAIAgent::Team::isPushover), force weId in InvasionGraph::Node::findTarget to
target WarEvalParameters::targetId() and force target=NO_PLAYER if InvasionGraph
::isPeaceScenario. To evaluate and implement this, I'll need a game state where a
civ that is way ahead militarily is being too slow mopping up.
• [104m] When asking for help, the AI should check if a package of several human
surplus resources would be valuable enough. (Also: Changes to tribute and help requests don't
really belong under id 104m.)
• [700] When the R&F option is enabled, perhaps show the victory stage in the
scoreboard help. Only show it if it's greater than 2. Maybe as a roman numeral after
the score, e.g. "1744(III)", colored orange if it's a rival at stage III, red if a rival at
stage IV and green if it's the active player at stage III or IV. And, ideally, the stages
should be computed by a simpler non-AI function that uses mostly public information.
• [083] Should add a shortcut somewhere in CvUnitAI.cpp that makes the AI conquer
empty cities in reach, perhaps just with a single unit – hoping that the rest of the
stack will respond appropriately to the conquest. The AI currently insists on going to
an attack-from tile chosen in advance (not necessarily on the shortest path) before
entering the city. Possibly related CFC posts 1 2
Similar problem: AI transports won't make opportunistic attacks on lightly defended
cities while headed toward their target city. The selection of the target city may also
be too predictable. CFC disucssion
• [UWAI] Try letting an AI civ estimate human military power more highly in situations
when the AI civ is not itself at war with the human. This should avoid AI-on-human
dogpile wars that are supposed to keep human cities from falling into a rival's hands.
It should also make the AI a bit braver when fighting alongside a human (more ready
to try and snatch away territory from a shared enemy) and more alarmed about
human wars of conquest.
• [306] Barbarian ships on patrol should eventually just permanently blockade some
city, or at least for a long time. Through CvUnitAI::AI_patrolMove, CvUnit::
getGameTurnCreated and a coin toss.
617
separately. Currently, Logistics::power returns the cargo capacity.
I guess this'll mean adding a capacity function to MilitaryBranch and all its
subclasses. Then go through all occurrences of [LOGISTICS] in the code and replace
power calls with capacity where appropriate. Logistics power should continue to be
included in Fleet power.
• [550] The relations bonus from "shared discoveries" should be based on the total
cost of the traded techs.
• [550d] The research cost adjustment for team games ( bTeamSizeModifiers) in
CvTeam::getResearchCost doesn't seem strong enough. May have to apply a modifier
to all research costs (not based on individual team size) in addition – if team size is
punished even more, Permanent Alliances may become unattractive. Could e.g.
multiply research costs by sqrt(CvGame::countCivPlayersEverAlive() / countCiv
TeamsEverAlive()). Apply this factor regardless of whether the bTeamSizeModifiers
parameter is set (I guess).
• [082] Implement UWAICache::updateRelativeNavyPower (see comments there) and
an auxiliary function for the intel ratio. Currently, the AI magically knows how a civ's
military power is split between land and sea units. The BBAI function CvTeamAI::
AI_getRivalAirPower also has this fault. Change 650 also lets the AI cheat with the
number of enemy nuke units.
• May want to force-disable HAPDebugger through gDLL->ChangeINIKeyValue in final-
release builds. Causes the game to get stuck at launch unless the HAP debugger is
actually running. Only a handful of modders have ever used it, and players
sometimes enable it out of curiosity.
• [085] Icons (e.g. religions) on the scoreboard are a bit displaced toward the top. I
took a quick look at CvMainInterface.py and BUG Scoreboard.py, but there is no
obvious problem. Perhaps an issue with the GameFont file.
• [707] Not sure if R&F games will end properly on a time victory. Should be tested
once with retiring (causing the game to end during Auto Play) and once without
(player controls a civ when the time limit is reached).
• Perhaps add an optional unit action button that deselects half of the currently
selected group. This has been requested here (penultimate bullet), and is actually
pretty easy to implement, as pointed out in this post.
• [127c] (see there under Tbd.) It's sometimes (very rarely?) impossible to add gold to
the trade table. I've seen this bug reported for Realism Invictus and Dawn of
Civilization as well. Workaround is to restart Civ; reloading without restart might also
suffice.
• [UWAI] Do something with AIDeclareWarProb from Civ4HandicapInfos.xml; currently,
it's unused. Just delaying AI war planning isn't good - that may well lead to bigger
attacks when they do happen. Perhaps make it into a preference for limited over total
war.
• [133] If resource trades are still canceled too frequently, try increasing the inertia for
keeping resource trades alive further. That said, it's probably already only canceling
when "nothing to gain", so a tolerance parameter may have to be added to the denial
function CvPlayerAI::AI_bonusTrade. Or simply reduce the cancellation probability
even if "nothing to gain" (when trading with a human). For AI-AI trades, consider
618
applying the inertia code that currently applies only to Human-AI trades – canceled
AI-AI trades could have a domino effect (unclear).
CFC discussion 1 2
• A bug introduced by BtS causes SAM Infantry to play its ranged-attack animation
rather than its intercept animation when intercepting aircraft. Disabling the wrong
animation in the DLL isn't difficult; could perhaps play the proper animation through
CyUnitSubEntity.PlayAnimationPath in Python. If I can at least verify that this is
feasible, I could perhaps prompt someone in this CFC thread to finish or fine-tune the
Python part. Possibilities for a more proper fix have been pretty much exhausted; see
earlier posts in that thread. Well, I don't think a CyUnitSubEntity (or for that matter a
CyUnitEntity) can be obtained, so this looks like a dead-end.
• [123f] To be tested: Is fail gold for world projects (the Internet) working correctly?
• [kekm.25] To be tested: Do vassals and friends behave correctly in repeal votes? Are
human vassals correctly forced to vote?
Larger features that I had considered including before v1.0 (not ordered by priority):
• Merge further UI conveniences from BULL-based mods and PlatyUI: See "Tbd." under
change id 004.
• Adopt some misc. tweaks from the BASE mod. Or rather from the mod's changelog (in
German) – the DLL is closed-source.
• Adopt the improved savegame format (explanation | Git commit) from the "We the
People" mod and perhaps also the revised setup for translations. Or at least this little
change. And UTF8 support. (Or perhaps that's easier to adopt from “A New Dawn 2” –
UTF8Support.h/cpp). Currently, special characters in leader and city names aren't
(always) displayed correctly if they're not HTML-encoded (Windows 1252 encoding, to
be exact) in the game text file. And the Japanese (Russian?) edition of Civ might not
even be able to load a mod with certain special characters next to an XML angle
bracket. Can't find where I read this originally, but here's a CFC thread confirming that
special characters right before a tag can cause problems.
When changing the savegame format, it would also be a good time for transitioning to a
single (31-civ) DLL.
• BBAI includes a file unofficial patch list.txt with "outstanding issues". Most of it is
incomprehensible, but a couple of items seem worth looking into.
• Scour SVN revisions from the the early days of Caveman2Cosmos and revisions from
RoM-AND from 2010/2011 for AI improvements and other useful tweaks that are easy to
adopt.
• Complete the EuroWorld scenario. Still a lot to do though and I've run out of steam
because the areas that interest me most are already done and because I regret a few of
my choices regarding landmass proportions.
• In large games, human players get contacted too frequently by the AI. Ideally, before
contacting a human player with an offer, the AI should compute some measure of
confidence about the offer being of interest to the human and decide based on that and
the number of players known to the human whether to proceed. Since offers can't hurt
the human player, there could be an option on the BUG menu in addition to further
619
discourage AI-to-human offers. I don't think the requests that come with a diplo modifier
are a big nuisance, so I don't think that a “cease bothering us” option is ultimately
needed. Known unhelpful offers: Trade offers for dead-end techs like Divine Right;
repeated offers for Open Borders. CFC disucssion
• To further improve the performance of UWAI in games with far more than 18 civs,
implement a heuristic for pre-selecting only the top 12 (or so) war targets. Top priority:
current war enemies, then humans. Then, for a start, I could try using K-Mod's
CvTeamAI::AI_startWarVal. For the targets that are ruled out this way, any calls to
UWAI functions need to be avoided; in particular, WarEvaluator::evaluate and
UWAICache::update mustn't be called. I might get away with updating the set of relevant
targets only once per turn. When a decision on war and peace comes up suddenly, e.g.
a war trade, war/peace vote or a tribute demand, K-Mod code could be used as a
fallback, but it's probably better to use some safe default behavior instead, e.g. refuse
categorically to be hired for war. Another potential issue: Evaluating a war plan against
a civ that has other war enemies could be problematic if no UWAI data is available
about those third parties.
• Try removing the at-war checks in the code for AI-AI war trades ( CvPlayerAI::
AI_doDiplo), i.e. let the AI sponsor wars without declaring war itself. UWAI should be
"smart" enough to handle that. Performance will be a problem though; may have to
check a bunch of preconditions beforehand to save time, e.g. check UWAICache::
warUtilityIgnoringDistraction. And can always make the check probabilistic to
improve the performance by a constant factor.
Brokered peace might also be doable. And the AI could demand that a human player
make peace.
• AI civs should ask other AI civs to stop trading with disliked third parties. Precondition:
Must be at war with the third party or the third party must be the worst enemy. Then
check denial (CvPlayerAI::AI_stopTradingTrade). Need to add a function
AI_stopTradingThemTradeValue that says how much the AI wants another civ to stop
trading. Embargoes will have to be win-win in terms of that value and AI_stopTrading
TradeVal. Could base the contact frequency on the ContactRand value for
CONTACT_STOP_TRADING (currently used for AI-to-human stop trading requests).
• Extend advc.xmldefault to some of the the large XML files like Civ4UnitInfos.xml. This
would make XML changes post-v1.0 more convenient.
• Make third parties less supportive of wars against their partners:
– Disallow attacks inside the borders of a non-war party. Air attacks should remain
allowed. Not sure about attacks at sea.
– Perhaps restrict railroad movement in third-party borders somehow during a war
(or always unless sharing a war, defensive pact or vassal agreement).
– Being at war with a friend (Friendly attitude) should raise the AI attitude threshold
for Open Borders by one level. There may have to be some delay to avoid making
an AI civ that starts a war look bad when its invasion is immediately stopped by
canceled Open Borders. The friendly AI civ will also have to check if the aggressor
is not too dangerous (e.g. check embargo denial).
• Tweak the AI personalities to make them more distinct and to match the historical
background better. (But don't introduce new quirks that players have to be aware of.) I
620
have notes for about one third of the leaders. May also have to adjust some diplo texts
to fit the personalities.
• Module with graphics from Varietas Delectat (VD) or BAT. Not sure what the best source
would be. Leoreth has made some adjustments to the VD graphics that would be nice to
have. Anyway, I won't do this on my own as I don't even want to play with those
graphics. If someone else does a merge, I can look into making the process easier.
CFC discussion; see also Tbd. under 002j about some changes to unit graphics that I'd
like to make.
Update: DeepWell published his Ethnic Units Extended mod in Feb 2022. That's very
easy to install on top of AdvCiv and to keep up to date. But doesn't cover cities.
A more expansive graphics pack could be extracted from spqkfk's AdvancedCiv Plus
(AdvC+) mod. Don't know how that overlaps with VD or which is better.
A different approach would be to curate graphics (from VD, AdvC+, other sources –
graphics modders have kept busy to this day) that won't have to be optional because
they're not just more realistic but also more functional than the original graphics. But,
even then, the increased download size will be a downside. And it's difficult to be more
functional than graphics that players are highly familiar with.
• Add a (worst) "enemy of my enemy" relations bonus.
• Perhaps decrease the 300% modifiers on Marathon speed to 250%.
• Changes in preparation of a tech diffusion system (see also "city trades" above). Should
only apply when tech trading isn't possible.
– The AI should make more gold available for trade.
– The AI should accept gold-per-turn as payment joining a war (now that joining a
war results in a peace treaty due to change 146).
– Gifted units should result in a sensible relations bonus (based on whether the
receiving side needs the units) and penalty from war enemies of the recipient.
– Increase the trade value of gold to make payment in gold (e.g. for civics changes,
joint war) more affordable.
– Make the "fair and forthright" and "traded with our worst enemy" modifiers more
sensitive. And also the "years you've supplied us with resources" bonus.
The documents about future gameplay changes on GitHub were mostly intended for a
version 2.0 of this mod (unlikely to ever be implemented). The following changes would be
suitable for v1.x:
• Various changes concerning religions, the Apostolic Palace and UN
• Forced Labor civic to replace Slavery when playing with the "No Slavery" option
(through an XML tag list of game options required to be enabled or disabled in
Civ4CivicInfos.xml).
621
• Limited Worker charges
• Drafting may consume stored food
• Changes to city conquest rules
• Reduce process conversion rates (e.g. Wealth), perhaps based on difficulty level,
and apply the mean of the city's production and special commerce modifier.
• Penalize extreme commerce slider positions (or frequent changes; cf. 157)
622