It was the 0×02 chat codes (for items) that were used for text coloring, not 0×03. I didn’t notice the error in your thread title until just now.
They modified the functionality of the 0×03 (dialogue) codes a few months ago. Instead of being shown in the chat box, they now only make the dialogue bubble appear over your character (see the talk page of the article you linked).
The obvious gap in a system like DarkSpirit’s is, of course, when an already known item/recipe changes. This happened to a lot of them on Sept. 3, when all existing equipment with Magic Find had their attributes removed, upgrade components that affected MF had their attributes/effects modified, and the recipes that crafted MF equipment were updated with a new output_item_id.
This is the gap that most of us (I assume) are covering by re-downloading the full item/recipe APIs after every release, just to be certain we catch all possible changes. Any system that could tell us which items had changed would make this step much more efficient. One option that I remember being mentioned a while back is to add an MD5 hash of the item/recipe’s JSON data to the API (maybe in a new endpoint like items_md5.json/recipes_md5.json). That way, we can easily tell which items/recipes changed by comparing their MD5 hash between releases.
They altered the item links so that they no longer include the encryption key within them. This is what allowed for the links to be corrupted in the past, so without that part of the link, the days of candy-colored guild adverts are finally over!
Bots have – or should I say had – ways of finding nodes long before the API. But I haven’t seen a gather-bot in at least four months now, so it seems that Anet has figured out how to detect them and ban them efficiently. Either way, exposing node locations in the API wouldn’t affect bots significantly.
Check the wiki talk page, bottom section, user Akyh posted a link to his site where he’s been tracking them through the API. I assume he’s doing it by watching a specific event related to the invasions.
Based on the history he shows, my guess is that there’s a 4 hour cooldown (accounting for the 45 minutes duration of invasions) and a 2 hour window.
The base achievement data, like you’re asking for, could probably be served up in the current API, but it wouldn’t be terribly useful until Oauth2 is implemented so you can actually see your account’s achievement data.
Pillaging is no longer in the game, it was replaced with Hunter’s when they removed Magic Find from equipment. This recipe would now produce a Box of Hunter’s Scale Armor, and indeed, the recipe sheet that unlocks recipe 1010 was renamed to Recipe: Box of Hunter’s Scale Armor. The fact that the new output item isn’t in the API simply means that no one has crafted this recipe since Sept 3.
That’s not how text encoding works – those are only representations of encodings. \u0000 is only used in prose to represent a Unicode codepoint, I believe. � ; is the HTML entity notation for an ASCII character – the number is the decimal representation of the character’s ASCII codepoint, i.e. & ; = & ; = &.
If I save the page to a text file, then open it with Word, it auto-detects that it’s UTF-8 encoded. If I try to force it into the Windows (Default) encoding, it looks like this:
You’re right, I forgot about food. There must be a separate NoAuctionHouse flag that isn’t currently being exposed through the API. The rest of my point stands.
The NoSell flag hides items from both the Trading Post and vendor lists. It’s likely that the vendor_value gets set at a different stage of development, and whoever sets the NoSell flag just doesn’t bother to zero-out the vendor_value.
I’m not sure about others, but until this is fixed I am unable to develop any of my tools which use the API. I am currently in the middle of a major overhaul of my application (gw2EventOly Suite) and because the results I’m getting for event state are so inaccurate, I can’t do any reliable testing. Are you saying we will have to wait until the next patch/update before this is fixed or will it (hopefully) happen much sooner.
Don’t use EU worlds to do your testing, there’s nothing wrong with events on US servers.
There was a thread about those two items a few weeks ago (I’d link it but forum search sucks). They appear in items.json, but return an error through item_details.json. The chat codes aren’t recognized by the client, so there’s no way to tell what these items are supposed to be.
and one item with an wrong name:
Vial of Qucksilver (should be Vial of Quicksilver)
Holy cow, I never noticed that. But the API uses the same underlying data as the game does, so I checked, and yes, that is the name of the item in-game as well. Funny that no one ever noticed that until now. I’ll go move the wiki page.
Don’t know if this is related to this forum or from your code, but your link seems to have the “&” signs html encoded (“&”), which causes the 404 error.
The buff is indeed a “skill” that gives an additional effect to your character when the item is equipped (remember that “effects” and skills are all the same thing to the game engine). The original need for this seems to have been Magic Find, presumably because it wasn’t set up as an “attribute” so they couldn’t stick it in the attributes array with power/precision/etc.
I can’t really say why they reused this system for the “inherent upgrade component” on ascended items, though.
You can parse it out into attribute and modifier values and merge them with the existing attributes list.
Alright, thanks. I’m a back-end programmer myself, so believe me when I say I understand where you’re coming from with the “not a trivial thing” response. We use it all the time. And the client never believes it! Pfah!
The item_details API lists the game_types that an item can be used in. I assume that this game_type is a map-level property, and while it’s relatively obvious for most maps, I think it would still be useful to have this as a return value within maps.json and map_details.json. It could even be added as a possible query value, allowing applications to restrict the return data to a certain game type instead of having to parse through all maps for all game types.
There’s a bug in the “item discovery” code that prevents some items from being flagged as “discovered.” Mostly this affects items purchased from karma vendors – the recipe sheets for rare/exotic insignias/inscriptions and sheets for random stuff from Renown NPCs.
The legendary gifts are purchased for coin from Miyani, but it seems like the same bug affects them.
Every armor item in my spreadsheet has a weight_class value. And yes, “Clothing” = town clothes. (For weapons, “Toy” and “TwoHandedToy” = town clothes weapons.)
Add all the possible event icons to files.json: “event_boss”:{"file_id":X,“signature”:"X"}
Then add a field to event_names.json to identify which icon an event uses: {"id":“5FE0AE58-2C78-4E44-9386-FDFE8B8C6767”,“name”:“Defeat Wiggin the Wicked.”,“icon”:"event_boss"}
I suggest event_names.json instead of events.json because, like the event name, it’s something that only needs to be retrieved once, instead of being retrieved every time you check event statuses (which some apps do every 15 seconds).
The only ascended items in the game right now are trinkets (and only ascended items have infusion slots). My item_details spreadsheet shows 120 trinkets with an infusion slot having been discovered by players – there are more that haven’t been discovered because it only lists 30 amulets while the laurel merchant sells 45 amulets.
Not a failure, just an inconsistency. But also an indication that the GW2 engine is robust enough to recognize both \n and <br> and translate them both to ASCII character 0×0D (linefeed). You should strive to include the same robustness in your program.
Too bad the wiki doesn’t keep track of “drop rates” for these.
That’s only because no one has bothered to start tracking them – we don’t automatically create drop rate pages for every known container item. And that’s probably because most people realize that these are a poor investment and very few people actually craft them.
This isn’t related to the API, but the method used to create the “colorized” chat text is a corruption of item chat links. See here. That’s why there’s always a [ at the beginning, and why it’s limited to the different rarity colors.
Those two actually pop up in your events monitor when the full meta event is complete – Flame Legion Battles when you finish capturing Incendio Templum, and A Celebration of Meat after all the events have succeeded. You don’t get any rewards for them, just a completion notification. I’ve never noticed any other meta events that do this.
So the actual issue that they exist as both a meta event and a normal event.
Back when I was playing around with guild emblems, I built up a collection of guild IDs by parsing the claimed objects in WvW every few hours. I would then go through all the guild IDs, look them up on guild_details.json, and (re-)build the guild emblem.
I noticed that sometimes, a guild ID that I had “known” previously would start to give this same error. The only explanation I could come up with was that the guild had been disbanded (either voluntarily or banned by Anet – a few of them did have offensive names).
Yep, Harathi Hinterlands is still there twice. The first has all POIs and all sectors, the second has all waypoints and vistas but no landmarks and only 1 sector (tasks and skill challenges are all present in both).
I just used the MF change as an example because it was recent and still on everyone’s minds.