ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)
-   -   EVENT_PLAYER_COMBAT_STATE timing incorrect? (https://www.esoui.com/forums/showthread.php?t=2035)

mattmillus 07/29/14 05:04 PM

EVENT_PLAYER_COMBAT_STATE timing incorrect?
 
Hi guys, something strange came up while coding my new combat logging addon..

It seems that EVENT_PLAYER_COMBAT_STATE events come in before EVENT_COMBAT_EVENT -> ACTION_RESULT_DIED (and the associated damage events for the final killing blow)

The picture should pretty much say it all:


Has anyone else noticed such things? Does the game not have some sort of event queue that guarantees ordering? Advice appreciated on this, I am considering using an asynchronous timer to delay my HandleLeaveCombat() function until like 0.1 seconds after EVENT_PLAYER_COMBAT_STATE comes in, but this seems like a **** hack.

Xrystal 07/29/14 05:57 PM

I'm not sure how it would affect things but you could have it so that it only tracks normal state after player state has been processed, then once normal state has been checked it stops tracking it until the next player state.

Theoretically it should then have your player state reports before the normal state reports.

EG.

Lua Code:
  1. function CombatEvent(eventID,...)
  2.     -- Process Regular Combat Events
  3.     UnregisterEvent(blah,eventID)
  4. end
  5.  
  6. function PlayerCombatState(eventID,...)
  7.     -- Process Player Combat Events
  8.     RegisterEvent(blah,EVENT_COMBAT_EVENT,CombatEvent)
  9. end
  10.  
  11. RegisterEvent(blah,EVENT_PLAYER_COMBAT_STATE,playerCombatState)

Of course, memory recalls that event buffering is a suggestion, so it might be worth checking out http://wiki.esoui.com/Event_%26_Update_Buffering to see how it can be done in your situation. It might prove to be the better choice with stopping event tracking possibly missing events needed.

Of course I am falling asleep so I may be totally wrong in both suggestions :)

Iyanga 07/30/14 10:30 AM

Quote:

Originally Posted by mattmillus (Post 10949)
Has anyone else noticed such things?

Yes.
Been there, done that.

Lua Code:
  1. function Battlelog.CombatStateChange(eventCode, inCombat)
  2.   if inCombat == true then
  3.     EVENT_MANAGER:RegisterForEvent("Battlelog", EVENT_COMBAT_EVENT, Battlelog.ProcessEvent)
  4.   else
  5.     zo_callLater(Battlelog.UnregisterCombat, 500)
  6.   end    
  7. end

mattmillus 07/30/14 02:28 PM

Thank you for that.

Out of curiousity I also had a check how the 'Recount' addon handling this whacky behavior. Lo and behold, its the exact same thing you do:

Code:

function Recount.playerExitCombat()
        if (Recount.inCombat == true) and (Recount.onExitCombat == false) then       
                Recount.onExitCombat = true;
                zo_callLater(Recount.doPlayerExitCombat, 1000)
        end
end

Only difference is the 1second vs 500ms delay. I am going to implement this the same way, with zo_callLater(), at least until ZO fixes the event triggering!

EDIT: Testing and this is working great, even with a 1ms delay - no need for 500ms


All times are GMT -6. The time now is 07:43 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI