Guild Wars 2

It still seems weird to me to “clamp” results to a given range “just because”, but I have very little experience with colorspace transforms like this.

So it’s perfectly alright to correct the result of a transformation (like applying contrast to RGB or a saturation-shift to HSL) if said result is outside the allowed range? If G < 0, just kick it up to 0? If S > 1, just smack it back down to 1?

947 White actually gives L > 1. I’m not sure how I didn’t notice this before.

name: "White"
    default: {
        brightness: 52
        contrast: 1.85938
        hue: 185
        saturation: 0
        lightness: 1.99219
    }

Base color: (R:128, G:26, B:26)

Apply brightness: (R:180, G:78, B:78)

Apply contrast: (R:224.68776, G:35.031, B:35.031) <— completely sane, no negative values

Convert to HSL: (H:0, S:0.75777, L:0.50925) <— matches the workwithcolor.com converter

Apply HSL transform: (H:0, S:0.51389, L:1.01453) <— L > 1 ???

Looking at smiley’s listing, it appears that colors 1222-1230 are the hair colors exclusive to the Self-Style Hair Kit, and colors 1231-1242 are the dyes from the Flame and Frost Dye Kits. The hair colors only have a default material, while the dyes all have cloth/leather/metal. This definitely supports Rhino’s hypothesis.

Cliff noted that while digit 1 follows that pattern currently, it’s not guaranteed to remain that way in the future. So just be aware of that.

I’m writing in Perl. My module is on GitHub.

Hmm… Correcting up to 0 solves Midnight Fire, but I’m still getting problems with S * saturation > 1. Let’s go back to color 592 Cherry on metal that I mentioned before.

name: "Cherry"
    metal: {
        brightness: -5
        contrast: 1.13281
        hue: 356
        saturation: 1.17188
        lightness: 1.05469
    }

Base color: (R:128, G:26, B:26)

Apply brightness: (R:123, G:21, B:21)

Apply contrast: (R:122.33595, G:6.78933, B:6.78933) <— completely sane, no negative values

Convert to HSL: (H:0, S:0.89484, L:0.25319) <— matches the workwithcolor.com converter

Apply HSL transform: (H:0.98889, S:1.04865, L:0.26703) <— S > 1 ???

Rhino, basically what you’re saying is that I should “correct” any negative RGB value to 0 before converting to HSL? Just want clear confirmation of this before I go put it in my code.

Doh, sorry, I’ve tracked my issue backwards now – it’s when I apply the contrast transform, and it gives me negative values for G and B.

Color 482 “Midnight Fire” for material “cloth” has “brightness”=-38;“contrast”=1. Applying that to the base 128,26,26 produces 90,-12,-12. I’m obviously missing something here, but I’m not sure what it is.

It’s not that the API’s saturation/lightness shift values are > 1, most of the time that’s okay because the calculated S/L that they get applied to are small enough that the result is still < 1. Also, I only see this problem on S, never on L (i.e. L * lightness is always < 1).

Color 592 “Cherry” has “saturation”=1.17188, however, the cloth and leather materials are okay; only on metal does this output an S > 1.

I’ve set this up in my Perl module, and I’m running into cases where the saturation transform results in a value greater than 1, which in turn results in negative RGB values. I know that hue can just wrap-around (i.e. if hue > 360 {hue = hue – 360} ), but what do you do for saturation?

Think.8042:

“hue”: 340,

…

1. Apply Shifts: 0°+320°=320°, 0.75*0.82 = 0.615, 0.32*1.44 = 0.46 -> HSL 320° 61.5% 46%

I see a copy error: the hue shift should be 340, not 320.

I rolled my own Perl methods based on smiley’s PHP functions, and I’m keeping everything as floats throughout. My unrounded (to 5 decimals) result is 193.46350, 47.02226, 95.83601, which is similar to what smiley posted above.

I know Perl isn’t exactly fashionable these days (darn young whippersnappers), but it’s still my script language of choice. So have a Perl module, and get off my lawn. :P

GW2API.pm

• Language: Perl 5
• Admin: Dr Ishmael
• URL: https://github.com/dr-ishmael/GW2API.pm

You need a margin-left of about 100px on your .content_box, it’s hiding behind the #leftside-navigation for me.

DarkSpirit.7046:

Missing a weapon subtype enum, “TwoHandedToy”.

