Closed grinstead closed 3 weeks ago
I'm not aware of the way the transition+tile costs work, but if it is possible to move from one tile to the next with a cost of 0, then this code will break and incorrectly trim away that movement.
At the moment the VisionConfiguration
and MoveConfiguration
objects both do something like map.someCostCalc(vector) || -1
, which implicitly will disallow 0
(as that will get replaced with -1
) . In that case this diff works fine, but it's possible that the intended code was map.someCostCalc(vector) ?? -1
...
This is great, thank you for the contribution!
The cost for moving from one tile to the next is always greater than 0. -1
as a cost means it is inaccessible.
This adds an optimization to avoid calculating where you can go from a position if you have already maxed out.
Small note that if there is a positive, minimum cost to making a move then the if statement could be expanded to
There is no formal benchmarking system in the repo, so this just used a homebrewed one. The (fairly unscientific) results were speedups ranging from 1.15x to 1.3x
This is to aid in https://github.com/nkzw-tech/athena-crisis/issues/9