Guild Wars 2

Hello everyone. The reason for this post is to make some suggestions for the information contained in the mumble link data, namely the Identity field.

I have two suggestions:

1. Changing the kinds of data stored in the Identity field.
2. Changing the format of the Identity field.

Additions and Removals in Current Implementation

Currently the identity field is in JSON format and looks like:
{
“name”: “John Doe”,
“profession”: 1,
“map_id”: 50,
“world_id”: 1006,
“team_color_id”: 9,
“commander”: true
}

What we’ve been given is pretty awesome already. However, I find myself wanting a bit more information about a player’s status.

Here are some of my suggestions for additional information to be included in the identity field:

• health (a 32-bit integer should work): health of character
• supply (a 32-bit unsigned integer): supply being carried by character
• in_combat (true or false)
• state (0 = up, 1 = downed, 2 = defeated)
• is_capturing (true or false): true if character is taking an objective, for example a capture point in PvP or a camp in WvW

My other suggestions are shown in the attached image. Note that items H through L are some pieces of information others might want to know.

Here are my suggestions for removal of redundant information from the identity field due to their inclusion in the context field:

• map_id
• world_id

Reformatting the Identity Field for Use in High Frequency Retrieval

Since the health, combat status, and state are things that could very well change quite frequently, I propose a new format for the identity field similar to the way the context field is defined: using set field lengths and byte offsets instead of a JSON string. The 512-byte identity field has a lot of room left to implement the new format.

This will allow developers to read data directly from the memory-mapped file instead of having to parse the JSON string prior to retrieving what they need. Also, character names are limited to 19 characters, so representing it as an array of 20 2-byte wchar_t’s (total of 40 bytes of data) should suffice.

Attached is my proposed layout. Let me know what you think!

Hm, depending on what high frequency is the target, one could think about just using another transport mechanism for those, e.g. a “GWLink”, to meet the requirement of rare updates set by Mumble.
Personally I prefer the context blob method over the JSON string.
The last char of the character name being a null char? Putting that there should avoid messing up the mumble default gui with the data which would be nice indeed.
I guess in_combat could be added to state, saving a byte.

struct identity {
   wchar_t name;
   int           team_color : 2;
   int           health            : 16;
   int           supply            : 6;
   int           profession     : 2;
   int           state                : 2;
   int           commander : 1;
   int           combat          : 1;
   int           capturing      : 1;
   int           instanced      : 1;
}

This would result in a total of 8 bytes for the whole structure. I removed a few of the attributes as I found them to be mostly unsusable like gathering (period is way to short) or dungeon which is more or less a duplicate of instanced. But of course all your fields could still be added which would add another 4 bytes due to byte alignment.

Given that there’s a lot of space left, from the perspective of a Teamspeak 3 plugin dev, I actually could make most use of having the groupmembers and commander name (replacing the bool in the progress?) if in a squad.
Think whispering to your group only etc. up to (if the ids play along) the option to talk to your team in single join tournaments if a server hosts that for a region. Hu, maybe that last one ain’t a good idea hehe.

From the former thread I think guild tag or name would be worth a honorable mention.

Wothor.4781:

Hm, depending on what high frequency is the target, one could think about just using another transport mechanism for those, e.g. a “GWLink”, to meet the requirement of rare updates set by Mumble.
Personally I prefer the context blob method over the JSON string.
The last char of the character name being a null char? Putting that there should avoid messing up the mumble default gui with the data which would be nice indeed.
I guess in_combat could be added to state, saving a byte.

Indeed it is actually desirable to change the Identity information from a string to a binary structure. The main reason for this being the frequency of the updates. Currently the Identity isn’t updated regularly however, the IsCommander field might be switched often enough to warrant this information as binary so that the JSON string isn’t parsed for each access or in some update thread.

CyFreeze.1275:

struct identity {
   wchar_t name;
   int           team_color : 2;
   int           health            : 16;
   int           supply            : 6;
   int           profession     : 2;
   int           state                : 2;
   int           commander : 1;
   int           combat          : 1;
   int           capturing      : 1;
   int           instanced      : 1;
}

