Curiosity question:

On a query like:
census.daybreakgames.com/xml/get/eq2/character/?name.first=Roammerr&locationdata.world=Antonia Bayle&c:show=type,equipmentslot_list&c:resolve=all

For the cloak (Visionary Scaled Cloak of the Archmagus) I get that the adornments are the effects on that piece of gear (refined, experimented). How do I get the effects and the actual adornments on the item?

 

This comes from their use of the term (and fieldname) "adornment_list" and "adornment" in 2 different contexts. Players tend to think of adornments as the slots and things you put in them. but SOE also uses it for the "built in" effects (aka the Blue Effect names, and the descriptive block below). The confusion comes in because you are using c:resolve to join item views onto the player data, and there is a field name overlap.

In the case of your cloak, it has 2 "native adorns"/effects called "Greater Draconic Might" and "Archmagi's Aura" right? Still with me? Good, cuz its going to get complicated.

In the (unresolved) player view of data, the adornment_list, is a list of the SLOT adorns YOU have equipped, as this is specific/unique data to YOU.

In the view of the item on its own, the adornment_list holds the "native" adorns/effect list, using name= properties, and this is perfectly fine to do, as this item exists on its own, in a vacuum.
<img src="https://dl.dropboxusercontent.com/u/83100/eq2/resolving_adorns3.png" class="bbCodeImage LbImage" alt="" />

If you look at your player equipment data WITHOUT using c:resolve, you will see ANOTHER adornment_list, this time, representing YOUR "slot" adorn choices. These will have a color, and an id (no names)
<img src="https://dl.dropboxusercontent.com/u/83100/eq2/resolving_adorns2.png" class="bbCodeImage LbImage" alt="[IMG]" />

Now, when the api does the join on the player equipment id, and the item data, the two adornment_lists get merged together. Because they dont intersect on data (one has color+id, the other just a name), they get merged in a strange way.

In this picture, the purple roped area of the adornment_list is related to the adornmentslot_list data, and the blue roped area is the "native" adorn effect [i]names[/i], but isnt connected to the ids listed in the same row.
<img src="https://dl.dropboxusercontent.com/u/83100/eq2/resolving_adorns.png" class="bbCodeImage LbImage" alt="[IMG]" />

Again, this all happens because you are resolving two things ontop of each other into 1 call. Each set of data makes sense on its own.

AFAIK, you cant resolve the adorns in that same call (Feldon will prob correct me on this). But you can easily take those id= values and do api calls to get them on their own (the nice part of that, is that people tend to have lots of duplicate adorns, like how you have two of the same on that cloak, so you will need to do far fewer adorn lookups then you think).

FYI: if any API dev/"red names" ever read this, you can save us all a HUGE set of confusion and resolving issues on this exact thing, by changing the "adornment_list" in the /item/ view to "effectname_list" since these are the "names" of the things going on in the "effect_list" rows

 

c:resolve on equipmentslots has some bugs and can be very confusing as Uberfuzzy pointed out. EQ2U actually doesn't use it for our Character View. Instead, we pull the character without that resolve, and then join in all the items and compare them all to figure out reforging (except on items with green adorns, which don't pass reforging info GRRR!!).

Gear Report on EQ2U does uses c:resolve=equipmentslots (because I didn't know how to do the other ) and I've had a number of problems as a result.

The most obvious bug in c:resolve=equipmentslots is if a character has 2 of an item equipped, like two mastercrafted weapons, only one of them will resolve. The other will just have the itemid and nothing else.
Also, since you specifically mentioned Refined, there is data in Census for Experimented (the boosts="" field) but there is no specific marker in Census for Refined. All you can do is compare the base item to the resolved item and if you figure experimentation in your calculations and at least ONE stat is still higher than it should be (like 15% more than the base item) then you know that item is Refined.

I was really hoping that a sane way of reading Refined would be added, but it never has, so I guess I'll need to add the fragile, crazy, could break at any time way.

 

I, and I'm sure there are others, appreciate the time for the detailed explanation. Thank you very much.
I was just curious why it was doing it.

Argh!

I've already figured out that I need to do local caching of data. After one run of one character and then each item. I pondered for a little bit on how you guys were getting the speed you were getting then it dawned on me the second run through. Do you keep cache for "static" forever or do you refresh it periodically? Any performance/operational tips you can offer? I'm just building stuff for a raid group that wants to be able to do reports on who's where gear progression wise in a nice compact format like Gear Report over at EQ2U. I've got it at base stats and include indicators on which items have empty adorn slots, which slot. Building in exceptions to the rules (like certain 170 stat range pieces with a red adorn are better than 187 Steward without the red, etc.)

 

Yes.

We cache everything, especially AAs which we never dreamed was possible to do in realtime (until Dedith at Dragon's Armory showed us how it's done ). When you view an Item Details page, we check if that's the latest version of that item. Everywhere else we use items, it's the cached version. Same for Character and Guild. We check to see if they are the latest when you load the actual details pages for those, but everywhere else, we're on cached data.

I'm sure you're doing this as a tinkering project, but if there are any features you'd like to see me add to Gear Report, let me know.

 

Yeah, just tinkering around trying to save someone 6 hours of doing character look ups to check their gear stats and manually building an spreadsheet and doing it all over again the next time they check.. Work smarter, not harder. Sure, it's taking some time to learn some stuff but it's sure saves more time in the long run when you do it once a week.

If I think of something to add to the Gear Report, I'll definitely let you know. I think this is just a one of a kind thing that's specific to this group. Doubt anyone outside the group would ever need to be able to see at a glance if a character is completely geared in EM raid gear and which slots still need pieces so they can add a third character to your raiding rotation. But *shrug* Feel free if you think your users would find it useful enough to implement something like it. It's funny, I put the page live and the first thing I got from one of the members was "but that's experimented and has better stats" so that's what started me looking at the refined/experimented stuff.

 

An item can be Experimented up to 5 times. Each time the item is experimented, a Prefix is added to the item:

1. Experimented
2. Prototypical
3. Innovative
4. Ingenious
5. Visionary

Each Experimentation session on an item adds a boosts="" value to the stat that was increased. Experimentation on a stat multiple times yields a diminishing return on the boost:

1. +10%
2. +5%
3. +2.5%
4. +1%
5. +0.5%

If someone were to experiment on the same stat 5 times, it would result in a boost of 10% + 5% + 2.5% + 1% + 0.5% or +19%.

If a Mastercrafted item is created with a Refined rare, than most of the item's stats will be increased by 10% (some will be increased by 5%). Here is the master list of stats affected by Refining. Thanks to the Design team for this list:

• AGI
• INT
• STA
• STR
• WIS
• Artistry
• Fletching
• Sculpting
• Metalshaping
• Metalworking
• Tailoring
• Artificing
• Chemistry
• Scribing
• Adorning
• Tinkering
• Fishing
• Foresting
• Gathering
• Mining
• Transmuting
• Trapping
• Alcohol Tolerance
• Swimming
• Tracking
• Disarm Trap
• Pick Lock
• Safefall
• Crit Chance
• Crit Bonus
• Potency
• Ability Mod
• Hate Gain Mod
• Ability Reuse
• Casting Speed
• Recovery Speed
• Spell Reuse
• DPS
• Attack Speed
• Multiattack
• AE Autoattack (1/2 as modifiable as other stats)
• Strikethrough (1/2 as modifiable as other stats)
• Accuracy (1/2 as modifiable as other stats)
• Spell Weapon Multiattack
• Spell Weapon DPS
• Spell Weapon AE Auto (1/2 as modifiable as other stats)
• Lethality
• Toughness

 

When you look at a character WITHOUT the resolve, then only those stats which have been CHANGED by an adornment, reforging, or experimentation bleed through. Let's look at an example Cloak (LINK) (I hid adornments just for clarity):

HTML:

<equipmentslot displayname="Cloak" id="19" name="cloak">
  <item id="17926794">
    <modifiers>
      <all displayname="All" reforged="true" type="normalizedmod" value="315"/>
      <intelligence boosts="1" displayname="int" type="attribute" value="206"/>
      <critchance displayname="Crit Chance" type="modifyproperty">
        <addon_list>
          <addon value="13.200001"/>
        </addon_list>
      </critchance>
      <basemodifier boosts="2" displayname="Potency" type="modifyproperty" value="12.750000"/>
      <critbonus boosts="2" displayname="Crit Bonus" type="modifyproperty" value="12.750000"/>
      <spellweaponattackspeed displayname="Spell Weapon Attack Speed" minitemlevel="102" reforged="true" type="modifyproperty" value="7.480000"/>
    </modifiers>
  </item>
</equipmentslot>

Ability Mod (all) is listed because it was increased from Reforging.
Intelligence is listed because it's been Experimented once (boosts=1).
Crit Chance is listed because of two +6 crit chance adornments.
Potency (basemodifier) is listed because it's been Experimented twice (boosts=2).
Crit Bonus is listed because it's been Experimented twice (boosts=2).
Spell Weapon Attack Speed is listed because it was reduced by Reforging.

So looking at the basic version of the Cloak, we see that the base Crit Bonus and Potency are 10.2%. We see above that these two stats have been Experimented twice each due to the boosts="2". So if we take 10.2 and multiply by 1.15, we get 11.73%. Nope, that's still short of the 12.75% we're seeing. But if we take 10.2 * 1.25, we get 12.75%. So by induction, we test and determine that this item has been Refined.

But remember, only the stats affected by Reforging, Experimentation, or Adornments are shown above. What about Wisdom? Where's the Stamina? Where's the Spell Reuse and Ability Casting Speed? Those are also increased by 10%, but aren't listed anywhere. And if we do a c:resolve=equipment slots, we get the base values of those stats, not the improved values.

So to <span style="text-decoration: line-through">kludge <span style="text-decoration: line-through">jerry-rig add support Experimentation and Refined, you have to step through all the stats on an equipped item against the base item, find at least ONE stat that is too high to be just from Experimentation, and then you have to use the master stat list above to boost ALL those stats by 10% plus any boosts from Experimentation. And finally, you have to add an item prefix based on the number of boosts.

Dedith of Dragon's Armory is doing all this nonsense. EQ2U does not yet do this <span style="text-decoration: line-through">convoluted mess process.

 

Technically, I'm only doing this in the updated code base. I have not pushed it live yet.

 

^ that is a <span style="text-decoration: line-through">convoluted mess process.
I think I'm just going to cache as requests happen instead of crawling the data and caching it up front. Since it's a such a limited subset of the data I don't really see a need to get it all. And the performance will go up as items get cached.

 

And lookie what happens when you take out name and resolve equipmentslots LINK: (hint, look at value/value_merged for intelligence)

HTML:

<modifiers><all displayname="All" reforged="true" type="normalizedmod" value="315"/><basemodifier boosts="2" displayname="Potency" type="modifyproperty" value="12.75" value_merged="10.2"/><critbonus boosts="2" displayname="Crit Bonus" type="modifyproperty" value="12.75" value_merged="10.2"/><critchance displayname="Crit Chance" type="modifyproperty" value="27.700001"><addon_list><addon value="13.200001"/></addon_list></critchance><intelligence boosts="1" displayname="int" type="attribute" value="206" value_merged="171"/><spelltimecastpct displayname="Ability Casting Speed" type="modifyproperty" value="7.0"/><spelltimereusespellonly displayname="Spell Reuse Speed" type="modifyproperty" value="5.6"/><spellweaponattackspeed displayname="Spell Weapon Attack Speed" reforged="true" type="modifyproperty" value="7.48" value_merged="31.1"/><stamina displayname="sta" type="attribute" value="171"/><wisdom displayname="wis" type="attribute" value="171"/></modifiers>

 

Your link structure with a character ID followed by a resolvable field name, followed by a resolve, is not one I am familiar with. As far as I know, EQ2U doesn't use any queries like that!

I have have to admit I have not seriously investigated Census.soe.com (a different server cluster) beyond experimenting with PS2 data. We've typically used Data.soe.com for performance reasons. PS2 publishes a substantially larger chunk of data for each character, and on a much more frequent basis. Also one shortcoming I noticed about Census.soe.com is that YAML/YML is disabled. YML has been invaluable to me in determining the correct path to a specific field.

So I'd be curious to learn more about this link structure you have posted above. It might solve some significant problems we're having with Refining and Experimentation.

 

The link http://census.daybreakgames.com/xml/get/eq2/character/502511775266/equipmentslot_list?c:resolve=equipmentslots
goes: census/resultstype/get(duh)/game/collection/id in that collectoin/subcollection ?resolve sub-subcollection of that subcollectoin.
Not really sure why I ended up trying that query. I could have probably meant to try a c:show but c/p a resolve instead. Immediately noticed it got me the worn stats, the item base stats, and the worn modifiers (reforging and experimenting).

Which is great... IF I could get my stupid program to deserialize the xml properly. it dead ends where it thinks that character_list.character.equipmentslot_list.equipmentslot[x].item.modifiers is an object[] instead of a list[]. Probably something xsd is doing when I'm building the classes (Yeah, I'm taking shortcuts and not hand coding the classes to handle it). *shrug* I'll get it if I have to IList the object I can get to with the current class and enumerate from there.

 

