Guild Emblem Editor: http://nailek.net/gw2/emblemeditor
Stats increase on all items
Guild Emblem Editor: http://nailek.net/gw2/emblemeditor
Oof, not really sure why it isn’t returning the updated values. Will look into it — by my reading it should already be using the updated tables
Thanks for the heads up.
Also a bit weird that is has “AccountBindOnUse” instead of “AccountBindOnAcquire” as rings don’t come un-bound, no?
And description is very wrong (says +32 Power instead of 94 or 126)
Although now that you say it, 94+32=126.
This may have to do with the fact that you can’t have upgrades on ascended rings, so maybe in-game it uses a weird trick to compensate?
Guild Emblem Editor: http://nailek.net/gw2/emblemeditor
Although now that you say it, 94+32=126.
This may have to do with the fact that you can’t have upgrades on ascended rings, so maybe in-game it uses a weird trick to compensate?
Yeah, the description in buff might be driven by hidden attributes of sorts. Though it’d be more useful to have them as individual items instead of having to parse "buff"’s description to calculate total stats
IIRC, there’s some madness with how some attributes are enabled — healing power I believe has always been encoded in a string -_-
I’ve never been happy with the entire .details blob for weapons/armor. It’s structured to mirror the internal representation of the data rather than what you’d expect it to be like. I really want to change it, but haven’t figured out how to do it in a backwards-compatible manner.
On another note, the attribute named “CritDamage” should now be “Ferocity” (since the April 2014 Feature Pack).
Example item: https://api.guildwars2.com/v2/items?ids=48075
Guild Emblem Editor: http://nailek.net/gw2/emblemeditor
A few of the ascended items have weird stuff like some of their stats (the jewel part) is in a string and the (base stats) are in an array with attributes/modifiers as id. In fact, for Althea’s Ashes (39233) has
["description"]=> string(36) "+32 Power +18 Ferocity +18 Precision"
and then
["attributes"]=> array(3) {
[0]=> array(2) { ["attribute"]=> string(5) "Power" ["modifier"]=> int(78) }
[1]=> array(2) { ["attribute"]=> string(9) "Precision" ["modifier"]=> int(56) }
[2]=> array(2) { ["attribute"]=> string(10) "CritDamage" ["modifier"]=> int(56) }
}
For other non ascended items, the modifier and attributes SEEM to be ok (includes the jewel stats). Maybe a good backward compatibility way would be to simply update the attributes as appropriate?
On another note, the attribute named “CritDamage” should now be “Ferocity” (since the April 2014 Feature Pack).
Example item: https://api.guildwars2.com/v2/items?ids=48075
“<c=@flavor>”
o_O
Oookay
I guess all ascended items have description with that tag which should add a class to HTML or something.
Oh and yeah, CritDamage is also in some other ascended items (where description add-in correctly says Ferocity. i.e. https://api.guildwars2.com/v2/items?ids=37005 )
On another note, the attribute named “CritDamage” should now be “Ferocity” (since the April 2014 Feature Pack).
Example item: https://api.guildwars2.com/v2/items?ids=48075
“<c=@flavor>”
o_OOookay
I guess all ascended items have description with that tag which should add a class to HTML or something.
It’s more than ascended items — a lot of named items have flavor text too.
Be aware that the syntax for those “tags” is maddeningly loose; it’s not XML.
That’s a great opportunity to figure it out and convert it all to a format that makes more sense. Future you might even thank you one day :P
If there is really a lot of stuff to change, maybe a v2/items2 endpoint would be a good idea? This way, it would be entirely entirely backwards-compatible at least.
Guild Emblem Editor: http://nailek.net/gw2/emblemeditor
If there is really a lot of stuff to change, maybe a v2/items2 endpoint would be a good idea? This way, it would be entirely entirely backwards-compatible at least.
I was just gonna go with /v2/itemz or /v2/shinies.
Yours is probably better though.
Is there any chance that the “buff” values on ascended items will ever get rolled into the “stat” values on the API side in the future, or is that something us devs will have to do on our end if desired?
Another way to be backwards compatible would be to have the old block stay there, but add a new block on items, which presents things in a saner way. Then if there’s ever a v3, we can drop the old block.
Alternatively, give us a cheat sheet endpoint that tells us skill_id 15755 is {power: 32, ferocity:18, precision:18, agony_resist:5}
If there is really a lot of stuff to change, maybe a v2/items2 endpoint would be a good idea? This way, it would be entirely entirely backwards-compatible at least.
I was just gonna go with /v2/itemz or /v2/shinies.
Yours is probably better though.
Could be /v2/normalizedItem
As you’d make it a more sane version versus “historical representation”
Another way to be backwards compatible would be to have the old block stay there, but add a new block on items, which presents things in a saner way. Then if there’s ever a v3, we can drop the old block.
That’s probably the approach I’ll take — just throw in a .details.stats field for weapons/armor that’s an object whose keys are the attribute names and values are the amount each attribute is adjusted.