Guild Wars 2

Teranas.6150:

I have not tested if the Guild Wars 2 OAuth server really supports response_type=token (it has to, based on the RFC.) Did anyone tried this?

We do not support the implicit grant flow — we want clients (e.g., OAuth2 implementations) to be authenticated.

Nabrok.9023:

While we’re talking about timers … how about the time of the next score tick?

Yeah, that’d be really useful too.

I really need to sit down and draft an initial proposal for the /v2/wvw endpoints.

Nabrok.9023:

That would be great, but I agree that the authenticated endpoints are more important. I unleashed my app on the world today and it seems to have been well received. If you happen to play on TC you’ll see it in action if you use the server voice comms.

That is awesome. Are you guys using Mumble or TS?

I Am Dansker.7105:

Lawton Campbell.8517:

Nabrok.9023:

Lawton Campbell.8517:

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Not yet, but it’s something I wanted to add into the /v2/account response. Since OAuth2 tokens can last indefinitely if you include the “offline” scope, I didn’t want any end-users to be surprised when that suddenly appeared.

Any expected ETA on when this will be made available?

Shooting for a couple of weeks at most, might slip on that though.

Qwertasy The Amazon.2906:

So in short: what is 49:1014:8008:353 and/or how can I avoid getting it.

That error code is “permission denied” and, by my reading, is only hit when the redirect_uri supplied does not match one in the application’s list of redirect_uris.

If you PM me the entire request where the error is returned (without redactions) I might be able to provide further insight.

EDIT: Note that you need to include redirect_uri both in requests to /oauth2/authorize and /oauth2/token; the value passed to each pair of requests must be the same (and in the application’s whitelist).

Eastborn.6089:

Lawton Campbell.8517:

I’m seeing CORS headers.

Also for the options request that browsers request before a get?

Response

hide spoiler

Remote Address:64.25.47.16:443
Request URL:https://api.guildwars2.com/v2/account?_=1427309039459
Request Method:OPTIONS
Status Code:404 Not Found
Content-Length:253
Date:Wed, 25 Mar 2015 18:45:41 GMT
Server:Microsoft-IIS/7.5

We only currently support simple requests which don’t require a preceding OPTIONS. This is unlikely to change in the near future.

Nabrok.9023:

Bloodlust doesn’t appear to be a part of the new map? So I guess that part would not be useful anymore … at least until we see how you plan on reusing alpine.

You know as much as I do at this point, I’ve read on reddit there’ll be some kind of rotation? So it makes sense to ensure that the format works for both the new and old maps.

The new map has some kind of timed event thing; it’d be really nice to include the timer in the response as well so the countdown could be displayed.

Nabrok.9023:

Honestly, I’m not looking forward to grabbing the icons (I still haven’t updated mine from the old blue color) and figuring out co-ordinates for all the objectives again. Any chance that stuff could at least be documented, if not part of the API itself?

I want the objective coordinates to one day be in the API. I really want to gut how the WvW endpoints work and make the /v2/wvw endpoints much more usable, but the authenticated endpoints are currently eating up all my time.

Nabrok.9023:

Oh … as sentries are gonna get a buff and become more important, any chance those could be added to the API?

IMO the sentry status would be really nice to see, whether or not they get a buff.

Qwertasy The Amazon.2906:

If I don’t send the redirect_uri this is what I get

You must send a redirect_uri in the /oauth2/token request.

Qwertasy The Amazon.2906:

But what I also found out is that if I send ‘redirect_uri=’ (so no value) this is the response

I’m guessing that the redirect_uri you’re sending is not configured on your application’s list of redirect_uris (which is a newline-delimited list). That’s the only thing I’m seeing that would cause that error code.

Eastborn.6089:

Is it possible that the v2/account endpoint does not have CORS headers set?

I’m seeing CORS headers.

Not sure, been flailing around trying to get the authenticated APIs out and working. If there are any changes, we’ll post them in the CDI Github Repo with a “Breaking Change” tag.

I suspect that we’ll be adding more stuff to /v2/wvw/objectives and put map IDs or something into /v2/wvw/matches so you can display the correct map (EDIT: err, maybe s/v2/v1/; I am posting pre-coffee)

Nabrok.9023:

Lawton Campbell.8517:

Nabrok.9023:

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Should be fixed now

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Not yet, but it’s something I wanted to add into the /v2/account response. Since OAuth2 tokens can last indefinitely if you include the “offline” scope, I didn’t want any end-users to be surprised when that suddenly appeared.

Nabrok.9023:

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Should be fixed now

Okay, the ErrBadData stuff should be fixed now. One of the backend servers didn’t get updated with the most recent hotfix and was early-outing because the account data was from a more recent build. Sorry about that!

Remfin.4892:

Is there a delay for your permissions-granted showing up, or is that bugged?

Uhh, what do you mean? Does the token returned from /oauth2/token not work immediately? The token should be fully working when we return it :<

Divine Don.9752:

Anyone else getting this type of response?

{ statusCode: 400,
data: ‘{"error":“invalid_grant”,“error_description”:“Grant is expired or revoked”,“text”:"ErrSessionNotFound"}’ }

Above is what I get running the nodeJS example

That can be caused either by attempting to use the same grant more than once, or by waiting more than a few minutes to pass the grant code to /oauth2/token (or it could be a bug in our backend). Not sure which is happening.

Does the auth-go example exhibit the same issue?

Not currently, no. It’s something I want to do in the future, but probably won’t happen for awhile.

TranquilInSpirit.6291:

Is there an API IRC or other form of communication?

There might be an IRC channel or two that other API consumers use, but I personally only use the forums and Github.

I Am Dansker.7105:

Is the world id updated as soon as someone change server/world? or is it updated once a week with WvW reset?

It’s more-or-less as soon as someone changes server/world (there’s some delay due to cache coherency issues). I’ll look into what we can provide as far as server loyalty goes (e.g., so you can tell they switched just before/during the matchup).

AlterForm.7045:

Getting the same unhelpful “internal error” response, which is doubly unhelpful in that the response code is actually 400 so I’m not sure if it’s an actual internal error or some problem on my side.

As a guess, are you sending cookies to /oauth2/token? That might cause some confusion on our end. I’ll have to look up the error code on Monday and see what it turns up.

AlterForm.7045:

Messing with the request parameters some more I can produce

{
    "error": "internal_error",
    "error_description": "10:1014:8039:171 - NetAdjOAuth: missing or invalid user id"
}

.
when I send a “code” parameter of “a”. Munging any of the other parameters results in the same unhelpful error_description as above.

This is expected — the code we send is an OAuth2 grant identifier — which is basically the account GUID concatenated with a randomly-generated unique ID. You’re sending something that doesn’t match the format, so it aborts before even looking up to see whether or not the request is valid. The error_description there could probably be made a bit more clear though.

Also note that since this is kind of a BETA, the application page link will not show up on the account sidebar (outside of the applications page) — you have to manually navigate to “/account/applications” to access it. We still have a handful of issues to sort out before making it more widely-visible.

Pat Cavit.9234:

Sytherek.7689:

Pat Cavit.9234:

In the end you, the user, are responsible for determining who gets access to your data. If you don’t like what they do with it revoke their access.

We just provide a safe, standardized way to authenticate and say “Yes, App <XYZ> can read parts of my private data.”

I assume character data is private unless explicitly made visible by the account holder to specific web sites.

Yes, anything not available on the public APIs is private until the user explicitly gives an application access to it.

Which, to clarify, is everything that involves information associated with your account.

ItIsFinished.9462:

Lawton Campbell.8517:

It’s definitely something I’m working on. If you’re technically-minded, there’s a pull request on Github that details our plans for the initial release of an API endpoint that will allow the creation of sites that can access your character data.

What kind of time frame are you looking at before we see any kind of release?

As a non-committal estimate, late March – early April?

It’s definitely something I’m working on. If you’re technically-minded, there’s a pull request on Github that details our plans for the initial release of an API endpoint that will allow the creation of sites that can access your character data.

Illconceived Was Na.9781:

Dr Ishmael.9685:

You’re reading too much into how the wiki treats the MF recipes.

Therefore, I again urge ANet to change the design decision and to publish standardized MF outputs via the API, so that they are more universally available to the community as a whole.

How would you feel about an API endpoint that effectively was just a wrapper around the wiki’s semantic search?