If you don't do the c:resolve just the way you've listed it above, you don't get the magic. Only by doing /id/section_list/?c:resolve=sections are you getting this magical "value_merged". None of these URLs do it:

http://census.daybreakgames.com/xml/get/eq2/character/502511775266/equipmentslot_list
census.daybreakgames.com/xml/get/eq2/character/502511775266/equipmentslot_list
census.daybreakgames.com/xml/get/eq2/character/502511775266/equipmentslot_list?c:resolve=equipmentslots

I used to like XML. Until I started trying to read large quantities of it. Forget it. It's maximum effort, minimum result.

Read from Census as JSON and then use json_decode($blah, TRUE); and you will get a beautiful array with everything just where it should be. I know json is hideously difficult to read in a browser. JSONview plugin for Chrome makes that a lot better though.

 

Yes, the /id/section_list/?c:resolve=sections is what causes the value_merged.(EDIT: and it only works on census, not data) I was looking at the original query that I started with with the resolve and the adorns and how it was merging the data from the worn and the effect and started poking around trying to figure out exactly what other data I could get "merged". I stopped doing that and was playing around with resolving only the specific information I wanted (I only wanted worn modifiers from equipment_list) and hit upon the /id/section_list. The resolve was I think supposed to be a show or a hide when I was playing with it. I'm still playing around with the queries and seeing what oddness I can throw at it that ends up with a valid result.

