AI city distance?

[SamBC]

So, some initial screenshots are attached. None that show more distant settling, or at least no more distant settling where the gap didn't get filled in, as I didn't watch it running.

 

[alpaca]

Looks pretty similar to what I get. Basically, the AI version of 3-tile ICS (new city is always 3 tiles away from another city). I will post some screens of my current game once I scouted a bit.

 

[SamBC]

Looks pretty similar to what I get. Basically, the AI version of 3-tile ICS (new city is always 3 tiles away from another city). I will post some screens of my current game once I scouted a bit.

Yeah; after the test with an average of about 1.2 greater-distance settlings per civ I nerfed the dropoff value a bit, and maybe I nerfed it back a bit too far. However, some of those settlings were ones you wouldn't see skipping straight to turn 250; they only existed for maybe 50-60 years until the gap was filled in. A couple of them were also silly, but then again so are a lot of the AI city placements. I am, however, quite happy with the fact the AI goes for coasts more, with fewer 1-tile-away-from-coast cities.

For it to work better, I'm sure there needs to be more account taken (or any account taken) of hexes, down-valuing them for being in another city's radius... but that's something we don't appear able to do.

 

[nokmirt]

Not sure yet about the variable you mention, but I've been looking at this pretty hard today, doing some testing (I've had a little luck promoting 3 hexes between rather than 2 and increasing the likelihood of distant settling for prime real estate), and I've realised this:

If the AI's factors for deciding are what they appear to be from the exposed variables, and there are no hidden factors, I'm guessing part of the problem is that it doesn't down-value hexes that are already covered by a city, or even being worked. Now, it's conceivable that it automatically zero-values hexes that are currently worked, but there ought to be a reduction for hexes already in first, second and third ring of an existing city (of any player, although ignore unknown cities for other players), much as the current ones to promote 1st ring of target hex over second, and each over third. It'd be great to have clarification from devs on this, and maybe ask for it to be added (with those variables tunable), so I think I'll seek that.

I am going to try to change that MDC to 4 hexes, and try the 50 and 20000 changes to GlobalAIDefines.xml. I will post and let you guys know how it goes. I had tried with 3 hexes but there were still some bad city placements I noticed. I think with 4 there will be more room to maneuver.

GlobalAIDefines.xml

<Update>
<Set Value="50" /> (instead of vanilla-POSTpatched value of 75)
<Where Name="AI_STRATEGY_AREA_IS_FULL_PERCENT" />
</Update>
<Update>
<Set Value="20000" />
<Where Name="AI_STRATEGY_MINIMUM_SETTLE_FERTILITY" />
</Update>
I also use this, which you already know about...

globalDefines database:

UPDATE Defines SET Value=4
WHERE Name="MIN_CITY_RANGE";

 

[alpaca]

Yeah; after the test with an average of about 1.2 greater-distance settlings per civ I nerfed the dropoff value a bit, and maybe I nerfed it back a bit too far. However, some of those settlings were ones you wouldn't see skipping straight to turn 250; they only existed for maybe 50-60 years until the gap was filled in. A couple of them were also silly, but then again so are a lot of the AI city placements. I am, however, quite happy with the fact the AI goes for coasts more, with fewer 1-tile-away-from-coast cities.

For it to work better, I'm sure there needs to be more account taken (or any account taken) of hexes, down-valuing them for being in another city's radius... but that's something we don't appear able to do.

Can't say I ever saw those one-tile-in cities, the AI in my games always goes for the coast. I did boost coast gold yield by 1, however, maybe that affects it.

 

[Thalassicus]

Base coast yield would definitely affect it, since that'd double the gold_flavor value of the tiles.

 

[DragonBlood87]

I still think there should be a tunable factor to de-value any hex that's already in a city-radius, greater for ring1 and less for ring3, of course (I usually build my cities with an overlap at ring3). But as I can't add that, this is what I've managed so far.

I'd say it would be even better to make it tunable by ring; first-ring tiles of another city are more or less worthless when considering expansion locations, but it's definitely possible to steal some third-ring tiles away (if an enemy city) or share them (if a friendly city) without much trouble; perhaps a small devalue to denote the hassle of it, but it's much more acceptable than considering the inner tiles that will never be usable to the new city.

Edit: Wow, I completely glanced over you already saying that.

 

[kingpapawawa]

I've changed MIN_CITY_RANGE from 2 to 4 and it helps. they still pick crap spots to drop cities. a block of ice with some fish and nothing else..

how about changing the happiness cost. i noticed that the AI does not get 2 unhappiness from each city like i do. maybe they wouldnt drop so many useless cities if they were less happy.

 

[SamBC]

I've changed MIN_CITY_RANGE from 2 to 4 and it helps. they still pick crap spots to drop cities. a block of ice with some fish and nothing else..

how about changing the happiness cost. i noticed that the AI does not get 2 unhappiness from each city like i do. maybe they wouldnt drop so many useless cities if they were less happy.

The AI gets the same unhappiness as you do, except that above prince it gets a reduction to all sources of unhappiness (while below prince you get free happiness to start with).

Happiness might change the number of cities is builds (maybe), but it won't affect how it places them.

MIN_CITY_RANGE is an easy fix, but it changes the underlying rule, and there are situations where a range-2 city is actually appropriate. Hence trying to improve it without alterations to MIN_CITY_RANGE.

 

[alpaca]

The AI gets the same unhappiness as you do, except that above prince it gets a reduction to all sources of unhappiness (while below prince you get free happiness to start with).

Happiness might change the number of cities is builds (maybe), but it won't affect how it places them.

