Follow-up Comment #12, patch #3186 (project wesnoth):
brilliand:
Well, no, there are no other events that would interrupt movement, but then
again there are currently no events that trigger in the middle of movement. (I
did say "similar", not "same".) However, sighting a unit can interrupt
movement (does interrupt movement if the unit is an enemy). There is no
analogue of [allow_undo] in that case, but it does provide a precedent for
unexpected events interrupting movement, giving the player a chance to
reconsider.
Plus, a player could opt to move one hex at a time, and I'd think it should be
desirable to not disadvantage those who want to speed up the game (by moving
further each click). Also, if the paradigm was switched to [allow_undo], WML
could still block undoing at the end of the move by creating a "moveto" event
in the middle of the "movethrough" (or whatever it gets called).
On the other hand, you do have a point on the non-intuitiveness of this with
"movefrom". However, keep in mind that such an event would not render a unit
unable to move unless it contained "first_time_only=no", and that this
behavior can be documented as part of its functionality. It might not be too
bad.
Adding the option to "press t to continue" after an interruption by a
movethrough looks like a good idea to me. (And draws a stronger parallel to
movement interrupted by sighting a unit. ;) )
boucman: OK with me. I believe these events would fit into the second loop
through the proposed route -- specifically surprise_movement_end() -- in my
version, and there would already be logic in place to stop the unit on an
unoccupied hex, if an event calls for that (both the most recent unoccupied
hex and the "next" unoccupied hex are used in my version; I'd think the most
recent would be more appropriate for movement interrupted by event).
Instead of "enter_hex", would it make sense to combine "movefrom" and
"movethrough" into "exit_hex", firing for each hex except the last? (With the
secondary location being the next hex on the route.) This would have the
side-effect of removing the redundancy of two events firing upon entering the
final hex.
(With this setup, the check for the trigger hex being occupied could almost be
seeing if the primary unit is adjacent to the secondary location. It fails for
a teleport, but that might not be too big an issue.)
_______________________________________________________
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
