WoWCenter.pl
wikass zabił Mythrax the Unraveler (Normal Uldir) po raz 2.     
kuturin zdobył 7th Legionnaire's Cuffs.     
Nikandra spełnił kryterium Loot 200,000 gold osiągnięcia Got My Mind On My Money.     
Tooly zdobył Fairweather Helm.     
Muattin zdobył osiągnięcie The Dirty Five.     
Yoozku zdobył Parrotfeather Cloak.     
Mlody89 zdobył Royal Apothecary Drape.     
Weakness zabił Dazar, The First King (Mythic King's Rest) po raz 6.     
liq spełnił kryterium osiągnięcia Saving for a Rainy Day.     
Osiol spełnił kryterium osiągnięcia Saving for a Rainy Day.     
Wuntu zabił Zek'voz, Herald of N'zoth (Heroic Uldir) po raz 1.     
Olsa zabił Vectis (Heroic Uldir) po raz 6.     
Sarenus spełnił kryterium osiągnięcia Saving for a Rainy Day.     
kajtasus zdobył osiągnięcie Come Sail Away.     
ossir spełnił kryterium osiągnięcia Saving for a Rainy Day.     
mcpablo spełnił kryterium Alliance players slain. osiągnięcia Frontline Slayer.     
Emmm zabił Taloc (Heroic Uldir) po raz 17.     
AsaGorth spełnił kryterium Big-Mouth Clam osiągnięcia The Oceanographer.     

Yellowsix

I ran into a minor bug this morning -- characters with the new Operation: Shieldwall rings equipped are showing up as empty via the API, e.g.
https://eu.battle.net/api/wow/character/Quel'Thalas/Babadochia?fields=items

finger2 is missing, but this person definitely has it equipped:
http://eu.battle.net/wow/en/character/quelthalas/Babadochia/advanced

Not a huge deal, but thought I'd post a concrete example if it helps.
Unusual Error Result from API” wysłany:
Every now and again, we get sporadic errors from the armory API that resemble the following (from the Mr. Robot site, www.askmrrobot.com):

(These errors all result from attempting to load a single character's information with talent, gear, and profession data included.)

This particular example happened when loading the character Heartsøng on Frostwolf (USA).

Anyone else run into this, or have any ideas as to the cause?


http status: 503 (service unavailable)

The response body contains the following:

body.ko-kr .info .title, body.ko-kr .info .twitter, body.ko-kr .footer { font-family: "Malgun Gothic", "맑은 고딕", "AppleGothic", "Dotum", "돋움", "Trebuchet MS", "Arial", sans-serif; } body.ko-kr .footer { font-size: 11px; } body.zh-cn, body.zh-cn .info .title, body.zh-cn .info .twitter, body.zh-cn .footer { font-family: "微软雅黑", "Microsoft YaHei", "Helvetica", "Tahoma", "StSun", "宋体", "SimSun", sans-serif; } body.zh-cn .info .twitter { font-size: 16px; } body.zh-cn .footer { font-size: 12px; } body.zh-cn .notice .logo span { background: url("/static/local-common/images/logos/bnet-default-cn.png"); } body.zh-cn .info .twitter { line-height: 1.5; background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAD4AAAA7CAMAAAAU0snFAAADAFBMVEUqMDXZDTfXCzfqBQXfIUP1//9ZJCnhK0rdBgrjAQHeAwXrUl2XFBjWCjbwdmnsS1vUABrYDDfkME1LKC3x///lLEbtCgrkNVBkIifeGT27CibaETrZCzLVBTPgHkDbDzfbFDv////+/v7iJ0cxLjP6gGzdDC3HCjH6dlmHFxrxa2L6///ptbv5eW3s7e7dHEH0amnvWGHTCQ/kOlL4c23oIj31WlVzGyH4+PjhHDzuISGnFReYFCo6LDL29varCxX2fWzbBC36+vrrXmFEKjFmHSb6c2OrHCnECQ3pQVbUACLbCA3xXmPXASvxTU7wQkPfFjnbACXnPFPrRVjVBAfy8vTXaHndETnUBwvGBwtbIi/aDDD8/PzYBS/OCi64CRktLzXpKD/3fHHt///5+fn9/v79/f2yDSv7+/vjJUTx8PH19PWUKy/uOkfjPUvuFxf0c2m6DjTXlJ3yembtxcv0tLzZCzf2hWrySFPZRlWDGSrlDhncyc/UrLbZWmi0EBT8hXHl8/P8//+0SVjvKyvbPVXsP03mY3jzY2WtMjTPdoX0gWfl7u70iW/yvsnl2uHkRFbWtLyqDTT4i230Z2eSEzbpbV31bFPOBgjcDi/xcWTl5eb6p5t3GzH+i3XbFj3x8vLjESTZDSPsl6foMkvnWnfojJ3KGjP++vrfDifuM0L+iGjlSGLFJzHZOEPx9vXq///zgnLDChXs9fSQDyvcFz7GDCfMBgfPCjV+Gx7uZGC7Cw3ao67b09f8+/z+///+/f3MCg7y/fz1iIz7/Pz9e2LnytDPKT3ufY/vPEvnb4Dw3N+hETH6jYDbKDznSFjhTln3bGrYfo3vorLXDDLn09biioTpRUteUlbj/vzsgoDUCzDsX079zs3lQ1rPMk3+/v9tHTDTEi+GGjT5+/v48vPfDzT1+PjxzdTsL0D8l4X+yb37ZmPUDjbwn5voSFPxMzPk7/HwqLj///7/8e/JgpD54+TVjJjSBzr//f7eHR2bT1GAaGs/NzvyQEru+vkpiOp2AAAAAXRSTlMAQObYZgAABehJREFUeF6dllN0JFsUhrvatq3Ytm3b9tC2bdu2bRvXtm3uU90zc9e6naRmvofOysO3///sqpMOiQiJnRMnfhBFelmilLsTGC7lpJdGMnxXSZXkBQRrooReXl4uSbTi+XsUBkMkUZU+ImX3nT7Xr3ftkN3ZmjKinJ4i0+ca+xMrGrn7lRP82P376/n9fBdlcgo21YW16cNUh/vXEpBvyRJiZ88eOnTozNhY8Kdl+nEEaeI2vUpVbe3VHhHGGTgTGIpwupzsvgh8QUH+JoteZVjd2xNqkSXwBw5E9sKdrkuX8Pn8E8HZfn6CtHxxW1gu9l6PduIRRYL7CqQv3Ll0yRPPx95F7Tc9X88exinIVzCoKqM2srYH20XMsekLXZcMmEs7a8KhDUroEqQFiC36Eg3Wv9uXr1ZteZtzwn0Ff+BM1ydzPUw/frHq89u3V71lMrXf+KwgX2yh5hoMX7V0l784V3EX0kF3enOU6edV4y5fhtUFB1/cZrowtS5fDO0NBoNosWNborUEgI7iY5Nf/zrWdeeaNeOcvAJ9cwK3mdrn1SmQjmEYz/G7f8vIsOv9+sUmL3UaB4ANb07XxQkTroTJGNTDSBe5OKofVe2DdD/c53vVOzk51dd7eQXeXzTNb8dgD+mDXIt+LegiEc/R41v9iMoImCfgZPq63+/nZScQ2Zl+Uwo+oq3U632MSCeTWxx1L9EzFGl3/b65s6dPn1eyg5NxGbc5nLprNzeG6VUaDNd1Dm5uf6MPQ5Ev6LN1xuj5owfMGHMPRnxpswUFabJNQW1Ula07Wevg5XUx+ljEAQXv//SalEaTNnw36tSD4ntTuv4eNkwAusJiaQsz4uE8XkWkA12jojIU4qunPc79YEJ4SMefHv1L8ZjJsqCgIJkYXRm7vrzFQXnNYYhve2elR+ilZvO7JhwP2r5Zp+cPKB5OdXZWoXAMbO1ytYPVYUYfqsVy9TEtOr6yyWzT7TMaxo8aMDkvTgM2mUd2qK/mQTyVUXGK1tEI+nPffpLXHuRpYXEQXrHdgS75FUP+x8MbLkA8qv8Ms/mc+bcJ+4qFtsU5rx9L+j8LRJgR/Lwt0r3R8c3NZijwTG8+0xhNu1JVRcbD13Md6MpfMcy41qckzhP8D880m5vMZ3EZ7MrWxg7pTU0WDw8fmURyGC/CNEZVXJWn9EJHY/yZSqjQ1GRuaq681Boa3d4wKEuH7O3rM6wgODo9GrA2C/pL98KA1tZKRGt8Y2hHkbf0hhCqgz0S7+5o+cjHNFXCtwehAdGhjYjQ6Ogi71kNc7J0ZDg4hHf3ZXmLLEK+ARPmTYUB0n8OrisqWrfO2/tgA22wNl2krUDhIaTuWEDGyOCjAnm7tny6lya18cmczelP7QhSt1gX8ERDYIAIM1QJhXGKzdc2Pvz+4Zap4nShTqR1RvZYUk8cOkYeAgMATJSVLhQK0/EPHR6N7F6+595T4wMAEUDm6XQ6HpmsxYujpfdG4iH1sWNgADwbz+QDShIByg+pXWAChA4BkIvL592sJGKEtKjVR1yqq99441FFxfLlGzZs8I8JiSIRJSmmpqZGDRwBDtTEcEMkBM0oelISt+Y/xCQRj43iLitcVlaWesAO2CEkwkiOspnMjNLzT0lNTT3pRti2LmMD4Pv7P/fLCMe7sVisk9wyKJDhD9hnHOUS21ttIYvFhfOnIj+jFDoApUAhoQNI+lLYVlSCyWSWhkiU5zNw4Dc2l4CuzO5bhgKOw/5QXgioCNgHi07gqeWE49fxJJvJTgSdjtyYCDbSicS/+sdfKBTSbC2YeAtJGRs2SiKIEtZvO2sMm4mPkbyATqcgnY7OUshm21Z+lEUZS8yWhIdT7FlucAilLZ1C4RLTU7InySkUFE5HLfDbkkqRy5XE9M7MnHDKcdwGUpHAlcvlGVZieu30nN9xmwLglZXhfeVy4vcmERWWTAqnUOQU9PSvZof3ZeLhxOkMzoHM40iY7vutnE56MV6dlj2JYmts7YyQkF6UP6dHELnn/wKagPx6Gion/QAAAABJRU5ErkJggg==); } body.zh-cn .short { text-align: center; } body.zh-tw, body.zh-tw .info .title, body.zh-tw .info .twitter, body.zh-tw .footer { font-family: "微軟正黑", "Microsoft JhengHei", "Helvetica", "Tahoma", "新明細體", "PMingLiU", "SimSun", sans-serif; } body.zh-tw .info .twitter { line-height: 1.5; } body.zh-tw .footer { font-size: 12px; }
Battle.net
We’ll be back soon!

The Blizzard family of websites is temporarily unavailable. Thank you for your patience!
For updates, follow @BlizzardCS on Twitter.
©2011 Blizzard Entertainment, Inc. All rights reserved Terms of Use Legal Privacy Policy Copyright Infringement Americas – English (US)
Validate TRUSTe privacy certification
Issues with High Volume Sites” wysłany:
I am a co-creator and the main engineer for the site www.askmrrobot.com, which is a very high-volume site that allows users to load their characters from the Armory.

We registered with Blizzard and started signing all of our requests with the provided public/private key, but we still ended up exceeding the daily limits. (For background, we do not run "batch" operations or crawl the armory: all armory requests are user-initiated requests to load a single character.)

Unfortunately, we have been unable to contact api support to discuss possibly raising the cap for our site -- they are probably pretty busy working on new features and the such, so I'm not too surprised. First question: is Blizzard open to discussion on increasing rate and volume limits for reputable sites that can guarantee responsible use of the API?

In the meantime, we have been using a JSONP approach: if a user asks to reload his character, we send a request right from the browser using JSONP, then send that data to our own server for processing and caching. There are a few issues with this approach though:

When using JSONP, if an error occurs, it seems that the callback is never invoked. Thus we are unable to display or respond to any of the nice error handling that Blizzard has provided. Our only recourse is to set a timeout and if it doesn't come back in say 10 seconds... throw up a generic message. Does anyone have any advice on this front?


This approach noticeably degrades the user experience, particularly over a slower internet connection such as a 3G network. Whereas before we would send just one request to our server, now we have to do 3 requests: one to our server to get the last-updated date on our cache, a second out to the armory, and a third back to our server to process the armory response.

The JSONP approach also leads to customer service issues: sometimes a user will have battle.net blocked with a script blocker, or be using a work computer that blocks game-related domains.


In summary, fundamentally the Armory API is handling the same amount of traffic using JSONP as routing it all through our own servers, so from their perspective they shouldn't "care" which way it is done. But I'm pretty flexible -- ideally we could discuss increasing the rate limit, but if that's not possible, advice on error handling with JSONP would be much appreciated!
Item API Questions” wysłany:
I am working on updating www.askmrrobot.com to use the new community API, and I have some questions about retrieving item information.


The returned item data for a single item contains several IDs for which I can find no way other than brute force to relate them to actual data:

- stats are listed with just an id rather than "strength" or "mastery"
- item class, subclass, and inventory type are just ids
- set items have just an id for the set

For stats, item class, item subclass, and inventory type I can probably just use brute force to enumerate the possible values in a couple hours... but I was wondering if there are any plans to document these IDs, or is there documentation that someone can point me to?

The item set IDs would take much longer to do the same. Is there a way to get the item set name and set bonus descriptions?


When retrieving a character, a similar issue occurs: you can get enchant ids and random item suffix ids, but there appears to be no way to map these to the text associated with each. Is there a recommended approach to locating this information?


Our site requires this information because we need to load the full detail for items in order to read the stats and do fancy math to rank items and the such. At the moment we are reading the battle.net html for items, and the specified information above can easily be read out of the page content. But that will not be an option soon.

If the API has no plans to support this kind of extra information, a possible alternative would be for our site to continue using the battle.net html to get this particular information. The amount of traffic would be very low because we cache item information indefinitely -- it rarely changes. Does anyone know what kind of limits will be placed on reading battle.net html, i.e. would very small amounts of traffic be OK? For an example of the scale, if we clear our item cache because of a patch or content update, we might need to re-load a list of 1000 items once every couple of months. Would that be an acceptable usage of the battle.net html?