Feedback and issues/questions regarding the data feeds

I've been working with the fields for a couple of days now, using PHP and SimpleXML.  So far no major issue were encountered.  I'm making sure to use one of the indexed fields whenever possible (with one exception, which only occur at configuration time when retrieving the Guild ID).  So, performance is really good so far.

I only worked with the XML format, so I can't say if the same issues also apply to the JSON format.

Issues:

- Sorting doesn't seem to work properly when used on fields that contain text (for example, Guild names).  And that's when I actually type it right (thanks for clarifying the direction argument BTW)

- In the Guild collection, the guild['guildstatus'] attribute contains 0.  Should that contain the amount of status accumulated toward attaining the current guild level, or is that some status flag that reflects something else?

- Occasionally, some characters will return "0" for the amount of completed quests.  If I try the same query later, it seems to properly get filled.  Seemed rather random, and occurs only with a few characters out of a test guild of 200+ characters

- The c:case modifier doesn't seem to work for me when trying to do a search (searches are always case-sensitive).  Unless it's an error on my end.

Questions:

- Once characters will start being flagged as private by their owner, will they still appear in the guild collection, or disappear completely?  My personal recommendation would be to still list them in the guild collection, with their proper dbid, however masking out their name with "Anonymous" or something like that.  Just so rosters will be able to properly reflect the total number of members, and have a unique identifier to distinguish between the different anonymous character, while still making it impossible to retrieve any additional info through the character collection.

- The old EQ2Players was providing some item discovery info on the Guild page (number of discovered items server-wide and world-wide, and the last discovered item).  Will it be possible to also retrieve this info with these new feeds once leaaderboard info becomes available?

- Is there any defined API for error handling (http error codes, or an XML-formatted error page)?  One suggestion I could make for scheduled downtime is to have a redirect page stating that the feeds are currently under maintenance.  Combined with an HTTP result code 307 (Temporary Redirect), this could be easy to handle at a the client's end.

- Is it more efficient to send a query with a lot of c:show fields, or to use c:hide on a few fields instead?

Overall, the feeds are working great.  I've worked with another MMO's XML feeds in the past, and while they were pretty good, the SOE feeds are far, far more versatile.  If those feeds can stay in-sync with actual game data over time, then this will be awesome.  (for reference, that other MMO's XML feeds started experiencing issues after they launched an expansion).  Thank you for putting this online <img src="/station/images/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" />

 

We'll start digging into these issues as quickly as possible.  

One thing, it does appear that c:case has NOT been implemented.  I'm going to remove that from the DATA API for now.  Our implementation *IS* case sensitive.

-dan

 

It is much more efficient to only c:show what you need instead of using c:hide.

-dan

 

First, please forgive my ignorance if I am wrong on this. If I try to combine a character lookup with a c:resolve, the response can take 60 seconds or more.bad:

• census.daybreakgames.com/xml/get/eq2/character/?displayname=^Feldyren&c:show=warders;c:resolve=warders

good:

• census.daybreakgames.com/xml/get/eq2/character/?displayname=^Feldyren
• census.daybreakgames.com/xml/get/eq2/character/463858445365?c:show=warders;c:resolve=warders

Am I doing it wrong?

 

Try using name.first instead of displayname, and removing the caret so you can search by exact name.  This query seems fast here:

census.daybreakgames.com/xml/get/eq2/character/?name.first=Feldyren&c:show=warders;c:resolve=warders

 

One thing that is wrong in the syntax is that you should use ampersands ("&") to combine multiple items in a request instead of the semicolon (";").

Instead of...

<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">census.daybreakgames.com/xml/get/eq2/character/?displayname=^Feldyren&c:show=warders<span style="font-family: verdana, arial, helvetica, sans-serif;"><span style="color: #ff0000; font-size: large;">;<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">c:resolve=warders

...it should be...

<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">census.daybreakgames.com/xml/get/eq2/character/?displayname=^Feldyren&c:show=warders<span style="font-family: verdana, arial, helvetica, sans-serif;"><span style="color: #00ff00; font-size: large;">&<span style="color: #333333; font-family: verdana, arial, helvetica, sans-serif;">c:resolve=warders

It is totally okay to use displayname in this fashion as it is indexed.

I'm seeing some performance issues right now that I'm not happy about.  I'm digging in more.

-dan

 

It does look like the ";" will work, but the preferred way is to separate query string components with an "&".

The database seems to be doing better.  We are running a job to convert all of the existing images (paperdolls, headshots, etc.) so that they can be included with the new c:attachment Query Command.  There are a lot of them, so it will probably run most of the day.

-dan

 

Another thing you may want to do if you're trying to pull back a specific character is to include the server:

census.daybreakgames.com/xml/get/eq2/character/?name.first=Feldyren&locationdata.world=Butcherblock&c:show=warders&c:resolve=warders

This restricts the query to one specific name on one specific server and should only return one specific character which I believe was the goal.

 

That actually brings up another question.

I've been using locationdata.world to limit my searches to a specific server.  Is this a reliable thing to do going forward?  In the character data itself, in the displayname, it has "Character (World)" but this isn't split out into a separate field anywhere other than locationdata.world.

My concern is for the current battlegrounds and potentially any future cross server group capability.  If I go to battlegrounds, since my location has changed, will it push new data potentially changing locationdata.world to something other than my home server?  I know it would be changed right back once I zone home but is this something I should be concerned with? 

I would have thought name.first=Character&locationdata.world=World would have been better than searching for displayname=Character+(World)  but now I'm not so sure.

Thanks

Dethdlr

 

Either should work.  The displayname field is a useful field for displaying this information (hence the clever name).  It is very useful when you use a regex - displayname begins with "blah" (or =^blah).  You could do a more complex regex that looks for a name and a server within the parentheses.

locationdata.world is perfectly fine to use for searches.  This *shouldn't* be affected by battleground use. 

-dan

 

That was the only thing that worried me.  What does locationdata.world say when I'm in battlegrounds.  If it still says Butcherblock (for me), then we should be good.

Thanks!

 

First and foremost, thanks for this new API!!  Now onto my feedback:

Character Collection:

1. I never understood why Transmuting was never within the secondary tradeskills data in the prior feed, nor in this one.  But I do see it down in skills data with everything else so that's completely workable.
2. I would have loved a raid boss kill count feature for use in individual character progression tracking.  However, I'll be able to nightly process each guild member achievements to at least track down who's killed what.

Guild Collection:

1. Guild member points, can we get those added to the guild collection such that our officers only need to update DKP in the game vs having to updated it in game and on our website? (filterable by guild leader)
2. Guild calander events, can we get a list of scheduled calander events?  I would love to have these show up in an external calander on the website as well. (filterable by guild leader)
3. Guild event log, would be nice to see as well. (filterable by guild leader)
4. Guild member notes, would be nice too. (filterable by guild leader)

Will there be any collection for monsters or even just raid bosses?  It would be nice to link the kill achievements to a collection id for a that raid mob with maybe it's proper name and and icon or picture of the mob.  I'm mainly looking at progression tracking with this data.

I presume the desired method for pulling data is to cache as much as possible on our end to allieviate any workload from the soe servers?  I'm mainly looking at rebulding our Recruiting, Progression Tracking, and Roster portions of our site (a guildportal page)

These are just initail thoughts/feedback from presusing the data manually.  I'll post more when I delve more into coding for it.

 

This system actually pretty generic and game-independent.  The information is all provided by the game team to us and we make it available.  To get additional data (i.e. monsters, etc.), we just need to make that request to the game devs.  I think a good collection for this would be one that represented all NPCs within the game - monsters as well as quest givers and such.  I will certainly pass this along.

This is your ultimately a decision for the consumer of this API.  I expect that different customers will have different requirements and technical ability.  At one end of the spectrum is a full-service site like yours, but the other (equally important to us) is a fan that wants to embed information on their Facebook page or Tumblr blog.

We have designed the REST service such that we will have storage and capacity to meet the needs of anyone who wants to request data.  If you feel that you must cache the data to improve performance or to implement a particular feature, then please go ahead.

The ultimate "source of truth" for all of this information is within the game itself.  If the DATA service does not get an update, or if you miss an update on your end - it cannot affect the gameplay for those in the game itself.  

Thank you so much Dedith!  Please do keep your questions and concerns coming.  This will only be as useful as what you guys push us to deliver.

-dan

 

(cough, cough) Alternateadvancements resolve (cough, cough)

Sorry, had a bad cold lately. 

 

Yeah...that too.  

One caveat on this is that we are going to be freezing the implementation later today for much of the holiday season.  I am going to still be doing some development, but it won't be pushing out to production until after the New Year.  I will be putting up a post on both forums to get feedback from you so that we can best prioritize our efforts.

-dan

 

I ran into another data oddity tonight.  One of the characters (a level 90) is currently reporting -180 for its stats->health['max'] and 4908 for its stats->power['max'].  Sounds as if instead of reporting the character's max, it reports the current value (and the character might have logged out while dead, which could explain those values).

 

I seem to have the extraordinary talent of coming up with Queries that keep the server very busy and I eventually get a Gateway Timeout. So I will get more specific in my Queries to try to minimize that. Thanks!