Guild Wars 2

EasonPro/CronosPro. They’re included at the top of the wiki’s Common.css.

On the buffs, you again reiterated exactly what I had said. Because ascended trinkets and back items don’t have a standard upgrade slot, they instead have a “baked-in” ascended jewel. These baked-in stats are supplied as a buff, rather than being part of the base attributes. As I said above, I believe this to be due to how the base attributes are generated during item creation.

When ascended trinkets were first introduced, the base attributes and the buff’s attributes were listed separately in the tooltip. Refer to this screenshot from November 2012:

http://wiki.guildwars2.com/images/archive/2/22/20131223230756%21Ascended_example.png

This actually reminded me that Magic Find was treated the same as Boon/Condition Duration, it always had to be added as a buff. That’s why Yakkington’s Ring shows two entries for Power/Precision but only one for MF – Power/Precision are the only base attributes, the base MF and the jewel’s MF are added together in the buff.

In May 2013, this was changed so that the base and buff attributes are added together in the tooltip: http://wiki.guildwars2.com/wiki/Game_updates/2013-05-28#Guild_Wars_2_Wiki_Notes_2

I can’t explain All Seeing or Engagement Ring. The latter’s buff doesn’t even have a description.

Look at this old version of the Faithful page:

http://wiki.guildwars2.com/index.php?title=Faithful&oldid=524308

It used to have Magic Find as an attribute. That’s why the API entry no longer has an infix_upgrade for the old Faithful, 25951.

Now look at the new Faithful, 47091: https://api.guildwars2.com/v1/item_details.json?item_id=47091

This is exactly what I described above – the original versions of MF items were stripped of their infix, and new items were created to replace them with different stat combos.

Alcarin.9024:

1. Image errors:
the following image are 16×16 instead of 32×32 like the others:
item_id:24695 Major Rune of the Flock
https://render.guildwars2.com/file/2BA523C17A3BE0D6D2EC773361746A6FE3282E23/222500.png
https://render.guildwars2.com/file/2BA523C17A3BE0D6D2EC773361746A6FE3282E23/222500.jpg
item_id:24766 Minor Rune of Dwayna
https://render.guildwars2.com/file/BC7E4DD2B7717AD7054CAFE103C7BEAC55C8142B/222502.png
https://render.guildwars2.com/file/BC7E4DD2B7717AD7054CAFE103C7BEAC55C8142B/222502.jpg

That’s just how some icons are. Most skills use 128×128, but some of them have 64×64 icons. Same thing with items.

2. Not correct item type (or subtype):
7. items: 64754 ( “Pirate Captain’s Outfit”), 64756 (“Cook’s Outfit”), 65194 (“Executioner’s Outfit”), 65195 (“Bloody Prince’s Outfit”), 65196 (“Mad King’s Outfit”), 65198 (“Fancy Winter Outfit”), 65201 (“Witch’s Outfit”) are type=Consumable, consumable.type=Unlock, consumable.unlock_type=Unknown. Unlock_type=Unknown, is an error?

Internally, all these enumerations (types/subtypes, rarity, etc.) are stored as integer IDs, and the API has to use lookup tables to translate the internal ID to a text representation. ‘Unknown’ is the default value when an internal ID doesn’t have an entry in the lookup tables, and it usually shows up when a new ID is added to one of these enumerations.

3. Minis 21047 (Miniature Rytlock) and 39090 (Risen Priest of Balthazar) are the only two miniatures withouth a description.

Simply anomalous, I wouldn’t call it an error.

4. Items have no indication if they are usable by a crafting profession (this info is available in in-game tooltip) and the relative level requirment.

This data is not part of the item’s data entry. It is generated for the in-game tooltips exactly as StevenL described, rendered here as pseudo-SQL:

select discipline, min(rating)
from recipe_tb
where item_id in (ingredient1_id, ingredient2_id, ingredient3_id, ingredient4_id)
group by discipline
;

5. I’ve found on Trinket and Back (I’ve not analyzed Armors and Weapons yet) that the stat bonuses (back.infix_upgrade) sometimes are splitted in attributes and buff, both give bonus to character attributes. Are there any reason for this? It could be very useful to have all bonuses with the same structure of back.infix_upgrade.attributes instead of splitting them.

Two reasons:

1. The internal mechanics of how the game handles attribute bonuses on equipment don’t recognize Boon/Condition Duration as attributes. Thus Giver’s armor/weapons have to have a buff applied to them in order to modify these attributes.
2. The baked-in ascended jewel on ascended trinkets/back items similarly has to be added as a buff, rather than being added to the infixed attribute bonuses. This is probably due to how the item creation process generates default attribute bonus values based on type/level/rarity.

