whimxiqal
commented
1 year ago I see your use case, but I'd sooner do something a little different:
The algorithm is step-by-step outward from known points, and will generally go directly towards the destination. So, if you are next to the road, the algorithm may just continue along parallel to the road and never know that there was something faster just a few blocks over.
Rather, Journey could leverage the itinerary-level algorithm and let administrators/developers register complete "roads" that are basically just paths. They have known cells and known distances, so they're just stored in a structure similar to the cached paths and are used at the start of every search.
That way, the fastest itinerary might be one in which starts with a path that goes to the start of the intermediary "road" and ends with a path that starts at the end of the "road", and no long path is needed at all.
I've thought about this kind of thing for special "ice-boat" roads, minecart rail systems, etc
Administrators could use it by creating persistent "roads" through a tool that just tracks movement for a period of time.
Developers could use it by creating transient "roads" that just register whatever existing system imposes such paths from other plugins, although I'm not sure what kind of thing someone would be making to need that.
Idk about "road" as terminology, though. Maybe just "CustomPath"
Roads would be one or more patterns you could provide that tell Journey a specific path speeds you up.
For example, on a server I develop for you can gain a speed boost by putting copper slabs under any block, so if I were to register that setup as a road I would so something like:
registerRoadPattern(["*", "COPPER_SLAB"], 1.25) (list of materials, speed multiplier).The main issues I could see arising from this are: