Advanced Civ

[MightyToad]

The one posted by P&nny is the "newer" one I was talking about. I was just going by the last modified date. The both look identical actually. Although, spaces look identical to tabs in notepad++. If they both work for you we can safely conclude the problem was located between the driver seat and the steering wheel.

 

[MightyToad]

These pop up during a war. The Civ created new vassal civ from it's overseas colonies. I've seen this three times now. Two times the "colonies" became the master rather than the other way around. Nothing else happens. Apparently harmless.
I did have this unsolvable CTD a few days ago. I think it maybe due to me screwing something up in XML. I didn't change anything to see if it reoccurs.

 

[f1rpo]

These pop up during a war. The Civ created new vassal civ from it's overseas colonies.

A bunch of things go wrong there. You could probably fix it by putting this

    if iPlayer == gc.getBARBARIAN_TEAM():
        return

under the iRivalTeam = argsList[2] line in onChangeWar (autologEventManager.py). Autolog shouldn't log wars declared by the Barbarians. Moreover, "iPlayer" is not actually a player id but a team id. That's another bug, but I think it's unrelated to the Python crashes you've encountered, The DLL code also has issues – it lets the Barbarians declare war before the new civ is fully initialized; however, letting Python ignore the Barbarian DoW should work around that. I'll (try to) fix all this stuff properly in v1.0. Never noticed it myself because I don't normally enable Autolog. Btw, the line number in your screenshot doesn't match my line numbers; it might be that you're using a non-AdvCiv version of autologEventManager.py; AdvCiv already fixes some (minor) bugs in that file.

I've seen this three times now. Two times the "colonies" became the master rather than the other way around.

I assume that the AI had moved its capital to the New World in those two out of three situations. Because otherwise it sounds kind of worrisome.

I did have this unsolvable CTD a few days ago. I think it maybe due to me screwing something up in XML. I didn't change anything to see if it reoccurs.

I'm attaching a v0.99b DLL with assertions enabled. Not as fast the release DLL, but might help diagnose errors. (Seeing that I'm not going to be able to load your savegames.) Should only be used in windowed mode because the failed-assertion popups don't work properly in fullscreen. Oh, and maybe you use the 48-civ version; uploading an assert build of that as well.

 

[MightyToad]

Yeah, that code works. It took me many tries since I don't understand code at all. It turns out python is extremely particular about indentations. I also didn't have the exact save. I had to recreate/ retrace my steps from an earlier save. This is during a war with 100+ units on campaign. So, that took awhile.
I enabled autologging in an attempt to find the cause of the CTD. I'm too ignorant for it to be of use to me, but I left it on anyway.

It had since occurred to me that the save itself could have just been corrupted. There was no way to tell since I routinely deleted older saves except the latest one.

On a side note. It would make things easier during a world war if the Air units were ALWAYS selected first by default. I typically want to bomb enemy units first before the ground units move in. As the front moves forward I will move 4 bombers into captured cities. Typically have 20-80 bombers total. I lose track where they all are. The game randomly selects a unit around the world to move which is annoying. A single turn on a world war can take an hour to move everything.

I assume that the AI had moved its capital to the New World in those two out of three situations. Because otherwise it sounds kind of worrisome.

This was on the Earthevolution3 map. The Khmer were being invaded by Mongols. I don't remember if they lost their capitol, but the mainland cities became the ottomans, and they from then on controlled most of the Indonesian islands. Which became my islands when I got marines.

I'm attaching a v0.99b DLL with assertions enabled. Not as fast the release DLL, but might help diagnose errors. (Seeing that I'm not going to be able to load your savegames.) Should only be used in windowed mode because the failed-assertion popups don't work properly in fullscreen. Oh, and maybe you use the 48-civ version; uploading an assert build of that as well.

I've changed too many things for a save game to work. I would have to upload the entire mod which is 120mb at this point.
I tried out the 48civ dll (in full screen mode). Have to TAB out to see the windows. A ton of windows about missing terrain/resources (bauxite, salt, marsh, ect). If a crash returns I will see if anything interesting pops up.

 

[svu97]

Is it possible to play BTS with K-Mod 1.46 AND Advanced Civ ? So I have both mods installed in my computer. I would launch the BTS and then load K-Mod 1.46 and then load Advanced Civ ? Or does Advanced Civ has K-Mod 1.46 built in and I only need to load Advanced Civ? Thank you very much for the mod and I'm looking forward to play many hours with it.

 

[keldath]

hi svu97,

first, its not possible to run more thn 1 mod in civ 4 usually *. unlike civ5, 6.