I’m standing by my guns on not automatically revealing new recipes upon or after discovery. In my opinion, the discovery process is for Bartle’s spades and the only reward is temporary control over the use of the discovered recipe. An API, even with an arbitrary delay, would severely hamper the incentives behind the forge puzzles.

In this particular case, /v2/items is lagging behind because we’ve added a manual verification step to the item whitelisting process. This is a (hopefully) temporary workaround until I figure out why items like this sometimes get whitelisted and how to prevent that from happening.

Wilz.8461:

• Would it be possible to have the list of ingredients on items that can be crafted, even Mystic forge recipes like legendaries or exotic weapons (i.e infinite light, mjolnir, etc…) ?
  This information is on the wiki but not in the API.

Not in the forseeable future. Refer to this thread.

Wilz.8461:

• afaik, the vendor price when selling the item is included in /v2/items but not the vendor price when buying the item (if buyable from the vendor)

There are some technical difficulties that prevent this from being feasible. More discussion in this thread.

That’s a good idea; I’ll put it on my backlog.

Pat Cavit.9234:

Nabrok.9023:

Any news on this yet?

Those went in yesterday so barring any other excitement hopefully will be shipped next week.

We slipped on this release date (PAX and Rezzed are exciting); gonna try again next week.

Dr Ishmael.9685:

TranquilInSpirit.6291:

Lawton Campbell.8517:

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Would their profession fall under immutable (assuming it’s accessible)? If that could work, maybe doing something with the character’s creation date could mix with that to make some form of ID.

Account ID + character creation time would work

I’ll have to dig creation date up and throw it into the character blob — that should be in there regardless.

I’ve also been toying with the idea of exposing SHA1(character-guid ++ salt) as another alternative. Not sure how much I like that approach (has some minor issues on the backend w.r.t. resolution back to character-guid), but it seems like a somewhat reasonable workaround.

I haven’t looked at it, but I’m pretty sure it’s going to be on Tyria (e.g., id 1). The continents are basically completely separate maps (e.g., check the world map when you’re in Heart of the Mists), and Maguuma is already on the Tyrian world map.

Just finished an initial writeup of the /v2/characters endpoint.

Not currently, no. Though it’s something that’s being worked on, it’ll be a month or two until it’s ready to use. There might be third-party sites that provide such an API, but I don’t know of any

Currently, no. Eventually, yes. See this PR for the proposed endpoint details.

Nabrok.9023:

Lawton Campbell.8517:

Refresh tokens are valid until either the user explicitly revokes them via the management UI or you consume them to get a new access/refresh token pair. The access token should only be valid for a day.

In my testing I was able to use the same refresh token repeatedly.

Hmm, yeah, I was just confused. Our implementation does not regenerate refresh_tokens and they should not expire until the user explicitly revokes them.

aRestless.6213:

Sorry for two posts in a row, but I just noticed another thing that’s missing in the identity field, and that’s the race. The profession is already included, but the race is not.

Oof, that’s a good point. I’ll try to slip that in.

Nabrok.9023:

I believe the spec calls for an “expires_in” field which is provided in seconds.

Yup, it’ll be in seconds once it’s added in.

Remfin.4892:

Lawton Campbell.8517:

I Am Dansker.7105:

How long does the access token and refresh token last before they expire?

I wanna say … a day?

Both tokens are a day, or the access token? Because the refresh token isn’t very useful if it expires at the same time

Refresh tokens are valid until either the user explicitly revokes them via the management UI or you consume them to get a new access/refresh token pair. The access token should only be valid for a day.

I Am Dansker.7105:

How long does the access token and refresh token last before they expire?

I wanna say … a day?

Nabrok.9023:

Yes, could we get “expires_in” included with the access/refresh token response please?

Will definitely look into adding that.

I think an okay heuristic for now is to request the “offline” scope and use the refresh token if your access token is a few hours stale. I’m not sure what the turnaround time for getting expires_in on that endpoint is going to look like.

rodadams.5963:

https://github.com/arenanet/api-cdi/commit/c0aa094cebd52d1c9ce5040825be900e011ec3d9
Bank:

• Transmuted to a new skin?
• Is soulbound/account bound? (can change from base item)
• If soulbound, to whom?
• Uses left on harvesting tools/salvage kit.
• If armor, is damaged/broken?

