Settler AI missing

[Thalassicus]

It appears the settler AI adjustments are missing from the project, likely forgotten when I rearranged the GEM AI stuff into CAT a long time ago. This is a severe issue since unmodded settler placement is horrible, and explains some of the weird AI city patterns I've seen. I don't know how I didn't discover this earlier. I'm working on fixing it.

[Thalassicus]

I discovered why AIs almost never settle within their own territory, even if there's lots of excellent city sites. This often happens when cities rapidly expand borders. Firaxis cut the value of these sites to a drastic 1/4th of normal. It doesn't matter how good the site is, and they did this with a hardcoded value that's not exposed in the data files.

This can completely stall AI settlement. I've seen it happen many times. The AI always tries to settle 3-4 tiles away from their other cities. If cities expand borders to that range, the AI is extremely unlikely to settle in the area, even if the tiles are too far away for existing cities to work!

[GrantSP]

Care to enlighten us more with where you found it?

[Thalassicus]

line 433 of CvCitySiteEvaluator::PlotFoundValue() in CvSiteEvaluationClasses.cpp.

I suspect this is the main cause of AI settlement problems. In short, it artificially forces AI cities away from their borders, even when settling 1 tile closer would be vastly better.

It's an extremely simple mistake that causes big problems, but is hardcoded in a way we'd have to mod the core, which introduces the compatibility issues with other core mods.

I'm starting to think we should just make a core mod. If there's something we want from another author's core mod, and they give permission, we can include the feature in our own mod. Most of the bad AI code I'm most interested in is in the core.

[GrantSP]

That change was introduced in the 1st expansion! Does that mean GEM had a problem with the settlers back then and you fixed it or is this a deeper issue that can't be solved without a DLL mod?

[Thalassicus]

It appears the classic multiplier on owned tiles was 2/3, much more reasonable. They dropped it drastically to 1/4 in G&K. I don't know why they did this, and it explains why AI settlement patterns got so bad after that point.

I've never been able to fix this problem. I recognized it even before they released the source code, but looking at the code confirms it.

The sad thing is most of the rest of the AI settlement code is good. It's just this one critical hardcoded mistake that breaks everything.

The other mistake I see is in chokepoint detection. They didn't even try searching for chokepoints; they just add 5 to the city value for each mountain within 2 tiles. That finds clusters of mountains, not chokepoints, and they didn't even try to search for land bridges (single land tiles separating two bodies of water). This is disappointing but not surprising. Chokepoint detection has been a problem with the AI for over twenty years of Civilization games. I wonder why they never taught the AI to find chokepoints? It would only take five hours of work, at most, and if they'd done it back in the 90s then we'd have had two decades of better AIs.

It really baffles me when game companies don't spend a small amount of time on something that has such a dramatic impact on the game, like AIs finding chokepoints.

[GrantSP]

Further down that file there is a section that uses Boldness (I bolded Boldness :smiley: ) // use boldness to decide if we want to push close to enemies int iBoldness = pPlayer->GetDiplomacyAI()->GetBoldness(); if (iBoldness < 4) { if (iClosestEnemyCity <= 4) { rtnValue /= 4; } else if (iClosestEnemyCity == 5) { rtnValue /= 2; } } else if (iBoldness > 7) { if (iClosestEnemyCity <= 5 && iClosestCityOfMine < 8) { rtnValue *= 3; rtnValue /= 2; } } else { if (iClosestEnemyCity < 5) { rtnValue *= 2; rtnValue /= 3; } } Can we use that as a way of making the AI look closer to home?

[Thalassicus]

Bold AIs are typically the opposite of who encounter the problem. It's usually peaceful AIs with lots of wonders, culture, and Tradition policies who get large borders.

Besides that, the boldness code looks for cities, not territory. If two cities are 5 tiles away, and one city has 1-range borders while the other city has 5 range borders, that code equally values both cities. If we push cities closer, it helps the 5-border problem, but would put 1-border cities too close.

[GrantSP]

Ah well! What were the chances I would find the solution?

[Thalassicus]

The solution is that multiplier gets changed back to its classic value of 2/3. I don't think there's any other way to solve it, unfortunately.

[Thalassicus]

However, reactivating the GEM settler data will solve some other issues:

• Less likely to build 1 tile away from coastlines.
• Settle cities more readily (lower minimum settle fertility)
• Search for amazing tiles somewhat further away than their capital (higher evaluation distances).
• Build barracks in cities with lots of forests or hills nearby.
• etc...

[GrantSP]

DLL mod in the winds? Has WHoward & Gedemon already solved this with their DLL mod?

[Thalassicus]

I don't know, I haven't had time to investigate those. I'm very reluctant to pursue a c++ mod because of the compatibility issues... but there's so many critical problems in the game core that could be solved with a second of effort.

[GrantSP]

Just checked. Nope. Just the same.

[skodkim]

Just thought I'd let you know that I've been playing with Whowards dll enabled alongside CEP without any problems for the last six months or so.

\Skodkim

[ghost]

As a Mac user I can't use .dll mods so I would vote to stay the course as is or to make the .dll mod an addon to the existing .lua mod.