3.3.5 Inspect Issue
 

An update from Zarhym, with a bit more info:

We're starting by capping the number of Inspects that can be sent in a 10-second time frame. It'll likely be 5 Inspects, but that could change in either direction.

Keep in mind that this change is intended to help those using addons which are sending a lot of these requests from lagging or disconnecting. If you're not actually using such addons, and therefore not sending a large number of queries to our database, the change won't affect you either way. You're not lagging or disconnecting because someone else in a raid or major city is unknowingly spamming such requests.

=========================================================

A post by Zarhym, providing some explanation of their reasoning:

It's important to understand that this wasn't really the fault of addon authors. This needed to be fixed because we were allowing something we really shouldn't have. Many addons pull Inspect data when mousing over characters and there was nothing on our end to throttle the rate at which that data could be pulled. So if you're standing in Dalaran with one of these mods and slide your mouse across the screen and over several characters within a very small amount of time, your client is spamming the database with Inspect queries. We're correcting that issue on our end.

=========================================================

After the next set of rolling restarts, Blizzard will be implementing server-side throttling of inspection requests from addons. This may cause any addon that uses player inspection to not function properly after the restarts.

This throttle is being activated in order to reduce server load from some addons that use the inspection system. Currently any addon can request inspection data from the server as often as they want, and this problem seems to have gotten worse with the new patch.

Most addons will continue to function properly, however keep this in mind as you play with your addons. If you are an addon developer, you may want to restructure your addon so that it no longer expects an event reply for an inspection request. With most throttled API calls, a throttled request will simply disappear into the void with no response.

UPDATE: It appears that the rolling restarts may be delayed until the next maintenance window, but the next set of restarts should activate the throttle mechanism.

Updated information is available in the official WoW forums:

I see the end of GearScore comming.....

dum dum dummmmmmmmmm

Before there's too much speculation, I should specify that although there is an issue with server traffic at the moment and Blizzard are taking action to resolve it on their end, GearScore and addons like it that use the inspection API will continue to function, but they may need to be a bit more conservative about the number of inspect calls they are making.

It's not the end of GearScore and the like. The problem is that so many players use it as a staple of who's "good" nowadays that it's bogging down the process. As Cladhaire said, they'll just have to throttle their checks now to reasonable levels. I think everyone will notice a drastic improvement in performance while in Dalaran as well.

GearScore will still be a requirement to play WoW, sorry to say. :(

Well now, that would be some news to me ;)

In the short term, gearscore is probably going to break other addons. 99% chance, in fact. I've had users report that gearscore blocks the inspect API, failing to properly relinquish it correctly until it finishes a round of profiling. After this change, that block could span multiple timeout attempts. I hope they change that architecture sooner than later, to relinquish control of the inspect API after each transaction like a good little addon.

In the long term, I wonder what changes are coming to the actual API calls. It would be fantastic to receive success/ignore codes after requesting inspect data, have functions to check the current status/timer on the inspect API, and generally have proper facilities in place to "play nice" with the blizzard servers.

This should be an interesting conversation to follow.

Do we have an ETA on when these rolling restarts will commence?