In both cases, I doubt it would be possible for the API to combine them.

6. item_id: 2 “Assassin Pill” ?

No clue.

7. Antique Gold Dye (item_id 20476) is the only Dye with rarity Basic.

Again, this is simply anomalous; it’s a starter dye, so the rarity doesn’t really matter.

8. There are about 28 Alcholics (consumable.type=Booze) missing

Probably due to the discovery bug that still seems to plague karma vendors.

9. There are 2125 weapons withouth info about stats (weapon.infix_upgrade), some are correct, but a lot no, I’ve saw a lot of Exotic weapon withouth any info about their stat…

I bet most of those will have Pillaging/Explorer’s/Traveler’s/Wayfarer’s prefixes.

When Magic Find was removed as an equipment attribute, all affected items were modified to remove the infix attributes. At the same time, they added a new architecture to the game where players can double-click an item with no stats to select the stats from a list.

All clothing items were removed from the game, so yes, that value is now defunct.

The only trace left of clothing is on characters who haven’t been to the BL Armorsmith yet – they have a data record of what clothing they were wearing before April 15, so the game can determine which tonics or consumables to give in return.

That’s the kind of statistic a game developer never makes available, because they don’t want the public to have a clear, objective measurement of how many people are actually playing the game.

StevenL.3761:

https://api.guildwars2.com/v1/skin_details.json?skin_id=2388

{"error":10,"product":71,"module":2,"line":314,"text":null}

source of skin_id: https://api.guildwars2.com/v1/item_details.json?item_id=23009

There are quite a few skin IDs listed on items that aren’t in the skins API. They also don’t appear in the wardrobe.

That’s not metadata, Jazerix, so my statement stands: event_details.json still works the same as it did before Megaservers. I never said or even implied that it is a replacement for events.json.

All zones have been Megaservered. Yes, this makes the events.json API useless.

event_details.json gives metadata about the events, so of course it still works.

While looking through the data from the skins API, I discovered what appears to be a text bug:

https://api.guildwars2.com/v1/skin_details.json?skin_id=145

The skin is for Light Armor Leggings, but the name is “Student Circlet”, which is a helm name. The name used for the items before the Feature Pack was “Student Pants”.

http://wiki.guildwars2.com/wiki/Student_Pants

StevenL.3761:

What exactly is this /characters API? I have to know now.

Eventually (hopefully soon) Anet will implement a method by which you can “login” to the API in order to access account-specific information such as character and guild info.

Wow, way to derail the thread, you two. Take it to PMs, maybe?

Discovered something else just now – in terms of chat links, outfits are not skins. They use the prefix 0×0C (12).

And yes, I checked, but outfits.json does not exist (yet). Considering there are only 7 outfits, and new ones are released rarely, it may not be all that useful anyway.

Skin/wardrobe prefix is 0×0B (11).

Stefan Larimore.6872:

But will be more useful once we ship APIs that show personalized items, such as the /characters API.

Any news on how soon we might see those?

Discovered a new attribute on item_details.json: default_skin. Woo-hoo!

Bored at work, on a whim I decided to just type “skins.json” into the URL. And whaddaya know, it worked!

https://api.guildwars2.com/v1/skins.json

Okay, how about skin_details.json? Yep!

https://api.guildwars2.com/v1/skin_details.json?skin_id=1343

The details appear to be a stripped-down version of item_details.json. I haven’t attempted to process everything yet, but here’s what I’ve seen so far:

{
skin_id: integer,
name: string,
(maybe) description: string,
type: enum(Armor, Back, Weapon),
flags: [any(“ShowInWardrobe”, “HideIfLocked”, “NoCost”)],
restrictions: [<race>],
icon_file_id: integer,
icon_file_signature: string,
(maybe) armor: { type: <armor_subtype>, weight_class: <armor_weight>},
(maybe) weapon: { type: <weapon_subtype>, damage_type: <damage_type> },
}

I’d guess that type can also be Outfit or Back, but I haven’t found any of those yet since there are so few compared to armor and weapons.

[edit] Found type:Back, does not have a back:{} sub-object.

[edit2] Found flag HideIfLocked, seems to be on most gemstore skins. This explains all the people on reddit who couldn’t unlock a quaggan backpack (because they hadn’t opened the container yet) and also couldn’t see it in the wardrobe.

[edit3] Doesn’t look like outfits are in here at all.

Nope, you just have to loop through items.json and call item_details.json for every item_id. My Perl script runs 4 threads and takes about an hour to process everything. Once you’ve processed every item for a build, though, you can skip any items you already have data for – item data can’t change on-the-fly, only with a new build.

