Guild Wars 2

Ugh I just made a really long post about this and the forums ate it. It was probably the best post I’ve ever made and this is a poor facsimile.

Anyway.

After looking at the data, I’m pretty sure that “etime” and “atime” are poking into the animation sequence data. The animation sequence data does contain both the evade frames and the activation timings.

“etime” looks like it basically has the time offsets for the animation sequence steps that control the end of precast/end of cast. I’m not entirely sure where this data is coming from, but the timings are matching what I’m looking at. “etime.a” appears to be the time between casting the spell and the precast being over; “etime.b” is the time between casting the spell and the spell being over.

Or, that’s what it looked like until I just now looked up Meteor Shower

Mar 07 02:27:54 sdef 5501 Bn0VAAA= at 18b1b98eb9c: Meteor Shower
Mar 07 02:27:54 —etime
Mar 07 02:27:54 --— a: 3.8100s
Mar 07 02:27:54 —-- b: 1.8000s
Mar 07 02:27:54 —atime
Mar 07 02:27:54 --— 5: 1.4000s
Mar 07 02:27:54 —-- 1: 1.4000s
Mar 07 02:27:54 —-- 4: 1.4000s
Mar 07 02:27:54 —-- 5: 1.8000s
Mar 07 02:27:54 —-- 5: 2.2000s
Mar 07 02:27:54 —-- 5: 2.6000s
Mar 07 02:27:54 —-- 5: 2.8000s
Mar 07 02:27:54 —-- 5: 3.4000s
Mar 07 02:27:54 —-- 2: 3.8010s
Mar 07 02:27:54 —-- 0: 3.8010s
Mar 07 02:27:54 —-- 3: 3.8100s

I’m actually not totally certain what etime is because that doesn’t look quite right. Or — meteor shower might be a bit of a special pickle because it’s got really wonky animation timings.

Assuming that “etime” is a subset of the animation sequence step data — the animation sequence step data contains the evade frames, but those don’t appear to be exposed by this.

Anyway, “atime” has the animation sequence’s trigger data. The “number:” prefix is the trigger id — the important ones, I think, are “0” is the trigger for “give the player back control”, and “1” is “do the skill’s effects”. Pretty sure the other ones are totally irrelevant for gameplay purposes.

tl;dr, man this would really be useful to have in the API so we didn’t have to root around all crazy-like.

Oof, gonna add that to the skill enumeration bits. Here’s a tracking issue.

Whoops, they’re not. Tracking issue.

Unfortunately, this is technically infeasible. Completed transactions are not indexed in a per-item manner. Implementing this would require additional plumbing all the way from the bottom of the stack, which is beyond the scope of what we can do to support the API.

Seems pretty reasonable; I went ahead and made a tracking issue for this.

Added an icon field to v1/event_details; it should reach live in a month or so (release process takes awhile). Some events don’t have icons — I presume that the event icon, if specified, overrides the default icon.

Chaba.5410:

Edit: Your inbox is full (figures). What’s the best way to send you the key?

orz, cleared out my inbox. You can PM me, or email to lawton@arena.net.

So funny thing, I looked at the actual bits and bobbles after posting that. Not only was I totally mistaken about the story data being hard to expose, at some point I’d already written the backend implementation to dump out the journal stuff?

It needs to be massaged into a usable API, but I can probably have a PR for the details on github next week.

The patch last night shouldn’t have had any effect on the API stuff (but then again, distributed systems happy fun times).

Do you happen to have the actual error string? Is it “invalid key” or “ErrBadData” or something else? There’s an unexpected blip around that time which would have generated ErrBadData — but that wouldn’t make keys go invalid permanently?

I’ll spend some time rooting around to see if I can some idea about what could have caused this :<

EDIT: Do you happen to still have the broken API keys? On Jeremy’s account I’m seeing what may be two broken keys? But want to verify that I’m looking at. They probably won’t be in the account site anymore — you’ll have to get them from whomever runs the TS verification bot.

EDIT2: This story is becoming more and more terrifying.

roj.1085:

Am I missing something? Is there a clear story progress indicator that you can tease out of character or achievements?

Not currently, unfortunately. The hacky achievement approach is the closest you can get to via the API, at the moment.

roj.1085:

Likewise, you can cobble together that first list from achievements; I’m actually currently doing this, you can look at the achievement for twilight arbor (twilight’s idol) and the part of it with ‘story’ in the name is the story

