AddOn for reduced zoning times

A

Asmodean

Guest
Blozzom said:
Hello,

this add-on might be useful for people who experience long zoning times (boat trip anyone?)....

cheers,
B.
Click to expand...

Atfirst:
Wait til tomorrow for 1.10.1. The new minor patch fixes a memory leak within the UI handling which should let things go alot smoother. At the moment, you heavily slow down your client due to memory leakage and the garbage collector going gaga.

I looked into your suggested addon and it interrupts specific events for specific addons. This is the wrong approach imo. As addon author I'm quite familiar with the internal WoW UI event handling and trust me, you don't want fiddle with specific events for specific addons as you never know how they react. Yay...Nil error messages for the masses.

http://ui.worldofwar.net/ui.php?id=2419 has a more generic approach and personally I can only suggest that addon.

I made a few tests today to find out what works best for me. I zoned into and out of Stockades without CTRA but all other addons enabled I normally use. I made zoneins and -outs with
1) My normal client without a tuning-addon
2) Blozzoms suggestion (http://www.curse-gaming.com/mod.php?addid=3775)
3) My suggestion (http://ui.worldofwar.net/ui.php?id=2419)

The values are an average of 3 zone-ins and zone-outs:

1) IN: 25s OUT: 28s
2) IN: 7s OUT: 10s
3) IN: 3s OUT: 4s

:eek:
 
G

Guest

Guest
Tried the one Asmo posted. Really helps a lot.... 5-10 times faster than normal. Phew, was getting quite tired of waiting that long all the time :) Thanks for this thread, Blozzom and Asmo!
 
K

Kizza

Guest
idd, with asmos one i zone in and out in under 4 seconds, rly nice
 
OP
B

Blozzom

Well-Known Member
Nov 3, 2005
809
@Asmodean:

I had quick look at the AddOn you posted and I'm a bit confused why you think the approach used in yours is much safer than the one I posted?

Ok, I admit, I have very limited LUA script, let alone WoW API, knowledge, but my 20 years of programming experience allow me to "understand" it a bit of whats going on there:

"my" AddOn deactivates/activates event handling in specific other AddOn's which it knows to have/cause problems but doesn't touch AddOn's that have a built-in leav/enter world handler.

"your" AddOn just goes through all installed/registered AddOn's and deactives/activates their handlers no matter what. obviously you'll get better performance as it doesn't need to know what other AddOn's you have installed. but imho this is more open to errors than selective picking what to disable and what not.

It's very much possible I missed something obvious, but it's kinda late and I'm tired etc, so please point me in the right direction.

I'm not trying to pick a fight or stroke my e-peen, just trying to understand your reasoning better (from a programmers pov). :wink:
 
A

Asmodean

Guest
Blozzom said:
I'm not trying to pick a fight or stroke my e-peen, just trying to understand your reasoning better (from a programmers pov). :wink:
Click to expand...

In order to answer your question, I have to describe WoW's general event handling abit.
Events in general are recieved by frames. Yes, you're reading correct: UI Frames.. stupid, 'eh? That basically means, that nearly every addon has a - visible or hidden - frame which consists of several On-function (OnLoad, OnMouseClick, OnEscPressed, OnVomit.. OnNameIt).

One of those On-functions is the OnEvent function which passes every registered event to the addon's event handler. What do I mean with 'registered event'? Every single change in the environment is being flooded with defined event to the UI and its addons (buffs, dmg, chat actions, target changes, aura changes, everything). The auther can define which events he wants to recieve and which not. He registers those events on which then his OnEvent function is triggered.

Example: Assuming the author wants to recieve an event every time a change occurs in the player's bags (loot recieved, equipment changed, pot swallowed etc), he registers the respective event and than can act accordingly (for example recount the free bagslots).

Ok. Let's go into details:
Events then can be computed in 2 different ways: At the end the event handler is a single function with decides what to do after a certain event occured. Lazy addon authors have a big function with a huge if-elseif-elseif-elseif.....end construct to catch all the possible events. The second option is to use some fake-OOP approach and simulate a case-contruct which basically leads to parallelizing events into dedicated functions.
That's the way most people do the job and it makes sense as it's seperated, more logical, easier to debug and extend. But that leads to the fact that you have to work with global states (global in your addon environment) as you normally don't only work with one event and they most likely depend on each other.
Example: SheepWatch checks for the "user successfully casted a spell"-event, sets a specific state and then waits for the "mob gets debuffed"-event before it actually displays a progress bar.

And that's basically the reason why your addon suggestion is a bit problematic. This addon disables specific events for an addon. The addon generally runs but doesn't get dedicated events anymore. What happens now if the addon relys on events to be fired because several states have been met? During that time the addon as it still runs and computes other events and data and ofc changes its status. That may lead to an undefined status which can cause alot of trouble.

The addon I suggested uses the opposite approach: It hooks (and then disables) all events to be sent to addons (but a few necessary ones like CHAT events) and therefore kinda puts them into a kind of hibernation mode during the zoning. The actual state when zoning started remains the same as - like mentioned above - the addon execution itself relys on events.

EDIT: Typos :cry:
 
You must log in or register to reply here.
Top Bottom