The “break” is that the base item name for suffix-able equipment is no longer present. If the item has a suffix_item_id, that item’s “suffix” is returned as item_name, otherwise you get a blank item_name.

Items with the “HideSuffix” flag are unaffected, e.g. legendary weapons. There are some others as well, but I don’t see a pattern for them yet – one is item_id 57 “Hearty Back Brace”.

UncleSniper.4086:

it would (in theory) still be possible to expose all event status — only by instance ID rather than map ID.

The only way that will be useful is if they also make it possible to find out which instance_id your character is currently in. And that won’t be possible, if they do it at all, until after OAuth2 is implemented. So don’t expect it anytime soon.

Becka Williams.4978:

This thread answers the question: yes, they are absolutely going to go ahead with megaservers, and nothing we say will stop them.

Uh… why would you have ever thought differently? o_O

That’s correct.

• The data returned by item_details.json / recipe_details.json / map_floor.json / colors.json / etc. can only change when a new build is released.
• items.json and recipes.json will have new IDs added as players discover new items/recipes, so you should probably check them periodically.
• event_names.json is special because it’s a combined static/discovery endpoint. New events will be added to the list the first time they run after a build, but the name is then static and can only change after a new build.

I already asked basically the same question: https://forum-en.gw2archive.eu/forum/community/api/The-API-the-Wiki-and-the-Wardrobe but instead of proposing new endpoints, I suggested that they just add skin_id to item_details.json (the data is probably already structured this way anyway, which should make it relatively easy to implement).

I don’t know what else you would expect to get from a wardrobe.json endpoint… I doubt they would be able or willing to host model/texture files the same way they do item icons.

chephan.8527:

Also, as far as I understood: The worlds won’t just go away. If it is just some kind of forced guesting you just need to figure out what wolrd you’re on.

The world-map linkage is going away – maps are no longer linked to any specific world. The world_names.json endpoint will only be meaningful for WvW after this.

Question for Stefan:

• With the upcoming wardrobe changes, every equipment item (armor, back, and weapon types) will be able to unlock a skin in the wardrobe.
• On the wiki, we would like to be able to document this by listing the skin in the item’s infobox at one end, then at the other end be able to list all the items that share a skin.
• So the question is this: Is there any chance that a “skin_id” or similar element can be added to the item_details data structure for these item types?

The same way you remove sell orders? Open the BLTC window, then follow my screenshot:

1. Click on “My Transactions”
2. Select “Items I’m Buying” from the dropdown
3. Click “Remove”

Ta-da!

You can already remove buy orders (“custom bids”) and get the full amount back.

Regardless, this is in the wrong forum.

LadyRhonwyn.2501:

I picked one of those unlocks, and I have an item type of “Consumable” and a type of “unlock” in my database…

He’s talking about the unlock_type value for those, not the consumable.type.

https://api.guildwars2.com/v1/item_details.json?item_id=36517

{"item_id":“36517”,“name”:“Limited-Use Snowman Finisher”,
…,
“consumable”:{"type":“Unlock”,“unlock_type”:“Unknown”}}

LadyRhonwyn.2501:

And most items that can be bought using karma (the same goes for recipes).

Those have always been missing, due to how the game reports “discovered” items – karma vendors aren’t in the loop for some reason.

I would guess this is because the actual values in the core datastore are numeric, and the API uses a lookup table to translate them into strings. The lookup table simply hasn’t been updated with entries for these new sub-types, so the lookup fails through to the default of “Unknown”.

Items, recipes, and events are also broken, only returning a small set of results.

This is a known bug.

Kahrgan.7401:

Reinforced Shield This should be adept tier.

Not gonna happen, he stated in the Dec. 10th elementalist discussion that they don’t like having recharge-reduction at the adept tier.

Killer Rhino.6794:

I’m still putzing around about requesting wiki access

Bah, just do it! Until then, you can always start writing the page in your userspace and it can be moved later.

I assume your actual intent with that is the ability to query all items with Rabid attributes? You’re still kitten a bit in that, due to named exotics and karma items that don’t include the stat prefix in their names.

Bandlero.6312:

There’s no real single item search outside of knowing the recipe/item ids (i.e. no request by name (like the guild API supports), by crafting profession, etc.)

Requesting by name wouldn’t make sense for items, because item names are not unique and you could get any number of items returned. Guild names must be unique, so you know requesting a guild name will return exactly 1 guild (or 0 if it doesn’t exist).

Been done by a lot of people. The most popular ones are probably:

• http://gw2hero.com/
• http://us.gw2stuff.com/

Lil Puppy.5216:

Some events move, I don’t believe the API gives current GPS type location info, only starting location info.

That’s correct, the API only lists the starting location of the objective, it does not track the current location.

