Follow-up Comment #3, bug #13118 (project wesnoth):
Ok since I really thought that the "send path" change was simple (and didn't
parsed your last "separate the pathfinding stuff from
actions.cpp::move_unit"), I quickly tried to see if it was easy to implement
without touching too much things. I think it's ok, here is a basic patch
using simple (but compact) storing for path. It seems to work even with undo
and AI, but I didn't really study these parts, I just plugged my new function
there and checked if it work with standard cases.
Of course compatibility is still broken, but if the OOS risk is small enough
(I don't think so, but hard to evaluate), we could easily add a backward
compatibility hack: continue to send [source] and [destination], detect any
missing [path] and do an A* to replace it. For 1.6 or after few releases, we
could declare RC1 obsolete (I doubt that many users will keep a RC1 when 1.6
will be out). Well, it's just a possibility to think about.
Now, OtOH, I continue to think that trying to synchronize the pathfinding
stuff is not a good idea, so here some more warnings that I noticed:
-When adapting this patch to the AI code, it saw that the AI seems to use the
"other pathfinding function" paths(), this will need to be converted to a A*
result and check if changing the wanted path doesn't affect the AI stuff.
-The pathfinding is affected by fog/shroud stuff and it's only recently that
the fog of the local side is "relatively correctly" updated. But if the
sender used the "delay shroud update" option, then he does all his moves on a
more shrouded map. OtOH the first move executed by the receiver will start to
clear shroud. Now I think it will still work, because any unit is supposed to
have cleared all reachable areas (+1 hex). Without the +1 hex, some reachable
hex could have been under ZoC of a temporary-shrouded unit and thus forcing
to give different pathfinding results depending when the shroud is cleared.
So, this specific thing works but this is close and hard to analyze. For
example, I believe that the A* search will put some of these hexes with an
out-of-sync cost into its heap, because it takes all adjacent hexes near the
the edge of the FoV. In theory, such hexes will not be considered, but again,
a bit too close for my tastes.
-We will also need to check that all fog is correctly in sync between
clients. Bugs there are hard to detect, because users never see the fog of
enemy. For example I still have some fog-thing to check after a "slow"
attacks.
And for the future (both maintenance of 1.6 and new features in 1.7), if we
keep that idea, it will put a serious pressure on features linked to
pathfinding, fog, mouse interface etc... All these things will need to be in
sync, preventing any local bug / optimization / preference.
PS: oops a bit long sorry :-)
(file #5383)
_______________________________________________________
Additional Item Attachment:
File name: send_path_r33360.patch Size:6 KB
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?13118>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
