ID:1534240
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
With the step_to() pathfinding I would like an ignore_objs argument so that it does not consider dense obj's as obstacles in the path.

It would only consider dense turfs. Because in my game people can fly over dense obj's or punch them to destroy them and get past, but dense wall turfs are still an obstacle.

This would also reduce cpu usage for those that don't need to consider obj
Customizing pathfinding is not a simple task. I think ignoring objs would be way too specific, so customization would never be considered in that form. Also I doubt CPU usage would drop by very much.

What I would consider would be some way to call Cross() and/or Uncross() during the pathfinding, but that could potentially be slow; luckily the number of items condidered for the calls would be fairly low, but then it'd almost be imperative to store the path somewhere and possibly adapt to changes. Storing paths for the short term wouldn't be such an awful idea anyway of course, as it'd more drastically reduce CPU load in situations that do very heavy pathfinding.
A poorly method would be step_towards() and then check if they are in the same location or not, if they are, call step_to() to make them correct their path.

Just a work around.
@Lummox: Maybe just implement a BD-Astar approach to slim down existing pathing a bit, and build in two new functions with an argument failure distance we can pass in. Rather than walking the mob along the path, why not return the path via a list of turfs? Allow us to handle our own pathing AI, while allowing the engine to do the grunt work of actually performing the search?

This gives us the best of both worlds: Built-in speed and handrolled limited customization.