It’ll probably be in the Gw2.dat file somewhere. Good luck finding it, though.

Forum search in general is pretty much borked, and has been for a while.

Ice of Dragons.1637:

the dragon timers website changed to : http://wildworlddev.com/apps/dragonpro.html
can someone change it on wiki

Fixed.

EU server time is GMT. US server time is PST. Both of them adjust for summer time / daylight saving time. There’s no need for an API for this, you can get it from a site like http://time.is/ .

http://time.is/London = EU server time (I think)
http://time.is/Los_Angeles = US server time
http://time.is/UTC = The only one you really need to figure out daily reset time.

The only one I know of is http://gw2.maximeloizeau.fr/invasions.html

I don’t really understand why HTTP errors are being returned at all, except for explicit 5xx server errors and 404 errors for non-existent endpoints (e.g. /v1/character_data.json). (And 401 for authentication issues on OAuth2-enabled endpoints.) As I see it, an API error is not an HTTP error – the endpoint was reached successfully, so the HTTP status should always be 200. If the client supplied misspelled parameter names or invalid parameter values, those errors should be returned in the JSON content, not as an HTTP error code.

It seems like this would simplify things a bit. At the HTTP level, the client only needs to worry about handling 5xx and 404 error codes, which indicate that no response can be returned at all. Any other valid request should return HTTP 200, in which case the client should then check the JSON content to see if an API error was returned.

LordBanon, look 3 and 4 posts above yours.

We’d have to corner an Anet dev to find out why they did it like this, but that’s how Magic Find (before it got removed this month) was applied to equipment from the beginning – a buff effect (all effects are skills) that is always active while the item is equipped.

When they added stat prefixes with Boon Duration and Condition Duration, those got added the same way, with an always-active buff. (example)

When they made ascended trinkets, the base item’s attributes were handled normally, but they used a buff to add the “baked-in” upgrade component’s attributes. Originally these were displayed separately in the item’s description, such that Tome of the Rubicon would show 2 entries for each attribute. This image on the wiki still shows the old style. Anet changed this on May 28, 2013 to only show one entry per attribute.

Omit the braces, that’s the first problem. The second is that I think you’re trying to use map/continent coordinates, which equate to pixels at the highest zoom level. You need to use tile coordinates, which start at [0,0] and define the individual tile image’s position at the given zoom level. Third, the lowest zoom level is 1, not 0.

https://tiles.guildwars2.com/1/1/1/0/0.jpg
https://tiles.guildwars2.com/1/1/1/0/1.jpg
https://tiles.guildwars2.com/1/1/1/1/0.jpg
https://tiles.guildwars2.com/1/1/1/1/1.jpg

Take a look at Smiley’s code to see how to handle this.

Eurhetemec.9052:

I don’t think the data on the wiki is actually accurate to the way colours behave in the game, either.

You’re talking about how the colors are actually applied to specific items, which is really outside the scope of this thread (and has been discussed in-depth before, see Smiley’s link). The wiki’s data is accurate in terms of hue/set/material groups (except for the material on Tequatl dyes, as White Wolf noted) and in terms of the base cloth/leather/metal RGB values provided by the API.

Specifically, see my second attachment in the thread that Smiley linked. Y coordinates get inverted when translating between continent and map coordinates, I don’t know why, but that’s why you got a point near the south end of the map when it should be at the north end.

In your fiddle, after the initial calculation of yMap, you need to do:

yMap = 1 – yMap;

before the yContinent calculation.

[EDIT] Whoops, I just realized that there are parentheses missing in that image. After the first set of parentheses in each equation, the (B2 – B1) terms should also be in parentheses, with the final + B1 outside of parentheses. If I have time later I’ll try to remember to type that all up in LaTeX again.

We’re talking about the groups that dyes are placed in by the in-game dye panel, where you can group them by hue, set, or material.

• Set is mostly based on the rarity. The Starter set is automatically unlocked on all characters (can’t check the rarity on them), the Common dyes are all fine rarity, the Uncommon set are masterwork, and the Rare set are rare. The special Living Story-related sets (Flame and Frost / Tequatl Rising) are also rare, so there’s no obvious differentiation there.

• Hue does appear to be based on the actual RGB values of the dye color, although I have no clue what the breakpoints are between e.g. Red and Purple or how you would identify dyes in the Brown or Gray groups.

• Material is the most mysterious. Supposedly, it would identify which armor material the dye was designed to look best on – Natural Leather and Natural Metallic, obvious, for leather and metal respectively; Vibrant for cloth or “everything.”

The wiki currently knows these properties for every dye in the game, but it would be convenient for non-wiki sites to have this data available from the API.