-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor map::route to extract (some) cost functions #74373
Conversation
Can I bring this to your attention? #74200 (comment) As in, "some pathfinding may currently be broken". You can see that in the example video the omniscient player pathing still manages to run into a trap, somehow. (Also the beartrap does not stop them, which is in itself a problem). I am not saying this is in scope for your changes. I am just trying to provide some information that may help your decision making. |
Hm, I wasn't able to reproduce that in my testing. Would you be able to provide a save so I can make sure I'm testing exactly the same thing? |
Due to the various testing shenanigans I was getting up to, the trap will error on load unless you also load the trap definition from #74200's original post. Note that the trap function was replaced with |
Summary
None
Purpose of change
map::route does a lot, and a lot of it is shared logic that is inconsistent
with other places (e.g. monster::know_danger_at). This is a first step toward
refactoring that shared logic into a common function.
Describe the solution
I extracted two functions from map::route:
cost_to_pass
andcost_to_avoid
.cost_to_pass
is responsible for calculating the difficulty of navigating theterrain, e.g. by climbing, bashing, or opening doors, or deciding that it's not
navigable.
cost_to_avoid
is responsible for calculating the danger ofnavigating the terrain, e.g. if there's a trap present. The reason there are
two functions instead of one is that they are additive: some terrain might be
difficult to pass and have a trap present. Splitting them simplifies the
logic in each.
In future I'd like to add logic for avoiding dangerous fields into
cost_to_avoid
, but I've kept the logic unchanged for this refactor to makethings easier to review.
Describe alternatives you've considered
Testing
Tested player and NPC pathing around caltrops and ledges. Both seem to work
correctly, avoiding when possible but walking through them when necessary.
That's definitely not an exhaustive test, but it's indicative that things
aren't totally broken!
Additional context