/ifcmd -o (Test for Mouseover) doesn't work with DelvUI Player Frames

I'm not sure if this is a TinyCommands problem or a DelvUI problem. For some background, I'm trying to run a Healer Macro (naturally, comments are not in the final macro):

/micon "Egeiro" action                                  //Make the button look like Egeiro (SGE's Raise) so I can see Recast, MP cost, and availability.
/ifcond -OFP /echoerr Get a friendly target first!      //FIRST OF ALL, IF I don't have a mouseover target, a focus target, or a human target, tell me I messed up...
/ifcond -OFP -$ /playsfx 11                             //...then play an angry sound effect, and throw out everything after this line. Better luck next time, dumbass.
/action Swiftcast <wait.1>                              //Get Swiftcast.
/ifcond -o /p Raising <mo>! <se.3>                      //IF my mouse is hovering over someone's name, tell the party I'm raising my Mouseover Target...
/ifcond -o /action "Egeiro" <mo>                        //...then raise my Mouseover target, pursuant to that evaluation.
/ifcond -tp /p Raising <t>! <se.3>                      //IF I have someone targeted and they're a player, tell the party I'm raising my Target...
/ifcond -tp /action "Egeiro" <t>                        //...then raise my Target, pursuant to that evaluation.
/ifcond -Ofp /p Raising <f>! <se.3>                     //IF I don't have a Mouseover Target, but do have a Focus Target and they're human (the Tank), say I'm raising my Focus Target...
/ifcond -Ofp /action "Egeiro" <f>                       //...then raise my human Focus Target, pursuant to that evaluation.

(I'm not great at coding, and I'm actually very proud of this, even though it probably will break immediately in practice and doesn't have, like, basic exception-handling for if somehow no criteria apply, or whatever.)

However, this flops right out of the gate because it doesn't appear to interact with DelvUI's Mouseover handling. I've been using DelvUI for so long that I don't actually remember what the stock UI is like, and one of the things I use is that the game evaluates hovering the cursor over a name in an entity table (the party list, the enmity list, the Focus Target box) is akin to hovering the mouse over that entity itself. I don't remember if that is normal behaviour, and is because DelvUI. has a dedicated Mouseover function (as well as a fallback, which isn't relevant here): But hovering the cursor over the DelvUI player list causes the /ifcond -o evaluation to fail. /echo <mo> returns the party member whose name I'm hovering over, and all spells and macros that otherwise depend on <mo> pass properly (provided that "Mouseover" is active in DelvUI).

Reckon there's anything that can be done about this?

(As an aside, during testing, I found that an evaluation like /ifcond -op ("Do I have a Mouseover Target and is it a player?") fails (even if hovering on a player's model, and not this DelvUI faff). It would be useful in my macro to make sure that I don't pop my Swiftcast and fire off a haphazard Egeiro if my fingers slip while I'm fighting the crowd of enemies my cursor is hovering in. The -p argument (and its inverse), however, seems to respond properly to the other methods of targeting. -fP specifically passes in my test scenario of Focus Targeting an NPC.)

There's a couple of things here: first, you can add the $ flag to the second /ifcond of each pair, so that if it applies, the macro halts after raising. Second, this is probably a joint issue actually, but I consider most of it on DelvUI's side, with the explanation below. Third, the /ifcond -op thing doesn't do what you expect, no: -o tests for a mouseover target, and -p tests for your normal target being a player, so that combination will require a mouseover and a player being targeted. The -fP is similar: any focus target and not having a player (normally) targeted; if you focus an NPC and then target a player, you'll see it break the same way.

This is one of the reasons that conditional commands are deprecated in favour of WoLua, which already allows much more control and is a lot easier to expand on. It doesn't yet support testing the type of various targets, but that's already on the list to be added.

The issue with DelvUI is that I'm using Dalamud's standard TargetManager.MouseOverTarget, which is the official and normal way to do this. I don't use DUI personally, but given how I'm doing it, I can only assume that DelvUI's total UI replacement breaks Dalamud's target manager and they probably replace the functions that handle <mo> placeholders to inject their own tracking. Since TinyCommands already pokes at that function for the /evaluate command, I doubt it would be too hard for them to simply hook it and run their own custom parser first to handle anything that they break. The problem is that this doesn't actually stop them from breaking it, as seen here.

Frankly, I don't think I can really fix this on my end; DUI breaks a lot by completely overwriting the game's entire UI, and it's probably sheer luck that it took this long for any of my plugins to suffer from it. If they can change their system to properly set the game's mouseover target, this will work normally again, and so will any other plugins that depend on such information.

While I'm talking about your macro, by the way, you may want to look into something like ReAction instead. It'll let you define a priority list for targets per-action, while still retaining the action queueing system that macros don't support. You'd only lose out on the party announcements, but if your party uses ResPlz then they can see who you're raising anyway, and more intuitively.

I understand. The point of the macro was (would have been) expressly for party announcements. I alternately find myself cueing a Swiftcast only to hear a beep in chat that someone has taken the task upon themselves and now I have a Swiftcast that I can't use, or getting a Swift Raise off and then hearing the beep in chat aimed at my patient. In either case, a healer is getting inconvenienced. I actually already use ReAction. All of the beneficial spells and weaponskills are set to mouseover (and maybe a few other things), and these seem to work with DelvUI.

If this isn't "your problem to fix", or whatever, I don't have the knowledge or experience to disagree. I'd debated with myself whether this was "your" problem or "theirs". I'll have to consider where to go from here. WoLua looks interesting for some other unrelated ideas.

Thanks for your time!

I'm surprised it works with ReAction. I wonder how they're doing it differently. You can see how /ifcond does it in the source, checking Plugin.targets.MouseOverTarget, and if you look at the source for Plugin.cs you can see that's Dalamud.Game.ClientState.Objects.TargetManager. My access to your mouse over target is provided by Dalamud itself. If DelvUI is breaking it but ReAction is working fine, they must be using some alternative that I haven't seen.

I'll try to take a look at ReAction's source, maybe I can figure out DUI compat somehow. No promises, but I'll give it a shot.

Found it - looks like FFXIV itself makes a distinction between your UI mouseover and field mouseover targets. Dalamud's target manager apparently only offers access to the field mouseover. ReAction is manually reading the game's memory at a particular offset in order to find the UI mouseover target, which DUI presumably does set correctly by the sound of things.

I'll add this to the todo list for WoLua, but I'm afraid that TinyCommands conditionals are already deprecated and no longer receiving updates. Not to mention condition processing for this one in particular is already a mess, and I'm running out of flags to use for things.

PrincessRTFM / TinyCommands

/ifcmd -o (Test for Mouseover) doesn't work with DelvUI Player Frames #7