[v30]stack attack not using best unit?

martinuzz

Chieftain
Joined
May 14, 2013
Messages
28
I have a stone spearman, and a clubman in a stack, together with a Great Commander.
Whenever I attack with the whole stack, the game picks the clubman to attack, even though it's not the best attacker at all. I'm used to having stacks use the best unit available for the task. Is this an intentional change, or is this a bug?

I do not have the stack attack option turned on btw. I did turn on archer bombard
 
I have a stone spearman, and a clubman in a stack, together with a Great Commander.
Whenever I attack with the whole stack, the game picks the clubman to attack, even though it's not the best attacker at all. I'm used to having stacks use the best unit available for the task. Is this an intentional change, or is this a bug?

I do not have the stack attack option turned on btw. I did turn on archer bombard

What are you attacking and what promotions do the units have? Post a save game that reproduces it also please.
 
The clubman only had combat I promotion, the stone spearman had a ton of promotions.
WHen stack attacking though, the game always uses the clubman.
When I made the thread, it wanted to attack a Neanderthal warrior, with something lke 2% survival odds. The stone spearman had over 90% survival odds, but wasn't picked.

In the current save, another spearman has been added to the stack, and all have gained some more promotions. Still, when attacking, the game favours picking the inferior clubman, be it against animals or Neanderthals, makes no difference.

Luckily, this does not extend to defending. For defense, the best unit is still used.

View attachment martinuzz Romans CtC.CivBeyondSwordSave
 
Just to be clear which stack attack are you using the one on the BtS options or the one in the BUG options or both like me. They do different things.
 
@ Dancing Hoskuld: I am NOT using stack attack option at all.

What's "lead from behind" ?
 
Ok, I've looked into this now, and it's quite interesting. A couple of factors are causing this:

1) When selecting the best unit it calculates odds for each unit in the stack in turn. Odds are restricted to 1-99% (100 and 0 both cause issues with rounding, so we discard them and treat as 99 and 1 respectively). If a unit has better odds than the one previously checked it is noted as the best so far, and the eventual best is returned.

2) If several units have odds of 99% or above then the first one evaluated will 'win'. In your case, for any animal attack, and also for an attack against a Neanderthal warrior (at least in non-defensive terrain - I didn't check against a Neanderthal on a wooded hill), the clubmen has odds of over 99% (which is not what is displayed in the hover text, and I'll come to that) and happens to be the first unit in though group (so it gets evaluated first). Since the two spearmen also get a 99% evaluation they do no replace the clubman, and it gets used because all have what it considers maximal odds.

3) The hover text uses a totally different routine to the AI to evaluate probability. BOTH are approximations of the actual combat code (because the combat code runs several rounds and is expensive, so you cannot afford to use it for odds calculations or turns would run way slower). I'm not totally sure which is the more accurate - they differ significantly when the attacker and defender have very different first-strike counts, which is true in your case (1-5 vs 0)

4) The routine that generates the displayed (hover text) odds is used ONLY for that, and for the evaluation of xp received from a win. It is NOT used for the actual combat at all.

As such I think this is a display issue mostly (really all 3 units have great odds), and slightly a rounding issue (it doesn't choose 99.5% over 99%).

However, if you ever see a case where this happens when it i clear that the chosen unit does NIOT have great odds, it might be indicative of a more serious bug and I'd like to see any such save. For the save you supplied I tried attacks against a variety of animals, and against Neanderthals - both were in the 99% category above.

I also tried it against an archer, which shouldn't be such a push-over, and a longbowman. To my surprise they also came out at 99% odds in favour of the clubman!!!

I have pinned this down to bugs in the withdrawal evaluation in the combat mod, but I don't yet have a fix. However, the AI evaluated odds (which are used to select the attacker and are used by the AI to plan all its moves!) at least (and possibly the displayed odds - I'm not sure yet) are grossly miscalculated if any withdrawal chance is in effect (which i is here due to the 50% withdraw your Great General is giving).

I'll get a fix made for this over the weekend - should be pushed to SVN on Sunday at latest. That won't necessarily correct the display-vs actual mismatch when first strikes differences are significant, but that's a lesser issue. I may try to fix that also - we'll see...
 
