A new approach is taken for deriving follower paths from leader paths. The general idea is that the waypoints in the follower path should follow the waypoints of the leader path, regardless of which tokens are STG or not. In most cases this is exact, but in the case of a STG token following a non-STG leader the waypoints are snapped to grid cells after being calculated. When both tokens are STG or both are not, the follower path will precisely follow the leader path even between waypoints (so pathfinding is accounted for). In the other cases, only the waypoints are considered, and intervening points may be interpolated.
Refactoring
There is a supporting refactor to Path to make the above idea solid. Path now has an invariant that makes sure the waypoint list and cell list make sense together:
if either list is empty, both are empty
if not empty, the lists have the same first and last point.
All waypoints are guaranteed to appear in the cell list in the same order, but possibly with extra cells interposed.
To do this, callers are only allowed to append to the path, not otherwise modify it. And they no longer add cells and waypoints separately. Instead they can either:
Append a single point to be treated as both cell and waypoint.
Append a partial path whose last point is treated as a waypoint.
Only SelectionSet and MeasureTool really had a problem with that, and specifically for gridless paths. They were easily fixed by having them handle their own current point instead of hijacking the Path to do it for them.
New unit tests are included that fully cover Path aside from readResolve().
Possible Drawbacks
Serialized paths will not obey the new rules. This shouldn't really be an issue, but it does mean that if a user loads up an campaign, hit "Show Path" on a follower token, the paths they see won't match what they see if they tried the same drag that produced it originally.
Documentation Notes
Follower tokens try to follow the leader token as closely as possible when dragging.
Release Notes
Fixed a bugs where follower tokens would take different paths to the destination than the leader.
Identify the Bug or Feature request
Fixes #4813
Description of the Change
Bug fix
A new approach is taken for deriving follower paths from leader paths. The general idea is that the waypoints in the follower path should follow the waypoints of the leader path, regardless of which tokens are STG or not. In most cases this is exact, but in the case of a STG token following a non-STG leader the waypoints are snapped to grid cells after being calculated. When both tokens are STG or both are not, the follower path will precisely follow the leader path even between waypoints (so pathfinding is accounted for). In the other cases, only the waypoints are considered, and intervening points may be interpolated.
Refactoring
There is a supporting refactor to
Pathto make the above idea solid.Pathnow has an invariant that makes sure the waypoint list and cell list make sense together:To do this, callers are only allowed to append to the path, not otherwise modify it. And they no longer add cells and waypoints separately. Instead they can either:
Only
SelectionSetandMeasureToolreally had a problem with that, and specifically for gridless paths. They were easily fixed by having them handle their own current point instead of hijacking thePathto do it for them.New unit tests are included that fully cover
Pathaside fromreadResolve().Possible Drawbacks
Serialized paths will not obey the new rules. This shouldn't really be an issue, but it does mean that if a user loads up an campaign, hit "Show Path" on a follower token, the paths they see won't match what they see if they tried the same drag that produced it originally.
Documentation Notes
Follower tokens try to follow the leader token as closely as possible when dragging.
Release Notes
This change is