-
-
Notifications
You must be signed in to change notification settings - Fork 994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assertion Failure for AI with two leaders - src/attack_prediction.cpp:1763 #2117
Comments
@jyrkive - Well, it is fixed, but your description seems unrelated to the situation I described. If the recruit lists and keeps business (no enemy required, within range at least) makes sense to you, it's all good. Just bringing it up in case this is suppressing a symptom of something that will flare up again later. |
My description is about the actual cause of the bug, which I found out by debugging in your test scenario. Your guess about two leaders was incorrect. (Indeed, attack prediction code doesn't even know how many leaders you have.) |
Well, I only know when it showed up, and your description still doesn't apply to what I saw (who was dying? -> no one. Why do the secondary keeps matter? Why does changing the recruit list matter?) |
It was in attack prediction. It predicted that one combatant was 100% guaranteed to die in a future fight if it were to occur. |
EDIT: I've made a mess of this, I'll post my question on the forums. Maybe someone there will have an answer. |
Regression from commit f6c4f3d. The code divided by zero and the probability to stay unscathed ended up as NaN, which triggered an assertion failure if the AI simulated one more fight for either combatant.
On v1.13.10+dev (f6c4f3d), the program aborts with assertion failure:
wesnoth: src/attack_prediction.cpp:1763: double {anonymous}::calculate_probability_of_debuff(double, bool, double, double, bool, double): Assertion 'prob_touched >= 0.0 && prob_touched <= 1.0' failed. Aborted (core dumped)
when the AI has control of a side with two leaders, each with their own 'extra_recruit' lists, but the side recruit list is empty.
Such a situation used to work just fine, I'm not sure when this first became a problem - I think it was OK in 1.13.8, but I'm not sure.
I'm attaching a demonstration scenario. If you modify the map to remove the secondary keeps (the encampments), the game does not abort. Campaign is found in list with name "Empty Recruit List".
Demo_Camp_D.zip
The text was updated successfully, but these errors were encountered: