[MumbleLink] Aknowledging the v2/continents subendpoints and customized-soundtrack-system states. — Guild Wars 2 Forums
Home API Development

[MumbleLink] Aknowledging the v2/continents subendpoints and customized-soundtrack-system states.

Nekres.1038Nekres.1038 Member ✭✭
edited January 6, 2021 in API Development

Dear ArenaNet,

I would like to request specific information exposed via the Mumble Link API.

I know that we already use a lot of space in there but as discussed there is still much room for more information in the extended context.
Previously I requested some states from the customized soundtrack system (Ref.: https://wiki.guildwars2.com/wiki/Customized_soundtrack ) to be exposed that would help with seamless overlay development and popular marker and path helper tools:

  • Victory ~
  • Downed $
  • Defeated ~$
  • MainMenu ~ - Possible by setting the value on detecting a log-out event and before mumble goes inactive. Aknowledged limitation: Has to go from in-game to MainMenu..
  • BossBattle ~

~ = As seen used by the customized soundtrack system.
$ = A well known and highly popular (and tolerated) third party addon exposes it already for other developers to use.

I would like to still expand on that with information that would improve readability of the continents API endpoint and its very complex subresources.

Ref.: https://wiki.guildwars2.com/wiki/API:2/continents

The information I would like to see are ids relevant to the map id that is already exposed:

  • continentId
  • regionId
  • floorId
  • sectorId

Most importantly I'd like to explain why I would want the floor id. Floor ids are arbitrary values that do not just depend on height of the player and differ per map (i.e. floor 1 on Queensdale can be different compared to floor 1 on another map.). They cannot be calculated and it makes it difficult to distinguish between sectors given the subresource found under the continents endpoint and impossible on non-flat maps for the reasons explained earlier.
Knowing the sector could save resources and performance for marker and path systems and augmented stuff.

On the other hand giving the sector id directly would reduce queries as one does not need to query the floors first to get a specific sector object. Same goes for the continent id.
So because there aren't many more sizes to a maps context (continent > region > map> floor > sector) I request that you consider - if you look at the complexity of the "continents" subendpoints - that it makes sense to just expose all four of above ids - while we are at exposing the most important of them that is floor - to improve access to the very complex continents endpoint.

Furthermore, it was stated that the API nor MumbleLink exposes enough data to detect the current floor which means that the continents endpoint and a large portion of its data contained in subresources is in fact useless for augmented overlay developers that rely on MumbleLink. A pity because it would open up huge space for improvements in regards to performance and resource handling.
Ref.: https://github.com/arenanet/api-cdi/pull/2 (Highlighted statement: https://i.imgur.com/nAdaOSD.png)

Thank you.

Best Regards,


  • Orih.5210Orih.5210 Member ✭✭
    edited January 4, 2021

    All 3 ids requierd for a spefic output from the contients subpoint are given in the Maps Subpoint where u just need the map id what u get from the Mumblelink https://wiki.guildwars2.com/wiki/API:2/maps

  • Nekres.1038Nekres.1038 Member ✭✭
    edited January 6, 2021

    Floor ids are completely arbitrary and differ per map. Current floor detection is impossible and thus current sector detection BREAKS on maps with sectors lying ontop of each other.
    Another thing mentioned is reducing overall queries to said endpoint. Given sector id directly would also improve it as you don't have to query for floor to get the current sector (if given floor id). For said endpoint it makes sense to just throw all four ids in there, especially floor.

    Sector detection on a flat map: https://gfycat.com/CompetentReadyGilamonster
    This would not work flawlessly on - for example - Verdant Brink with sectors being ontop of each other as there is no way of calculating a floor.

    Floor is the most important out of the four but because it makes little sense to not include all four while we are at it(!) I listed them all four. This would give us the complete hierarchy of IDs of a maps context from biggest to smallest.

    continent > region > map > floor > sector.

    Perfectly suited for any of said complex subresources of the continents endpoint such as:

    And little extra weight on the overall size of Mumble Link since we are only dealing with those ids.