second,
advc is built on top of kmod 1.46 and it is the greatest Ai mod in existence for civ4.
so, load it, play it and prepare to sweat on ways to win it

 

[svu97]

Thank you. You have the answer I needed .

 

[Jorunkun]

Kudos, f1rpo.

I heard about AdvCiv on reddit and have been playing it for a week now, in place of KMod. Here's my notes.

I play huge totestra maps, marathon speed, with 18 random personality civs and no tech trading, no vassal states, no huts and no random events. With these settings, I can win on Monarch, but, after two years, have yet to win a game on Emperor.

With KMod, my main complaint is the mindless aggressiveness of AI civs, which keeps throwing stacks of doom at you and was overly fond of dogpiling. I also dislike the ability to whip more than one unit per turn, which means grinding through dozens of archers to take one pop cities every time.

AdvCiv is my new mod of choice because it fixed this while making the AI play smarter. Thanks a LOT, f1rpo!

Some other changes I liked:

- turning defense value of forests to 25%
- increasing move and cargo capacity for ships
- tech tree and building resets / changes

The main thing I don't think quite works as intended is the AI diplo changes. While I like the idea of relationship modifiers decaying, I found that the end result is that most AIs oscillate around cautious for most of the game unless you share a religion. Supplying resources seems to do nothing, as AIs constantly cancel and re-offer trades and even long time-trades often don't yield a bonus. The same goes for open borders agreements, which get cancelled and renewed seemingly willy-nilly.

Also, I'd rather have the old barb behavior back: on large maps there is huge variance now in who gets the grease and who does not based on the surrounding terrain.

That said, AdvCiv is a huge improvement on the already excellent KMod and I look forward to every new release.

Thanks again.

 

[f1rpo]

@Jorunkun: Thanks for the feedback.

The main thing I don't think quite works as intended is the AI diplo changes. While I like the idea of relationship modifiers decaying, I found that the end result is that most AIs oscillate around cautious for most of the game unless you share a religion.

Friendly attitude being too difficult to reach is an issue I'm aware of but undecided about how to address it. No Tech Trading takes "you shared your discoveries" off the table and mostly also "traded fair and forthright" and "traded with our enemies." I can see how that'll make even Pleased and Annoyed attitude somewhat rare.

Supplying resources seems to do nothing, as AIs constantly cancel and re-offer trades and even long time-trades often don't yield a bonus. The same goes for open borders agreements, which get cancelled and renewed seemingly willy-nilly.

I can imagine that a lot of resource trades get canceled on a (super-)Huge map, but, for Open Borders, really only a drop in attitude (normally from Cautious to Annoyed) or becoming the worst enemy should lead to cancellation – and there should be randomized delay, 5 turns on average, between the attitude change and cancellation.

Could you perhaps provide a screenshot of the diplo modifiers between two civs that, in your estimation, are too small, i.e. that you feel should sum up to a relations value +2 or +3 higher? Bearing in mind that the mod bases some of the modifiers, in particular OB, resources, shared war, on the usefulness of the traded items, not just the trade duration.

If there's any overtly nonsensical trade behavior by the AI, then I could look into that; will probably require a savegame on the turn before the AI cancels a deal. Canceling a resource trade and then offering the exact same trade (or a more generous one) can be legit because, usually, other players take their turn in between the AI decision to cancel a trade and the renegotiation popup on the human turn – but it should be quite rare.

Also, I'd rather have the old barb behavior back: on large maps there is huge variance now in who gets the grease and who does not based on the surrounding terrain.

I agree that, toward the end of the Classical era, Barbarian activity can become implausibly high in places where only a few Grassland or Plains tiles are unobserved. I've been meaning to decrease the Barbarian spawn probability on and near tiles where a Barbarian unit was recently defeated.

On a side note. It would make things easier during a world war if the Air units were ALWAYS selected first by default. I typically want to bomb enemy units first before the ground units move in. As the front moves forward I will move 4 bombers into captured cities. Typically have 20-80 bombers total. I lose track where they all are. The game randomly selects a unit around the world to move which is annoying. A single turn on a world war can take an hour to move everything.

I've never looked into that. The relevant K-Mod code has been easy enough to find – CvSelectionGroup::groupCycleDistance – hm ... looks like maybe cycling from an air unit to a non-air unit really should be discouraged.

A ton of windows about missing terrain/resources (bauxite, salt, marsh, ect). If a crash returns I will see if anything interesting pops up.

In theory, it should be possible to "fix" all those assertions in the map script – or in XML if that's the cause.

 

