Guild Wars 2

coldwaterq.6258:

Something I would like to see added to the items api is for the vendors that the item can be purchased from to be included, along with the price those vendors charge. Alternatively the lowest price charged by a vendor would also be nice.

This is on my list, but it’s pretty far down as it is actually quite difficult to determine which vendors are (or have been) player-accessible, and under what conditions they’ll actually sell their items. Some additional discussion in this thread.

ClockworkUnltd.2690:

For the authenticated api, I would like to request adding the time a particular skill was last used.

This is more-or-less infeasible. The data we have access to is always between 1 and 5 minutes stale. The stream of data that could meaningfully contain skill usages (e.g., the raw logs) may be even more out-of-date.

Basically, none of the APIs actually talk to game servers and are heavily cached, so real-time info isn’t going to happen.

The only bit of data we currently expose is the current character’s profession. You can get this info from the super poorly-documented Mumble link API (see this thread). Specifically, the identity field of the Link data contains a JSON blob which looks like

{ “name” : “character name”
, “profession” : 1
, “map_id” : 2
, “world_id” : 3
, “team_color_id” : 4
, “commander” : true
}

Where “profession” has the following mapping:

1 = Guardian
2 = Warrior
3 = Engineer
4 = Ranger
5 = Thief
6 = Elementalist
7 = Mesmer
8 = Necro

“map_id” corresponds (or, should) to a map accessible via /v2/maps, “world_id” to an id in /v2/worlds, and “team_color_id” to a color id which can be resolved against /v2/colors (I … think). Oh, and “commander” is set to true iff you’re running a commander tag.

Rising Dusk.2408:

So let’s say I want to “opt in” to an app or overlay that allows other players to perform a gear check on me in dungeon groups. How would I do that? Would I have to use the app? Or would there be a user preference in-game (disabled by default) that shares my information for others to pull from the API?

You’d go to the app’s webpage, which would redirect you to the official sign-ins. After signing in, you’d be presented with an authorization prompt telling you what permissions the app is requesting. Clicking a “accept” button would send you back to the app and give the app a token they can use to make authenticated API requests on your behalf.

So, an example app, “pingyourgear.com”, might allow you to list your party members by name. You could them send them to the app — they’d log in and grant the app access to view their equipment. The app would pull their equipment and update it on your screen. The app could additionally save authentication tokens (with the user’s permission) so they’d only have to opt-in once — so any party members you add who’ve already used the app could have their current gear appear immediately on your UI.

DeviantShark.6548:

With the possibility of authentication there ought to be some guild-roster-api, but i don’t know how this should be implemented. Obviously there should be a setting in the ingame privileges tab like “API-Access” which grants those rights to a specivic guild group.

Probably not going to be an in-game opt-in for this. Anyone in the guild can already see the roster in-game, so it doesn’t make sense to hide the roster from them out-of-game.

quenoz.3859:

i would be really excited about a possibility to have guild chat outside of the game too, maybe somewhat like twitch allows to connect to their irc: http://help.twitch.tv/customer/en/portal/articles/1302780-twitch-irc

Out-of-game guild chat is definitely something I want to have, but we haven’t really settled on a protocol for it yet. XMPP, IRC and “something custom with HTTP+SSE” have all been tossed around as potentials but it’s not immediately clear which is most advantageous to implement. As far as interoperability with existing clients, IRC’s probably the winner (though it’s a horrible mess of a protocol).

smiley.1438:

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Ooh, those look shiny. In addition to fixing up the response format, I definitely do want to get the objective flip times in there, though I think that’ll take some more involved backend changes.

Sol Solus.3167:

The trading post APIs only accept IDs, so it would make sense to have an item name search API to get that ID. Right now the only way to implement name search is to maintain your own database, which is burdensome for non-website apps.

Preferably, it would allow type, rarity, etc. filters via parameters.

Actual search endpoints is definitely something I’ve been looking into. The way we pull content data right now is to basically load stuff from the dat file — which is designed for semi-random access and doesn’t really yield itself to indexing. So I’m trying to pull all the data into a more normalized format so we can load it into search indexes and index all the things (not just items/recipes, but also future endpoints like skills and maps and whatnot). Still a ways from being production ready though ;_;

zerorogue.9410:

On the matter of actual editing of character/game data through the API I would rather not have it.

Don’t worry, it’s technically infeasible for us to edit game data. We only have a read-only copy (which is potentially ~5 minutes out-of-date) due to the nature of our architecture.

Pat Cavit.9234:

dlonie.6547:

One API endpoint I’d like to see would provide access to historical trading post data — for example, to get the data to produce a graph similar to those on gw2spidy, gw2tp, etc.

Doing this currently requires constructing an external database and scraping the APIs regularly to populate it, and data from before the scrapes started is never accessible.

Before putting up a proposal for the endpoint parameters and response format, would something like this be possible? I.e., does ArenaNet store a detailed history of trading point data? Would the sheer amount of data that would potentially be pushed through their servers be problematic?

And thanks for starting this Pat — the APIs are one of the coolest things about this game for people like me

Lawton’s got a proposal for a user-specific TP transactions history endpoint he should be putting up as a PR. We need to get authenticated APIs up & stable before that API can become a reality though.

Here’s the PR for /v2/commerce/transactions, which would allow users to delegate access to their trading post transaction history.

Remfin.4892:

Just to be clear, when we keep talking about authentication and authentication APIs, what scenarios are intended to be supported?

• “User” APIs (apps calling APIs)
• “Server” APIs (servers/websites calling APIs On-Behalf-Of)
• External authentication (ala OpenID and such) (being able to get and verify a token that ANet says you’re “X”)

The authenticated APIs will use OAuth2, which is best described by the second (servers/websites calling APIs On-Behalf-Of). You must explicitly grant a server access to specific portions of your account for your data to be disclosed. Servers/API consumers cannot access any API which requires authentication without the explicit consent of the user whose data is exposed.

While technically OAuth2 isn’t meant to be used for authentication, the /v2/account endpoint will effectively provide external authentication so you can restrict e.g., guild websites to only people who are actually in the guild without relying wholly on manual in-game checks.

aRestless.6213:

Guild management and especially member management can be a big problem in larger guilds. Having Roster and Roster History exposed would be a huge thing.

This is definitely on my todo list, but I don’t yet have any designs for the endpoints. One of my guild leaders exports the influence log by hand to a spreadsheet so he can compute and graph various engagement metrics — that’s really something that should be automatable.

veggies.2178:

As a proud owner of 11 “mule” alts out of 35 character slots, i like the api changes, but one thing that anoyed me is the lack of api for character inventory.

We’re planning to eventually expose character inventories via the /v2/characters endpoint (and the account bank via /v2/account) so that someone can write a webapp to locate where you put that extra stack of Superior Sigils of Wrath or Lemongrass Poultry Soup. I’ll post a link to the Github PR once I’ve got the endpoint proposal writeup finished.

Just finished an initial writeup of the current in-dev state of /v2/skills. It’s still quite a bit away from being ready for public consumption, mostly just looking for ways to improve the output format.

Divus.3175:

About historical tp data.

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

Querying it is neither fast nor scalable, so it’s very unlikely that we’ll be able to provide access to anything beyond what you can see via the in-game UI. I think the current cutoff for the transaction history is three months, but might be mistaken about that.

MithranArkanere.8957:

All I want for now is just 3 things:

• Some sort of authentication, so the API can get permission to get info about an account and its characters.

I put together a PR about upcoming /v2/account API. The PR has more details, but it’ll give you the ability to authenticate users and determine their homeworld (and eventually more stuff is planned for it).

Wanted to have it released this week, but having some fun technical issues with the deployment.

AfterXII.2761:

As a guild leader and a web/phone app developer, I took a look at the announcement of API authentication and immediately thought of the following possibilities for implementation:

Personal Account

• Personal bank contents, assets, wallet, etc
• Current guilds (with flag on current rep)

