Guild Store search extension now broken?

pjwrwb17_ESO · April 2014

It's the extension that makes the dreadful guild store interface vaguely useful. And now it retrieves stuff too fast.

I have no idea if the developer was informed of this change before the patch, but how about just adding a throttle in the client rather than breaking a plugin?

This is very annoying.

D34thly · April 2014

Addon author will get it fixed lol addons tend to break after patches it happens.

GossiTheDog · April 2014

The addon author needs to fix it. Disable it for now.

pjwrwb17_ESO · April 2014

Im sure they will, but this is a game that (seemingly to me) relies upon addon developers to fill in holes in their only vaguely functional UI.

Further, it seems sloppy, lazy and inefficient to not implement the throttle in the API rather than requiring the (generous, socially minded and FREE) AddOn developer (and EVERY addon developer) to implement the throttle.

dawnhawk · April 2014

As a suggestion...it usually helps if you send a message to the addon creator (or at least post on THEIR forums) rather than the games customer service forums. ZOS isn't going to help you with this...and really neither can the masses here.

Go to ESOUI.com (or other official addon site) and check the comments for the search addon. You can see if he/she is working on it/is aware of the bug/if any users have taken the time to "patch" it in lieu of an official update/forked the project.

pjwrwb17_ESO · April 2014

Actually my reason for posting was to flag the issue with the developers as something they need to consider in the future, as well as a policy that probably need to be considered.

If limits, throttles or other features are needed in the API, they should be built into the API.

Phyrdrin · April 2014

Well said, @dawnhawk. ZOS does not care about troubleshooting your add-ons, therefore posting in this forum will serve no purpose.

dawnhawk · April 2014

Are throttles needed in the API though? I ask from a purely philosophical point of view. Too many years taking a comp sci degree coupled with an English degree = way too much devil's advocate.

I can think of a half dozen reasons to force addon devs to put their own throttle checks in rather than a blanket check via the API. The least of which being..a blanket check is easy to screw with because it only takes into account a single behaviour - where as having a cap and allowing addon devs to put in checks of their own under that cap allows for more wiggle room depending on exactly what they are attempting to do.

JessieColt · April 2014

This is so not going to happen. It isn't to say that game developers do not care about 3rd party add on designers/creators, but no way in hell would any game company adjust their software so that patches do not affect 3rd party add ons.

It is the sole responsibility of the add on designer/creator to maintain their own software to ensure that patches to the game that cause issues are addressed, not the other way around.

This would be like telling Ford, or GM, or Honda, or Volkswagon, or any other car manufacturer that they should redesign their dashboards because an after market stereo system you like only fits a Tesla.

It is not up to the car manufactures to ensure that the stereo you like fits into the car that they build, just like it isn't up to the game developer to ensure that an add on you like never breaks when they release a patch.

pjwrwb17_ESO · April 2014

@dawnhawk: The specific instance here is, apparently, too many calls to the guild store search. It's a perfectly reasonable thing to limit, and because of the useless store interface was probably killing the server.

My suggestion about how it should be handled is to throw the request (probably already in its own thread anyway), into a delay of whatever time is deemed appropriate (200ms? 1 second?). This is not something every caller should have to handle.

It's possible some callers will want (in the future) to manage this themselves, at which point you add an option to the call that says 'return now if you can't complete immediately'...or something similar.

What we have now is probably half a dozen helpful free contributors going off to patch their code because Zos seemingly didn't care enough to put the code where it is most efficient.

pjwrwb17_ESO · April 2014

JessieColtub17_ESO wrote: »

This would be like telling Ford, or GM, or Honda, or Volkswagon, or any other car manufacturer that they should redesign their dashboards because an after market stereo system you like only fits a Tesla.

No, it would be like asking them to use common sense in designing their cars. Make the maintenance cheap by adopting common practice: standard bolt sizes, standard radio enclosures, so that the maximum number of suppliers can inter-operate with the minimum cost. And don't redesign the radio enclosure in each model.

JessieColtub17_ESO wrote: »

it isn't up to the game developer to ensure that an add on you like never breaks when they release a patch.

And that is most definitely NOT what I am asking for.

I am suggesting that they consider their downstream suppliers when making design changes so that they don't waste everyone's time and money, and those same suppliers don't just give up supplying.

dawnhawk · April 2014

pjwrwb17_ESO wrote: »

What we have now is probably half a dozen helpful free contributors going off to patch their code because Zos seemingly didn't care enough to put the code where it is most efficient.

Well the "half a dozen" (I think I personally know more mod creators than that in my IRL social circle...) addon creators are pretty much the definition of addon creators (well barring that fact that most addon creators follow the basic "why would you" design principal of coding - the answer being "because I can or to see if I could"...so basically they make addons because they can and want to use it...or they were curious and wanted to see what they could do).

However LUA...is a an odd "language" (scripting "languages" vs "real programming languages" debate aside) to work with.

Every time you add a hook into your API you have to consider what that hook is granting access to. And that's all the API really is. A series of hooks.

Now...should Zenimax create a bunch of EXTRA code on top of the existing API code that takes into account threading (which can be a royal pain in the arse) and collisions - adding a bunch of sleep/wake commands based on how many items are in a guild store when the addon is retrieving page after page of items in order to then sort/filter through the data that gets returned on every cycle (and in the meantime taking time away from...well anything else on their plate) OR...should they create a quick hard cap and allow addon devs to handle their calls on the client end rather than the server.

Efficiency comes from multiple directions.

pjwrwb17_ESO · April 2014

dawnhawk wrote: »

Now...should Zenimax create a bunch of EXTRA code on top of the existing API code that takes into account threading (which can be a royal pain in the arse) and collisions - adding a bunch of sleep/wake commands based on how many items are in a guild store when the addon is retrieving page after page of items in order to then sort/filter through the data that gets returned on every cycle (and in the meantime taking time away from...well anything else on their plate) OR...should they create a quick hard cap and allow addon devs to handle their calls on the client end rather than the server.

I do not know much about LUA, but...what I assume will now happen is each scripter will now have to include something like this in their 'got-a-store-page' event code:

if [time-since-last-call] < [some-limit]
    wait....
end-if

get next page

whereas those same 3 lines could effectively been put in the API for 'get next page'.

My mention of threading was to forestall discussions of blocking API calls etc, which is probably handled via threads but may not be.

Edit: and depending on how sloppiy this was done, every time they change the throttle values, the addins will break.

GossiTheDog · April 2014

You can't build throttles and security features into the client side API (eg rely on it where the code is). Because you could just circumvent it. The changes will be due to botting. Addon owners just need to code around it.

dawnhawk · April 2014

I suspect your pseudo-code is apt enough for the discussion.

I presumed you have at least enough theory from the get-go even if not necessarily practical hands on. You do read as quite intelligent.

And in the long run - as strange as this sounds - likely a "good enough" solution in comparison to the trying to make the check server side. There is a preference to force checks to client side. It's easier for the server to just push back against too many requests and dump the client than it is to make it...well try to think. For a overly simplified phrasing.

I agree with in that it likely isn't "optimal" in a perfect white-box world. But remember we are "living" in a black-box world. That's what an API is...a black box where we push requests in...some magic happens...and stuff comes out. The more complex you make the "some magic happens"...the more you potentially make the "stuff" that comes back from the "potentially garbage in"...scary and likely to hunt you from dark corners like a Gru.

pjwrwb17_ESO · April 2014

They need both: the client side helper code to prevent massive time-wasting, and of course the server side code that protects the interests of the server.

JessieColt · April 2014

pjwrwb17_ESO wrote: »

JessieColtub17_ESO wrote: »

This would be like telling Ford, or GM, or Honda, or Volkswagon, or any other car manufacturer that they should redesign their dashboards because an after market stereo system you like only fits a Tesla.

No, it would be like asking them to use common sense in designing their cars. Make the maintenance cheap by adopting common practice: standard bolt sizes, standard radio enclosures, so that the maximum number of suppliers can inter-operate with the minimum cost. And don't redesign the radio enclosure in each model.

JessieColtub17_ESO wrote: »

it isn't up to the game developer to ensure that an add on you like never breaks when they release a patch.

And that is most definitely NOT what I am asking for.

I am suggesting that they consider their downstream suppliers when making design changes so that they don't waste everyone's time and money, and those same suppliers don't just give up supplying.

Except this is exactly what you are asking them to do. Either give code to 3rd party sites before the code is released (keeping in mind that it might not even get released, or ends up getting rolled back, which still impacts the 3rd party code), or tweaking their software so that it doesn't impact 3rd party add on creators.

And car manufacturers are not responsible for ensuring that something that isn't built into their cars can still be used in their models. They can change the dashboard every freaking month if they want to, and it still isn't up to them to ensure that the changes do not impact after-market items that the consumer wants to add to the car.

It is always up to the after-market creator to re-design their product to fit the car.

pjwrwb17_ESO · April 2014

dawnhawk wrote: »

There is a preference to force checks to client side.

Except, because of hacking and client-side circumvention, they will probably have to put checks on server side as well. Which they have apparently done.

dawnhawk wrote: »

That's what an API is...a black box where we push requests in...some magic happens...

Yeah, and ISTM that doing the basic externally imposed conformance enforcement should be done within the call wrapper, not the AddOn. ie. the 'wait' in my pseudo-code should be part of the 'magic'.

Corvosa · April 2014

The fact that we have to use an addon to perform a basic search is insanity to me.

pjwrwb17_ESO · April 2014

Volcana wrote: »

The fact that we have to use an addon to perform a basic search is insanity to me.

lol, yep.

pjwrwb17_ESO · April 2014

pjwrwb17_ESO wrote: »

Yeah, and ISTM that doing the basic externally imposed conformance enforcement should be done within the call wrapper, not the AddOn. ie. the 'wait' in my pseudo-code should be part of the 'magic'.

..and if they had done this in a sensible location, their own guild search would probably still work also.

Daiceman · May 2014

JessieColtub17_ESO wrote: »

This would be like telling Ford, or GM, or Honda, or Volkswagon, or any other car manufacturer that they should redesign their dashboards because an after market stereo system you like only fits a Tesla.

Actually, its more like Ford selling a car without a steering wheel, but a socket to put your own purchased one into. Then Ford recalls the vehicle, and changes the shape of the socket so your old steering wheel doesn't work anymore.