IIRC, transmuted skins and charges show up (I’ll update the PR with the serializations). Binding and armor damage does not, and likely will not for the initial release. I’ll thread those through the pipeline and add them in later.

rodadams.5963:

https://github.com/arenanet/api-cdi/commit/5fe9d1470f54e7fcbeb36c2c635217f55aa1ec7b
Commerce:

• You have created timestamp, how about filled?
• Any tracking for cancelled orders?
• Have the gold/items been collected? (should I log in to grab my fat loot?)
• Perhaps walk through what we’d see if we post a buy order for 250 ecto, 150 fill in various sized batches, and we then cancel the remaining order of 100.

Filled dates are in there, I’ll update the PR with the serialization. Cancelled orders are, IIRC, deleted wholly by the trade engine so there’s no way to get any record of them on my side (you’d have to track that on the application side). Pending gold/items work through a separate system that we currently have no insight into, so that’s not going to make it for the initial pass.

I’ll create the walkthrough you requested on Monday.

rodadams.5963:

https://github.com/arenanet/api-cdi/commit/7224da8e3c930f9635a902ce9f2592b34fb038b9
Skills:

• Without information like cooldown, aftercast, damage, boons, conditions, target type, number of targets, range, etc. the utility of this endpoint will be very limited.
• Will ‘categories’ be canonical in determining which traits can mutate it? I could see Phantasmal Berserker have several categories to support trait processing: “phantasm”, “illusion”, “greatsword”. Having the client build this list from “weapon_type” and a hierarchy of categories seems expensive and error prone. Exactly what does the Shrapnel trait apply to again?

I’m intentionally omitting any skill attributes which can be modified by traits for exactly the reasons you mentioned — it needs to be clear exactly how traits modify skills. I have a couple of different serializations in mind, but want to hold off for a bit on posting them (too many other pots on the stove).

Rest assured, I want the returned data to be clear both ways — a skill should indicate that “trait 45 increases range to 1200” and the corresponding trait should indicate that it “modifies skills 14, 42 and 45”.

rodadams.5963:

How far down your list is /v2/account/wallet?

Not terribly far.

rodadams.5963:

Will I have a server side portal to review and revoke security tokens?

Yes.

Remfin.4892:

Is there really a reason it needs to be in the Mumble data? Conceptually there’s nothing stopping you from making your own “MumbleLinkGW2Ext” memory-map for that kind of non-standard Mumble data…

I know it’s non-optimal, but if you’re really worried about breaking compatibility it’s an option. The primary reason for having it in the Mumble location (so it works in Mumble) has already been achieved with the data that’s there

Conceptually, I completely agree with you. Practically, I don’t forsee adding enough additional functionality to warrant another transport that relays almost entirely the same data. If there’s reams of other fields that you’d like (and I can reasonably expose), then it’s definitely something to look into. But for just FOV it’s really hard to justify the expense, if you will.

The other important point is that, because the mumble link is an existing interface, a modification to it will arrive much sooner than a brand new largely untested one (though it’s more an issue of me being unfamiliar with the client codebase).

In any case, I’m open for debate on this, either here or on the corresponding Github issue.

draos.9574:

After the definition of the identity field in the mumble data the field can store 256 wchar_t which means 512 bytes.

That’s not really how it works. Yes, it’s 512 bytes, but with the current encoding that’s only enough for 256 JSON characters. We’re currently using about ~110 of them, and adding FOV would only cost up to an additional 30, so it’s not the end of the world.

draos.9574:

One other option could be to replace the JSON inside the identity for more data and simply memcpy the bytes into the identity field. This would create some problems with older programs but can store more data and could be faster to read and write.

Yes, but at that point there’s no reason to use the Mumble link format since … it won’t really work with Mumble anymore. I’m fairly unwilling to break compatibility with existing programs — which is a bit of a nightmare since I’m currently not familiar with any that use this API.

In any case, I don’t see any better place to put it and really don’t foresee having a better interface for it. I’ll put a PR on Github for anyone to raise objections on, otherwise it’ll go in.

Pat Cavit.9234:

Lawton found the cause. He’s chatting with some folks about how to a) fix it and b) prevent it from breaking like this in the future.

Quick reminder…

Pat Cavit.9234:

This is considered BETA-quality at the moment

The error should now be resolved. Sorry about that.