The personal bank account (and material storage) is planned for the /v2/account API (see the PR link above), as is the current guilds an account belongs to. The currently represented guild will probably live in /v2/characters, and the roster in an account-specific guild endpoint (haven’t really sorted out the design for that yet).

Anyway lemmie get some more writeups posted on Github for you guys to peruse.

And the fix is live.

The match IDs are GUIDs, actually.

In any case, as much as I want this API to exist today, it probably isn’t going to arrive any time soon

Tracked this one down today, hoping to have the fix deployed sometime this week. Thanks for the report!

Sariel V.7024:

Unlike crafting recipes, which are often bought as sheets and remain forever documented in your UI after you learn them, the combinations of the forge are intended to be a puzzle. They are a secret, and their revelation to the world at large remains at the discretion of the players that discover them. Or, in a single case, at the discretion of John Smith ;D

FWIW, I share this sentiment.

Not sure how you created a topic without a post, but check out this thread for the chat codes.

For the wiki link, you can usually just append the item name to the wiki search URL, e.g., http://wiki.guildwars2.com/index.php?search=Courage.

Since there’s not a response in the linked thread, I’ll go ahead and say a Mystic Forge recipe API is unlikely to happen in the near future.

I’ll go ahead and throw the various vendor icons (bank, guild bank, trading post, vendor, armor vendor, weapon vendor, etc etc) and the WvW icons in there too. Note that the component that reads from the dat file is tied to the normal release schedule — so I have no idea when these additions will actually go live.

Hmm, I’ll look into getting some of those images added to the /v2/files endpoint. Not sure if/when they’ll be available though.

I actually have no idea how the new daily system works — the old one was on a rotation. I would blindly assume that the new system is still deterministic, but that doesn’t preclude the dailies from being randomly selected (e.g., via a synchronized RNG).

Eh, server time is just UTC. I would assume that the servers have an NTP client running, so there shouldn’t be that big of a sync issue between the GW2 servers and your local machine.

weregamer.2739:

Now that the new daily quest system is in place, it would be great to be able to see what today’s PvE dailies are before I get home, so I know whether to budget time for them or just a quick login before moving to other things. (I’m not sure if the PvP ones would be useful to folks who do that; the WvW ones seem generic enough that one wouldn’t plan one’s evening around them).

That’s a pretty good idea. I can’t promise results, but I’ll look into that.

This is definitely something I’d like to see — there’s a huge amount of things that could be done with this. I’m thinking something along the lines of automated duel ladders via a password-protected/guild-only custom arena with an external web interface for match-making and gloating.

For ranked matches, I’m pretty sure we can’t provide data during the match — since you’d be able to inspect your opponent’s builds pre-match-start and other shenanigans. There may be other issues w.r.t. privacy/build secrecy. For hotjoins it’s no big deal since you can see everything in spectate mode; however, it’d be providing an advantage for ranked matches, which is probably something we don’t want. I’m not really sure.

Finally, there’s an issue of data retention — I’m not sure how much historical data we can feasibly store, but there’s a limit somewhere. It’d be on the application developer’s end to archive data, that’s just not something we can do.

Anyway, I don’t know if/when we’ll be able to implement it (or even which parts will come to light), but it’s an endpoint I really want, at least.

We’ll try our best to keep everything working without changes on the application end. I don’t know if there’s going to be any HoT-related changes, but there definitely are some warts I’d like to see fixed, which include:

• The “Outfit” consumable’s type is currently listed as “Unknown”.
• Boon/Condi Duration isn’t listed in the infix_upgrade’s attributes, but rather in a string.
• Some other stuff I’m forgetting.

Since these change the values of existing fields we’re returning, I personally consider them breaking changes and would like to (eventually) figure out a good way to make them to the v2 endpoint. It’s not really on the immediate list of things to do, though. If we do plan on breaking stuff in the future, we’ll probably post a topic about it to get feedback on the change before deploying it.

