Follow-up Comment #2, bug #22988 (project wesnoth):
Firstly, if this is not a bug then it is a new behaviour. I think UMC creators
should be warned (maybe here?
http://forums.wesnoth.org/viewtopic.php?f=21&t=36057)
>In most situations this makes sense because the movto event might have
changes the sitution
It might but it needn't to.
In my add-on I have a moveto event handler that does some work in the
background only (e.g. recalculates income, because it depends on position of
units), and so from the point of view of a player there is no such moveto
event (i. e. a player doesn't know about it). Therefore a player must be
surprised that suddenly the UI behaves differently.
>an event with [allow_undo] should not cause this behaviour
Indeed, I just tested it.
It sounds nice ... yes, an UMC author should have under his control whether
the attack will be removed from the 'queue of orders' move+attack or not.
But what if the UMC author wants
[not to remove the attack] AND simultaneously [not to allow_undo]
?
You can answer that it won't happen, because ...
situations where no new information was revealed to the player in the moveto
event handler (=A)
happen if and only if
the undo may be allowed (=B)
and it happens if and only if
there is no reason why the player would want to interrupt his order
move+attack (in other words not to attack (=C)
so mathematically we can say A <=> B <=> C
This idea sounds very reasonably.
(Also I noticed BfW 1.12 reflects this idea, because in 1.12 there is an
"internal moveto event handler" that checks whether an enemy unit was revealed
during the move and in that case the attack is canceled. (In BfW 1.10 the
attack was performed anyway.) )
But ... I think "A <=> B" is not fully true: there may be a situation where "A
and not B".
Example: a unit consumes 'fuel' during movement, and the fuel is stored in a
variable. Then undo must be forbidden, because BfW offers no mechanism that
would allow to restore that variable after undo (at least I don't know about
that mechanism)
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?22988>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs
