Follow-up Comment #21, bug #21966 (project wesnoth):
Yes those lines look correct.
i dont know exactly how this was handled in in 1.10.x but in 1.11.13+ not
executing the complete move if it was stopped by any reason is exactly the
expected behaviour.
(The following is molst likely not true for 1.10.x versios)
Let A be te currently acitve side and B be the other side.
The reason is:
In 1.11.15+ it might happen, if side A does a movement, that the movement
action is sended to client B before it's execution is finished on client A.
This happens if a mp_sync (random/[message][option]/ ...) is used durign teh
move (enter_hex events). Especialy side 1 doesn't know how far the movement
will go (wheter it will be stopped by sighted event especialy), so it just
sends the full movement an relies on the other side calculating the same
destination hex. If this is not the case then the OOS will not be detected
now.
If the movement doesn't invoke mp_sync (this is especialy true for all
undoable moves) then client A knows where the movemnt ended when it sends it,
becasue it is sended later. In this case it still sends the data of the full
(possibly not completed) move and relies on the other side calculating the
same destination hex, but it also adds some checkup data so that the other
client can veryfy wheter the destination hexes are the same on both client and
give an oos message if thats not the case.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?21966>
_______________________________________________
Nachricht gesendet von/durch Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
Wesnoth-bugs@gna.org
https://mail.gna.org/listinfo/wesnoth-bugs
