Open agaertner opened 2 years ago
Fundamentally, I agree that this is a very useful feature to have but I'm not happy with the proposed structure for two reasons:
context
are used by Mumble to ensure that positional audio is delivered to the appropriate users. Adding additional fields here that are not constant within a map such as a sector ID breaks positional audio. Additionally, adding fields in the middle of the struct will break all existing MumbleLink reading tools for GW2. To retain compatibility and to not break positional audio, all fields should be added at the end of the struct.context
struct has a 256 byte limit. While adding things like continentId
is useful for developers as you demonstrated, I'd rather preserve as much of the free space as possible for future additions. Since continentId
and regionId
can be trivially inferred from the API, I propose only adding floorId
and sectorId
to the context. (Technically, sectorId
can be calculated as well, but it can be fairly tricky since sectors can be arbitrary polygons.)Good point. Initially this was about floorId and sectorId anyway. I've put them around mapId to just highlight the hierarchy for the example. Definitely add them to the end.
Add use case
- Conviniently trigger a request of sector constrained data from a backend. ( "paginating" map constrained data.)
Feature Description
Add
floorId
and/orsectorId
to the mumble link context struct supporting and reducing queries to the very complex v2/continents endpoint.As discussed in PR #2 of the official API repo floor ids from the API differ per map and are arbitrary! We do not have enough information about the player's coordinates to calculate the current floor. Current floor detection is impossible and thus current sector detection by any means (eg. R-tree) BREAKS on maps with sectors lying ontop of each other.
Possible use-cases for having floorId and/or sectorId in mumble is
Implementation
The context struct may be adapted like so:
Example
Example of v2/continents endpoint as reference of how quickly it becomes messy:
becomes
Anything else?
Ref: original PR#673