[VDNKh]

I agree that, toward the end of the Classical era, Barbarian activity can become implausibly high in places where only a few Grassland or Plains tiles are unobserved. I've been meaning to decrease the Barbarian spawn probability on and near tiles where a Barbarian unit was recently defeated.

One gripe I have with the barbs is the units progress in tech way to fast. I'm barely setting up my first bronze mine and spearmen and axemen are spawning outside my border. Especially bad when I have the only source of bronze or iron for some distance and it's not near my capital.

 

[f1rpo]

@VDNKh: I was going to ask for specifics about your settings, but then ran a quick test on Monarch myself, and it turns out that I haven't implemented the tech requirements test for Spearman correctly. BtS allows Spearman to appear as soon as the Barbarians have Hunting and Mining; in AdvCiv (I think since the initial release – perhaps unsurprising insofar that I didn't get it right), I had meant to add a check for the reveal-resource tech (BW) and a check for at least one civ on the continent having access to a required resource (Copper or Iron). I guess because the second part worked and did delay Barbarian Spearmen a bit, I never realized that the first part did not. In my test I saw Spearmen appear around 900 BC and Axemen around 600 BC. Based on that, I would assume Spearman to appear 300 years later than it currently does once I fix the issue in v1.0. That's 12 turns on Normal speed (turn 79 vs. turn 91). You write that both Spears and Axes appear way too early ... Maybe it would be more balanced if BW were to spread to the Barbarians only from civs that have access to Copper or Iron, but that's a bit of a weird special rule. By turn 100, it's not shocking to see an actual DoW, so t91 doesn't seem all that early. Another test (on Monarch, Fractal), with the bug fixed: First Spearman on t87 (700 BC), first DoW (Ragnar) on t96 (475 BC). And t88 in a third test, no early DoW.

 

[wfeiger]