Annoyingly enough, the story mode completions are tracked on a per-character basis, not per-account. There’s no current way to get those per-character unlocks out of the API

Other notes:

• issue for exploration bits.
• issue for story progress.

The exploration/story stuff is, uhh, surprisingly complex and very difficult to expose in a structured manner.

Hah yeah the aftercast is embedded in the animation data as well, as are the precast duration and the evade duration (though I think some of the evade durations are hardcoded skill facts — otherwise they wouldn’t show up in the API at all).

Once I find the time to do the necessary refactoring it should be possible to expose all four values (precast, aftercast, total cast time, total evade time).

I actually have half an implementation lying around somewhere. I don’t remember what was wrong with it that caused me to pause working on it; will have to revisit it. IIRC there was some weirdness with emitting packages (or maybe it was the interplay between packages and discounts, I don’t recall).

There’s an existing issue for this, but the short story is that this is pretty difficult to expose (since activation times are stored in the animation data), but I’ll see what I can do to pull it out.

EDIT: so the long story short is that the cast time is actually stored in the skill’s animation data and the code that extracts the value displayed in-game is fairly coupled to the UI. Pulling that out is a pretty significant undertaking; not sure when I’ll have time for it.

Oops, good point. Tracking issue.

Okay, pushed some changes today that should fix

• /v2/wvw/matches was erroneously being cached for 5 minutes; it’s now back to a 1-second cache (hooray for complicated cache code).
• /v2/wvw/matches.scores (and .map.scores) no longer count the current skirmish twice. The scores should properly represent the total scores.
• /v2/wvw/matches.map.objectives.last_flipped should be properly “null” when it’s never been flipped (rather than 2001-01-01).

As always, let me know when you find further issues

Ugh, best guess is that it’s including the current skirmish score twice. I’ll see if I can get that fixed next week; I’m all hopped up on cold meds right now and don’t trust myself to make any correct changes right now.

Next week I’ll look into exposing the raw skirmish data in addition to fixing this.

Yep! This feature is almost ready. Here’s the github pull request.

aandiarie.7195:

Q_Q This is not a good set of links.

Hey man I don’t make the rules I just break the API endpoints.

I updated the temporary hardcoded API configs for the NA merges+matchups; let me know if I botched something else; I’ll check back later tonight. AFAIK everything should be working (KDRs should be fixed, /v1 endpoints should be fixed, scores should be the total match scores, not just skirmish scores, etc).

What a week.

Weris.5248:

Seems to be working again, but now kills and deaths are equals to 0

This is how I feel right now.

After briefly panicking, the fix for the KDR data is en-route.

Hopefully this will be the last stop on today’s pain train.

Weris.5248:

Wow, and now score is score of the current skirmish (and not the total score of the week). Is it a another bug or is it defenitive ?

Uhh, that’s a bug.

Sorry, bear with me on these changes.

EDIT: also apologies for this disaster; I’ll bundle the fix for that one with the /v1 deploy later today.

Hmm, not actually a bug. Those recipes aren’t craftable by any disciplines.

I’ve gone ahead and un-whitelisted them; they might show back up since they’re technically auto-learned (e.g. every account should have them unlocked).

Color me confused because Spatial Surge looks like basically the same fact type? I opened a tracking issue for this; it’ll get sorted at some point.

Boss Nomad.6487:

Are all these problems related to an update of the api?

Specifically, to an update to one of the API’s backend components. Long story short, we updated how WvW data is stored last year and the API component has been using the old data source which doesn’t have some of the newer features. Talking to the new data source is a bit involved so I’ve been rolling back after finding more bugs on stage each release. This time the bugs didn’t crop up until it was on live (whoops).

Despite that, this time everything appears to be working except for the merges/matchup worlds, which I can just update manually at reset until the next release. Everything should be more-or-less good to go after the next release (i.e. patch not hotfix).

Boss Nomad.6487:

I dont recognize seeing points_tick, points_capture, yaks_delivered or upgrades before. Also appears that there are objectives with a new “Spawn” type.

The updated backend code has support for the extra fields, so the API frontend detects that and just emits them with the response. There’s an open PR on github for those that needs to be closed out (I’ll have to go through github and merge a bunch of stuff I think). I can strip out the Spawn objectives if wanted; IIRC some application developers and I had a discussion on gitter and the conclusion was to just leave them in.

