Follow-up Comment #19, patch #3186 (project wesnoth):
Are you significantly increasing the complexity of the code in order to stay
true to your one possible use"? (A use that I would expect to be uncommon to
rare, but I could not speak for most people anticipating this event.) Maybe it
is worth coding for, but don't forget the KISS principle.
Regarding [stop_action] plus [allow_undo], there are four distinct cases.
1) *Interrupt movement and allow the move to be undone:* This is probably an
abuse of [allow_undo].
2) *Interrupt movement and block undoing it:* I think this should be the
default if nothing is specified, and can be accomplished without
[stop_action].
3) *Don't interrupt and allow the move to be undone:* This would be what both
of us expect if [allow_undo] is specified without [stop_action].
4) *Don't interrupt and block undoing the move:* This is what you want the tag
for, isn't it? It can be done without a [stop_action] tag (as I mentioned
earlier), so the question becomes which option is more desirable for the
markup language.
How I would envision not interrupting, yet still blocking the ability to
undo:
Add the following inside the enter/exit_hex event. (It could be made into a
macro for brevity.)
# Do not interrupt movement now.
[allow_undo]
[/allow_undo]
# Clear the undo stack when this move is finished.
[event]
name=moveto
[/event]
-verbatiim-
The tag nomenclature is odd/off a bit for this use, but it would get the job
done (and the WML snippet could be placed in a suitably-named macro). So the
question should not be whether this functionality is needed (since it would be
available in either case), but what is the better syntax for it.
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?3186>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
