Little improvements with AI using settlers (dev)

Leodim

Warlord
Joined
Nov 25, 2013
Messages
108
I won't PR for such small changes (2 lines) but in v43.1 I noticed too often AI don't use its settlers. It's quite possible it's the same in v44.
After a long while (thanks debugger and logs) I noticed it was mostly due to no available escorts.

1) I think there is a typo in CvUnitAI::AI_settleMove()
there is
if (!getGroup()->canDefend() || getGroup()->getStrength() <= AI_minSettlerDefense())
to start looking for an escort.
I see no reason for the <=, it should be < (strict) no? because the escort just need >= to validate, so theorically it could request more escort while its already there.
Truth is I didn't see big changes with <, but still, seems more logical/bugfree to me.

2) I understand the risk of increasing the priority of settler escort is to have the AI not defend its city enough (priority : escort settler > defend cities) BUT:
- settlers only requires 1 good unit (2 if at war) for escort, so possible but unlikely in practice (+ AI don't produce many or uneeded settlers, so even safer)
- the crippling of not using existing settlers is, atm, more an issue in my opinion than this possibility.
- HIGHEST_PRIORITY_ESCORT_PRIORITY is already used by others thing than escorting settlers which are, imo, much less of a priority for AI development than settling (other gold/happiness/goalPlot checks still being here of course)
- I know C2C is not made for later eras start, but it's even more crippling there (I saw civs at peace with only 1 city but 2 available settlers and 7+ defenders in it, still after turn 70!!)
All in all, I found that adding some sort of #define HIGHEST_PRIORITY_ESCORT_SETTLER_PRIORITY 1100 and assigning it ONLY to settlers (used only once in the whole solution, in CvUnitAI::AI_settleMove()) gave really better results, for no downsides in practice (only theoritical downsides imo).
Best solution would be to still check for at least one/two unit left to def, but honestly I can't even produce such an example in reality, never happens. So I didn't test such a scenario with WB I admit.

I tried reloading the same game and pass 20 turns multiple times with different code configuration and the one with the modifications always gave much better results. Both in settling and overall development of AIs.
I might be missing a bigger picture, since my tests were pretty much always on the same game, but that's my 2 cents ;)

EDIT : I also made some bigger additions to support later eras start, and it's starting to feel good/challenging, but that's another topic.
 
Last edited:
Can you br more precise with how to implement your solution? Example in file x line y there is aline z and change it to...
 
Can you br more precise with how to implement your solution? Example in file x line y there is aline z and change it to...

v43.1 lines were :

CvContractBroker.h:
line 65 add: #define HIGHEST_PRIORITY_ESCORT_SETTLER_PRIORITY 1100

CvUnitAI.cpp
line 1931 (change <= to <): if (!getGroup()->canDefend() || getGroup()->getStrength() < AI_minSettlerDefense())
line 1954 (use new value instead of HIGHEST_PRIORITY_ESCORT_PRIORITY) :
GET_PLAYER(getOwner()).getContractBroker().advertiseWork(
HIGHEST_PRIORITY_ESCORT_SETTLER_PRIORITY,


Then recompile DLL of course.

Or just ctrl-shift-F for if (!getGroup()->canDefend() || getGroup()->getStrength() <= AI_minSettlerDefense())
is faster imo

Escorting settlers will now be top priority for units (see first post for theoritical cons) compared to other "contractable jobs". So the settler(s) asking for a little escort will be more likely to find one fast.
Use at your own risk but works better here.
 
Last edited:
Probably a helpful change. We've discussed in great detail the resetting of the contract brokerage every round and how that's breaking quite a bit - it was expected that it would be able to continue to re-recruit every round but its inability to keep an accurate count of what's doing what and why is a huge part of the problem we're having in larger scale task management that leads to massive unit spam towards all kinds of roles that the AI is continuously thinking it needs to keep trying to address rather than tracing the job from the beginning to the end what units have been selected to respond (or be ordered to be trained so as to respond) and where they are in the process of attempting to.

Perhaps you can see what I mean if you've been able to demystify the setup this far.
 
Perhaps you can see what I mean if you've been able to demystify the setup this far.
Well not completely but logs showed quite a lot of request "approved" for units that were in the city where the settler(s) was idle, turns after turn.
Is that what you meant ?
I didn't look at what those request were about.
I noticed that increasing the priority of settler escort change the behavior (as expected), and stopped there.

Clearly I don't have an overall view on the whole thing. Just seemed pretty "ultra important" to settle, in the grand scheme of things, tested locally and then run with it locally.

I leave the rest to you (or people who designed the whole concept and/or have a larger view on pros and cons).

EDIT : I understand the concept you explain though, just not how it's actually made inside atm.
 
Top Bottom