I would argue that the identity field is also the wrong place for it, but there’s literally no where else to put the data within the Mumble link API (somewhat related: does anyone know what the description field is used for? Can we co-opt that for additional machine-readable data? EDIT: looks like it’s used for the plugin description string, not really usable).

Can you explicitly lay out all the fields you need? Is it just FOV? The identity field is limited to something crazy small and I’m worried that we don’t have much of the 256B left.

Bugabuga.9721:

For guild-related things probably better to keep both list of guilds and currently represented one (basically “which guilds character is in” and “right now represented blah”).

This way an overlay can show all guild activities at once (i.e. “Guild A is doing rush” “Guild B activated +5 transport buff” etc)

The currently represented one is stored per-character in the character data, so I was going to put it in /v2/characters rather than /v2/account.

Nabrok.9023:

I think this kind of thing (exporting chat/combat logs) should be handled directly by the client.

Either a real-time stream or a slash command to save the log.

Yeah, the client has a wealth of data available to it that we don’t; I’m not even sure how we’d go about exposing that (or what the process for getting it implemented would be). While it’s definitely something I’d like to expose, it’s realistically not going to be in any time soon :/

Nabrok.9023:

Would /v2/characters expose everything that we currently see in the character select screen?

That would be …

• Order most recently played
• Level/Race/Class
• Represented guild
• % Map Completion
• Last location
• World (presumably for if a character is guesting? Not sure, I never really guest)

It would be useful to me to see which guilds an account belong to, having the guilds each character is representing may not give a full list but it would be something I could work with.

I’ve also had some ideas about how I could use the name of the character they are currently playing, and order of most recent play would achieve that.

I haven’t written up the RFC for /v2/characters (should probably do that today so we can get some eyes on it), but briefly — no order, yes level/race/class, probably rep’d guild, no % map completion, no last location, no last guested. There’s a bunch of other stuff in there like current equipment, inventory items, etc., that’ll make it useful at first for some applications.

This doesn’t preclude those features from ever being added, they just aren’t attributes that are currently pulled out of the character data on our side yet (and it takes awhile to make and deploy changes to the code that parses character data, unfortunately).

EDIT: In addition to recently played, time played per character would be nice as well (also perhaps deaths, heh).

aRestless.6213:

Due to the current Overwolf App Contest… is there a (rough) ETA or priorization for the upcoming API functionality? I could start implementing without the API up and running as long as I knew that the functionality would come within the time frame of the contest.

My informal roadmap basically looks like this:

1. Get the OAuth2 application registration bits deployed.
(1.5. Pat’s /v2/continents additions.)
2. /v2/account/bank, /v2/account/materials.
3. /v2/commerce/transactions.
4. /v2/characters.

So, basically all authenticated endpoints which aren’t really useful within the scope of a desktop application. No timeline for those, but that’s the general order they’ll probably happen in. The other endpoints I’m working on still need a bunch of manual verification (looking at /v2/skills, there’s a lot of wonky stuff still coming out of my current implementation) or are otherwise still in a half-implemented proof-of-concept state.

Nabrok.9023:

The OAuth2 library I am using (perl’s Net::OAuth2) wants to add “Host: account.guildwars2.com:443” to the access token request header. This results in a 403 error from the server.

It works fine if the header is set to “Host: account.guildwars2.com” or left out entirely.

I was able to make changes to the library code to fix it for myself, but other users and possibly other libraries may come across this problem.

Could you capture and paste the request that’s returning 403 (make sure to remove the “code” and “client_secret” parameters from the query string)? I’m totally unable to reproduce the behavior from the host header alone.

Remfin.4892:

Is the ID, Name, or both primary/unchanging keys?

I imagine that same question is going to come up again for characters

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Khisanth.2948:

Lawton Campbell.8517:

Pat Cavit.9234:

Khisanth.2948:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Name is also what’s displayed on the forums.

In that case I suggest some renaming.

Account Name is the email address according to the launcher and what is displayed on the forum is usually referred to as the Display Name.

Yeah, but the API is never going to provide the “account name” (e.g., you’ll never be able to access email addresses), so just referring to the “display name” as “name” is fine, I think.

Valento.9852:

Skills/traits – https://forum-en.gw2archive.eu/forum/community/api/API-Suggestion-Skills-and-Traits/first#post4700324

