EQ2 Item Data for 2013

Additional data was added to Items in 2013. A tutorial is still needed for the original Item spec.

Negative Item Identifiers

When viewing an in-game item link, sometimes the itemID (the first number) is negative. For example:

\aITEM -276085484 -1628941263:Stalwart Thudomatonian Chausses\/a

When you see a negative ItemID, that means you're seeing a SIGNED version of the ItemID. If you convert that to UNSIGNED, then you'll have the correct number. If you are using PHP, then you can use:

$id = sprintf("%u",$id);

Another workaround is to add 4294967296 (2^32).
Do the math and -276085484 + 4294967296 = 4018881812 which is the correct itemid:

census.daybreakgames.com/get/eq2/item/4018881812​

Harvestables

All items which can be harvested now have a HARVESTABLE flag.

Code:

<flags>
<harvestable value="1"/>
.
.
</flags>

Classifications

Some items which can be used as a material in crafting have gained an additional info block called classifications. For example a xegonite cluster:

Code:

<classifications>
<raw/>
<materials/>
<metal/>
<condition/>
<xegonite/>
</classifications>

Set Bonus Info

Items which are part of a Set Bonus now have the correct information to display the effects, and find (through an additional search) other items in the same set. For example,*Necklace of the Aberrant

Code:

<setbonus_list><setbonus descriptiontag_1="Increases range of divine damage spells by 3." effect="Applies Reach of the Aberrant." requireditems="3"/>
<setbonus all="20" requireditems="5"/>
</setbonus_list>
<setbonus_info desc="" displayname="Aberrant Set" id="123200294"/>

Could be displayed as:

Aberrant Set (1/5)

• 3) Applies Reach of the Aberrant
  • Increases range of divine damage spells by 3.
• 5) Increases Potency of caster by 20.

A query could be used to find other items in this set.
<span style="color: #d40000;">House Item Placement

House items have gained some new info, including whether they can be placed on the floor, wall, or ceiling, house, dungeon, or guild hall, or any combination of the above.

Code:

<typeinfo house_type_all="0" house_type_dungeon="0" house_type_guild="0" house_type_no_dungeon="0" house_type_no_guild="0" house_type_no_player="0" house_type_player="1" layout_ceiling="0" layout_floor="1" layout_wall="0" name="houseitem">

Item Patterns

At long last, items which are a "pattern" used by crafters to make other items now list these subitems within their data.

Code:

<typeinfo name="itempattern">
<item_list>
<item displayname="Armored Cincture of Rage" id="1307014436"/>
<item displayname="Blood Drenched Dagger" id="714287629"/>
<item displayname="Blood Drenched Great Sword" id="2121261717"/>
.
.
</item_list>
</typeinfo>

Item Containers

Some items are "crates" (internally called miscbags) which, when opened/consumed will place their contents in your bags.

Code:

<typeinfo name="itemcontainer">
<item_list>
<item displayname="Circlet of Erollisi Roses" id="3399868954"/>
<item displayname="Blackened Vanguard Armor Crate" id="1524946781"/>
.
</item_list>
</typeinfo>

Note: This will not help with crated items, etc. which, when unpacked, give you a dialog box with 1 or more choices of item. Those are mystery crates and will require other types of data to be exposed.

Individual Drop

A new flag has been added to all items called individual_drop. If true, it means that when the item is looted, all group members receive one. This is useful for quest updates, shards, obols, etc.

Code:

<item ... individual_drop="1" ... >

Weapon Type / Required Skill

The requiredskill field was added to support Adorning and Tinkering skill on certain items, but has revealed some other unexpected values, specifically, the exact type of each weapon like Bow, Dagger, Fists Spear, Sword, etc. Creative use of this field depending on item type can be very useful.

Code:

<requiredskill min_skill="1" text="dagger"/>

min_skill is only of value on items with Adorning or Tinkering ability:

Code:

<requiredskill min_skill="450" text="tinkering"/>

 

The classification flags, when viewed in JSON, are very strange indeed. One might say, broken.

Perhaps this should be done more like the "flags" list, although perhaps even better: just list the classifications that apply, or if using an array here is really too hard... return a list of values exactly like the flags list.

So, rather than:

"classifications": {<ul ><span >"carbonite": {},
"condition": {},
"dynamic_purchase_value": {},
"inorganic": {},
"materials": {},
"metal": {},
"raw": {},
"spike": {}
},

One has:

"classifications": [ "carbonite", "condition", "dynamic_purchase_value", "inorganic", "materials", "metal", "raw", "spike"]

or

"classifications": { carbonite: 1, condition: 1, ... }

or

"classifications": { "carbonite": { value: 1 }, ... }

 

Classifications is a bit strange yes. I thought it would be very useful on tagging crafting items, but the HARVESTABLE flag took care of that. I think the main use of Classifications was back when crafting required subcombines and interdependency.

I thought I might be able to get rare vs. common so I don't have to have a hardcoded list of each, but Classifications doesn't have that.

At this point the only thing I am using Classifications for is <transmuting_material />.

