Littlebob86
Prince
- Joined
- Oct 24, 2016
- Messages
- 332
How does the cheating Bastard ai have the population for so many damn settlers ! 
Resource icon
- Thread starter Delnar_Ersike
- Start date
-
- Tags
- ai
How does the cheating Bastard ai have the population for so many damn settlers !
Actually that one's easy think about how fast cities can go from pop 4 to 5 as opposed to 12 to 13... with the huge production bonuses they get they aren't restrained by hammers for builders and low pop cities can churn them out and then regrow.
So just a bit of feedback on .7 with a bit of my own mods. The changes you made certainly cut down on settler spam and I can confirm that adding in a 1 gold cost on warriors cuts down on the ancient era silliness, but.... the AI still doesn't prioritize actually settling nearly enough.
Playing on a large continents emperor, with 200% tech cost and 50% build cost by about 100 BC I have 15+ settled cites and my neighbors all have 4-7 cities. I've only captured 2 cities FYI. so the snowball has already begun as I'm producing 2-3 times more tech and hammers than any of my neighbors.
Again please don't take this as complaining and I get that a lot of work is going to wait for the firaxis, I'm just giveing feedback.
Littlebob86
Prince
- Joined
- Oct 24, 2016
- Messages
- 332
I'm just putting this here in case anyone else wants to change the warrior/ slinger cost
Civ vi/base/assets/gameplay/data/units.xml
Using notepad ++, line 627 and 628, I just had to add in 'Maintenance="1"'
Civ vi/base/assets/gameplay/data/units.xml
Using notepad ++, line 627 and 628, I just had to add in 'Maintenance="1"'
Not sure if this is a result of your mod or just really bad AI or what but I just had Germany run a settler across the continent (probably about 30-40 tiles) from where their capitol is to build a city next to my capitol. Heck, I don't even know if something like that is moddable. Needless to say, I'm really pissed with them for this, I plan out my early settlements at the very start of the game, not anticipating the AI being THIS dumb.
SuperSylph
Chieftain
- Joined
- Oct 5, 2016
- Messages
- 11
What. Just, what. How can the AI possibly cope with moving their units if its programmed to fundamentally misinterpret the cost of doing so... This must explain the moronic constant shuffling and illogical routing of units that happens in some cases, as well as the seemingly random wandering of some units. I think it would be a very good idea to change back to the Civ5 movement cost system, until the AI is able to understand the new one.
ichbinsehselber
Prince
- Joined
- Jun 22, 2005
- Messages
- 331
Did the devs open access to the xml schema (xslt) file? That would probably help a lot with these changes.
Siesta Guru
Prince
You can see the schema in Assests/Gameplay/Data/Schema/01_GameplaySchema.sql
You can at least see some defaults etc there, not sure if you can do much useful editing there though
You can at least see some defaults etc there, not sure if you can do much useful editing there though
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,180
This is likely only "due to the mod" in so much as everything we fix, is going to bring up new problems. You fix one thing, you get to expose the AI for additional faults.
They may have intentionally made the AI not settle because of how bad this was. There are functions to deal with AI settling, I'll start to play with them.
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,180
There are a tremendous number of mistakes. It's code, it happens.
We have access to the database, which is better than any crummy xml schema.
Delnar_Ersike
Prince
Legacy code from Civ5. The settling spot evaluation algorithms have a terrible way of understanding when a settle spot is too far away from their core empire to properly protect, and Civ5's high-boldness AIs will deliberately go out of their way to settle near opponents because those spots get an extra +33% boost to their score under high boldness (and a penalty under low boldness). I'm fairly certain that you're seeing a similar version of this in Civ6, albeit with boldness being replaced by some other AI property. Settle plot evaluation is hardcoded into CvGameCoreDLL in both its computations and the way it feeds into operation targeting data, so there's no way we can change it without access to DLL source code.
Random wandering and some illogical shuffling is actually intentional, via the "wander" tactical and homeland moves. If the AI doesn't know what to do with a unit, it just has it wander about randomly, which occasionally conflicts with other units who have a goal to get to but wandering units are in their way (especially because the AI doesn't have access to the swap units command, or at least Civ5's doesn't). No, the movement point system's effects are primarily in how the AI judges "closeness": when units need to spend movement points before entering tiles instead of after, raw tile distance is even less of an indication of closeness than before, and the code has plenty of places where raw tile distance is used instead of a dummy pathfinder to judge how close a unit is to a target. This is because an extra turn's worth of movement needs to be spent in most cases moving from open tiles to rough ones, so the standard of 2 movement only actually translates to 2 tiles' of movement if both tiles are open terrain, whereas in Civ5, open + rough was also possible.
This also creates a larger variance between high-movement units (like horsemen) and low-movement ones. In Civ5, a 3-move can move open + open + open, open + rough, rough + open, and rough + rough, while a 2-move can move open + open, open + rough, and rough: the 3-move unit is more about being able to move 2 tiles over any terrain than moving 3 tiles, while a 2-move can still move 2 tiles under most cases. In Civ6, a 3-move can move open + open + open, open + rough, and rough + open, meaning only one (rarer) case of 2-tile movement out of 3 is removed, while a 2-move can move open + open and rough, meaning one case for 2-tile movement (out of 2, and also a much more common one) is removed. However, I suspect no AI alterations, e.g. to the way it judges the value of more movement points, were made to account for this.
Last edited:
Are you sure of that? I have taken a look into Siesta Guru's work (AI+ mod), and it seems he has figured a way to improve the AI settler spot selection (via a "ModdedSettlerSpot" favored item in the behavior tree).
It's my understanding that the Civ6 Ai uses behaviour trees.
Delnar_Ersike
Prince
I had a look, and the mod's intriguing. Some of the new rows they've written don't have vanilla equivalents, e.g. the "Total Yield" and "Specific Resource" items, which means that unless they've debugged the AI with the settler plot evaluation layer, it's possible that they're not actually doing anything with rows that reference. There's definitely indication that the modder isn't necessarily thoroughly testing of their work, because their STD_DISTRICTS favored list would actually do nothing, since they're not actually setting the districts in that list to be favored, they're just introducing a new list of possible districts to build that the AI may or may not take. However, some of the items they've edited definitely would affect settle plot evaluation, it's just that most of them are rather limited in scope (e.g. there's no way to make the AI disfavor settling near an enemy city).
Besides that, the values they modified are many of the same values that could be modified in Civ5. There are still many other, algorithmic portions of settle plot evaluation that cannot be changed (because they're algorithmic, i.e. they revolve around the process and the operations by which the AI evaluates a tile, not just the numbers feeding the evaluation). Also, settler targeting doesn't use the unmodified values spat out by the settle plot evaluator: there is a non-linear distance dropoff scaling, where tiles further away from the settler will have their settle values lowered, and this dropoff definitely affects how the AI uses its settlers.
Nope, or at least not in majority. The behavior trees stored in SQL are but a tiny portion of the AI system. Most of the AI actually runs off flavor systems (now renamed pseudoyields) not dissimilar to the way The Sims' scoring systems work.
Siesta Guru
Prince
Hey, chiming in here. Most of the features have been tested out, including the districts one. The districts work because the default for 'Favored' is true and its set at not null (see the schema), so if you dont add the attribute, it'll pick true. It's only necessary to specify if you want it to be false.
The total yields aspects and the specific resource also work (I have tested them with extreme values and have seen settlers run across the continent to avoid production) and are indicated in the source vanilla, I didn't just think of them on my own haha. They're in agendas.xml and leaders.xml:
Spoiler :
The total yield has no implementation, but I just tried it the same way as inner yield and well, it works.
You can try a royale game with my mod on and you'll see that the settling spot choices are pretty decent now. It unfortunately seems to still count tiles already in your territory, which is a big issue with luxuries etc, and makes it settle a little too close to its own cities, but I don't think we can do anything about that. You rarely see a settler pick a far spot either until very far into the game.
It does still sometimes do those settler traffic jams which I'm sure you'e experinced too, where it somehow ends up creating 3 settlers, then only has 2 slots for OP_SETTLE, so that it can only run two over. But then it runs them both to the same spot, so once the first settles, the second still has to run somewhere else. Even more slots than 2 for the operation just makes them produce way too many settlers as I saw you experienced too
Not sure what to do about that, not even behaviortrees can solve that I think. Perhaps special settler operations that don't use the contracts to build more settlers.Any thoughts on how to proceed with 2 AI mods around btw? It may at least be desirable to use some of each others stuff
Last edited:
notque
Artificially Intelligent
- Joined
- Nov 13, 2005
- Messages
- 2,180
Yeah, 5 I had a setting, I've been searching for something for it, and have yet to find it.
Thanks for your work and all these explaination. Personally I use Delnar's mod and I have borrowed your ModdedSettlerSpot thing and integrated it in a custom personal mod (with other stuff I tweak).
Two AI mods can work together, we just have to be carefull with their integration.
Ah, thankyou for the clarification.
Delnar_Ersike
Prince
Hey, chiming in here. Most of the features have been tested out, including the districts one. The districts work because the default for 'Favored' is true and its set at not null (see the schema), so if you dont add the attribute, it'll pick true. It's only necessary to specify if you want it to be false.
The total yields aspects and the specific resource also work (I have tested them with extreme values and have seen settlers run across the continent to avoid production) and are indicated in the source vanilla, I didn't just think of them on my own haha. They're in agendas.xml and leaders.xml:
Spoiler :
The total yield has no implementation, but I just tried it the same way as inner yield and well, it works.
You can try a royale game with my mod on and you'll see that the settling spot choices are pretty decent now. It unfortunately seems to still count tiles already in your territory, which is a big issue with luxuries etc, and makes it settle a little too close to its own cities, but I don't think we can do anything about that. You rarely see a settler pick a far spot either until very far into the game.
It does still sometimes do those settler traffic jams which I'm sure you'e experinced too, where it somehow ends up creating 3 settlers, then only has 2 slots for OP_SETTLE, so that it can only run two over. But then it runs them both to the same spot, so once the first settles, the second still has to run somewhere else. Even more slots than 2 for the operation just makes them produce way too many settlers as I saw you experienced too
Any thoughts on how to proceed with 2 AI mods around btw? It may at least be desirable to use some of each others stuff
Ah, I'd assumed that the default state for districts was favored=false.
As for the other stuff related to settle spot evaluation, good to know that it works, I was just on the more hesitant side. It'd still be good to know how some of those values are factored in (e.g. does Nearest Enemy city simply multiply distance x score, or is there a more complex function behind its weighting?), but for the most part, I can guess how those value feed in by looking at the Civ5 settle spot evaluation C++ code and assuming that Civ6's works in a similar way (so far, that has worked for me more often than it hasn't). For example, setting the max failures arguments on nodes 4 and 21 for the Settle City Op behavior tree to -7 is probably pointless: they most likely control the maximum times an internal retargeting loop is run (read: that's what these things did in Civ5), and usually 2 or 3 failures is plenty enough, you don't need to make the AI run until it fails the process 7 times. It's also pointless to set the Attack High Priority and Attack Medium Priority moves to be homeland moves as well, since the functions only exist in CvTacticalAI, there's no way they could be run within a CvHomelandAI loop (really, I highly recommend you have a read-through Civ5's DLL source code if you have the time, it'll give you a ton of insight into how Civ6's code would work). Now, if only there was a way to access the citizen manager's values...
Re: settler traffic jams, that was a problem in Civ5 as well, one that I think CPP / Vox Populi ended fixing the best. Different settle operations can't target the same spot, but they can still target adjacent spots, and this can cause the problems you're seeing, especially with Civ6's new movement rules emphasizing choke points caused by rough terrain even more. Even if you have the settle behavior tree have a bunch of operation retarget leaves, there's nothing stopping two settlers from targeting two adjacent tiles. My usual answer is, "we need DLL source code", but all we really need for a hacky solution is to create a "zone" of bad settle value around a settle operation's target, then make sure said settle operation doesn't see the "zone" it's generating... and it might be possible to hijack one of the existing plot evaluation conditions to set these zones up, hmm...
Re: 2 AI mods, well, right now, Civ6 doesn't have workshop support, and I definitely don't plan on really immersing myself in AI modding until CvGameCoreDLL's source code is released (if it's released), so I'd definitely say we're fine with these 2 AI mods. Besides, nothing's stopping either of us from using each other's code, e.g. I've definitely been using some of notque's code, and I might have a look at those settle plot evaluation arguments now that my attention has been brought to them. I don't mind helping you out with questions, either (or asking you a few myself in the future); PM your Discord if you're up for discovery/testing sharing.
Siesta Guru
Prince
Ah, interesting stuff here. I've done a bit of civ 5 dll reading but clearly not nearly as much as you. On the -7 thing, I can at least tell there's a clear difference between -7 and -1, the AI puts their cities much closer together in my version that in vanilla which uses -1. But it may also be because they said favored to false, which might put it out of consideration range entirely. There's also a commented out '5' value in the default which at least suggests that diffrnt values do different things.
My hunch is that it gives a weight to a spot depending on a boolean value that represents 'is the closest city to this spot a city of mine'. This best represents behavior I've seen. For example. I've noticed it will have some difficulty settling on the opposite side of city states, probably because that boolean is set to false there and that it would rather settle on the other side of its empire, in a place thats further from its capital in terms of distance.
From so far as I could tell, the 'favored' thing has basically three levels, 'true' 'unmentioned' and 'false. With 'true' options selected often, false rarely if ever at all and unmentioned sort of in the middle. Then in some systems, the value tag is used for some kind of weighting (with at least plotevaulations, yields and pseudoyields), but it seems its not in others.
It does not seem that putting favored to true makes them force that usage either, while I've set industrial zones to favored, they still don't always build them first while the option for it is open. There's some scoring in the citybuild logs, and I'm guessing it just gives a boost to those scores, but haven't fully tested that out.
I looked a bit through your stuff and noticed that the reordering of the tactical moves probably doesn't do anything either, just like my attempt to add values. It seems to be heavily affected by the way operations work, where for example a defensive move like running back or promoting is always picked if a unit is below the health specified by the defensive node in the behavior tree. Whether they attack units or cities, pillage or move also seem to be affected by nodes in the behaviortrees rather than the order of these things.
Do you think making such a zone is possible in civ 6? It sounds like a good solution but I can't see any way to specifiy nearby tiles and reduce their plot evaluations. Something with lua perhaps?
Yeah using some of each other's code and finding out what works individually would probably work pretty well to create two decent mods.
SuperSylph
Chieftain
- Joined
- Oct 5, 2016
- Messages
- 11
It's not a mistake, it's an oversight, and a pretty big, and possibly deliberate (i.e. it must have occurred to the development team they'd have to update the AI if they were making such a significant change to the movement system), one.
This and everything above it is exactly why I suggested reverting the movement ruleset until the AI is made halfway competent at the new one.