See the pull requests on the CDI repo.

Remfin.4892:

A C# example of using a temporary token to get account information

I’d recommend just using an existing OAuth2 client library. More meat for the dollar and all.

Teraphas.6210:

A request. I don’t do much work with api so i don’t know if this is possible. Could it either be made an api or an ingame option to track the storyline choices we have made?

say i am playing a second or third etc character of a race and i did the story so long ago that i don’t remember which missions i chose the first time. Could there be a way to see which paths we chose before. Nothing worse then either remembering wrong and having to restart. I had to reroll a charr because i forgot what legion i had made my first one and accidentally made my new one the same.

That’s already a thing. Check the “My Story” section of the “Story Journal” tab of the Hero Panel. The first entry has icons in the lower-right corner with tooltips indicating which character creation choices you made, and the other entries detail the choices you’ve made throughout your personal story.

It doesn’t give you the tl;dr “You pressed option 3” but it’s enough text to figure out which choice you chose.

Terrasque.8735:

I’m completely new to Oauth, so bear with me here.. I’ve read https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified as a simple introduction, and from what I can see it – at least for this app – requires a web server to get the callback, right?

Is there a way for a native app, like a command line script, to get a token for an account?

OAuth2 is more-or-less designed for web applications.

If there’s a lot of demand for native applications we can look into adding EVE-style API keys (wherein the user can generate a long-lived token via the account site and copy-paste it into your application), but for now just assume that you need a webserver.

Also, unrelated, I pushed my example Go application to the Github repo.

Pat Cavit.9234:

Khisanth.2948:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Name is also what’s displayed on the forums.

Teranas.6150:

munkiman.3068:

I’m confused, this is possible now with mumble tracking, can you not write an extension that utilizes that code? This seems pretty straight forward to me and something mentioned before the game launched.

I suppose mumble retrieves its data directly from client side in real time meanwhile the API retrieves its data from pre cached databases of the server. This data will be pretty fast outdated when you get them from the API.

Two very different mechanisms.

Pretty much on the money.

dlonie.6547:

Ravenmoon.5318:

IRC is older than me (I’m 24 years old), it is time to let it go xD

This is actually an advantage to using IRC (or another off-the-shelf technology) — existing chat clients already understand it and third party apps can use existing libraries since the protocol has had time to gain acceptance.

IRC has some cobwebs for sure, but everything understands it

I’m in the IRC boat myself, but arguably XMPP shares the same “doesn’t need a custom client” properties. Also, calling IRC cobwebby is a bit of an understatement — the protocol is riddled with all kinds of undocumented extensions and it really baffles me that clients are even capable of communicating with the wide range of implementations that they do.

The main issue with IRC/XMPP is that it would require a bridge to use within a browser. We need to internally figure out what our most common use-cases for a chat endpoint will be, I think.

There’s also an authentication issue with IRC/XMPP that I’m not sure how best to handle (e.g., OAuth2 isn’t really going to work for it), but eh.

mahri.8410:

I would like the API to provide location coordonates of players. If I would be able to see my guildmates location on Tyria map in a web app, there would be more collaboration.

This probably won’t be technically feasible. We don’t have real-time access to character data (it can be up to 5 minutes stale).

mahri.8410:

Also, another suggestion for the API is 3D asset streaming. Currently, only 2D assets could be displayed, such as items. What I suggest here is 3D asset streaming.

I’d prefer to just provide the 3D models and textures in a common format, then let the application render them directly with e.g., WebGL. Makes everything a bit less complicated.

Whether or not that’s something we can provide is a question that’s above my pay grade :P

As far as pre-rendered stuff goes, I really really want to provide character portraits though. There are some outstanding difficult-to-solve issues with rendering on servers that we’d have to sort out first though, so it’s probably not going to happen for a long while.

Yeah, it’d be a desktop program that uses a shared memory-mapped file which uses the Mumble link data format.

There’s really only two fields in that format that we can put data into; each of them are only 256 bytes long. One of them, “context”, is used to determine which players should hear which other players (so we can’t change it). The other, “identity”, is documented as “shouldn’t change more than a few times per second if at all during a game”. So there isn’t really any place we can put real-time data without breaking existing usages of that API