Either the wallet API is wrong or the wallet in GW2 is wrong, because there’s a difference between the amount of gems I really own and the amount of gems the wallet API returns… It looks like the API never noticed I bought some gemstore items during the SAB festival…
Yeah, the gem balance specifically is bugged. There’s a tracking issue on Github — waiting on a backend change to get deployed to live.
Did this get fixed with the latest patch?
Are we waiting for normal patch Tue for the fix if above is No?
No, it’s not yet fixed.
We tracked down the issue today and the current plan is to get it hotfixed tomorrow evening, but can’t make any promises. Sorry again about the downtime, software is hard :<
Thanks for the heads up; I need to fix the whitelisting bits to automatically whitelist achievement-related items for whitelisted achievements (among other things).
In the meantime, I’ve manually whitelisted all items that appear in either achievement requirements or as rewards.
Am I a “v2” character? I haven’t been able to access my API all day…
“v2” refers to the API version — not the character version. The only way to access character data is via the “/v2/characters” API endpoint, which is disabled.
Effectively, all API access to all character data is turned off until I can resolve the issue.
Just pushed out a terrible fix which hardcodes the world links. The API should be now be returning the correct data.
The WvW endpoints might be a bit flaky today; we’re adjusting some stuff on the API backend to compensate for a significant increase in request volume (normally is 4k requests/minute; was up to 6k requests/minute this morning). Will keep y’all updated.
Sorry for the hassle
EDIT: Adjustments are finished and everything seems stable. I’ll keep a close eye on it over the weekend to make sure no additional shenanigans happen.
Looks like there was an achievement that shouldn’t have been whitelisted (3010) — it doesn’t exist and is causing the breakage. I just blacklisted it — the last page should start working in ~5 minutes when the caches expire.
We found some issues with /v2/characters that necessitated temporarily disabling the /v2/characters endpoints. I’m not sure when we’ll have it back up, but it likely won’t be before the next release.
There seems to be an issue with the unlocked recipes, I cannot access them anymore. I can read my bags’ content, so it’s not a scope issue.
Oops, that was my fault. Refactored some code and had kitten in my test coverage so a mis-typed scope requirement went undetected (“inventory” instead of “inventories”). Will have the fix out today.
Yeah, those upgrade events have a zero’d out user id in the raw event data generated by the map instance servers. This is an issue that we’re aware of, but I don’t really have any visibility into since it’s fairly far outside my area. Hopefully one day it’ll be fixed
Which guild? I need the name/id to pull the data and see what’s going on.
I have a feeling that, under certain conditions, the server generating the data doesn’t log out the user id. I’ve gotten a report or two about this previously, but haven’t been able to track down exactly why this happens :/
The missing achievements are because the achievements have never been completed before and need to go through a manual whitelist step (e.g., I have to click a button before they appear on the API). It’s less than ideal but necessary to stop stuff from appearing on the API too soon. All the ones in the list should be whitelisted now.
Going to try to whitelist achievements a day in advance (or maybe set up a script to automatically whitelist dailies) because the setup is currently sub-optimal. Until that’s done, please bear with my slowness :<
I’ll try to figure out what’s going on with the double ids — there might be a new flag that’s not exposed.
EDIT: Yeah, there’s some new stuff that’s not exposed. Here’s a tracking issue; I’m not sure when I’ll be able to get the fix out (best case is with the next release).
Proposed changes are detailed here. Will almost certainly make all_worlds always there if only to make it easier for testing; should have that bit out today/tomorrow.
That mostly falls under this tracking issue. It’s on the list of things to do soon-ish; not sure when it’ll be finished though.
EDIT: RE: server id of claiming guild; I believe each guild is limited to one claim/map, regardless of which server they’re on. So if you’ve got guildies in the same team but different worlds, you’ll still be able to only claim one objective. I’ll see if I can dig the server id out but I’m not sure that bit will be doable.
I thought there was an open github issue or pull request, but there isn’t. Anyway, someone asked for this awhile back, and I’m looking to deploy it late this week or early next week. When I push the new code out we’ll have “stash” events in /v2/guild/:id/log.
EDIT: I am stupid and this has already been deployed — I blame post-lunch sleepiness — there should already be “stash” events in there. Those should be emitted for all the guild storages. If you seem to be missing events, shoot me your guild ID via PM or in the thread and I’ll figure out what’s gone wrong.
For skill icons, you’ll find the icon URLs in /v2/skills; for inventory/bank icons I think they’re in /v2/files, but there’s never enough stuff in there.
Model renders are still at least a year out — the rendering bits are all tied to the engine, which requires a window context (which is not currently possible since all the servers run headless).
Though that technically works right now, I believe it’s an implementation artifact. Scribing was originally implemented to give you “Immediate”-type items which were consumed before entering your inventory (and when consumed added the corresponding guild upgrades to the guild’s inventory). AFAIK that whole system was gutted and replaced with an entirely different codepath for crafting that just adds the guild upgrade directly into the inventory.
So future guild upgrades may not have any corresponding items.
Also IMO it’s probably easier to manipulate the data as a gist (since gists have revision tracking and stuff).
It sounds like you have 4 layers here, the server, server cache, api cache, and api frontend. So the server cache would send the request when updated, the api cache would be receiving and trigger the sync request when new data is available.
Yeah, adding notifications to the server cache would allow us to flush the api cache and have better coherency.
I’m a little bit afraid to make changes to that system — the server cache is basically where account/character persistence is handled (it’s effectively backed by MSSQL) and fiddling with that terrifies me. Our backend systems don’t really support pub/sub style events — and the DB component is basically a generic piece that basically converts from our internal message protocol (“STS”) to stored procedure invocations — so there’s not really a good place to stick in functionality to notify other components on update.
I think this need is better met by having a local in-client websocket API (since the client always has up-to-date data). It’s still a pie in the sky, but I have a feeling by next year I’ll be out of lower-hanging fruit to implement.
IIRC I missed the last release; the fix should be going out with this one. Pretty sure there’s another fix that removes obsidian sanctum kills/deaths from the totals that’ll be going out tomorrow too (need to check on that).
Thanks for the explanation. One final question: Is the value of 5 minutes a fixed value? Is it always exactly 5 minutes?
There’s effectively two levels of caches when you’re logged in — the map instance server has to persist the changes to the database, and the API backend component has to fetch the updated data from the database. The API backend component has a fixed 5-minute expiry time, but it’s possible that it re-reads the same data because the database hasn’t been persisted.
In practice, the database copy is almost always updated by the time the 5 minutes has expired, so assuming the value is updated exactly 5 minutes after requesting is pretty safe.
When you’re logged in and on a map, the map instance server you’re connected to has authoritative control over your character data. It only writes it back to the database when certain events occur. The database is read by an API backend component that can parse the account/character data; it’s cached by this component for ~5 minutes so that API requests can’t negatively affect game systems. Finally, the API frontend makes a request to the API backend whenever someone wants the data.
To get the data immediately, the API components would have to talk directly to the map instance servers — we don’t do this because the API is intentionally decoupled from all the game systems so that the API can independently catch fire and burn down without affecting anything else. (additionally, this is one of the main reasons why the API will ever only be read-only, for the most part).
I’m making some sweeping generalizations here, but that’s the rough explanation.
Just deployed the fix. For the interested, the global sums were including kills/deaths from Obsidian Sanctum, which isn’t listed in the maps array (also OS doesn’t count towards PPK when PPK is enabled).
They really shouldn’t — the map totals are computed on the API frontend as the sum of all the maps. The per-map kills/deaths are the authoritative values. I’m gonna track down why this is happening and have it fixed sometime this week. Here’s a tracking issue.
Hi guys, I’m not sure if I am missing something but since starting on API development in a nodeJs app recently, I’ve not been able to manage getting images to work. I would love it if someone could please point me to resources that show/explain how images are retrieved and how to display them?
What images in particular are you looking to retrieve? Most v2 endpoints that have icons/images have the fully qualified URL. For the v1 endpoints that return icon_file_id and icon_file_signature, the URL can be constructed via “https://render.guildwars2.com/file/$icon_file_signature/$icon_file_id.png”.
also is there currently (or future plans) to be able to display our character image in some form on the site?
There are plans but it’s more of a personal wish upon a star at this point. I basically need to integrate a software renderer into the game engine, then lift only the parts responsible for rendering into a server. I’m not really a server programmer nor do I know anything about graphics programming, so it’s like a six-month project for me that I don’t know when I’ll have time for.
The API backend doesn’t talk to a relational database — it talks to a backend server which basically serializes bits of the .dat file to XML/JSON. The canonical approach is to dump the data into a relational format and feed it to a fulltext index; the nature of our backend architecture currently makes this fairly difficult technically.
I think there are some third-party services which provide such an API, though I can’t recall which ones.
If you could map Chat/Combatlog-information inside this mumble mem-file. We would be able to build stuff like “better” combat announcements, in combat time tracker for raids or even a dps calculation.
The MumbleLink format is unsuitable for chat logs. The format is fairly rigid and really only meant for data that can be read/written semi-atomically (e.g., camera position and such). Adding more fields to the exposed data runs into both space and synchronization issues (dirty reads are already a thing that applications have to work around).
Thanks, got the info I need. The dupe events in-game are an artifact of the guild inventory bits using the same system as old-style upgrades. I’m not really sure if that can be fixed.
Those events returned by the API are being created on the game server with a zero’d user id which is why they’re not being correctly emitted. I’ll raise the issue with someone who’s knowledgeable about that; I’m not sure if/when it’ll be fixed though.
The user field should be appearing already — it is on my local server. I’m also not seeing the duplicate entries locally. Could you PM me an API key with guild access and the guild ID you’re looking at? That’ll help me track down what’s broken.
They don’t appear in the whitelist queue until someone’s completed them. For normal achievements, there’s an additional caveat that a request to /v2/account/achievements will automatically whitelist any results — but dailies are not current returned from that endpoint, so they’ll probably only appear around 10:30AM PST Mon-Fri :/
4. If this isn’t possible, is there a way to request images to be added to the v2/files/ endpoint other than listing them sparsely through forum/github posts?
Having separate github issues for each bundle of file requests is the easiest way for me to keep track of things. I’ll toss all your requests onto this issue since I haven’t started rooting around for the last batch yet.
Looking over the server logic for when an entity dies, it’s roughly like this:
1. If the entity being killed was an NPC, stop.
2. Increment deaths for the killed entity’s team.
3. If the last hit on the killed entity was by an NPC, stop.
4. Increment kills for the last team to hit.
(okay, for a second I thought the problem was “kills are higher than deaths” which really threw me for a loop — that shouldn’t be possible).
Deaths are higher than kills likely caused when someone is killed by an NPC affiliated with a team (e.g., failed to solo a camp or ate SM lord’s meteor during a brawl), it’ll count as a death (since the NPC is team-affiliated) but not as a kill (since the last-hitter is not a player).
A player killing an NPC (team-affiliated or otherwise) definitely does not increment the deaths counter.
I’ve got a vanilla javascript example for rendering emblems. It’s not ideal, but it mostly works.
There’s also gw2w2w.com which a lot of sites hotlink to (you’ll probably want to ask permission first) — but their rendering backend is available on github if you want to stand up your own instance or check out how they’re rendering emblems (it’s a nodejs application).
It would be faster on your end to batch calls to /v2/recipes and /v2/items with the ?ids parameter, e.g. /v2/items?ids=1,2,3,4. You can request up to 200 resources at once. Alternatively, you could use /v2/items?page_size=200&page=N to pull all the item data (and /v2/recipes?page_size=200&page=N to pull all the recipe data) and it’d probably be less network overhead.
Ultimately, it doesn’t make that big of a difference performance-wise on our side, so I’m not too concerned about it. If you’re making under 100k requests/day (which comes out to about one request/second) it’s not really a big deal.
Yeah, I think that error message gets kicked back when you’d get less than 1 gem back. I’ll try to make the error message a bit better. There’s an open issue for this on github.
Bleh, the kill/death data has been flaky since I implemented it.
I’m really not sure why the NA/EU resets are causing each other to reset — I thought I’d quashed that — but I’ll see if I can get it fixed. Re-opened the github issue for this.