Hello f1rpo,
Your mod is AWESOME and makes a lot of my days better when I would otherwise be in a rut. I am eagerly awaiting version 1.00
With that said, I do have a few questions. First, I am trying to make a blank map. However, even though the map loads under custom scenarios without any issues whatsoever in BTS 3.19 and K-Mod, it will crash when I try to load it into Advanced Civ. Is there an explanation for this (file is below, and it is a significant edit to another person's map)?
Second, I know how to mess with a few things in civ but I don't feel comfortable messing with the CivCoreDLL. By chance, is there a 34 civ (or higher, I just need at least 34) version of this mod that I could download?
Thanks so much!

 

[keldath]

hi wfeiger,

the sceario issue, got fixed, very recently.
version 1 will bring great changes and countless upgrades.
i too await it,
i recommended not to handle the dll and wait it out.
higher civ count is easy to do,
take into account that the higher the number, the slower the mod and turns will run, thats true to all mods.

advc is indeed, awesome.

 

[f1rpo]

the sceario issue, got fixed, very recently.

That bug should only affect the Aggressive/Legacy AI game option (in scenarios), and I'm not sure if it affects the release version at all. The code does look like it should crash, but I didn't get a crash when I just tried it. Maybe only results in an out of bounds access that does no harm most of the time.

[...] I am trying to make a blank map. However, even though the map loads under custom scenarios without any issues whatsoever in BTS 3.19 and K-Mod, it will crash when I try to load it into Advanced Civ. Is there an explanation for this (file is below, and it is a significant edit to another person's map)?

The only error I'm getting with this WB save (in PythonErr.log when LoggingEnabled=1 is set in CivilizationIV.ini, or in a popup if HidePythonExceptions=0 is set) comes from parsing the Handicap=(nothing) lines. The rest of the player data isn't loaded then and the scenario isn't playable. (I didn't get a crash to desktop, but got a "you've been defeated" message right away.) Without mods, BtS also tries to reject those empty assignments, but the incorrect BtS error handling code (wrong use of Python's assert keyword), ironically, saves the day. So, to fix the problem, it should suffice to set the handicaps to NONE – or to simply delete the Handicap= lines. Did you copy those from somewhere? (Just wondering if such lines are likely to be found in other community-created scenarios too and should therefore be tolerated.)

[...] By chance, is there a 34 civ (or higher, I just need at least 34) version of this mod that I could download?

Here's a DLL for v0.99b that allows up to 48 civs: CvGameCoreDLL.dll (There's a link to that on the download page too, but it's a bit hidden, namely in the installation instructions.)

I am eagerly awaiting version 1.00.

version 1 will bring great changes and countless upgrades. i too await it,

I've started putting together release notes. Maybe I'll post a preliminary version here in the thread soon. I rewrote quite a bit of code (certainly more than would seem advisable for a supposed final release), I guess in order to leave the codebase in a tidier state; anyway, I feel that this will need to be tested for a while.
(And thanks for the praise also.)

 

[keldath]

simply delete the Handicap= lines

i did that in my scenario, though i set it to a specific handicap level.

also try to add stuff like specific civs , see what happenes.

 

[wfeiger]

That bug should only affect the Aggressive/Legacy AI game option (in scenarios), and I'm not sure if it affects the release version at all. The code does look like it should crash, but I didn't get a crash when I just tried it. Maybe only results in an out of bounds access that does no harm most of the time.
The only error I'm getting with this WB save (in PythonErr.log when LoggingEnabled=1 is set in CivilizationIV.ini, or in a popup if HidePythonExceptions=0 is set) comes from parsing the Handicap=(nothing) lines. The rest of the player data isn't loaded then and the scenario isn't playable. (I didn't get a crash to desktop, but got a "you've been defeated" message right away.) Without mods, BtS also tries to reject those empty assignments, but the incorrect BtS error handling code (wrong use of Python's assert keyword), ironically, saves the day. So, to fix the problem, it should suffice to set the handicaps to NONE – or to simply delete the Handicap= lines. Did you copy those from somewhere? (Just wondering if such lines are likely to be found in other community-created scenarios too and should therefore be tolerated.)
Here's a DLL for v0.99b that allows up to 48 civs: CvGameCoreDLL.dll (There's a link to that on the download page too, but it's a bit hidden, namely in the installation instructions.)

I've started putting together release notes. Maybe I'll post a preliminary version here in the thread soon. I rewrote quite a bit of code (certainly more than would seem advisable for a supposed final release), I guess in order to leave the codebase in a tidier state; anyway, I feel that this will need to be tested for a while.
(And thanks for the praise also.)

Thanks so much for the quick and adequate reply! BTW, I got the code for the scenario players and handicaps from Laskaris's blank accurate earth map.

 

[f1rpo]

[...] I got the code for the scenario players and handicaps from Laskaris's blank accurate earth map.

Thanks for the hint. In that case, I think it's better to allow empty strings; also seems easy enough to do – just a one-line Python change. You could adopt that change directly from this Git commit (will also be in v1.0) if you'd rather not change your scenario files.

 

[f1rpo]

I've attached a release candidate for version 1.00. I've run the smoke tests that I always run before a release and also properly played a few hundred turns in total; looks good, but, seeing that I've changed a lot of stuff around, probably a couple of severe issues will make themselves apparent when others play with it. The updated manual can be found here, a 48-civ DLL here.

Draft of release notes (edit, 29 Sept: outdated):

Spoiler :

This is intended to be the final major update. It weakens the Philosophical and Creative trait as well as some early unique units, tweaks Barbarian placement, the nuke damage formula and nuke AI behavior and adds enhanced city bar hover text as in the BULL mod. The specifics – and many less significant changes – are described below. Very minor changes are only covered by the Git commit history starting on 27 Mar (a few of the changes from spring were already included in v0.99b though).

Misc. balance changes:

Spoiler :

• Reduce the GP birth rate modifier from Philosophical trait to 80% (from 100%). E.g. a city with a base birth rate of 11 will now gain 8 GP points (11 * 80 / 100 rounded down) – 19 in total – instead of another 11, i.e. 22 in total. [change id advc.908c]
• Production cost of Aqueduct, Baray – but not Hammam – reduced to 90 (from 100). Just a common-sense balance change to make this iconic building less underpowered. [advc.911c]
• Weaken early unique units (note that Praetorian, a.k.a. Legionary, and Quechua have already gotten this treatment in earlier updates):

- Fast Worker has only 2 moves, ignores terrain movement costs. This is a big nerf, but ought to be closer to the proper power level than 3 moves. [advc.907c]
- Skirmisher only has 1 first strike chance, i.e. loses its guaranteed first strike. [advc.907d]
- War Chariot is not immune to first strikes. [advc.907e]
- Immortal is immune to first strikes, but has only +25% combat against Achery units, not +50%. [advc.907e]​

• Streamlined the K-Mod buff of Panzer: 2 guaranteed first strikes instead of 1 plus 1 first strike chance, and no free Flanking promotion. [advc.909b]
• AI civs no longer start the game with the Agriculture tech on Immortal and Deity difficulty (except for those civs that start with Agriculture regardless of difficulty). This should -sometimes- hamper early AI expansion and thus make it less likely that the human player gets boxed in with just 3 decent cities or lacking strategic resources. [advc.250e] Related post
• When the commerce sliders result in a rounding error, the lost commerce gets added to the commerce rates that contribute most to the total rounding error. This change removes one incentive for using binary research in the early game (but other strong incentives remain). [advc.157]
• Research cost of Iron Working decreased by 10. Still 10 higher than in BtS. The original change had mainly been aimed at the AI – which doesn't seem to be so keen on Iron Working anymore lately; perhaps never had been when Copper or Horse are available. [advc.131b]
• Tweaks to religion spread from Holy Cities: vaguely related post (2nd quote box)

- Spread probability increased in order to even out an earlier change to the calculation of the spread distance factor. I think that change has slowed down religion spread a bit overall and that hadn't been my intention. [advc.140]
- For civs that still have 0 cities with the Holy City religion, the spread probability gets adjusted based on the civ's city count. This should make the chance of a religion becoming available to a civ less dependent on its city count. (A separate spread dice roll is made for each city, so civs that have expanded fast generally have a much higher chance overall.) [advc.173]​

• City defense modifiers don't apply when the city owner is a neutral third party. (Rationale: The neutral city is not being attacked.) [advc.183]
• The Internet project counts civs with a particular tech, not teams. Based on a Kek-Mod change. [kekm.38]

Culture tweaks:

Spoiler :

• The Creative trait provides only +1 culture, not +2. Cities of Creative leaders start at culture level Fledgling, i.e. with 10 free initial culture. Rationale: Culture is more powerful in the mod, and Creative is already a strong trait in BtS. Just halving the culture rate would weaken the trait too much however (considering also that the discount for Colosseum was already removed by update 0.99), so the free initial culture is intended as a middle ground. [advc.908b]
• The Incan Terrace also provides only +1 culture. (Don't want it to be more effective than the Creative trait.) [advc.908b]
• Reverted K-Mod decreases of wonder culture rates – to reduce the number of stat changes that players new to AdvCiv and K-Mod need to get accustomed to: [advc.201]

- Pyramids, Hanging Gardens, Colossus, Chichen Itza: 5 → 6
- Great Library, Angkor Wat, Hagia Sophia, Spiral Minaret, University of Sankore, Shwedagon Paya 6 → 8
- Notre Dame, Taj Mahal: 8 → 10
- Creative Constructions (not a wonder): 2.5 → 3.0 per resource
- Stonehenge 4 → 6, Temple of Artemis 6 → 7 (not fully reverted; were both 8 in BtS)​

That is, I've left the K-Mod changes to the following wonders alone: Oracle, Great Lighthouse, Parthenon, Statue of Zeus, Mausoleum of Maussolos, Sistine Chapel. I believe those wonders would, through K-Mod's extended range of culture spread, indeed exert too much culture pressure too early in the game if the BtS rates were restored.
• National Park, Red Cross and all Corporate Headquarters set to 0 culture – for the sake of simplicity.
• Great Wall: 2 → 4 (doesn't need to have such an unusually low culture rate) [advc.310]
• Slightly increased the constant factor ("CITY_FREE_CULTURE_GROWTH_FACTOR") that gets added to each city's culture rate when calculating the amount of culture that gets spread to surrounding tiles. And increased the decay rate of tile culture from 1% per turn to 1.5% (more on "stolen" workable tiles). Both to somewhat even out the building culture rates restored by this and earlier updates. [advc.098]
• Culture can't spread to unowned tiles. That is, cities still spread culture beyond their ownership range as per the K-Mod rules, just not to unowned tiles. This makes the AdvCiv option for showing culture percentages on unowned tiles unnecessary (now always enabled, but only relevant after city razing). [advc.099f]
Also supersedes an AdvCiv special rule that had made cities immune to revolt for the first 10 turns after their foundation during the early game. [advc.099c]
• Increased culture level thresholds on Quick speed. Update 0.99 had already increased the threshold for Legendary culture, but there's really no good reason why any of the thresholds should be lower (relative to the game length) than on the other game speed settings. [advc.251]

Barbarians:

Spoiler :

• Fixed a bug in the AdvCiv tech checks for Barbarian Spearmen. They should now require the Barbarians to have Bronze Working – as I had intended all along. [advc.301] Related post
• Amended an ineffective AdvCiv fix for a BtS bug: The randomization of Barbarian city locations should finally work as intended (though it may not make a big difference). [advc.300]
• New mechanism for making Barbarian units less likely to appear on low-yield tiles. Should be more balanced and intuitive now (albeit more complicated under the hood). [advc.304] Related post

- The old approach was to re-roll tiles chosen (uniformly) at random up to two times when rolling a non-river, non-resource Tundra or Jungle. This had been easy to implement, but made Barbarians highly unlikely to appear on low-yield tiles so long as a fair number of higher-yield tiles were also available (i.e. unobserved by the civs). The new approach is to use a probability distribution that explicitly makes a low-yield tile 20% as likely to be chosen as a higher-yield tile.
- This still doesn't solve the problem of Barbarians appearing very frequently on low-yield tiles when (almost) no other tiles remain toward the end of the Classical era. I've addressed this, to an extent, through a chance of placing no Barbarian unit at all based on the number of available tiles and the maximal number of Barbarian units to be placed. This is also, more generally, supposed to prevent Barbarian placement from becoming highly frequent and predictable in a small region of valid tiles.
- River Jungle and Tundra are now also treated as low-yield tiles. So, apart from resources revealed to the Barbarians, all Jungle and Tundra are now treated alike (unless a map script allows something like Tundra Flood Plains). As before, Barbarian units can't be placed on tiles with 0 food yield at all.
- The per-tile unit creation probabilities are affected also by Barbarian units recently placed or destroyed in nearby tiles. This is another safety net against excessive Barbarian activity in a single place.
- Barbarian units on patrol are (probabilistically) affected by the same factors that affect unit placement: tile yields and recently created and destroyed Barbarian units. The choice of a target city to flock to is also affected by recently destroyed Barbarian units as well as garrison units remembered by the Barbarians.​

• Animals avoid non-native terrain harder than before. [advc.309]
• The defense modifier of Hills is disregarded when placing Barbarian cities – in order to make impregnable Barbarian cities less common. [advc.031]
• AI civs avoid using big stacks to harass ("choke") Barbarian cities that are too strongly defended for conquest. (Not sure if this fully solves the problem of AI stacks lingering near Barbarian cities.) [advc.300]

Map generator:

Spoiler :

• Slightly fewer strategic resources are added per player when the player count is high. (To rein in the overall abundance of strategic resources on crowded maps.) [advc.129]
• Fixed a somewhat consequential bug in the iterative evaluation of starting positions. Should now be (somewhat) better at avoiding crammed starts. [advc.027]
• PerfectMongoose: Spread Hills out more; tweak river frequency on large maps. [advc.021b]
• Further increase Pangaea dimensions for Huge world size. (Pangaea allows for few coastal cities and hence has less room for expansion overall than maps with multiple econtinents.) [advc.165]
• Fix compatibility issues with 3rd-party maps:

- EarthEvolution3 (Historical Starts option had been ignored; related post) [advc.108b] and
- Laskaris's Accurate World Maps (unplayable because scenario parser was too strict; related post) [advc.001]​

Nukes: [change id advc.650]

Spoiler :

• Nuke damage to units is chosen through a single die roll (for each unit) instead of two dice. Without Bomb Shelters, this gives each unit a ca. 64% chance of surviving a single nuke and a 17% chance of surviving two nukes in a row (if I've done the math right), whereas, in BtS, the chance of surviving one nuke is 85% and the chance of surviving two is very small (difficult to compute on paper). This means, dropping a single nuke (as the AI likes to do) becomes more effective and dropping two in one place becomes less effective and is, in particular, unlikely to clear a city of all defenders.
• SDI interception chance reduced from 75% to 60%, production cost increased from 1000 to 1500. To make this project (and Tactical Nuke vs. ICBM) less of a no-brainer.
• A summary of the effects of a nuke explosion (e.g. units killed) is announced on the main screen.
• Help text in Nuke Mode shows the interception chance (if the target has completed the SDI).
• The AI takes into account the interception chance when deciding whether to nuke an enemy.
• The AI counts intercepted nukes for its "You nuked us" memory, adding 1 to the memory count (whereas a nuked city normally adds 2). [advc.130q]
• The AI may target stacks outside of cities with ICBMs. (Tactical Nuke and ICBM largely use the same targeting logic now.)
• When deciding whether to nuke an enemy stack (in a city or elsewhere), the AI estimates the chance of destroying units outright and of destroying them through a follow-up attack with conventional units. (The latter part is very rudimentary.) Previously, the K-Mod AI code had summed up the production cost of the affected units, but hadn't considered whether they'd survive and heal.
• Reduced the utility value that the AI counts for hitting buildings with a nuke – based on the buildings' odds of withstanding the nuke. (City buildings seem to have been the dominant factor in most of the ICBM targeting decisions of the K-Mod AI code.)
• Cities with a high military production rate are preferred as nuke targets by the AI. (idea by @Inthegrave)
• Tweaked the AI logic for creating the Manhattan Project.
• Made the AI much more interested in producing at least a small nuclear arsenal once nukes become available.
• Increased impact of personality (espionage weight, no-war probability, Environmentalism as favorite cvic) on the eagerness of AI cities to produce nuke units.
• Fixed some rather minor issues with AI civs not valuing Uranium highly enough.

Misc. AI:

Spoiler :

• Made the "mutual struggle" relations modifiers a bit easier to get by requiring some 20% fewer war successes/ losses to reach any particular modifier. [advc.130m]
• Based the "heathen religion" relations penalty on the populations of revealed cities with the offending religion. In previous versions of AdvCiv, the penalty had applied in full 8 turns after any one city with the offending religion had been revealed. The new behavior is smoother and hopefully more intuitive. [advc.130n]
• Tweaks to the cancellation of deals:

- When an AI civ cancels an Open Borders agreement or Defensive Pact, it'll refuse to reinstate the deal for an expected duration of 5 turns – instead of the expected 10-turn cooldown that still applies when the other side cancels the deal. [advc.130j]
- The AI may cancel gold-per-turn deals in order to enforce its per-player trade limit for gold-per-turn. This addresses the "gold subsidy" loophole. [advc.133]
- When the attitude level of an AI civ drops below the level required for upholding a deal, the grace period for cancellation now has an expected length of only 2.5 turns (instead of 5) when the trade partner has become the worst enemy of the AI civ. [advc.133]​

• Made AI cities quicker to expand their borders to the outer ring of workable tiles through culture buildings like Monument. Still too hesitant for my taste, but should at least no longer keep important strategic resources just out of range for dozens of turns. [advc.192]
• On the highest difficulty levels, the AI places an extra garrison unit in each of its cities already around the start of the Medieval era (instead of Renaissance). [advc.107] Related post (see item #2)

UI:

Spoiler :

• Overhauled the city bar hover text by adopting everything from BULL except the "Base Values" and "Base Production" info (which I find too obscure). No options except one for the building list (icons/ names/ disabled). Endeavored to make the formatting more compact and more self-explanatory than in BULL. Minor innovations: Larger specialist icons; buildings sorted alphabetically; showing output of production processes (e.g. Wealth) and showing stored production (chopping, overflow). [advc.186]
• BUG options for moving revolt chance and air unit capacity from the tile hover text to the city bar hover text. (Any information about cities really belongs in the city bar hover text, but information that also pertains to units garrisoned in the city is convenient to have in the tile hover text, so that remains the default setting.) [advc.101, advc.187]
• Optional (disabled by default) fist icon above city bars where the revolt chance is positive. (The fist icon will still appear above cities under occupation in any case.) [advc.101]
• Show turns to starvation directly on the city bar on the main map. [advc.189]
• Production decay warnings adopted from BULL, enabled by default. [advc.094] Related post (2nd quote box)
• "Zoom City Details" feature adopted from BULL, i.e. show the city bar hover text when hovering over the choose-production popup. Optional in BULL, always enabled in AdvCiv. [advc.186b]
• "GP Rate Breakdown" feature adopted from BULL, i.e. the hover text for the Great Person bar on the city screen says how many GP points are generated by buildings and how many by specialists. [advc.078]
• Combat modifiers are now listed in the same way (order, color, sign conventions) regardless of whether Advanced Combat Odds are enabled. I think this formatting is the best of both worlds. Also fixed an issue with the color and sign shown for the Disorganized promotion that Barbarian Galleys start with. [advc.048]
• Custom icon for the air bomb button (superimposing the bombard icon), to make it easier to distinguish from the air strike button. (This change was supposed to be in v0.99, but I don't think it worked at all as I had put the modified graphic in the wrong directory.) [advc.004c]
• The unit cycling order distinguishes air units from civilian units, i.e. should be less likely to cycle between air units and workers. [advc.004c] Related post (penultimate quote box; I don't really think I've addressed that issue though)
• Pathfinder: When breaking ties between paths of equal length, landing on a tile with a route (Road or Railroad) is now preferred (among other criteria) – even when that route does not shorten the current path – because it may well speed up subsequent movement. This change also benefits the AI civs. [advc.pf]
• "Internet Games" selection on the opening menu grayed out – because the GameSpy servers have long been disabled. Can still be clicked (this can't be helped). Inspired by a similar change in the Caveman2Cosmos mod. [advc.002g]
• Yields displayed for tiles owned by a rival no longer give away unrevealed resources. (But Mines on flat terrain will still give away unrevealed mineral resources.) [advc.182] Related post
• The Customizable Domestic Advisor can no longer show global city ranks (because information about unrevealed rival cities can be inferred from those) and XY-coordinates of cities can't be shown until the map has been centered. Based on similar changes in the "Close To Home" mod.

Stability:

Spoiler :

• Fixed two rare crashes to desktop that were introduced in v0.97:

- Out-of-bounds access during map generation. Took many dozen (re-)generated maps until I ran into this; was harmless when it didn't crash.
- Repeatable crash when an AI Paratrooper was considering to drop onto an unowned tile with a resource. (Rare because most land tiles are owned once Paratroopers become available.)​

• Crash to desktop when regenerating the map after founding a city.
• Autolog issues (Python crash, only when Autlog was recording):

- Upon the creation colonial vassals; bug report
- Potential divide by 0, adopted from the "More Naval AI" mod.​

Performance:

Spoiler :

• Introduced a list-like data structure ("ListEnumMap"), mainly for data that BtS stores at every tile about every civ. Scarcely makes a difference with an 18-civ limit, but seems to speed up AI turns by some 15% with a 31-civ limit (i.e. 32 players incl. the Barbarians). The performance penalty for allowing 31 civs while playing only with 18 should now be under 10%, so, for any mods based on AdvCiv, there should no longer be a strong reason against increasing the civ limit in the (GameCore) DLL. AdvCiv itself can't switch to a 31-civ limit because that would break compatibility with old savegames. [advc.enum]
• (A few other optimizations, but I don't think they're having a significant effect. Well, mods based on AdvCiv might benefit more, who knows.)

Software design, coding style (only relevant for DLL modders):

Spoiler :

More extensive changes than would seem advisable for a supposed final update – but there was some technical debt for me to pay.
• Rewrite of the EnumMap class, originally from the "We the People" mod. Now integrated into a hierarchy of class templates that also cover the ListEnumMap mentioned above under "Performance," and similar classes optimized for two-dimensional data loaded from XML. The enum map classes are based on type traits defined for enum and integer types. [advc.enum, advc.003t]
• Revised all code in the UWAI component (AI war planning) to make it conform with the style that I use in the rest of the DLL. (Bugs discovered in this process had already been fixed by v0.99.)
• Floating-point numbers – which the mod had originally used widely, especially in the UWAI component – have been replaced almost entirely with fixed-point numbers (ScaledNum type), the exception being a couple of uses of std::log and the (BtS/ Lead From Behind) combat odds calculations. I don't think floating-point math was ever going to be an issue for network synchronization, but, if I'm proved wrong about this, it won't take much effort now to switch fully to integer-based math. [advc.003g]
• Rewrite of the code for listing combat modifiers, so that modifiers with an unexpected sign (e.g. -25% city attack) are shown with the correct sign and in the correct color.[advc.048]
• Calls to synchronized instances of CvRandom (random number generator) no longer pass along a message for the RandLog; instead, the calls are wrapped in a macro that generates the message from the function name and line number at the call location. The macros also make conditions that "flip a coin" easier to read and less error-prone to write. [advc.007b]
• Added a bunch of functions for easier access to the ID of the "active" player, i.e. of the civ whose human player is assumed to be interacting with the UI.
• Removed most "inline" keywords (the bulk of which I had added myself). Based on a test, this has had no impact on performance, or almost none. One could argue that the keywords were benefitial as a means of documentation, i.e. to make the reader aware when a function is expected to be called very frequently, but I don't think that's worth the clutter. [advc.inl]

Additional credits:
• Thanks to @keldath for making me aware of a number of (potential) problems already during the development of this update.
• This update includes the last few revisions (r593 to r596) of the BBAI mod, which had not been included in K-Mod.
• A couple of very minor tweaks (1 | 2) from the "More Naval AI" mod by @lfgr have not been mentioned above.

 

[keldath]

in common Hebrew,
when something good happens that is awaited, the marrocan jews, say,
KOO LOO LOO (as a word or a tongue thing whistle off sort),
so Koolooloo for the much anticipated 100, which is the pinnacle of your work, from the changes in code i witnessed.

its soo strange to see all the commits arranged into a detailed explanation as your wrote it.
well done F1, i salute you, as always.
i wish great fun to all that plays.

 

[eXalted]

Oh my, this release is crazy! Thank you for the great mod and updates!