WalkTo actions (or anything involving route planning, actually) currently plan their routes on start(), introducing a long delay if the distance is large.
Instead, these actions should be able to plan ahead, changing things as follows:
WalkTo actions store their route instead of generating it on-the-fly.
Their route is initially pre-populated with a naive straight line. It is intended to replaced very soon by the first update_route(Pos start) call.
They offer an update_route() method that's intended to be executed from a different thread.
update_route() will atomically / mutex-locked update the previous route, so at any point in time, there's a route that's more-or-less-valid.
If at the begin of update_route()'s execution it is discovered that the action is already running, then route calculation takes the current player's position as its starting point.
If at the end of update_route()'s execution it is discovered that the action is already running, the player is "pulled onto the route" with another short pathfinding call.
The pre-planning thread will iterate over all WalkTo's in tasks and over the implicit WalkTo's in between the tasks, and pre-plan them up to a limited time/waylength in the future.
Also, upon start() of a WalkTo action, it is replanned again, to account for last-minute changes.
WalkTo actions (or anything involving route planning, actually) currently plan their routes on
start()
, introducing a long delay if the distance is large.Instead, these actions should be able to plan ahead, changing things as follows:
update_route(Pos start)
call.update_route()
method that's intended to be executed from a different thread.update_route()
will atomically / mutex-locked update the previous route, so at any point in time, there's a route that's more-or-less-valid.update_route()
's execution it is discovered that the action is already running, then route calculation takes the current player's position as its starting point.update_route()
's execution it is discovered that the action is already running, the player is "pulled onto the route" with another short pathfinding call.The pre-planning thread will iterate over all WalkTo's in tasks and over the implicit WalkTo's in between the tasks, and pre-plan them up to a limited time/waylength in the future. Also, upon
start()
of a WalkTo action, it is replanned again, to account for last-minute changes.