MIN_CITY_RANGE is an easy fix, but it changes the underlying rule, and there are situations where a range-2 city is actually appropriate. Hence trying to improve it without alterations to MIN_CITY_RANGE.

Actually, the AI plays on chieftain difficulty so it does get extra happiness. I didn't believe it either, but just start a game and investigate in FireTuner using the happiness getter functions on the AI (and GetHandicapType)

 

[Thalassicus]

Does changing chieftain difficulty settings affect the AI happiness?

 

[alpaca]

Does changing chieftain difficulty settings affect the AI happiness?

Yeah, and you can set it lower. And yes, I thought about swapping out difficulties but that doesn't work because the post-defines are apparently resolved to pointer once they are loaded, so exchanging the names of prince and chieftain doesn't help. You could make chieftain the neutral difficulty level and add some in-between, though.

 

[nokmirt]

Actually, the AI plays on chieftain difficulty so it does get extra happiness. I didn't believe it either, but just start a game and investigate in FireTuner using the happiness getter functions on the AI (and GetHandicapType)

It plays on chieftain when I play on prince level???

 

[alpaca]

It plays on chieftain when I play on prince level???

Yes, it always plays on chieftain, no matter which level you play.

 

[nokmirt]

Yes, it always plays on chieftain, no matter which level you play.

Have you made any adjustments to chieftain level in the xml?

Ok, I have changed this in chieftain. <AIUnhappinessPercent>165</AIUnhappinessPercent> I will play with this changed and see how things go. And I will try the game with MCR set at 3 hexes.

 

[alpaca]

Have you made any adjustments to chieftain level in the xml?

Ok, I have changed this in chieftain. <AIUnhappinessPercent>165</AIUnhappinessPercent> I will play with this changed and see how things go. And I will try the game with MCR set at 3 hexes.

I doubt it has any relevance to AI settling patterns

 

[SamBC]

So, the AI, at all difficulty levels, gets the handicaps the player does at Chieftain? So, you'd have to change the player settings for the chieftain difficulty level to change what affects the AI?

I agree that it won't affect city placement, though. The AI isn't planning to put as many cities as it can in a space, it's only looking where to put a city once it has a settler, and it's not planning ahead when it places it.

 

[alpaca]

So, the AI, at all difficulty levels, gets the handicaps the player does at Chieftain? So, you'd have to change the player settings for the chieftain difficulty level to change what affects the AI?

I agree that it won't affect city placement, though. The AI isn't planning to put as many cities as it can in a space, it's only looking where to put a city once it has a settler, and it's not planning ahead when it places it.

As far as I can tell, yes. I only tested for happiness, however, not for any other bonuses. The free units, for example, obviously work as intended

 

[nokmirt]

I doubt it has any relevance to AI settling patterns

Supposedly there are in the AI defines. I am going to leave those alone for now. In fact I am testing a world builder scenario of ancient Greece we have been working on. So most of the cities are already in place.

Also in the scenario editor in worldbuilder the default handicap is set at chieftain, so you are right.

 

[blitzkrieg80]

wakey wakey - <BUMP>

well, I was disappointed with my last discovery- because it was not enough...

it seems that my good experience / results was either random or placebo / confirmation bias or a combination of course, it could be that the variables helped but it was still not enough.... i ended up going back to MIN_CITY_RANGE 3 and nothing else and found it wasn't very different.... brute force is all that seemed effective.... I tried experimenting with some of those variables mentioned by you guys, but it wasn't very fruitful...

BUT THEN, I found a winning combination! I see very obvious difference now... I have also play-tested it all quite a bit

the factors and magnitude:

Spoiler :

GlobalDefines.xml

UPDATE Defines SET Value=3
WHERE Name="MIN_CITY_RANGE";

UPDATE Defines SET Value=25
WHERE Name="AI_CITY_SPECIALIZATION_REEVALUATION_INTERVAL";

UPDATE Defines SET Value=-1000000
WHERE Name="ALREADY_OWNED_STRATEGIC_VALUE";

[B]UPDATE Defines SET Value=2
WHERE Name="CITY_RING_1_MULTIPLIER";

UPDATE Defines SET Value=6
WHERE Name="CITY_RING_2_MULTIPLIER";

UPDATE Defines SET Value=12
WHERE Name="CITY_RING_3_MULTIPLIER";[/B]

UPDATE Defines SET Value=75
WHERE Name="SETTLER_BUILD_ON_COAST_PERCENT";

UPDATE Defines SET Value=50
WHERE Name="SETTLER_EVALUATION_DISTANCE";

UPDATE Defines SET Value=8
WHERE Name="SETTLER_PRODUCTION_MULTIPLIER";

[EDIT] these values were used but DO NOT seem to be necessary

Spoiler :

GlobalAIDefines.xml
<Defines>
		<Update>
			<Set Value="50" />
			<Where Name="AI_STRATEGY_AREA_IS_FULL_PERCENT" />
		</Update>
		<Update>
			<Set Value="20000" />
			<Where Name="AI_STRATEGY_MINIMUM_SETTLE_FERTILITY" />
		</Update>
	</Defines>

I know the contradictory logic of making the AI want to not settle close to resources might seem weird, but otherwise, you reward it for settling close to shared resources- know what I mean? So, I might be overlooking the negative implications/trade-off on that kind of emphasis, but it seems to me like this is the way to go... like I said, the tests look good.

*I didn't mess with the DROPOFF value because we don't seem to know what is means, FOR/AGAINST distance... and it can severely hamper any successful changes from the other values (from my experiments)
___________________________

screenshots of 150 turns on Autoplay... Pangaea map with 8 City-States (with all of the variables mentioned above)