UNIT_TARGET delay

Rilgamon · 03-23-10, 07:03 AM

I try to write a replacement for oRA2-Maintanks.
But I have sort of a problem that UNIT_TARGET
arrives really late. Its delay is less than half a second.
Still I see that the BlizzTargetFrame is updated faster.
I have an OnShow-Script that helps to solve this
when no target is selected. But when I have a target
and just switch to another there is the delay.

[tank1][tank1target][tank1targettarget]

Not sure if its a problem of my code (not yet uploaded and too
much to post

) or if its a general problem. I dont want the frames
to update too often so I want to avoid OnUpdate for it.

Is there a faster event to listen for ? Or could it be done with a state-handler ?

Xrystal · 03-23-10, 07:18 AM

I've not touched unit frames myself much if at all but looking at Blizzards TargetFrame.lua file I spotted the following function:

Code:

function TargetFrame_Update (self)
  -- This check is here so the frame will hide when the target goes away
  -- even if some of the functions below are hooked by addons.
  if ( not UnitExists("target") ) then
    self:Hide();
  else
    self:Show();

    -- Moved here to avoid taint from functions below
    TargetofTarget_Update();

    UnitFrame_Update(self);
    TargetFrame_CheckLevel(self);
    TargetFrame_CheckFaction(self);
    TargetFrame_CheckClassification(self);
    TargetFrame_CheckDead(self);
    if ( UnitIsPartyLeader("target") ) then
      TargetLeaderIcon:Show();
    else
      TargetLeaderIcon:Hide();
    end
    TargetDebuffButton_Update(self);
    TargetPortrait:SetAlpha(1.0);
  end
end

This function is called when the frame is first loaded and when the following key events are activated:

"PLAYER_ENTERING_WORLD"
"PLAYER_TARGET_CHANGED"

Hopefully you will see something there that triggers a possible solution to your problem.

Rilgamon · 03-23-10, 07:22 AM

Yes, I found a few postings that PLAYER_TARGET_CHANGED is faster.
But that would require the player to be the tank

Xrystal · 03-23-10, 07:30 AM

Originally Posted by Rilgamon

Yes, I found a few postings that PLAYER_TARGET_CHANGED is faster.
But that would require the player to be the tank

Yep... looking at how TargetOfTarget frame is updated and unfortunately for you they use the OnUpdate route.

From the XML file for TargetFrame.xml:

Code:

<OnEvent>
  TargetFrame_OnEvent(self, event, ...);
</OnEvent>
<OnUpdate>
  TargetFrame_OnUpdate(self, elapsed);
  TargetFrame_HealthUpdate(self, elapsed, "target");
</OnUpdate>

And this is the same file but the TargetOfTargetFrame portion:

Code:

<OnEvent>
  UnitFrame_OnEvent(self, event, ...);
</OnEvent>
<OnUpdate>
  TargetofTarget_Update(self, elapsed);
</OnUpdate>

The UnitFrame_OnEvent seems to be a basic event function as it isn't inside the TargetFrame.lua file. It is also called by TargetFrame_OnEvent before it does its own checks.

Code:

function TargetFrame_OnUpdate (self, elapsed)
  if ( TargetofTargetFrame:IsShown() ~= UnitExists("targettarget") ) then
    TargetofTarget_Update();
  end
end

And for the relevant OnEvent code block that calls TargetOfTarget_Update

Code:

if ( event == "PARTY_MEMBERS_CHANGED" ) then
  TargetofTarget_Update();
  TargetFrame_CheckFaction(self);

And finally the Blizzard TargetOfTarget_Update routine:

Code:

