MacroQuest64

Posted: **Wed Aug 22, 2018 5:00 pm**

Howdy,

Recently spent the last few weeks writing an enchanter macro for fun. Things are running pretty smoothly, but I noticed an unexpected delay when the enchanter is cycling targets. I tracked this down to a /delay with ${Target.BuffsPopulated} condition. The behavior I expected was that once /target actually acquires the target, the pulse will set ${Target.BuffsPopulated} to TRUE when we are sure that the buffs and debuffs are available to be examined. I noticed that without adding ${Target.BuffsPopulated} to my /delay condition, my chanter will often remez/tash/slow something because ${Target.Buff[Some Buff].ID} returns NULL, though the target actually has those debuffs.

It seems that after debugging a bit, BuffsPopulated is set back to FALSE at some point and will not fire TRUE again until something about the buff/debuff list changes (a spell is cast on them, etc). Is this the desired behavior? My expectation would be that it would always fire TRUE again after acquiring a target via /target, regardless if the buff list has changed since the last time we looked at the target.

Thanks for any feedback.

Posted: **Sun Aug 26, 2018 8:37 pm**

First off, welcome back.

Secondly, Much has changed (since you probably last visited.) The most likely reason the line "${Target.Buff[Some Buff].ID}" comes back NULL is because its returning a numeric output rather then a TRUE/FALSE output.

My suggestion is search the Wiki. Good Luck.

Posted: **Sun Aug 26, 2018 11:07 pm**

Heya,

Thanks for the feedback. I have lived on the wiki, its a great resource! I do know that the ID member of spell data type is numeric. It gives null when the buff with "Some Name" does not exist on your target based on my understanding and testing. I guess I'm pointing out what seems to be a race condition. In fact, it doesn't always seem BuffsPopulated is the culprit, so at this point this may just be a bug report and I may need to repost elsewhere.

I will try to show a the smallest portion of the relevant code. I have a routine that checks if mez is on the target and whats its remaining duration is.

Code: Select all

/target id ${CurrID}
/delay 2s ${Target.ID}==${CurrID} && ${Target.BuffsPopulated}
 
/if (${Target.Buff[${MezSpell}].ID} != NULL && ${Target.BuffDuration[${MezSpell}].TotalSeconds} > 15) {    
  /return
}

/delay 20s ${Cast.Ready[${MezSpell}]}
/casting "${MezSpell}|gem2"
/bcaa 0s mez check TargetID=${Target.ID} SpellID=${Target.Buff[${MezSpell}].ID} TotalSeconds=${Target.BuffDuration[${MezSpell}].TotalSeconds} BuffsPopulated=${Target.BuffsPopulated}
/delay 1s
/bcaa 1s mez check TargetID=${Target.ID} SpellID=${Target.Buff[${MezSpell}].ID} TotalSeconds=${Target.BuffDuration[${MezSpell}].TotalSeconds} BuffsPopulated=${Target.BuffsPopulated}
/delay 20s ${Cast.Ready[${MezSpell}]}

The second log message after the 1 second delay is to demonstrate the race. When things go haywire, the enchanter attempt to mez a target that already has mez.

The output in these erroneous cases looks like this:

Code: Select all

<Saranai>  [*ALL*] 0s mez check TargetID=29860 SpellID=NULL TotalSeconds=NULL BuffsPopulated=TRUE
<Saranai>  [*ALL*] 1s mez check TargetID=29860 SpellID=14548 TotalSeconds=58 BuffsPopulated=TRUE

Any suggestions? The workaround is surely to put a "hard delay" in after selecting a target that needs to be examined for mez, but this is system and network dependent and doesn't seem like best practice.

Posted: **Mon Aug 27, 2018 9:23 am**

Buffspopulated is serverside controlled, what I mean by that is that I hooked the function that’s called when the buffs are received from the server.
Once u target something I set it to false and then it will be set to true in the hooked function.

So, your problem is that you have ALREADY received that packet once you do /casting and you ALREADY have a target.

What you need to do do is either:
1. clear the target AFTER you do /casting and then target it again and then wait for a new buffspopulated to be set.

Or
2. /delay 5s ${Target.Mezzed.ID} after your /casting

I think option 2 is the cleanest way because targeting sends packets to the server and it seems pointless to spam it after each cast just to force a new buffs packet...

Technically I could probably clear buffspopulated upon calling the cast function but I’m not sure it gets updated correctly if I do that and some investigation would be needed which is time consuming...

For now use method 2.

Posted: **Mon Aug 27, 2018 1:55 pm**

I think I understand what you are saying. In the demonstrated case I am not sure that it fits exactly because I am retargeting in between the two mez checks. However, in reality it seems I shouldn't be cycling targets quite so quickly, since targeting forces network traffic. I'll add a more generous universal delay and a Mezzed.ID check after successful casts here all this probably goes away. Thank you!

For ref, the sequence I was trying to describe:
1. Target "Mob A"
2. Guard with BuffsPopulated and Target.ID in /delay
3. Decide "Mob A" has no mez from either Target.Mezzed or Target.Buff[Mez]
4. Mez it with /casting from MQ2Cast

5. <... go target other mobs, repeating mez routine ...>

6. Target Mob A some seconds later
7. Guard with BuffsPopulated and Target.ID in /delay
8. Decide "Mob A" has no mez from either Target.Mezzed or Target.Buff[Mez] - (error, he has mez)
9. Mez it again