This transmuted product looks as if it could be used for crafting level '.$item->itemlevel.'-'.($item->itemlevel + 9).' adornments.

 

Actually, I don't mind the current method.

1. We don't need any value per se

2. It reduces unneeded data size

3. It can be searched via Census url: census.daybreakgames.com/jml/get/eq2/item/?c:has=classifications.metal&c:limit=100

 

Let me point out the inconsistencies and why I think it is broken.  Note this is in JSON format, which I am consuming.  The XML may be OK, but the JSON is rather odd.

Flags look like:

flags: { ornate: { value: 1 }, foo: { value: 0 } }

Classifications look like:

classifications: { foo: {} }  #  note the empty hash as a "true" value, and no presense meaning false

House placements are also strange:

typeinfo: { layout_wall: 1, layout_ceiling: 1, ...}

So, now we have three distinct formats for JSON data to represent what is, at its heart, an array of flags.

The typeinfo for house_type is even more confusing.  It also uses 1 and 0 to mean true and false (good!) but it has _all, _player, _guild, and _dungeon.  Then confusingly it also has _no_player, _no_guild, and _no_dungeon.  This makes it somewhat hard to build a set of placements, where I want something like ['guild', 'player'].  Will I expect to find _all, _no_player to mean _guild and _dungeon are permitted?  Will I ever see the confusing _player and _no_player both set?  Why have _player and _no_player both?

IMHO, when these changes were committed without any concern about the JSON output, since the XML looked OK.  And I agree it does, but XML is not the only (nor preferred) format for many use cases.

 

I generally mess with queries through XML, but we ingest the data in JSON format and store a JSON blob for each item for display purposes. Then I walk through it, unpacking the various parts I recognize and ignoring the rest. This sometimes means that I am checking for the mere presence of a field, or its value, or a field.value.

As for classifications, if you add a fieldset, I'm not sure if all the subfields can be optional or what. I'd rather not see this:

<classifications raw="0" rosewood="0" materials="0" wood="0" condition="0" spongy="0" loam="0" finished="0" magical_scintillating="0" leather="0" dragonhide="0" porous="0" metal="0" xegonite="0" wood="0" ebony="0" jewel="0" moonstone="0"...... ad nauseum... />

It looks like some items are getting missed because quite a few house items don't have the house layout or placement flags, and only 16 items have a harvestable.value = 1 under flags.

 

That is how I do it as well, in general.  I just dislike having new things added that make a new form of parsing, such as how the classifications were added.  They are unlike anything else.  There is presidence for using a value of 1 or 0 to mean true and false, and there is presidence of using a hash with a value: 1/0 element.  I prefer the former, simplier way.

I would also have liked typeinfo.layout_* and typeinfo.house_type_* fields to be in its own element:

typeinfo: { layout: { wall: 1, floor: 0, ceiling: 0 }, house_type: { ... } }

But let's try to not add more ways to mean "this flag is set" and try to organize presentation as much as possible...

 

Found two other goodies in <classifications>.

Collectible:
<eig />

Guild Status Items:
<scrying_stone />
<sealed_document />
<amulet />
<relic />

 

I've looked through all the house items and none of them have more than one flag set in each group of tags. I suspect they're set exactly as you guess, since the possibilities are that the item is placeable in one, two, or three house types. If it's one, then dungeon, guild, or player = 1. If it's two, then no_dungeon, no_guild, or no_player can be set, and if all three, then all = 1.

Not all the tags are used, though, There are no items that can be placed in player houses and guildhalls only (no_dungeon). 7 items are showing as no_player, although these appear to be mis-tagged and should be no_guild.

There are also 1,314 house items still missing placement data.

 

Hopefully we can get this flopped. For now to work around the problem, I am matching no_player and no_guild and displaying "This may not be placed in guild halls."

I knew there were some but that's a lot. Hopefully that number can be whittled down to zero. EQ2 team is launching content tomorrow but maybe in the days after...

 

Coinpurses

Coinpurses are items that you never actually see in-game in EQ2. It is a random amount of coin from a*minimum*to a*maximum*that you get for looting the corpse or chest of an enemy. They've been published to Census in preparation for loot data.

The data on some of these is pretty straightforward. For example this data:

Code:

<typeinfo name="coinpurse" perplayer="0">
<coin_list>
<coin max="4892" min="6912" type_id="0" type_name="copper"/>
</coin_list>
</typeinfo>

would indicate that between 48 silver, 92 copper and 69 silver, 12 copper will be split between the group.

However on other coinpurses, the data is nuts:

Code:

<typeinfo name="coinpurse" perplayer="1">
<coin_list>
<coin max="261" min="239" type_id="2" type_name="gold"/>
<coin max="7187" min="6418" type_id="1" type_name="silver"/>
<coin max="66" min="59" type_id="0" type_name="copper"/>
</coin_list>
</typeinfo>

The above data would indicate a minimum of (59 copper + 18 silver + 64 gold + 39 gold + 2 plat) or 3p3g18s59c and a maximum of (66 copper + 87 silver + 71 gold + 61 gold + 2 plat) or 3p32g87s66c is granted to EACH player present.