I think changes that add completely new fields to existing objects are non-breaking, e.g., if we add a “learned_from” field to v2/recipes that contains a list of item_ids (from which the recipe can be learned), I don’t currently think it’d be a big deal. I kind of feel the same way about flags — if there’s some flag we missed, I wouldn’t really consider it a breaking change to add it in — but I can definitely see the argument to the contrary there.

Let me know if that sounds crazy.

Uhh, hmm. This might not be as simple as I’d assumed — take, for example, Dusk and Naegling which share the same skin — their item icons take precedence over their skin icons (specifically, Naegling’s icon appears to override its skin’s icon). I’m guessing there’s a flag that we’re not checking which toggles the override behavior.

EDIT: eh, nevermind, the icon for Naegling should be the same as Dusks; just an instance where the wiki is returning bad data from the API.

Whoops, yeah, that’s a bug. Apparently the item has a different icon than it’s default skin, which is unusual. The API code is wrongly making the item’s icon have priority over the skin’s icon — not sure when the fix will land but you can work around it in the meanwhile by pulling the default skin’s icon instead (e.g.,/v2/skins/5605).

I’m assuming you’re referring to the file signature used to retrieve the skill icons from render.guildwars2.com — if that’s the case, they’re not currently available

Alcarin.9024:

Months ago, I’ve done something similar to your suggestion Lawton, in about 10 hours of work (wiki was not as completed as it is now) I’ve created a DB with 29 tables without armors and weapons.

Huh, 29 tables seems a bit high. I’d love to take a look at your schema if you’ve still got it somewhere, as I’m probably forgetting something (working on a personal one right now, estimate around 19 tables).

A NoSQL solution is definitely more straightforward though, since the data format is so varied.

The API backend don’t have any tables whatsoever.

I’d probably store the attributes of each subtype in a separate table to maximize normalization. e.g., the items table would just store the attributes common to all items; for items with a “consumable” type, the items_consumable table would have the corresponding type-specific fields; and for consumables with an “unlock” type, the items_unlock_dye or items_unlock_recipe would have those details.

So for this somewhat contrived example, I would probably use something like —

CREATE TABLE items (
    item_id INTEGER PRIMARY KEY,
    item_name TEXT NOT NULL,
    item_type INTEGER NOT NULL
    -- etc
);

CREATE TABLE items_consumable (
    item_id INTEGER PRIMARY KEY,
    item_consumable_type INTEGER NOT NULL,
    item_consumable_desc TEXT,
    item_consumable_duration INTEGER
    -- etc
);

CREATE TABLE items_unlock_dye (
    item_id INTEGER PRIMARY KEY,
    item_unlock_color INTEGER NOT NULL
);

(the types/nullability of these fields are from http://wiki.guildwars2.com/wiki/API:2/items)

And then, for example, https://api.guildwars2.com/v2/items/20357 would have the following values inserted into the tables:

items(item_id=20357, item_name="Ash Dye", item_type=Consumable)
items_consumable(item_id=20357, item_consumable_type=Unlock, ...)
items_unlock_dye(item_id=20357, item_unlock_color=474)

Sorry, I meant to suggest using the existing data to infer what constraints can be applied. The backend doesn’t really follow any rules (in particular, string lengths are unbounded), so the existing data is the only thing we have to go by.

The ids should be the same between v2/items and v2/commerce/listings. Which one(s) in particular look incorrect?

There isn’t an RDBMS behind the API, so there’s no schema per say. I think the quickest approach is to pull the entire dataset and tinker with it until it makes sense.

Dr Ishmael.9685:

As for the accessibility of vendors, would it be possible to implement a “discovery” system similar to what’s already in place for items/recipes/skins?

Not sure whether that’s feasible or not; will have to look into it. Having a vendor endpoint would definitely be the best approach though — at that point, we’d be able to reference the vendor IDs from both /v2/items and /v2/floors.

Not currently, no.

I’ve looked into implementing this and it’s probably not going to happen. The same item can be sold by multiple vendors for different prices (or different currencies) — consider the Dry Top geode vendors or the Fortune Scrap vendors — and I don’t think there’s a feasible way to determine whether a vendor is still (or was ever?) accessible.