Need Help Referencing Buff IDs In Job_buff_change

While you can reference buffactive[##] to pinpoint a specific type of buff (normal Haste, 33, vs Geo Haste, 580), I haven't been able to figure out the proper syntax to do so in the job_buff_change function.

Essentially, right now I set


to play a sound through windower to let me know the buff has dropped, How do I tailor this to only return true when buff ID 33 drops, and not ID 580?

I've tried the following variants which don't work:

I've searched for info both referencing buff IDs as well as the job_buff_change function but have come up with nothing. I appreciate any and all insights - thanks!

You could try

then add your code to play that sound below then it should work.

Thanks Riyoko, that's pretty close. The only downside to that is when I have multiples of these (say, for as a BLU, when Nature's Meditation goes down, and Haste, and Refresh). Then, if any one of them drops (and thus triggers the job_buff_change function), and Haste ALSO isn't up, it will give me a false positive.

Is Windower generally devised such that you can only use the buff ID to check for active effects rather than changes of state?

the main issue is that motes include has not been updated for a long time and some things are not included in his code

like the below
in gearswap the full function is
buff_change(name,gain,buff_table)
but in motes include (as mote controls the buff_change function)
job_buff_change(buff, gain, eventArs)
so you lose the buff_table which already has what you are looking for

-edit-
one more thing
T(windower.ffxi.get_player().buffs):contains(33) can still show incorrect info when used in the buff_change sequence as gearswap directly gets all it data from the packet not memory for the buff_change function

Hmm this is quite tricky but do the following:

below function job_setup() add this
determine_haste_state()

then make a new function somewhere like this:


and below job_buff_change(buff, gain) function add:
and below function job_update(cmdParams, eventArgs) add:


and I think this should do it and other buffs shouldn't trigger the code again.
sorry for the wonky solution but I hope it helps. let me know if it works or not

Thanks again for the pointer Riyoko, was away from the PC all weekend but will give it a shot tomorrow. It looks like a pain but if it works I'll mimic the setup for Refresh as well. It'll be pretty awesome if it does end up working out, that way I can stay on top of my buffs and not get notifications everytime I move in/out of a GEO's range, heh.

And thanks Kigensuro as well for the additional background.

It's 2 weeks later and I wanted to thank Riyoko again for cobbling that bit of code together. It's a nearly complete solution - I've extended this to similar functions for regen/refresh so that the Geomancy version doesn't give me a false alarm and I have a much easier time keeping buffs up on BLU.

Just for awareness, there is only one quirk with this approach, that is that I can't seem to get it to work for buffs with multiple names in the title. For example, I tried to extend this to the buff from Nature's Meditation ("Attack Boost" 91, in order to exclude 549). I couldn't get it or similar buffs to work ("Defense Boost" from 93, "Magic Def. Boost" from 191, etc), and the only difference I can point to are the spaces in the name. I tried S{'attack boost'} and S{'attack_boost'} in the job_buff_change section, but it never triggered when the buff naturally fell off. Interestingly it DID trigger when I changed jobs, losing the buff in the process, so go figure. It's not a huge deal because it's far less likely to have these conflicting buffs than haste/refresh/etc.

So thanks again Riyoko for coming up with a rather novel solution, it's much appreciated!