Follow-up Comment #16, patch #3186 (project wesnoth):
jamit, I don't think putting enter_hex and exit_hex in surprise_movement_end()
will work. If we required that those events not change any game state and
just interrupt movement (and do anything important in moveto), then it would,
but if the user is allowed to "press t to continue", it becomes much more
complicated. Consider if moving anywhere near a certain tile (enter_hex,
[filter_location]radius=2) is supposed to cause that tile to become surrounded
in Impassible (or something that only sometimes obstructs, such as mountains
or deep water). If the player uses "press t to continue" to press on through
that interrupting event (perhaps after previously being interrupted by an
"enemy sighted" event), then he could potentially move right through the
barrier to the blocked tile, unless known_movement_end() is called again to
adjust. Likewise, the animation would look somewhat odd (with the terrain
changing before the unit starts to move) if make_a_move() hasn't started its
work by then.
Because of this, either known_movement_end(), surprise_movement_end() and
make_a_move() will need to be merged back into a single loop, or the algorithm
will need to go back to square one every time it hits an interrupting event
while ignoring interruptions.
_______________________________________________________
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