My addon is completely reliant on the inspect API. While It's designed as a single-threaded-apartment-model system, and therefore timeout safe, I'd still appreciate a guesstimate (or official #) for when to expect potential bug reports to come in.

I'm also extremely curious what the server-side numbers are going to be. I would hate to burst the server every 1/5/10 seconds if it's just going to have to parse & ignore the requests; it would also suck to make requests every 29 seconds if the timeout is 30 seconds :P

Wow that is really a shame, I guess I will have to quit playing then.

The whole concept of an addon that tells you that a player is good depending on what number he has, a number that is determined by ???

Who decides that one piece of gear is better than another? You could just as easy say that the ilevel is the way to pick good gear.

I really hope we can keep this discussion foccused on mechanics and implications of the inspection facilities of the wow api.

If you want to talk about gearscore, feel free to contribute to any of these other conversations:

http://forums.worldofwarcraft.com/th...78348839&sid=1
http://forums.worldofwarcraft.com/th...52677110&sid=1
http://forums.worldofwarcraft.com/th...52507042&sid=1
http://forums.worldofwarcraft.com/th...60027897&sid=1
http://forums.worldofwarcraft.com/th...59987870&sid=1
http://www.wowinterface.com/download...5&so=#comments
http://www.wowinterface.com/download...5&so=#comments
http://gearscoreaddon.com/forums/

No, it'll happen when it happens.

As I understand it the numbers will probably change over time as they tweak to get it to reasonable values. There's not all that much more I can say other than that.

I hope gearscore bites the dust, or at least the in game version of it.

Keep in mind that any sort of throttling to the inspect UI will also 'break' the default one. I'd be surprised if it was 30 seconds, probably will end up around 5 - 10 seconds.

Please, this is not the place for a GearScore discussion. At all.

I'm not a addon developer (hell, last time I touched lua was in mirc...) but I am an experienced programmer in other languages, so please excuse me if this is a stupid point...

The server has to send item data to the client so it can draw the correct armour every time you see a player. I'm just going to assume this is a simple skin id array. Why can't the server send an item id array, that the client looks up and loads the correct item data. This way, addons like gearscore won't need to do an inspect request, but access the cached item data instead.

Surely this would only increase server -> client player data by a small %, but allow the continued use of inspect-based addons without touching the inspect api at all?

Think of a zone like Dalaran, the majority of the players that are loaded you will never inspect, or Ironforge or Orgrimmar. A little bit of data adds up and you would have to add gems as well as non-visible enchants too. The vast majority of it would end up being unused, especially if the player isn't running an inspect mod.

If I had to take a guess, the majority of Gearscores requests are due to poor coding causing it to unnecessarily send requests on the same player. While caching would help it, it's an issue that could be fixed by competent coding. Anyway, if you want to believe the Blizzard post, it's not specifically due to Gearscore either. Tooltip mods do inspection requests on mouseover, various UFs do it on target, etc.

I've spent the last 3 days solid writing stream and data parsing for flv/amf, mp4 and ogg files. The main thing I've learnt from this, is the amazing extents you can go to with reducing data sizes. Packing a 4 byte integer into 1 byte using the high bit as a "is there another byte to this" flag, that sort of thing.

I've not noticed Gearscore pay attention to gems or enchants in its scoring, though I could be wrong.

Having a hefty delay in the inspect api, and proving item id data minus gem and enchant data for general use, plus someone adapting and improving addons to take advantage of the above (the inspect api throttling should be motivation enough), should in theory continue to reduce server load even further and not increase data transmission.

Another small thought: At least some enchant data must be transmitted already, for the graphical effects to be shown, making my points above even more valid.

------
Additional: This would also reduce inspect api requests to "give gem info kktnxbai"

This is not a permanent solution. It's a stop-gap solution to solve a problem. Anything else will require a client patch. This does not just affect addons, it affects the default user interface.

I really wish they would break all of these addons. They're being used for heroics, now, on my server. If you need someone in 5k+ for your heroic, you're being carried, plain and simple.

The query change is a good start, though. These stupid addons have been slowing down legitimate queries for ages.

This is not targeted at specific addons. It's being done to solve an issue that they are experiencing on the server-side of things. This is not the appropriate place for you to express whatever hate you seem to have towards any particular kind of addon.

If you do not have any constructive opinions about the actual news post, then don't bother posting here.

Tunnel vision.

*nod*


/edit: You guys have been warned, and linked to other (more relevant) threads for your addon hate. Any subsequent posts not related to the news post will be removed.

Aside from the noted effect it will have on UI elements, do you think this will have any visible effect on overall game performance?

Being that I know next to nothing about programming on this scale my brain wants to think that a reduction in server load may improve some aspects of performance. Any thoughts on this? Just randomly curious. :D

Well, the less things bombarding your client at once.... ;)

You won't see anything except for inspect requests that don't necessarily work correctly. It won't change the performance of your client in any way.

I am not certain I understand what this is going to do. Will it effect searching for minerals and plants? or is it just when you inspect another player? A bit of an explanation for those of us who are less than brilliant when it comes to computer programing would be helpful. Thanks.

Just inspection queries for other players.

This change didn't cause any errors to GearScore. The only change is that on mouseover the GS displayed could be several days out of date. So I added some date information and now only request an inspect when a player is targeted.

I didn't get a chance to test it, but does CanInspect(unitID) return nil if your past the inspection throttle threshold? My guess is no, and if so Blizzard should add that functionality to give addon Authors a very easy way to manage inspection requests.

No it does not, nor will it. The throttling is done on the server-side of things, so the client can't possibly know if it's next request is going to be satisfied or not. The irony is, to make work, the client would need to communicate with the server, which would make this point completely irrelevant.

The other APIs that have server communication do not have this sort of queryable API (with the exception of the full auction house scan, which is clearly an exception), so I wouldn't anticipate getting a function of this sort.

One way of making CanInspectUnit work without putting extra strain on the server by having to query the server on each call would be to send a time value along with each inspect reply from the server telling how many seconds or whatever before another inspect call should be available. Or they could send the amount of inspect calls still left before throttling starts. Either way its just 1 integer extra per inspect reply, and not an entire extra server query.

Just an idea.

Certainly, but this change was made five months ago, and was a stop-gap solution, as I state in the initial post. A longer term solution is of course, incoming.