Allow Support for Cross Zone Routes

[chanchiem]

Is your feature request related to a problem? Please describe.
Currently, all routes are only within the same zone and contains no assignment of zones for each path file. This is great for most use cases, but in cases where we need to go across zones (such as to go to areas that have higher level mobs), this requires manually stopping the bot and then moving to the location. This can be cumbersome especially for ideally zero-touch workflows.

Describe the solution you'd like
I can think of two solutions:

Solution 1

One is a path that is specifically used to move across zones. It can be in a similar format as paths except it will contain the named zone and the transitioning paths towards the next zones. Schema example:

{
	"Origin Zone": {
		"Name": "<name>",
		"Paths": ["<path coordinates>"]
	},
	"Destination Zone": {
		"Name": "<name>",
		"Paths": ["<path coordinates>"]
	}
}

Example dataset:

{
	"Origin Zone": {
		"Zone": "Elwyn Forest",
		"Paths": [{"X":46.241398,"Y":51.6652},{"X":46.179802,"Y":51.694496},{"X":46.111496,"Y":51.7239}]
	},
	"Destination Zone": {
		"Zone": "Westfall",
		"Paths": [{"X":27.6,"Y":72.993},{"X":27.411,"Y":73.22800000000001},{"X":27.168,"Y":73.441},{"X":26.912000000000003,"Y":73.604}] // Optional depending on if we want to load straight to next path
	}
}

And the algorithm will be as follows:

• Check that the current origin is the origin zone's name.
• Move the player to the beginning point of the first path point.
• Follow the point til the end of the point.
• Move Forward until the origin zone changes to the Destination Zone with a 10 second timeout
  • If the current zone never changes after the timeout, error out.
  • If the current zone changes to a different zone, error out.
• Once the zone is achieved, we can either follow to the paths of the destination zone paths, or go directly to the intended zone's path.
• This could then be configured with the existing Paths key, where if a certain level is reached, we can add a zone requirement + level and use those to determine we need to transition to a new zone.

Solution 2

An alternate solution would be to add an additional parameter to the existing paths schema to add named zones. And the paths themselves should automatically transition (using a variation of the top algorithm) to move between zones. When a large enough distance is detected on the path, then it will indicate a new zone transition.

Example Schema:

[
{"<ZoneName>": ["<paths>"]},
{"<ZoneName2>": ["<paths>"]},
]

Example Data:

[
{"Northshire": [...]},
{"Elwyn Forest": [...]},
]

The algorithm would be as follows:

• We assume the last item in each path is the last point for that zone before transitioning to the next zone. (Path recorder should be able to detect this easily)
• On the last path data point in each given zone, we move forward until the origin zone changes to the next zone.
  • Apply similar error handling as solution 1
• Once the origin zone changes, route a path to the first point of the next item in the path list. (Northshire -> Elwyn Forest)

Additional context
The second algorithm is likely more challenging to implement and it could be backwards compatible; if the keys in the point of each list is not "X" or "Y", then revert to simply using it as a simple path.

The first algorithm would be less coupled so it would be easier to implement.

[Xian55]

Gooday!

this requires manually stopping the bot and then moving to the location. This can be cumbersome especially for ideally zero-touch workflows.

To support unsupervised workflow there are many systems need to be developed to make it working.
It is far reaching goal. I would not say never, but it would take some time to achieve it.

As of now i have no interest embarking on such a journey. Feel free to contribute to that goal.

---

Thinking about the request i would rather introduce two breaking change to the current PathSettings

• When the local map(coordinates) based coordinates are used have to specify an identifier for the Zone(Name, Id). This way coordinates can be converted to world coordinates. Map coordinates can be easily identified as they are percentage values 0.0-100.0
• Allow to specify world coordinates based waypoints.

With these two addition in the navigation system i could make the necessary changes to only rely on world coordinates. Then cross zone movement would not be a problem.

Both pathfinding solution(v1 and v3) supports multi zone navigation with world coordinates.

Currently a hybrid approach is used, mostly due my laziness when i worked in supporting world coordinates, for player direction calculation still map coordinates used. Also most of the visible and saved coordinates are in map coordinates, easier to display on BlazorServer and easier to edit in the json.file.