XML is slower than almost anything else I've worked with. I'll probably re-write and use JSON but for now I'm doing XML for a couple reasons. Most of which is I've never worked with an XML data source before and am enjoying learning the different ways of getting data out of it.
Right now I've got everything running and working except a couple formatting things. Now I'm going to pick it apart, streamline it, move stuff into classes, etc. That'll make it easier to move over to JSON since I'll have the core finished and just will have to re-do the data fetch/parse parts.

EDIT: Not sure what the differences are but I've found that generally, census returns more information that data.

 

There's definitely some weird/interesting stuff on census.daybreakgames.com vs. census.daybreakgames.com. I wish we didn't have to guess though.

 

The value_merged has nothing to do with a subsection, that's just an incorrect param and ignored.. The following works fine to get the same effect:

http://census.daybreakgames.com/xml/get/eq2/c...olve=equipmentslots&c:show=equipmentslot_list

However, this doesn't help our issue with the refined stats. It just removes the need to pull the item data separately (which is a nice point..) We'll still have to detect it via experimented values. The other values are not showing as altered, so there is no value_merged for agility/stamina/etc (check the ranged item in the link above, it's refined and experimented)

 

Hrm. Looks like we don't even have to put a c:show in there. So we don't have to reference equipmentslot_list.
http://census.daybreakgames.com/xml/get/eq2/character/id?c:resolve=equipmentslots
I'm still learning and playing around with it. *obviously*

In the meantime, if anyone is interested in looking at what I ended up with (excuse the performance, it's on a test machine with the cache hosted on another machine, I'll be moving it soon) http://jmachek.net/ReadyCheck.aspx (it only looks for exact first name on Antonia Bayle)

 

Just a heads up, the value_merged and boost values don't show up for everything. Still trying to find an accurate way to figure out refining and experimenting.

HTML:

<equipmentslot id="10" name="right_ring" displayname="Finger">
<item id="4048288548" displayname="Tempered Azure Ring of Discipline" displayname_lower="tempered azure ring of discipline" gamelink="aITEM -246678748 1880890739:Tempered Azure Ring of Discipline/a" iconid="4195" individual_drop="0" itemlevel="99" last_update="1.372777426644088E9" leveltouse="95" maxstacksize="1" player_studio_creator="" tier="MASTERCRAFTED FABLED"tierid="9" ts="1.372777426644088E9" type="Armor" typeid="3" visible="1">
<_extended>...</_extended>
<adornment_list>...</adornment_list>
<adornmentslot_list>...</adornmentslot_list>
<effect_list>...</effect_list>
<flags>...</flags>
<modifiers>
<agility displayname="agi" type="attribute" value="152"/>
<all displayname="All" type="normalizedmod" value="159"/>
<arcane displayname="arcane" type="ac" value="6831"/>
<basemodifier displayname="Potency" type="modifyproperty" value="9.1"/>
<critbonus displayname="Crit Bonus" type="modifyproperty" value="9.1"/>
<doubleattackchance displayname="Multi Attack Chance" type="modifyproperty" value="21.700001"/>
<dps displayname="Damage Per Second" type="modifyproperty" value="23.799999"/>
<elemental displayname="elemental" type="ac" value="6831"/>
<flurry displayname="Flurry Chance" type="modifyproperty" value="4.0"/>
<noxious displayname="noxious" type="ac" value="6831"/>
<stamina displayname="sta" type="attribute" value="152"/>
<strength displayname="str" type="attribute" value="152"/>
</modifiers>

 

It's because you have a green adornment, the green adornment is triggering nothing to being placed in the data from the resolve.