Adding SSpathfinding.
Description of changes
- Adding a subsystem to handle scheduling/tick checking of A* pathfinding.
- Converts bots and ICs to use the subsystem.
- Adds handling for paths to mob automove.
- Should fix or at least limit/mitigate #4058.
TODO
- [X] Coarse implementation.
- [ ] Get bots to actually work again.
- [x] Get path following, updating and invalidation working on a test mob controller type.
- [x] Test asynchronous/tick checked AStar().
Why and what will this PR improve
- Allows use of A* without locking up the entire game.
- Generalizes pathfinding off the bot subtype so mob controllers in general can use it.
Authorship
Myself.
Changelog
Nothing player-facing.
I don't know if it's in the plans down the road, but having some way to prioritize some movers above others would be great. Since, having a lot of idle mobs running their idle or like fluff pathfinding over mobs in active combat would probably be a bit problematic.
Like say, if there's 12 cleaner and farm bots bots trying to get a path and then there's 2 medbots trying to path to heal people, and 2 hostile mobs trying to path to attack players, you probably don't care much about the cleaner and farm bots pathing really long paths over those that need to react quickly?
I am not planning on adding pathfinding priority in this PR. I just want it subsystemised and tickchecked, if someone wants to implement scheduling down the track then they can, but I am not adding more scope to this PR, I am already struggling to get through it.
Splitting the bot aspect out of this for a separate PR.
Need to remove or integrate/test the asynchronous A* for bot code.
This has broken bot behavior, but I can't tell if it was my changes or if bots were already screwed. Need to test bots on clean dev I guess.
works perfectly with #4586 in.
Farmbots and cleanbots are now working fine.
Some mob AI issues to work through with this one.
Fixed base automove and target validation.