Proposal for some MumbleLink-changes — Guild Wars 2 Forums
Home API Development

Proposal for some MumbleLink-changes

While the MumbleLink is pretty useful for people creating additional tools, its missing some useful stuff. I can kinda understand that ANet probably does't want to export too much stuff to not make it too easy for bot-devs but it would be nice if a few additional things could be exported:

  • account_uuid - the GUID of the currently logged in account (or the account-name)
  • commander_icon - 1 = blue, 2 = red, 3 = yellow, ... 32 = blue-catmander, 33 = red-catmander, .... 128 = default-mentor
  • mounted - true / false
  • mount_type - 1 = raptor, 2 = springer,.... 128 = player is using any kind of glider
  • minimap - array with the following elements: x/y/height/width/zoom/world_rect (coordinates of NW/SE corners of the displayed area on the world-map) - position of the minimap on the screen and position of the displayed area in the world
  • in_map - true / false - is true when the player opens the in-game map

And i should probably explain why i think certain thinks should be in the MumbleLink. So here we go:

  • account_uuid - pretty much everybody i know owns multiple gw2-accounts and providing the account-uuid (or the account-name) would make it easier for app-developers to automatically display data that is relevant to a certain account
  • commander_icon - has basically two purposes: the obvious one of being able to display the correct icon (for example on a site displaying which commanders are active in WvW, etc.) and to distinguish between a real commander and a mentor
  • mounted - obvious -> could be useful for something like the "Radial Mount Menu" to know if a player is currently sitting on a mount or not or could be used by people creating markerpacks to record when they are using a glider/mount
  • mount_type - similar to the commander_icon this serves two purposes - to know which mount somebody is using and to know if he is using a glider
  • minimap - exposing the postion of the map on-screen and what area it is showing would allow overlay-devs to display paths or other stuff on top of the map
  • in_map - the bane of all overlay-developers - it would be nice to know when the map is open so it would be easy to hide any overlay-stuff (( probably the minimap-data could be updated to contain the data for the big map when its open -> that way paths/markers/notices could be added to the big map, too))

And it would be nice if the current fileds like name/profession/race would be emptied when the player is in the character-selection screen. Right now, when you're in-game and return to the char-selection, these fields will contain the data for the last char you were playing with. that way, overlays could also kinda reliably detect the char-selection.

These changes would allow devs to enhance their existing apps (without breaking compatibility as the changes don't mess up any of the existing data) and probably allow completely new apps.


  • This is gonna be difficult. The context field inside the Mumble Link API can only contain 256 characters.

  • I am 1000% in favor of this kind of upgrade of MumbleLink, especially the mounted/mount_type and in_map data (for obvious reasons).

  • Tiscan.8345Tiscan.8345 Member ✭✭✭
    edited May 30, 2019

    @Archomeda.6472 said:
    This is gonna be difficult. The context field inside the Mumble Link API can only contain 256 characters.

    Oh, you're right. Lets see.

    The current data should take up 150 chars max


    which leaves us with 106 chars for additional stuff. Account-Name would be shorter than a UUID (32 vs 37 chars). If we shorten a few fieldnames and drop the minimap-idea (as IMHO its the least interesting information) we could use something like


    which would actually be 103 chars - kinda risky. We could still use uglier fieldnames


    bringing us down to 95.

    The only other ways I see would be abusing the description-field (and as i don't use Mumble, IDK if its displayed anywhere where it would be a pain if GW2 modifies it over and over again) or using non-descriptive field-names (a,ci,m,mi,im) to reduce the amount of data even further (to ~80 bytes).

    Changing the existing stuff is no option even if some field-names could be way shorter - but we don't wanna break any existing software.