Guild Wars 2

Drant.5902:

Unfortunately there is a map-long band of corrupt tiles for floor 1 of the Tyria map:
https://tiles.guildwars2.com/1/1/{z}/{x}/{y}.jpg

;___________;

Thanks for the heads up, I’ll regenerate the tiles again today — hopefully it was just a cosmic bitflip or something.

Yeah, it’s an unfortunate known issue. The backend component that handles gems globally needs to be re-deployed, which unfortunately is outside my purview

Morphine.6923:

Is it possible to implement interaction with game server so we can not only view but also act. Like correction of prices of current TP sell/buy listings. Is it even possible?

No, nor will that ever likely be possible.

At some point yes.

I’ve been trying to update the tiles all week, but the universe is colluding to prevent it from happening. It started off fairly mundane but it’s getting worse. The sixth attempt to regenerate tiles resulted in the power grid failing for about a mile around the studio yesterday. I’m hoping that today everything will work out.

I don’t think I made the fix in time for tomorrow’s release, but it should be in the one after that. Here’s the tracking issue.

Sorry about the mess

For mystic forge recipes, no. There’s a community-maintained JSON document somewhere that has (probably) all of the mystic forge recipes.

For discovered crafting recipes, if you know the item id (e.g., 15466), you can use /v2/recipes/search to get a list of all recipes that output the item, which can then be resolved against /v2/recipes to get the inputs. The inputs can then be recursively put into /v2/recipes/search to get the entire crafting tree.

I’m still reviewing the implementation bits for the skirmish stuff, but by my reading the API should be able to expose the skirmish results for all skirmishes within the current match. I can’t make any guarantees yet though, still in the reading phase and haven’t written a line of code yet :/

Timeline-wise, definitely won’t be with the next release. Hoping to make the one after next, but it’s going to be a bit tight time-wise. I’ll keep you guys up-to-date when I have more concrete data about the implementation progress (including more specifics about what the updated endpoints will/can expose).

History probably won’t happen, but I’ll be working on making backend changes this week to support skirmishes. They won’t be ready for the next release; shooting for the one after.

History outside of the current matchup is unlikely to happen, unfortunately.

I created a tracking issue for this. After thinking about it for a bit, the second PS is probably the best option. Will have to look into where those are stored.

Reincarnated.1754:

EDIT: Just did daily (Southsun survival). map 920 floor 37
Don’t Know if this is a separate issue?
I think it is. Looks more to do with the maps API.
http://img.techpowerup.org/160730/capture015.jpg
The default floor is not listed in the floors.
Floors show 12, not 1, 2 (not coma separated)

This may be a bug. In the actual data for Southsun Survival, the default floor is not listed in the list of floors. For some reason, it is for pretty much all the other maps. It may make sense to have the API frontend normalize the data so that the default floor is always in the floors list (because that would make sense).

Created a tracking issue for this.

I can’t repro it at all — I don’t see any weirdness with the new tiles (Bloodstone Fen, Stronghold of the Faithful, Raid on Capricorn, etc) with either your tool or mine.

I highly suspect there’s some kind of cache coherency error on one of the EU CloudFront edge servers — it’s possible that it somehow cached a bad request or something. I’m not entirely sure how that’d be possible given the origin is an S3 bucket, but I kicked off another invalidation of the entire CloudFront distribution to hopefully do something.

Invalidations usually take 20-40 minutes from what I’ve seen; I can’t connect to the broken edge servers so let me know if that changes anything ;__;

EDIT: As an additional datapoint, smiley mentioned on gitter that this is a regular occurance whenever tiles are updated and it usually resolves itself after awhile. It might be worth investigating setting the CloudFront edge servers to NA-only to see if that fixes the problem (at the cost of CDN latency for non-NA tile consumers) :/

EDIT2: The invalidation I kicked off says it’s completed.

Hmm. I’ll continue investigating; I’m pretty sure that this isn’t an API issue at least — the backend servers that handle the trading post were responding with that exact data. My suspicion is that there’s a cache coherency bug somewhere in the trading post servers that causes them to occasionally return erroneous data to both the game and the API.

I’m unable to repro. All of the subdomains are configured with the same CloudFront distribution — so they’re all identical in both origin configuration and invalidation. There was some talk the other day about tiles taking an unreasonable amount of time to invalidate at certain EU edge servers but I haven’t been able to repro it.

Do you have an example URL that serves different tile data than tiles.guildwars2.com? i.e. a specific tile. The ones I’ve peeked at are identical between domains.

…huh.

I’m guessing I ran the script that pulls the list of IDs from achievements and didn’t actually whitelist them? Because they weren’t whitelisted. Actually whitelisted them this time (and verified the whitelist server has them in the list) — I’ll double-check /v2/items in a couple of minutes to verify that they’re being returned correctly. Sorry about that.

(EDIT: confirmed that they’re all actually in the API now)

Blergh, I thought the changelist that did this automatically went out with this release. In any case, just whitelisted the following item ids:

79146, 79243, 79117, 79083, 79051, 79241, 79183, 79250, 79211, 79185, 79102, 79075,
79232, 79128, 79299, 79057, 79081, 79127, 79126, 79244, 79170, 79223, 79202, 79228,
79256, 79147, 79267, 79226, 79198, 79205, 79176, 79178, 79303, 79268, 79200, 79070,
79165, 79148, 79262, 79191, 79273, 79064, 79093

Huh, that’s super weird. It’s definitely a bug in one of the backend servers; I’ll notify the people involved and see if we can get it fixed.

(EDIT: I think there are just no buy orders for that item — so the backend server is doing the correct thing and those 0’s are totally legit).

Poetics.9743:

Certainly a few bugs (Favor returning 0) but the results of :id look great, thank you!

Huh, can you PM me the API key and guild id? Favor’s returning correct values for all the guilds my account is in :<

It’s a CORS issue — setting an Authorization header (or User-Agent for that matter) makes the API request a non-simple request. This means the browser attempts to preflight it with an OPTIONS request, which our backend doesn’t support, so the request fails. So for code running in the browser, you’re stuck with the access_token query parameter.

You can get the guild ids from /v2/account, or you can look them up by name in /v1/guild_details.json.

Private message me the full URL you’re using (with the API key) and I can take a look.

https://api.guildwars2.com/v2/guild/123/log?access_token=456 (where “123” is the guild id and “456” is the API key) should work fine; not sure what’s wrong. That error message should only appear if the API key doesn’t get passed correctly, AFAIK.

Rod.6581:

Any update on this?

Not yet ;__;

IIRC, the LUT transforms from the item’s {rarity, level, slot} into a static value (so all level 80 exotic hammers have the same value — 683 — which is further adjusted by the uplevel system etc). That value gets multiplied against the specific stat multipliers for the item to get the final stat bonuses.

Given this, it should be pretty straightforward to build your own LUT for a subset of items — say, level 80 rare/exotic/ascended. I might expose the raw LUTs at some point if there’s a compelling use-case (as it would need a lot of fiddling to pull them out).

There’s an endpoint, /v2/guild/:id, that still needs a bugfix to be deployed — been heads-down on some misc. backend cleanup for the last week or so. Once that endpoint is enabled you’ll be able to grab the aetherium/resonance/etc amounts for any guild you’re in.

darthmaim.6017:

Most API endpoints are cached for 5 minutes (as can be seen in the response headers).

Specifically, either the Expires or Cache-Control headers.

This is related to an existing issue so I merged ‘em together a bit. IIRC I had an initial fix for this, but I remember there being some issues with it. I’ll see what I can do.

Huh, that’s a good point. I made a tracking issue for this.

AFAIK historical TP data isn’t persisted in an accessible format for longer than 3 months — the available data should be the same between the in-game UI and the API (if not, it’s a bug).

This is unlikely to change on our end — our infrastructure is sized out with this retention policy in mind and changing it would (probably) be a significant undertaking. Sorry :<

Not really sure what you mean by “third endpoint”. For your account’s current orders, there’s only two endpoints:

• /v2/commerce/transactions/current/buys
• /v2/commerce/transactions/current/sells

Those provide paginated responses; you can use the page query parameter (e.g., “/v2/commerce/transactions/current/buys?page=1&access_token=asdf”) to get all the results (the first page is page 0).

Hmm, those look like content bugs — those items are mostly acquirable in-game but don’t have localized names. I’ll bug someone about it and see if we can get them fixed. Thanks for the report!

Yeah, it would.

Our backend doesn’t support OPTIONS requests which means we can’t preflight CORS requests — so code running in the browser can’t actually set an authentication header — so for most use-cases the key has to go in the URL. Which is a bit unfortunate, but it is what it is.

We worked this out over gitter, but for anyone else following along, the issue was that

var url = “https://api.guildwars2.com?access-token=<” +key +">/v2/account";

should have been

var url = “https://api.guildwars2.com/v2/account?access_token=” + key;

Eugh, the guild upgrade items are a known issue on my end — AFAIK all of the items associated with guild upgrades are purely advisory (e.g., when you craft them the item specified in the recipe doesn’t get produced — it just gets inserted into the guild’s inventory). That the recipes refer to acquirable items is an implementation detail rather than an invariant.

I’ve not a clue why those items ended up in /v2/commerce/listings without ever appearing in the whitelist queue.

In any case, thanks for the continued reports; I’ve whitelisted all of those.

All those will appear at some point in the future. There’s a old tracking issue for this; managed to find a handful of icons from that list too.

Oof, I forgot to add it to the hardcoded list. It’ll appear as “map_crafting_scribe” in either the next release or the one after. Sorry about that! :<

Nope, both you and the API have it right. That’s how it is in content and how it displays in-game.

I’ve no idea why.

I’ll let someone know.

Uhh, was posting before coffee and forgot to create a tracking issue for this. Here’s a tracking issue so this doesn’t get lost in the mists.

Aidan Savage.2078:

As for the timetable, I’d say that once it’s put on the wiki, release it in the API, as once it’s on the wiki, it’s likely to spread to a large number of players.

