Follow-up Comment #4, bug #13268 (project wesnoth):
Thanks for the remarks.
1.
redo equals re-erasing (dismissing) a unit from recall_list. This has the
potential to mess up recall_list if you undo a dismissal, manually dismiss
the unit again and then hit redo. This way you get a dismissal of an already
dismissed unit, which leads to dismissing a different unit or segfault if the
index is not valid anymore. Obviously, clearing redo_stack_ at every
(manual) dismissal solves that problem.
redo_stack_ completely clears for the following reasons:
a)
redo_stack_.pop_back() (as you suggested) is not sufficient. You can
interleave the undo/redo of a dismissal with some other action (say, a move),
which then gets removed from redo_stack_ instead of the re-dismissal. (just
tested that)
b)
recalling has the potential for the same bug, and there it is solved by
clearing the redo stack on a recall. To keep it simple I did it the same way
for dismissals.
c)
A way without clearing redo_stack_ could be the following: If unit A is
getting dismissed, check if there is a dismissal of A in redo_stack_, if yes
remove it. Yet, I found no easy way to identify the dismissal action of a
specific unit in the stack. Neither a unit nor an action seem to have a
unique id. So I sticked to the straightforward solution of b).
2.
dismissing a unit means erasing them from recall_list. Hence, undoing a
dismissal equals re-inserting the unit in recall_list. redo equals re-erasing
it respectively. In my tests, this yielded the desired results.
3.+4.: I agree.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?13268>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs
