[TG Mirror] Adds pathmaps, refactors pathfinding a bit [MDB IGNORE] #133
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…414) * Adds pathmaps, refactors pathfinding a bit (#78684) ## About The Pull Request Implements /datum/pathfind/sssp, which generates /datum/path_map /datum/path_maps allow us to very efficently generate paths to any turf they contain from their central point. We're effectively running the single source shortest paths algorithm. We expand from the center turf, adding turfs as they're found, and then processing them in order of addition. As we go, we remember what turf "found" us first. Reversing this chain gives us the shortest possible path from the center turf to any turf in its range (or the inverse). This isn't all that useful on its own, outside of a few niche cases (Like if we wanted to get the farthest reachable turf from the center) but if we could reuse the map more then once, we'd be able to swarm to/from a point very easily. Reuse is a bit troublesome, reqiures a timeout system and a way to compare different movables trying to get paths. I've implemented it tho. I've refactored CanAStarPass to take a datum, /datum/can_pass_info. This is built from a movable and a list of access, and copies all the properties that would impact pathfinding over onto itself. There is one case where we don't do this, pathing over openspace requires checking if we'd fall through the openspace, and the proc for that takes an atom. So instead we use the weakref to the owner that we hold onto, and hold copies of all the values that would impact the check on the datum. When someone requests a swarmed path their pass info is compared with the pass info of all other path_maps centered on their target turf. If it matches and their requested timeout isn't too short, we just reuse the map. Timeout is a tricky thing because the longer a map exists the more out of date it gets. I've added a few age defines that let you modulate your level of risk here. We default to only allowing maps that are currently being generated, or finished generating in our tick. Hopefully this prevents falling into trouble, but consumers will need to allow "failed" movements. As a part of this datumized pass info, I've refactored pathfinding to use access lists, rather then id cards directly. This also avoids some dumbass harddel oppertunities, and prevents an idcard from changing mid path. Did a few things to the zPass procs, they took args that they did NOT need, and I thought it'd be better to yeet em. If you'd all like I could undo the caching/can_pass_info stuff if you'd all like. I think it's useful generally because it avoids stuff changing mid pathfind attempt, but if it's too clunky I could nuke it. Oh also I added optional args to jps that constricts how it handles diagonals. I've used this to fix bot paths. ## Why It's Good For The Game Much of this is redundant currently. I'm adding it because it could have saved hugglebippers, and because I get the feeling it'll be useful for "grouping" mobs like bees and such. We're doing more basic mob work currently and I want to provide extra tools for that work. https://github.com/tgstation/tgstation/assets/58055496/66aca1f9-c6e7-4173-9c38-c40516d6d853 ## Changelog 🆑 add: Adds swarmed pathfinding, trading accuracy for potential optimization of used correctly fix: Bots will no longer take diagonal paths, preventing weirdo looking path visuals refactor: Refactored bits of pathfinding code, hopefully easier to add new pathfinding strategies now /🆑 * Adds pathmaps, refactors pathfinding a bit --------- Co-authored-by: LemonInTheDark <[email protected]>
Iajret
pushed a commit
that referenced
this pull request
Dec 28, 2023
* Reverts Canister Wiring (#80265) (#80607) ## About The Pull Request Reverts #80265 It's a cool idea, but the ability to toggle valves/control pressure make this just a ttv but without the access issues we tie to that. Eats into that space way too much. Removing those but not the rest results in disappointment, so I'm just full removing this. I am keeping the code quality changes, screentips, that sort of thing tho. That bit goes hard. Also, refactored a few procs slightly to make them easier to read. Early returns, sane loops, etc. ## Why It's Good For The Game Closes #80604 Cheap remote mass producible maxcaps are a bad idea actually Sorry I didn't catch this in review, been resting for the week ## Changelog :cl: del: Removes the wires from canisters. It's a cool idea, but cheap controlled maxcaps are bad actually /:cl: * Reverts Canister Wiring (#80265) --------- Co-authored-by: LemonInTheDark <[email protected]> Co-authored-by: NovaBot <[email protected]> Co-authored-by: Bloop <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mirrored on Skyrat: Skyrat-SS13/Skyrat-tg#24414
Original PR: tgstation/tgstation#78684
About The Pull Request
Implements /datum/pathfind/sssp, which generates /datum/path_map
/datum/path_maps allow us to very efficently generate paths to any turf they contain from their central point.
We're effectively running the single source shortest paths algorithm.
We expand from the center turf, adding turfs as they're found, and then processing them in order of addition.
As we go, we remember what turf "found" us first. Reversing this chain gives us the shortest possible path from the center turf to any turf in its range (or the inverse).
This isn't all that useful on its own, outside of a few niche cases (Like if we wanted to get the farthest reachable turf from the center) but if we could reuse the map more then once, we'd be able to swarm to/from a point very easily.
Reuse is a bit troublesome, reqiures a timeout system and a way to compare different movables trying to get paths.
I've implemented it tho. I've refactored CanAStarPass to take a datum, /datum/can_pass_info. This is built from a movable and a list of access, and copies all the properties that would impact pathfinding over onto itself.
There is one case where we don't do this, pathing over openspace requires checking if we'd fall through the openspace, and the proc for that takes an atom.
So instead we use the weakref to the owner that we hold onto, and hold copies of all the values that would impact the check on the datum.
When someone requests a swarmed path their pass info is compared with the pass info of all other path_maps centered on their target turf. If it matches and their requested timeout isn't too short, we just reuse the map.
Timeout is a tricky thing because the longer a map exists the more out of date it gets.
I've added a few age defines that let you modulate your level of risk here. We default to only allowing maps that are currently
being generated, or finished generating in our tick.
Hopefully this prevents falling into trouble, but consumers will need to allow "failed" movements.
As a part of this datumized pass info, I've refactored pathfinding to use access lists, rather then id cards directly. This also avoids some dumbass harddel oppertunities, and prevents an idcard from changing mid path.
Did a few things to the zPass procs, they took args that they did NOT need, and I thought it'd be better to yeet em.
If you'd all like I could undo the caching/can_pass_info stuff if you'd all like. I think it's useful generally because it avoids stuff changing mid pathfind attempt, but if it's too clunky I could nuke it.
Oh also I added optional args to jps that constricts how it handles diagonals. I've used this to fix bot paths.
Why It's Good For The Game
Much of this is redundant currently. I'm adding it because it could have saved hugglebippers, and because I get the feeling it'll be useful for "grouping" mobs like bees and such.
We're doing more basic mob work currently and I want to provide extra tools for that work.
2023-09-29.16-58-07.mp4
Changelog
🆑
add: Adds swarmed pathfinding, trading accuracy for potential optimization of used correctly
fix: Bots will no longer take diagonal paths, preventing weirdo looking path visuals
refactor: Refactored bits of pathfinding code, hopefully easier to add new pathfinding strategies now
/🆑