EDIT: Hmm I guess I should fix the v1 API as well.

Whitelisted all of those items. No idea why they weren’t in the queue.

Veleritas.2647:

Lawton, would you prefer additional bug reports to be posted here, posted as a separate thread, or should we skip this forum and directly create a Github issue (https://github.com/arenanet/api-cdi/issues)?

It doesn’t matter too much for me — for whitelist issues it’s usually only a few minutes to fix, so I can just fix them as they come up. For anything larger, I’ll create a github issue one way or another so that I don’t totally forget about it.

Do whatever’s easiest for you. If you do open github issues, open separate issues for each batch of ids so I can close ‘em out and keep track of which I’ve done though.

Okay, it’s back up now, but due to EVEN MORE BUGS (i did this) it’s only being held together with gum and duct tape. Some caveats while I work through the underlying problems:

• Linking data is currently hardcoded.
• Matchup data is currently hardcoded.
• The whole thing is liable to catch fire and burn down.

On Friday (and next Friday ;_;), I plan to disable the endpoint when the scores zero, then manually update the hardcoded bits once the new matchups are decided, then turn it back on; should be back up before the initial RI runs out.

It’s not currently possible. I opened a tracking issue for this.

It’s actually totally unrelated; for the WvW APIs I basically broke everything. Thought the fix I put into the first hotfix would correct the issue, but there turned out to be a totally unrelated issue that caused it to still be broken.

I’ll have it fixed tomorrow provided the rest of the API backend doesn’t explode and catch fire.

Sorry

Veleritas.2647:

Do you know which items have the ids of: 14918, 79430, 79491, 79521, 79571? They are listed on the commerce/listings endpoint but do not exist in the items endpoint.

Mostly guild hall decorations, looks like.

I’ve gone ahead and whitelisted them; they should appear in /v2/items shortly.

Jace al Thor.6745:

Lawton Campbell.8517:

JordanJD.3209:

Lawton Campbell.8517:

Thanks to a sudden influx of taco donations, the APIs have been turned back on.

After some investigation, it seems like the APIs were not the root cause of the underlying issues.

Awesome, can I become a developer for Anet?

We’re hiring!

Since WA is on the other side of the States can I consult from home? Would do for free too for the experience of working with a development team. Kind of like hey here’s a bug/something that needs balanced this can be done to fix it.

AFAIK we don’t do remote; you’d have to relocate, unfortunately.

JordanJD.3209:

Lawton Campbell.8517:

Thanks to a sudden influx of taco donations, the APIs have been turned back on.

After some investigation, it seems like the APIs were not the root cause of the underlying issues.

Awesome, can I become a developer for Anet?

We’re hiring!

Yeah, they’re currently missing. I’m pretty sure the fix for that goes out with tomorrow’s release.

You totally can make it a get request with ids separated by commas. Also the results can be paginated if you don’t want to deal with ids.

chaly.7638:

Well.. we do have some data again.
Is it stable already or still work in progress/ last checks?

Should be stable unless it explodes in a brilliant ball of fire.

Which I don’t expect it to, but hey, things happen.

Thanks to a sudden influx of taco donations, the APIs have been turned back on.

After some investigation, it seems like the APIs were not the root cause of the underlying issues.

They’ll probably be back up eventually but definitely not until tomorrow.

Not certain what the actual underlying cause was, need to pour over some metrics and such to get an actual understanding of what happened. Just not tonight. Sorry about the inconvenience

Just disabled the APIs temporarily. No ETA (yet) on when they’ll be turned back on.

Distributed systems are hard

Oh whoops, those fields didn’t actually get implemented. I’ve removed them from the github examples and opened a tracking issue to add them back in.

Ah, my b.

No, guild storage changes are currently not logged in a runtime querable format at all.

:/

/v2/guild/:id/log should provide stash events with the appropriate data; e.g. I added some items to my test guild, then withdrew them to generate the following two events:

GET /v2/guild/2546752E-7C2E-E611-9106-0862664D7672/log?access_token=ABE86FC6-9CF5-3E41-8288-A45B6270CBE4325BAD8E-A23B-41DA-9FD1-E447D26853CE

{
“id”: 1923,
“time”: “2017-02-13T23:27:22.000Z”,
“type”: “stash”,
“user”: “Lawton Campbell.9413”,
“operation”: “withdraw”,
“item_id”: 12271,
“count”: 10,
“coins”: 0
},
{
“id”: 1919,
“time”: “2017-02-13T23:27:20.000Z”,
“type”: “stash”,
“user”: “Lawton Campbell.9413”,
“operation”: “deposit”,
“item_id”: 12271,
“count”: 10,
“coins”: 0
}

Note that the guild endpoint requires an API key from the guild leader with the “guilds” permission.

Zok.4956:

This looks like a bug. Any chances, this could be fixed in the API-server?

Eugh, it’s probably bugged because the Hint Completion achievement requires you to complete 0 sub-achievements — so any accounts which have a non-zero value there will have that achievement in the API, but not any new accounts. Here’s a tracking issue.

Tharin.6358:

But what if there is actually an ID for every listing done by users and anet is just not providing us with that functionality? It would be so much easier with this to calculate if it was a normal buy or just a cancellation of order.

There is an id associated with every listing (the ids are returned from /v2/commerce/transactions), but we’re never going to return that from /v2/commerce/listings. The basic rundown is that those transaction ids are only stored in the actual database — which for performance reasons the API doesn’t have access to. Instead, the API talks to some servers which have cached aggregates for the listings (basically, what’s displayed on the UI in-game).

Adding in the ids would require piping them through a small handful of backend services and would probably have some serious performance implications, so it’s never going to happen.

Tharin.6358:

Oh! And is there a limit to how fast I can make another GET request?

Not currently, but there’s some caching going on. Check the Expires/Cache-Control response headers to see how often the API’s data is updated. My rough rule of thumb is to keep below 100k requests/day; we haven’t had issues so far but reserve the right to add in a rate limit if there’s ever a problem.

Those achievements have been manually whitelisted.

This has been requested a few times; honestly I should just make it happen. Here’s a tracking issue.

Should have the regenerated tiles up today (or tomorrow if something horrible happens).

EDIT: got the new tiles generated and uploaded, running a CloudFront cache invalidation now. The new tiles should start appearing soon.

Uhhhhhhhhhhh.

That sounds like an issue on my end, let me look into it.

EDIT: A quick glance at the changelog doesn’t show anything that should break anything (but did find a bit of stupid — I added a “map” field which contains the same thing as “map_id”). The old “map_id” field should have the same correct value as before, but I’m making a debug client build to double-check that. On the other front, I can’t get Gw2Taco’s PDB to be read in correctly by MSVS2013, so I’m unable to peek at their internals

TL;DR still verifying the issue, not sure what the ETA will be on a fix.

The API doesn’t currently expose map rewards — the wiki’s got a hand-curated table that that’s querying. That wiki page looks to be POST’ing a form to /wiki/Special:RunQuery/Map_bonus_rewards_query with the parameters

query: true
Map+bonus+reward+query[zone]: “Blazeridge Steppes”
wpRunQuery: “List map bonus rewards”

This corresponds to the following cURL command:

curl -X POST ‘https://wiki.guildwars2.com/wiki/Special:RunQuery/Map_bonus_rewards_query’ -F ‘query=true’ -F ‘Map bonus reward query[zone]=Blazeridge Steppes’ -F ‘wpRunQuery=List map bonus rewards’

I’m not sure there’s a way to get the data out in a machine-readable format though, I’m not that familiar with the wiki bits.

Here’s an old tracking issue. I’m actually working through fiddly progress bit stuff right now, so it might be deployable in a month or so.

I’ve had to roll it back on stage because I am a terrible programmer and it kept crashing.

Then I had to roll it back again since there were further issues causing it to crash.

Then, in the second rollback I did something wrong and the rollback propagated further down then it should have.

Long story short I missed the cutoff for the next release but I’m really hopeful that the release after will be the strongest castle in all of Tyria.

The posted screenshot shows Gold Hoarder has a current value of 72 — which would mean the account has only had 72 copper in it thus far. Lifetime Survivor has a value of 2052 — which (unless you die incredibly frequently) means that the account probably hasn’t done anything except complete the tutorial and gone to a few cities. Gladiator means they’ve only got 500 rank points — which I think is actually the default starting value.

Anyway it looks totally feasible that the account has only ever had 72 copper (and never spent a dime of it).