function TargetofTarget_Update (self, elapsed)
  if ( not self ) then
    self = TargetofTargetFrame;
  end
  local show;
  if ( SHOW_TARGET_OF_TARGET == "1" and UnitExists("target") and UnitExists("targettarget") and ( not UnitIsUnit(PlayerFrame.unit, "target") ) and ( UnitHealth("target") > 0 ) ) then
    if ( ( SHOW_TARGET_OF_TARGET_STATE == "5" ) or
      ( SHOW_TARGET_OF_TARGET_STATE == "4" and ( (GetNumRaidMembers() > 0) or (GetNumPartyMembers() > 0) ) ) or
      ( SHOW_TARGET_OF_TARGET_STATE == "3" and ( (GetNumRaidMembers() == 0) and (GetNumPartyMembers() == 0) ) ) or
      ( SHOW_TARGET_OF_TARGET_STATE == "2" and ( (GetNumPartyMembers() > 0) and (GetNumRaidMembers() == 0) ) ) or
      ( SHOW_TARGET_OF_TARGET_STATE == "1" and ( GetNumRaidMembers() > 0 ) ) ) then
      show = true;
    end
  end
  if ( show ) then
    if ( not TargetofTargetFrame:IsShown() ) then
      TargetofTargetFrame:Show();
      Target_Spellbar_AdjustPosition();
    end
    UnitFrame_Update(self);
    TargetofTarget_CheckDead();
    TargetofTargetHealthCheck();
    RefreshBuffs(TargetofTargetFrame, 0, "targettarget");
  else
    if ( TargetofTargetFrame:IsShown() ) then
      TargetofTargetFrame:Hide();
      Target_Spellbar_AdjustPosition();
    end
  end
end

Rilgamon · 03-23-10, 07:51 AM

hmmm, as I want to reuse the code later for a grid replacement
I shy away from the OnUpdate route ... or better I have a global onupdate
but that is fired only for unitframes with enemy targets with a 1s limit.

but thank you for going through the code ... perhaps I should stop trying to
use less resources and cpu cycles

Shadowed · 03-23-10, 11:41 AM

Originally Posted by Rilgamon

Yes, I found a few postings that PLAYER_TARGET_CHANGED is faster.
But that would require the player to be the tank

PLAYER_TARGET_CHANGED is instant because the client assumes the player targeted someone as soon as the player does it, hence why even if you are disconnecting you can still target someone. It's just a visual trick. Target of Target frames use OnUpdate because targettarget is not a real unit, not because of the speed difference between UNIT_TARGET and OnUpdate for target.

You actually will have issues with polling for targettarget only, because unless your poll time is <0.10s you can have times where someone detargets, the unit becomes invalid but because you only poll for updates it will show a blank frame until it repolls and sees its gone. You should always use UNIT_TARGET (even if it's in addition to) OnUpdate to monitor target changes.

Rilgamon · 03-23-10, 01:01 PM

Ah

Guess that means I can stop trying to find a better solution and should implement the onupdate for the units. Thanks for looking in my prob

nightcracker · 03-23-10, 04:08 PM

I've always used PLAYER_TARGET_CHANGED, and then extracted all the info I needed from "targettarget". It's a valid UnitID. I don't think I fully understand the problem here.

Shadowed · 03-23-10, 04:21 PM

Originally Posted by nightcracker

I've always used PLAYER_TARGET_CHANGED, and then extracted all the info I needed from "targettarget". It's a valid UnitID. I don't think I fully understand the problem here.

No, they are not. You do not get events for targettarget, or any of the #target units, and on some functions (like a few of the threat APIs) you will get errors.

Rilgamon · 03-23-10, 07:54 PM

Thats what I found, too. Thats why I use an onupdate for the enemyunitframes.
I've now added a frame that I can show/hide with an OnUpdate-script.
Hiding when unitid does not end with target reduces the impact on the
cpu-cycles

Check interval that I found was fast enough so I dont "feel" the delay
is 0.075. I check the current GUID to the last known GUID and only
update if the GUID has changed.

Thanks for all your help

I hope to upload a first version this week

Rilgamon · 03-24-10, 05:58 AM

Ok

A first alpha is available

http://www.wowinterface.com/download...Unitframe.html
http://www.wowinterface.com/download...TankGroup.html