Hi Ali, first of all, thanks a lot for this precise and very helpful analysis. It described the problem very well and gave me a good direction where to take a closer look at.
The motivation behind my change was to provide the same codebase for replays and the "regular" in-game actions. It was originally triggered by a bug (the one that is mentioned in the commit comment obviously). However, there is more to it. Problems like these weren't visible in the past, simply because WML was either much simpler back then or its possibilities were not exploited to the max (or both ;-). Meanwhile WML has become very mighty and its might is used as well. So unless we don't do things in replays exactly as they are done in-game, i am sure we will fight an uphill battle against OOS, since replays are the central mechanism to synchronize clients in multiplayer. That is why I would like to investigate the first (though probably more complicated) solution: Adjust pathfinding, so that it is the same in-game and for replays. Unless that turns out to be totally infeasible for 1.6 of course. I will keep you updated. Greetings Yogi Details: It's mainly pathfinding difference between clients. But first, I think that we must revert r32669 http://svn.gna.org/viewcvs/wesnoth?rev=32669&view=rev or at least the part where we now do a real move of unit, instead of just drawing one. The commit doesn't say what event was not being triggered, seems to be "move" events (possibly "sighted" event, but was never replay-safe, and will probably never be). In that case just firing it manually in replay code may fix this. The core of this problem is that we just send source and destination of the move action, letting local pathfinding found a path between them and assume that it will be the same as the sender really used. The 1.4 version was already horrible about that, because it didn't even used the same pathfinding algorithm ("paths" instead of A*) I tried to improve that with r27830: http://svn.gna.org/viewcvs/wesnoth?rev=27830&view=rev But at that time is was only a visual glitch, for example the receiver could see (enemy) sender's unit pass by the hex of his hidden unit. This old system is not safe because, any difference between two clients could cause different pathfinding results. Which is mainly a problem when the receiver solution pass near an ambushed unit, but it's also less good for the gameplay, because you have false assumptions on which hexes your opponent know to be ambush-safe or the fog he has cleared. Track and fix all of these pathfinding differences is probably too much work and we will never be sure to get them all (I already see potential problems with multi-turn moves from mouse or goto, AI, fog or discovered hidden units not up-to-date) Note that using different paths may also cause an OOS bug about the move_left (bug #12467) So, I suggest: - Get back to a purely visual move, send "move" event, and forget fog and "sighted" event in replay (I believe it's only a problem if they modify the game state) - Transmit the move_left in the [move] data, to be sure to avoid the move_left bug OR (and better I think) - Transmit the path in the [move] data, that is something like path=3,3,4,3,5,3... or x=3,4,5 and y=3,3,3 I think there is also future plan with a "pass by this hex" event which will need exact path. But sadly all of this will break compatibility with RC1, and it's a bit late for such change. OtOH it may prevent OOS troubles in 1.6 PS: YogiHH, assigned it you to get your opinion and possibly let you fix the problem (you know this code better than me), but I am available for help or coding about this (I also have other work which will depend how this stuff change or not) _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?13118> _______________________________________________ Message sent via/by Gna! http://gna.org/
<<attachment: winmail.dat>>
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