I can do that. The API endpoint would basically proxy the wiki’s semantic search for mystic forge recipes; will need to look into it a bit to figure out how the semantic search bits work.

The mystic forge is one of the bits we’ll probably never provide API access to, unfortunately. There was some previous discussion about it, but basically it boils down to:

• Determining the timing for revealing discovered recipes would be too arbitrary — there’s no solution that wouldn’t detract from the game.
• Some of the recipes are incredibly unwieldy (e.g., massive input tables for “4 rares to exotic”).
• There’s already community-driven program-readable resources (e.g., gw2profits.com and the wiki’s semantic search).

Yeah, that’s just how the content is — there’s probably a historical reason for it. Not really much that can be done about it at this point, unfortunately.

Whoops! Thanks for the bug report — will try to get those ids that you pointed out whitelisted today and will figure out a solution to get them whitelisted automatically in the future. Here’s a tracking issue, for reference.

It’s on the todo list, the goal is to put it in /v2/guild/:id (which would be available to any guild members regardless of rank). I’ll bump the priority on that up a bit; don’t recall offhand what blocking issues that had.

Whoops! Sorry about that — should be correct now :<

roj.1085:

So, uh. What do I do about that, aside from hard coding a catch?

Huh. The item id in your /v2/account/inventory is correct, and I’ve just now whitelisted it. It was a bit of a special case and — since it’s never been dropped in the world — it’s never shown up in the item whitelist queue. I’ve gone ahead and added it manually.

The other item is a container that you get after accepting the level 80 boost — not the level 80 boost itself.

I’ve got some code for the account bank and character inventories that pushes any unknown items into the queue automatically; I guess I’d forgotten to add it to the shared inventory slots. Though this is kind of a special-case, here’s a tracking issue to whitelist any future unacquirable items deposited straight into an inventory.

Aidan Savage.2078

Just use the noobiest character you’ve got for this though. The return is a condensed JSON output, which means minimal (ie almost zero) whitespace, so it definitely looks fugly if you have a looooooooooooooooooooooooooot of unlocked recipes and bags.

You can make it look nicer in-browser by installing a JSON prettifier (e.g. JSONView for Firefox or Chrome).

Ah, I think someone requested this before and I thought it was a good idea — and it promptly fell off the table. Here’s a tracking issue for it this time.

It’s not currently available though.

The tags are basically for a kanban view that I use: waffle.io.

• “ready” means that the issue has enough information to begin work on.

• “in progress” means that some work has been done on the issue. The ones that are there are mostly stalled.

• “needs deploy” means that the work is done, but pending either a game update or an API backend deploy. With some exceptions, an issue in the “needs deploy” state will be completed the release after the next release.

The sticky is a reasonable idea; I’ll see about setting one up next week or so. For the most part, I rarely make backwards-incompatible changes — the goal is to keep applications working without needing any changes to their code.

Well at least Thunder Hollow is correct now.

I’m just going to hardcode the newly incorrect ones to the right places. I’m not yet sure what’s spooked them around the map, but catching them in the act is definitely going to help narrow it down a bit.

EDIT: Change is live. Labels coordinates still are a bit off, but the objective coordinates should be correct again.

So, while I agree, there are some pretty large technical hurdles to providing non-current data. As a short primer, the data’s path looks roughly like this:

1. The map instance servers running the WvW maps keep track of the current state.
2. Periodically, the current state is flushed and persisted to the per-datacenter singleton orchestration server.
3. The orchestration server re-emits the entire map state to a pool of backend WvW API servers which mirror the current state.
4. The API frontend servers query the backend WvW API servers to handle requests.

The problems are twofold:

• The orchestration server is, from my seat, immutable. It’s a singleton and controls pretty much all of Tyria, so any change to it is rightfully accompanied by hand wringing and many sleepless nights. Sentry and ruins state aren’t currently sent to the orchestration server, so the API will probably never be able to emit that data, nor is the score (PPT vs. PPK) breakdown.
• Both the API frontend and backend servers are completely stateless and often restarted. It’s possible to make the backend stateful, but it requires a significant overhaul. This combination makes it infeasible to store anything other than the current state, which is mostly what the API exposes.

The good news is that we’re aware of the issues; the bad news is that I’m not sure when we’ll have improved them in a way that the API will benefit from. In the meanwhile, the periodic polling workaround kind of works, even if it’s a bit of a hassle.

Sorry :<

Ideally it’ll work with the current output format so that consumers using `Object.keys(json).forEach((key) => parseSection(json[key]))` don’t break.

I’ll go ahead and draft an initial PR; we can add more fields later.

Probably gonna keep them as an array. Their current organization isn’t formalized — it’s just how they’re all set up. I could hardcode the indexes but there’s not a non-manual way to tell that it hasn’t broken. Though there would be an advantage to having it hardcoded once in the API rather than in all the applications.

Any suggestions for how to specify the groupings in the response? Like, .category={"Scales", “Tier1”, “Tier2”, …etc}?