50 - OnHide sounds still playing at login
I'm using r43 and my sounds set for OnHide are still playing when I enter the game world. Sometimes the sound goes off multiple times (I think I've heard it like 4 times once.. it's different each time, normally it goes off at least 2 times though).
Here's my setup:
<name>(<type>)
+ GrpBarkskin(Group)
-- Texture (Progress Texture)
-- Timer (Text)
The Progress Texture control is the only control in the group with a sound that plays OnHide.
Here's the trigger for the Progress Texture in case it's of any use:
-------------------------
Trigger: Main Trigger
Type: Aura
Aura(s): Barkskin
or: (blank)
Unit: Player
Aura Type: Buff
Stack Count: unchecked
-- Operator: (blank)
-- Stack Count: (blank)
Own Only: checked
Inverse: unchecked
Conditions
Alive: checked
-------------------------
If I can provide any additional information please let me know.
| User | When | Change |
|---|---|---|
| Mirrormn | Dec 02, 2010 at 16:34 UTC | Changed status from Replied to Fixed |
| Mirrormn | Dec 02, 2010 at 16:34 UTC | Changed status from Waiting to Replied |
| Mirrormn | Nov 27, 2010 at 22:28 UTC | Changed status from Accepted to Waiting |
| Mirrormn | Nov 22, 2010 at 02:13 UTC | Changed status from New to Accepted |
| JStrese | Nov 21, 2010 at 23:46 UTC | Create |
- 9 comments
- 9 comments
Facts
- Last updated
- Dec 02, 2010
- Reported
- Nov 21, 2010
- Status
- Fixed - Developer made requested changes. QA should verify.
- Type
- Defect - A shortcoming, fault, or imperfection
- Priority
- Medium - Normal priority.
- Votes
- 0
Reported by
Possible assignees
-
- Manager
- Author
-
- Maintainer
- Translator
-
- Translator
- Reply
- #9
Mirrormn Dec 02, 2010 at 16:34 UTC - 0 likesHaven't thought of a better way to do this. I'm gonna mark it fixed for r45.
- Reply
- #8
Mirrormn Nov 27, 2010 at 22:28 UTC - 0 likesNevermind, the initial PLAYER_UPDATE_TALENTS does not seem to consistently fire after the seemingly random assortment of UNIT_AURA and SPELL_UPDATE_COOLDOWN events that occur during login.
I am gravitating back towards my initial thoughts that this issue can only really be solved with a timer. As such, I have changed the squelch time to be stored in a SavedVariables entry, with a default value of 10 seconds. That should fix this issue in most cases and allow any fringe cases to be easily solvable by instruction the end user to increase the squelch time with a simple one-line script.
I'll leave this ticket tentatively open in case I or someone else happens to think of less hacky solution.
- Reply
- #7
Mirrormn Nov 27, 2010 at 22:13 UTC - 0 likesActually, it looks like PLAYER_ALIVE doesn't even fire on UI reload (only on initial login), so it would be a poor choice. However, I think I may have identified the root issue here - the first PLAYER_UPDATE_TALENTS event may be the thing that's causing displays to "flicker" at login in the first place.
- Reply
- #6
Mirrormn Nov 27, 2010 at 22:03 UTC - 0 likesIt looks like PLAYER_ALIVE fires about 11ms after PLAYER_ENTERING_WORLD on my computer...
However, as we have learned in this thread, my computer may load much faster than some others. I'll see if I can find a grindingly slow computer on which I can test these timings further ^_^
- Reply
- #5
Mirrormn Nov 27, 2010 at 21:54 UTC - 0 likesWhen I did testing for the timings of login events, I didn't see PLAYER_ALIVE, so I'm not sure that that page is completely up to date. However, I might have just missed it - I'll check again.
VARIABLES_LOADED is what I was using before this whole ticket so it's definitely not sufficient.
- Reply
- #4
Carathas Nov 27, 2010 at 13:45 UTC - 0 likesWill it help when you use the event "PLAYER_ALIVE" instead of "PLAYER_ENTERING_WORLD"? And what about the event "VARIABLES_LOADED"? I don't know much about addon programming but it might help you to take a look at this list which describes the addon loading process: http://www.wowpedia.org/AddOn_loading_process
Sry for my bad english but i think you understand what i will to say.
- Reply
- #3
Mirrormn Nov 23, 2010 at 15:54 UTC - 0 likesWell, my first instinct was to simply keep displays from executing "On Hide" actions the first time they are hidden, because every display is created and then hidden at the beginning of login.
That didn't work - as far as I can tell, there is a period during login where it is possible for some displays to "flicker".
My second instinct was to find an event that would indicate that the login process was over, and prevent all On Hide actions from executing before that time. The best candidate for this was PLAYER_ENTERING_WORLD.
That didn't work - displays would hide and show after it.
So then I thought, well, no problem, I can just wait for a certain amount of time after PLAYER_ENTERING_WORLD to allow On Hide actions. After some testing I settled on 1 second, which worked for me every time. But apparently not for everyone.
I guess actually fixing this issue would involve going back to the first solution and figuring out why displays "flicker" in the first place. However, there are a wide array of triggering mechanisms in WeakAuras; in fact, due to Custom Triggers, I'd rather not even assume that I even know all of the ways a display could be triggered. This makes comprehensive testing of WeakAuras' behavior at login time very difficult.
- Reply
- #2
JStrese Nov 23, 2010 at 09:24 UTC - 0 likesThat seems more like a patch than a fix to be honest.. any plans on fixing the issue? There has to be a better way to go about this :P
- Reply
- #1
Mirrormn Nov 22, 2010 at 02:13 UTC - 0 likesI was afraid this might happen. My guess is that your computer loads slower than mine, so the amount of time it takes between login and the "settling" of auras is longer. I'll increase the time after log-in that WeakAuras silences sounds to like 5 or 10 seconds in r44.