Completely overlooked those. Fixed.

Moturdrn.2837:

The foreground and background IDs for this match the order on the wiki (http://wiki.guildwars2.com/wiki/Gallery_of_guild_emblems). Do you know if the IDs returned by the API will match these or will there be another order for them?

The numbers I assigned to them for the wiki are simply sequential based on their file ID order within Gw2.dat. I seem to remember that this matched the order that they appear within the in-game emblem designer, so it may very well match up to the in-game IDs (although I wouldn’t count on it).

Each emblem actually has 3 textures, a composite texture showing the full emblem and one texture for each of the two color channels. The backgrounds are a single texture. All of them are alpha-channel masks, no RGB data at all.

The Pointless.3869:

O_O

I’ve noticed you’d commented that the ID numbers were ints as well. I had chosen not to do that in my version because, unless I’m unaware of something, there’s not really any reason to convert them, is there?

If you ever wanted to sort items by ID, it wold be necessary depending on your coding language. Perl, for example, is smart enough to convert numeric strings to integers automatically and return a numeric sort, but other languages will just return a string sort: 1, 10, 100, 101, 102, 11, 2, etc. Not that sorting by ID is really meaningful, but I’m sure some people would find reasons to do so.

The Pointless.3869:

And clearly, my use of terminology is pretty sloppy too. :\

I wouldn’t be so quick to criticize yourself there, I’m not really certain of the proper jargon for JSON myself, so I just used the terms I’m familiar with (list vs array, for example).

The problem with including vendor costs is that different vendors can sell the same item at different prices. I’m not talking just coin versus karma, but I know at one time during beta there was an item that different vendors sold for different amounts of coin.

A better way to present that data would be via a vendor_details.json API, that would key off of actor_id or something and list all the items the vendor sells, along with the prices.

In a crazy twist of fate, I did the exact same thing and posted it on the wiki at API/item details (link fixed) before I saw Pointless’s page. It would probably be a good idea for someone to compare our two versions to see if there are any discrepancies.

I’ve compiled all the item data, including ALL possible data elements, into a set of pipe-delimited CSV files. (Pipe because comma and semicolon are commonly used within descriptions and I didn’t want to bother with quoting stuff.)

They’re all in the following folder on GDrive: https://drive.google.com/folderview?id=0B5NobLNMdY89X05tZjZaTUo2X1U&usp=sharing

Also in there are the Perl scripts I used to dump the data. I wrote it using Perl 5.16, but it should work down to 5.10 (it uses the smartmatch ~~ operator introduced with that version). It also requires a couple non-core modules:

• JSON::XS
• List::MoreUtils

I know, I know, Perl isn’t really a fashionable language anymore, but it’s the one I like. So there. :P I plan to work the GW2API.pm module into a full-fledged SDK interface, but I don’t have a lot of free time right now.

Here’s some VBA I wrote for Excel. The Base64 module is from http://www.source-code.biz/ , but it expected all input to be ASCII, so I had to modify it to accept integer/byte-array inputs.

• Base64Coder.bas: https://drive.google.com/file/d/0B5NobLNMdY89bElkRE9yRzRPWW8/edit?usp=sharing
• GWID.bas: https://drive.google.com/file/d/0B5NobLNMdY89U1hTRVl5QWlWWm8/edit?usp=sharing

Usage:

=EncodeGWID(12345)

=DecodeGWID(“[&AGXXXX]”)

Map on wiki of 35 pumpkins in LA

The high hit rate can also useful, especially if running a high Precision/CritDmg build with traits and sigils that exploit critical hits, like Rending Strikes (33% chance for vulnerability on crit) or a Sigil of Fire (10/20/30% chance for flame burst on crit).

I ran this for a while in PvE – until I completed Axe Master – and I pretty much blended everything that got in my way. Rending Strikes on Cyclone Axe + Whirling Axe usually resulted in at least 10 stacks of vulnerability, meaning my auto-attack did 10% more damage to finish things off.

I’m not a PvP player, so I can’t comment on how well a build like that would play in PvP, but it was great in PvE. Swords suck in comparison, but I gotta chase that Sword Master title. :P

The issue is that it’s only applying +0.1% per point (verified in the PvP lobby), but the displayed bonus is always rounded up. It’s not clear whether this is a bug or intended, so a response from ArenaNet would be nice.