I have pinned this down to bugs in the withdrawal evaluation in the combat mod, but I don't yet have a fix.
While I have a suspicion where this may be located, please do pm me to let me know what revision to review. Thanks as well for looking into this... as I've stated before, the odds is something I know I was somewhat muddling through and really wanted it looked over by smarter math heads than I if possible.

You remind me of what I feel is a bit of an issue here... why can't we simply consolidate to one single odds generator... there's so many places and ways its compiled its just overwhelming having to interact with these varieties!
 
@TB - Several problems fixed (well 'addressed anyway) in changes I'll be pushing to SVN later today - in some cases I am not 100% sure of the design intent though, so it's possible I have misinterpreted slightly. Specifics as follows (don't worry about this too much until after I push the changes so you can see the diffs):

1) Various loops evaluated things like early withdrawal, repel etc. had their cumulative probabilities wrong (round N only adds it's withdraw probability if you have not already withdrawn in an earlier round, and that was not accounted for in the calculation)

2) In the same calculations the round count used was incorrect - should be the min of attacker and defender needed rounds (if you lost in 5 you shouldn't evaluate the probability of withdrawing in rounds 6-10 if you would have needed 10 to win

3) In the same calculation the number of iterations for some cases (notably repel) was one too many, because the initialization of the accumulated result ('z') was set to account for one round without going round the loop at all.

4) Some discrepancies between CvUnit::resolveCombat() and CvUnitAI::AI_attackOddsAtPlotInternal() fixed. In particular the latter was using the inverse of the early withdrawal probability instead of the probability of it, leading to greatly inflated survival estimates

5) CvUnitAI::AI_attackOddsAtPlotInternal() was handling odds modification by withdrawal knockback etc. incorrectly in two ways:
5.1) Survival is not winning so survival should not up the aggregate result in the same way winning does (I gave it 50% value as a working estimate)
5.2) The bracketing of the expression was wrong, leading to an incorrect multiplier of the withdrawal/knockback component by the original win odds (times 100)
 
@TB - Several problems fixed (well 'addressed anyway) in changes I'll be pushing to SVN later today - in some cases I am not 100% sure of the design intent though, so it's possible I have misinterpreted slightly. Specifics as follows (don't worry about this too much until after I push the changes so you can see the diffs):

1) Various loops evaluated things like early withdrawal, repel etc. had their cumulative probabilities wrong (round N only adds it's withdraw probability if you have not already withdrawn in an earlier round, and that was not accounted for in the calculation)

2) In the same calculations the round count used was incorrect - should be the min of attacker and defender needed rounds (if you lost in 5 you shouldn't evaluate the probability of withdrawing in rounds 6-10 if you would have needed 10 to win

3) In the same calculation the number of iterations for some cases (notably repel) was one too many, because the initialization of the accumulated result ('z') was set to account for one round without going round the loop at all.

4) Some discrepancies between CvUnit::resolveCombat() and CvUnitAI::AI_attackOddsAtPlotInternal() fixed. In particular the latter was using the inverse of the early withdrawal probability instead of the probability of it, leading to greatly inflated survival estimates

5) CvUnitAI::AI_attackOddsAtPlotInternal() was handling odds modification by withdrawal knockback etc. incorrectly in two ways:
5.1) Survival is not winning so survival should not up the aggregate result in the same way winning does (I gave it 50% value as a working estimate)
5.2) The bracketing of the expression was wrong, leading to an incorrect multiplier of the withdrawal/knockback component by the original win odds (times 100)
Yep... everything I was doing was muddled through experimental and seemed to be working but I knew was baited for error as I never did fully grasp that degree of math. It was really my best effort and as I said at the time, really needed review.

So thank you heartily! There's a few other issues I need to sort out for odds that I'm really at a loss to even know where to begin at - most notably accounting for adjusting strength per round, Power Attacks, and mid-combat afflictions at the moment, but other mid-battle stat changes are planned. You apparently have a hell of a lot greater ability in the odds calculations to account for these things and to be honest, I'm humble enough to admit I'm just not that good at it so I could really use your help as application of those effects nears. Would you be willing to help me figure out the odds adjustments those kind of things bring into the picture at some point?

It SOUNDS like you've accounted for everything I was trying to accomplish there so thank you again - did you have any questions on the intentions of the codes or effects you were looking at there?
 
@Martinuzz - see patch thread if you want an easy way to get hold of the fix...
 
Back
Top Bottom