ls612's C2C AI thread

Fortunately I have just stepped through in his save and it wasn't even that routine that was attacking! It was AI_goodie(), and the reason was a bug in the oddds calculation that caused it to think it had 99% success chances!

I'll push the fix later along with other changes for maintenance etc.

I strongly recommedn ALWAYS stepping through fixes in the debugger when you have a repeatable test case (like the save here) to vaildate that what is going on is what you thought, otherwise thinsg like different random number generation can lead to observed effects that are not for the reason you think they are.

I'll have to learn how to do that.
 
the reason was a bug in the oddds calculation that caused it to think it had 99% success chances!
Was that a localized problem in AI_goodie or was it a problem in the overall odds calculator? If it's the latter I need to know what was wrong exactly so I can adapt at least an understanding of the fix into my code merges.
 
Was that a localized problem in AI_goodie or was it a problem in the overall odds calculator? If it's the latter I need to know what was wrong exactly so I can adapt at least an understanding of the fix into my code merges.

Overall odds calculator - it mishandled modifiers due to withdrawal chances. Once I push my fix you can just look at the change and it should be fairly self-explanatory.
 
very interesting... I'm pretty certain I would've done a rewrite on that so I'll have to try to properly understand how you fixed things when I take a look. I may have a question or two when that comes up then. Let me guess... it was mishandling the decimal placement when switched to a float?
 
very interesting... I'm pretty certain I would've done a rewrite on that so I'll have to try to properly understand how you fixed things when I take a look. I may have a question or two when that comes up then. Let me guess... it was mishandling the decimal placement when switched to a float?

No, it just had some incorrect bracketing that got one element added to anoer before being divided by 100.

if you mess with any odds calculations be very careful, because the AIs use of them has been changed fairly radically, so that the numbers they turn are no longer percentage odds of success, but are weighted by expected gain - so they are in some sense a goodness probability of the outcome. For example a strength 10 unit with 50% actual success odds against a strength 5 defender (due to terrain defense or whatever), will turn a result of much less than 50, because the expected outcome is poor (half the time you lose a strength 10 unit, half the enemy loses a strength 5 one). Some of this code is influx also, since it needs to use the relatively new actual value calculation for units to take proper account of promotions, it doesn't yet (it just uses strengths).

Obviously this only applies to AI evaluation routines, not to those that actually control the combat outcome, but if you're modifying things in that area be aware that it might not be what it seems when you first look.
 
That's an area I wanted you to look over closely once I push to the SVN anyhow. I'm not the greatest math mind but I needed to account for some functional adjustments and I'm hoping I've done a fairly good job of statistics there... seems to work fairly well in testing. But I suspect there's a few tweaks a better mathematician would find necessary there.

Anyhow, thanks for the explanation... I'll be on the lookout for that edit then.
 
I have question:

Does AI know what way treasure unit works and use it in its gameplay?
I am asking because i captured a lot of AI cites and in each city AI had from 1 to 3 treasure units.
 
I have question:

Does AI know what way treasure unit works and use it in its gameplay?
I am asking because i captured a lot of AI cites and in each city AI had from 1 to 3 treasure units.

Unsure TBH. Post a save though please, since it gives us a good example to work with in looking into it.
 
I would have thought that the treasure unit would be a big merchant caravan or small engineer so if it had the AI definitions of the caravans it should work correctly. I have not looked at the XML.
 
@Koshling:

I'm trying to add a routine to the CvPlayerAI::PromotionValue which checks the number of damaging terrain plots around a city and then increases the value of a promotion based off of how many plots nearby that promotion would avoid damage on. My question is, how do I check how many plots near a city have types of terrain that would be damaging, and then increase the value of a promotion that gives immunity to that damage based off of the number of plots that give that damage?
 
@Koshling:

I'm trying to add a routine to the CvPlayerAI::PromotionValue which checks the number of damaging terrain plots around a city and then increases the value of a promotion based off of how many plots nearby that promotion would avoid damage on. My question is, how do I check how many plots near a city have types of terrain that would be damaging, and then increase the value of a promotion that gives immunity to that damage based off of the number of plots that give that damage?

I suggest you don't for now. I've been intending to do that for some time, but been holding off because Thunderbrd is modifying the promotions code, and I didn't want to change it under his feet until he was done.

If you feel you must do it now, then the city cross is inappropriate - you need to take account of a much wider field to make good decisions. The code I added to provide combat valuation of a unit and its promotions in V26 already does this (it takes the proportion of the terrain that is matched by the promotion in the current area), and my intention is that the combat evaluator (the one I added in V26) and the which-promotion-to-get evaluator use common code for all aspects of promotions that they are both interested in (so we only have one to maintain in future). It's this combining stage I haven't been able to do until Thunderbrd is done however.

The routine that already does this evaluation for combat purposes (the new one in V26) is CvUnitAI::AI_genericUnitValueTimes100() if you are interested in seeing how it works.
 
I suggest you don't for now. I've been intending to do that for some time, but been holding off because Thunderbrd is modifying the promotions code, and I didn't want to change it under his feet until he was done.

If you feel you must do it now, then the city cross is inappropriate - you need to take account of a much wider field to make good decisions. The code I added to provide combat valuation of a unit and its promotions in V26 already does this (it takes the proportion of the terrain that is matched by the promotion in the current area), and my intention is that the combat evaluator (the one I added in V26) and the which-promotion-to-get evaluator use common code for all aspects of promotions that they are both interested in (so we only have one to maintain in future). It's this combining stage I haven't been able to do until Thunderbrd is done however.

The routine that already does this evaluation for combat purposes (the new one in V26) is CvUnitAI::AI_genericUnitValueTimes100() if you are interested in seeing how it works.

OK, I'll wait until the Combat Mod hits the SVN. That code (or a variation thereof) will also be useful when I want to write the AI for the Adjacency System I'm planning.
 
OK, I'll wait until the Combat Mod hits the SVN. That code (or a variation thereof) will also be useful when I want to write the AI for the Adjacency System I'm planning.

TB is going to push the current version of his code to SVN tonight I believe. I suggest you give me a couple of days to Integate it with the combat promotion evaluator (which should address this specific aspect anyway), and then do any further work you want to do.
 
Due to some extra polish I'm putting on it, eta is now pushed out to tomorrow. Sorry for any inconvenience (but it really should be much better after I get a few last minute details installed right.)
 
Due to some extra polish I'm putting on it, eta is now pushed out to tomorrow. Sorry for any inconvenience (but it really should be much better after I get a few last minute details installed right.)

Fine by me, I've got plenty of other stuff to work on.
 
Not sure if this has been changed in v26 or not, my current game is v25 still. AI really seems to like buying religion-founding techs and workers. Workers are at least somewhat useful, but the religion techs are almost all useless to trade for.
 
@Koshling:

Do you have any small and simple AI enhancements on your todo list that I could work on? I personally am planning on making some tweaks to the attack stack composition, as I have had large stacks of Ambushers in AI attack stacks against me (in a pre Combat-mod SVN), which I figure can't be right, but otherwise my slate is more or less open for the time being.
 
@Koshling:

Do you have any small and simple AI enhancements on your todo list that I could work on? I personally am planning on making some tweaks to the attack stack composition, as I have had large stacks of Ambushers in AI attack stacks against me (in a pre Combat-mod SVN), which I figure can't be right, but otherwise my slate is more or less open for the time being.

Not really. I suggest you just play test a bit and watch for the AI to do something stupid, then go back over the same tuen again in the debugger figuring out why. The things I specifically intend to do in the near future myself are:
  • Improve AI promotion selection - once I've done the basic work it might well be worth your while doing a pass over that and adding further tweaks to it (I'll let you know when it's done)
  • make the AI weight predicted combat outcomes more subtly than just be unit base strength (which is what it does now) - ie - take account of highly promoted units being more valuable, heroes, and limited national units also being valued more highly, etc.
One big area I want to look at (but which is going to be hard I suspect) is to try to make the AI less focussed on monolithic stack moves. Right now it decides what to do on a stack by stack basis, so for example if it has a large stack and sees an easy attack to kill one unit it will do so and move the entire stack into the tile where the unit killed was - it doesn't consider must moving one unit in, leaving the rest of the stack free to do other things (like make other attacks).
Getting it to split monolithic stacks temporarily, but still keep their actions coordinated is also foundational to bei able to write decent surround and destroy AI, so this is really a stepping stone.
 
I was thinking that having some kind of sub-ai definitions established when a unit is in a stack, defining the cause for it being there (fulfilling a 'build-to' call for what should be considered a volumized need in a 'well balanced stack') and how it may wish to act independently on certain triggers, could be useful.

Stack composition will be a big issue to make the ai use the combat mod effectively so you may wish to plan how to improve on that in light of some of the combat mod documentation I'm about to add later tonight (though I may not get through it all right away - there's a lot to it.) I have a lot to suggest there for the AI modding that I'm not above trying to help with myself but I'm not in full understanding of the whole ai maze yet, just some fuzzy understanding of basic employed principles so far.

If you're wanting to focus mostly on AI, I could use a bit of improvement on the Cure mission AI as well... which I think is going to require setting up a whole new AI definition for Healing units, which is probably a good idea anyhow for numerous reasons.
 
Back
Top Bottom