Update of bug #25222 (project wesnoth):
Status: None => Confirmed
Release: git => 1.13.5+dev
Operating System: linux => All
_______________________________________________________
Follow-up Comment #1:
I hate planning mode and I hate planned recruits in particular. ): Maybe I
should re-introduce my PR to disable planned recruits altogether.
//for a little extra safety, since we should never resize by much at a time
assert(turn_num <= num_turns() || future_only);
I'm not sure if anyone still active really knows what the planning code is
doing. But the general way to replicate this issue is to plan a recruit and
then plan several turns of movement (when I was testing, num_turns() returned
1 and it was the first turn of the game).
I disabled planned movements on planned recruits a while back but it only
cancels the planned movement when you attempt to add it to the queue. So I
suppose there's still some background processing involved which is where this
assertion gets hit. Incidentally, ignoring the assertion failure seems okay...
until you go to close the game in which case there's another crash/exception,
presumably due to the assertions failing the first time around.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?25222>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