This would result in a total of 8 bytes for the whole structure. I removed a few of the attributes as I found them to be mostly unusable like gathering (period is way to short) or dungeon which is more or less a duplicate of instanced. But of course all your fields could still be added which would add another 4 bytes due to byte alignment.

Agreed, this would be fine, assuming of course that the upper/lower bounds of the data are met. For example, aren’t there more than 4 professions?

Wothor.4781:

Hm, depending on what high frequency is the target, one could think about just using another transport mechanism for those, e.g. a “GWLink”, to meet the requirement of rare updates set by Mumble.
Personally I prefer the context blob method over the JSON string.
The last char of the character name being a null char? Putting that there should avoid messing up the mumble default gui with the data which would be nice indeed.
I guess in_combat could be added to state, saving a byte.

The “GWLink” would be nice, then ArenaNet wouldn’t be bound to the mumble link structure. Depends on if they want to implement one. Mumble link seems to take care of both cases: providing positional audio and additional info for developers. I’m torn on the issue because it would be really nice if they made one catering to developers specifically. Like all the extra stuff we want that is above and beyond the basic mumble requirements can be put in a GWLink memory-mapped file.

The last char of the character name is expected to be null char as well as making the name 4-byte aligned.

Good catch on combining in_combat and state. An enumeration for the state could look like this:
enum PlayerState
{
Up = 0,
Up_Combat = 1,
Downed = 2,
Downed_Combat = 3,
Defeated
};

I wouldn’t swear an oath that there’s an out of combat downed state, but yeah, sth. like that
If there ain’t I’d probably go
0: 00 not up, not incombat = dead
1: 01 not up, in combat = downed
2: 10 up, ooc
3: 11 up, ic
just in case, for the fun of it and have a couple of bits left for other bools.
But after all that’s details the devs will know best what they wanna do that.

Caldrick.6920:

CyFreeze.1275:

struct identity {
wchar_t name;
   int           team_color : 2;
   int           health            : 16;
   int           supply            : 6;
   int           profession     : 2;
   int           state                : 2;
   int           commander : 1;
   int           combat          : 1;
   int           capturing      : 1;
   int           instanced      : 1;
}

This would result in a total of 8 bytes for the whole structure. I removed a few of the attributes as I found them to be mostly unusable like gathering (period is way to short) or dungeon which is more or less a duplicate of instanced. But of course all your fields could still be added which would add another 4 bytes due to byte alignment.

Agreed, this would be fine, assuming of course that the upper/lower bounds of the data are met. For example, aren’t there more than 4 professions?

Team color is based on dye color. Since the highest Color ID is 1242, we would require 11 bits to hold that information. If more colors are added at a later date, might be best to round up to 2 bytes. As of now, Red Team uses Color ID 376: Salmon and Blue Team uses Color ID 9: Blue Rose (I haven’t figured out Green Team yet). So as far as I know, we would need 9 bits minimum to hold the Red Team Color ID.

Correct about profession. We would need at least 4 bits to hold that.

Max health I saw on the forums was ~70k, so 16 bits for health sounds right.

With Wothor.4781’s suggestions, the changes could look like:

struct identity {
   wchar_t    name[ 20 ];
   char           guild_id[ 16 ]; //guild_id looks like a 32-digit hexadecimal
   int              team_color   : 16;
   int              health            : 19; // EDIT: increased from 16 to 19
   int              supply            : 6;
   int              profession      : 8;
   int              state               : 4;
   int              commander  : 1;
   int              capturing       : 1;
   int              instanced       : 1;
}

63 bytes total out of 512 used. I think we might even be able to get that Squad info on here!

The update to the health was necessary I totally forgot about golem suits. Your max health in a golem is about 270k. So slightly more then 2^18. Good choice with the number. The rest seems to be appropriate too. Now that we have so much space left maybe some player identifiers would be nice so that we can get the whole party in there. I don’t think a squad could fit in there. But in the end that would require identifiers to be implemented first.

Since squads, unlike parties, do have a leader, the leader name/identifier would suffice (for me, at least).
Via character names that should total in (4+1)*40 = 200 bytes altogether isup.