(edited by Talus.1402)
Showing Posts For Talus.1402:
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
};
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:
- Changing the kinds of data stored in the Identity field.
- 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!
When making the call https://api.guildwars2.com/v1/files.json I receive the following response:
{"map_complete":{"file_id":528724,“signature”:"5A4E663071250EC72668C09E3C082E595A380BF7"},
“map_dungeon”:{"file_id":102478,“signature”:"943538394A94A491C8632FBEF6203C2013443555"},
“map_heart_empty”:{"file_id":102440,“signature”:"09ACBA53B7412CC3C76E7FEF39929843C20CB0E4"},
“map_heart_full”:{"file_id":102439,“signature”:"B3DEEC72BBEF0C6FC6FEF835A0E275FCB1151BB7"},
“map_node_harvesting”:{"file_id":157332,“signature”:"995534EBE5D26804AE605E205E50539821C0CBCB"},
“map_node_logging”:{"file_id":157333,“signature”:"FC01BB452D5327A0E5B2E4A3F5EFDF03F8264A7B"},
“map_node_mining”:{"file_id":157334,“signature”:"A89EB66C39C7C006A4A6CBEDA28061F16847E9BC"},
“map_poi”:{"file_id":97461,“signature”:"25B230711176AB5728E86F5FC5F0BFAE48B32F6E"},
“map_special_event”:{"file_id":502087,“signature”:"1273C427032320DDDB63062C140E72DCB0D9B411"},
“map_story”:{"file_id":102369,“signature”:"540BA9BB6662A5154BD13306A1AEAD6219F95361"},
“map_waypoint”:{"file_id":157353,“signature”:"32633AF8ADEA696A1EF56D3AE32D617B10D3AC57"},
“map_waypoint_contested”:{"file_id":102349,“signature”:"5EF051273B40CFAC4AEA6C1F1D0DA612C1B0776C"},
“map_waypoint_hover”:{"file_id":157354,“signature”:"95CE3F6B0502232AD90034E4B7CE6E5B0FD3CC5F"},
“map_waypoint_hover”:{"file_id":157354,“signature”:"95CE3F6B0502232AD90034E4B7CE6E5B0FD3CC5F"}}
You’ll notice two entries for “map_waypoint_hover” with exactly the same signature and file_id on the last few lines of the response. Not sure how much this breaks anyone’s code, but heads up!