ATA - Targeting Addon For Windower 4

Greetings!

Auto Target Assist is my first foray into making an addon for public use. It tracks party and enemy actions to create a pseudo enmity list and uses customizable parameters to pick the next target to attack when your current target dies. It also has a toggleable, on-screen list of enemies it is tracking, and a raid assist target feature.

Github: https://github.com/toast-ffxi/FFXIAddons/tree/main/ATA
For a full list of commands and features check the readme.

Filtering Features
You can customize how the addon will pick subsequent targets by setting

• maximum distance: (distance number enemies need to be within for the addon to consider them for auto targeting)

• hpfilter: (highest, lowest, none)

• petfilter: (whether or not enemy pets will be tracked)

• prefersimilar: (prioritize targeting enemies with the same name as what you had previously targeted. Good for ody segment runs where you want to stick to one family at a time, or if you're on statue killing duty in dynamis and there's enemies everywhere)

• blacklist: (prevent enemies on your blacklist from being tracked by the addon)

Settings
The addon settings were designed to be changed on the fly without overwriting your defaults. So once you get your settings the way you want them, you will have to invoke //ata save to make them your new defaults. This was in case you just want to tweak one thing for a specific activity, without changing what your default settings would be.

There is also a setup mode (//ata setup) for previewing / testing different settings for the visual elements.

Make sure you turn off in-game auto target when using ATA! Unless you just really like your camera flying around and giving you whiplash.

Disclaimer
ATA functions by reading and injecting packets. This can be easily detected by those around you since you will be switching targets faster than a human could. Use at your own discretion. This also means that in areas of high network traffic, it may be slower to switch your target arrow, but this would be the same as if you were trying to manually switch your target in the same high traffic conditions. If there's lots of packet loss happening, some strange things can occur (trying to lock onto a spot where an enemy died, for instance). I've done my best to mitigate this but it's all at the mercy of the client's incoming network buffer. Running packetflow in high traffic areas has been reported to help with target switching speed.

Will you end up putting your weapon away?

Sometimes yes, sometimes no. It seems to be a race condition between the server telling you to disengage, and the addon's injected incoming packet switching your target.

Ok so monster dies and ATA tries to send a change target right when the server is sending a disengage packet. Anyway to block the disengage packet? Biggest issue with turning off autotarget is the massive loss of damage from putting weapon away then taking it back out.

Yes, but from my testing all that does is cancel the animation on your client. Other players will still see you put your weapons away, then take them back out again, or other strange things with your character state can occur. Like other players see you "attacking" with no weapons in your hand.

There is still a delay before being able to attack a new target. The same delay that happens any time you switch your target.

The in-game auto target will always be faster. This is because (as far as I can tell with packetviewer) it doesn't transmit any information when it changes targets. This is why it's instant. There's no communication with the server when in-game auto target takes over. The only communication that happens is when you toggle in-game auto target on or off. The client sends an outgoing chunk (id 0x0DC for those who like to verify things themselves) that windower data.lua lists as "Type Bitmask".

What I can surmise from this is that when that flag is set, both the client and server have all the information they need to determine your next target, and have a shared set of logic they follow. Both client and server know what's on the enmity list, what direction you're facing, and which enemies would be within your cone of vision. So the target switch can happen without sending any communication.

ATA will never be faster than zero communication, but it can be smarter.

You can block the character state change in s>c 0x037 so that you stay engaged. Further, you can track incoming s>c 0x37 to ensure that if the server doesn't properly register you as engaged you can resend any engage packets to correct it. This prevents any chance of other players seeing you disengaged (because really, other players seeing you disengaged is just the server seeing you disengaged, which means you won't hit anything anyway). You should probably be doing this, because the whole point is that waiting for your weapons to go away and back on your screen is clunky and slow (though I guess people might call this comparable to JA0WAIT in that sense).

This is wrong, the server sends packet 0x058 to update your target if you have autotarget on and kill something(note that windower packet lib has the size wrong on that packet: it's 16 bytes not 14 and has 2 unused trailing trash bytes). The client has zero authority over what you're attacking, the server handles all of it. Having both determine it would result in some crazy out of sync behavior.

Edit: None of this is meant as criticism, I don't use windower anyway. This seems like it has had quite a bit of consideration put into it. Just offering information that could help to improve it.

Looks very cool, I am eager to try! I have been searching for something like this for years -- anything to stop auto targeting pet mobs in dynamis.


EDIT: After some light testing, I can say that this is the exact type of autotarget enhancement I've been looking for. Gonna be dope for all manner of thing. If you can do that thing Thorny mentioned about never putting away weapon, I would fall out of my chair.

It isn't really a race condition: with autotarget off, the servers marks you as disengaged at the exact moment your target's HP becomes 0, and *then* sends you the "mob dies" message in another chunk. You're sending the switch command in response to this message, so it means that at the very minimum there'll always be at least a packet cycle delay between you getting the disengage packet and you sending the new engage packet (~800ms, bit less with packetflow), sometimes more if there's any kind of packet loss. So the first suggestion here would be to change target when you get either the hp=0 chunk or the defeated message chunk, whichever comes first (or comes at all)


Thorny already went through why this is wrong so I'll just second what he said.

Autotarget being entirely server side is why a "better autotarget" addon has never been published before - it's not that they don't exist, it's that it's extremely noticeable that you're disengaging and reengaging something else at the speed of light - way faster than the client lets you re-engage after getting disengaged normally. Thorny described how to potentially get around it, but it's not too straightforward to do and it's still prone to desyncing you from the server. While testing you probably found yourself engaged to something and not swinging your weapon at it at all, while something else was whacking at you - that means your client thinks you're engaged to something and the server has a different idea.

None of this is unsurmountable but it all requires a lot more packet monitoring and handling than what you're doing currently.

And yeah, lua has no continue statement. One of my greatest sadnesses about the entire language >_>

This is interesting, as I have less of this issue using ATA (I've been one of his testers). I've only tested ATA in Odyssey due to the annoying way auto target targets the same enemy as everyone else. However, while it is slight slower to target, it did properly target without causing what you mentioned above. Glad I wasn't the only one having that issue though. Thought it was packet flow or some update they did because it has been happening way too much in zones with many enemies.

The client actually has *no* idea what you're engaged to, and simply follows some logic for displaying your current target. This generally happens if you engage(causing client to begin changing to engaged dialog), then something swings at you at the perfect frame to make you target it before the client finishes changing dialogs and locks.

This could pretty easily be prevented by monitoring incoming/outgoing packets for what you're actually attacking and force setting your target in this kind of mismatch.

This also happens when PCs cast on you, sometimes locking your "engaged" dialog box into a PC while you are attacking a mob, preventing you from using any /ws .. <t> macros since the target is now a PC.

This happens quite often in situations where target changes a lot.

Yea, same scenario. Target blanks momentarily between the dialog changes, and if something acts on you(whether it's a pc casting or a mob swinging) while it's blank, the target will change to that. Then, the lockon procedure from engaging doesn't overwrite the new target, so you end up engaged but with your target set to the wrong thing. You can force an example by hitting attack manually then pressing escape right before you engage(with the auto lock on setting disabled), you'll end up with nothing targeted but still engaged to the monster you attacked.

The client is never sent anything that specifically says which monster you engaged, just that your status changed to attack. It does some locks on your target at that time but no verification that the target matches what you engaged, and that's why you can end up in that situation.

Been testing this the last few months and really enjoy it in ody and dynamis. Simple just not targeting mobs at 5% or pets has been really nice. Good work Toast and happy to see it getting more eyes and sounds like some new improvement can be made.

Yep now that he's got a framework we can all test with, I think the others can help with iterative improvements.

I am intrigued. I thought I tried doing this exact thing before when I was testing and while it did stop me from disengaging on my client, it did not stop other players from seeing me disengage > engage. Effectively it was acting just like JA0WAIT from the perspective of other players. It also didn't seem to improve the amount of time it took from an enemy death until I started swinging at a new one when I was blocking the update character chunk.

I would LOVE to make this work but when I tested it only seemed to affect the visual state of my client, not what the server thought I was doing, and not what other players saw me doing. Perhaps I am missing something obvious. I can try looking into it again.

This is something I was pulling hair out trying to figure out. I could have sworn that an incoming 0x058 was not showing up on packetviewer when in-game auto target did it's thing. Is there any reason why packetviewer wouldn't see it only when auto target fires off? Because it caught the target change every time I changed manually or when ATA changed targets. Maybe I was just super tired and did something wrong but I distinctly remember thinking "well that can't be right, let me try again" when testing. I can also try messing around with this again. It makes WAY more sense that it would just come from the server with the death message but I just wasn't seeing it before.


I welcome criticism, skepticism, suggestions, and even clever insults if it leads to improvements.

ATA is doing exactly this. With the defeated / falls to the ground chunk. When it's received it determines the next best target and injects a fake incoming target switch packet, to make the client switch the targeting arrow as fast as possible, and an outgoing one to let the server know what you switched to. In my testing the hp=0 and defeated message came in the same cycle.

So many desyncs while testing... so much jank while learning. Much of which, as already discussed by others, you can do without even injecting any packets.

Lua gave me the big sad.

Right, I oversimplified a bunch, should have said something like "your client has locked you onto something while the server has you engaged to something else". But when injecting targeting packets, this also happens if the timing of injected commands ends up racing with what the server is sending you. Especially when injecting s>c targeting commands, as so many targeting addons do - that was the main thing I was referring to.


^ This


From reading your code, it looks like you're only listening for the defeated message. But that message is often dropped. Hp=0, target defeated, and target change (this one only if you set autotarget on) are all separate commands, and as such it's possible that in some conditions they get to you in different UDP packets (an udp packet can contain multiple commands, or chunks, we call them "packets" but it's a misnomer), or not at all - that's how you get a dead mob stuck at 1% on your screen. Or a 0% mob with the name gray that is never despawning, or that you are stuck engaged to for a whole lot of time until finally the client catches up with the server. My suggestion, that you quoted, was to monitor all of those packets, to increase the chances of catching at least one.



Lastly, I am sorry to be the thread pooper, but I feel like this must be said:

This is extremely detectable and obvious when you're using it, and people can and will report you for it.
Addons like this one are not new, you're just the first one to release your interpretation publicly, and most of those who wrote it haven't released it precisely because how janky it all can end up being and how obvious it is for anybody standing around you. You're probably safe from reports by using it around friends and in instanced content, but I would recommend the caveat emptor should be stated very clearly in your opening post.

You are correct. I'll amend my original post to be more clear.

Disclaimer; I don't know anything about sending packets, so I can't speak to the nitty gritty coding details.

But so are things like Superwarp, EasyFarm, CurePlease, Healbot, React, Anchor, and any number of addons people use at all times, no? And that's not even factoring in people's casual Tako use. All detectable, even by the naked eye, and all obvious.

The determining factor on you getting banned is if somebody is going to report you or not. And is this particular addon the tipping point for somebody reporting you? I don't see why it would be. You are just as likely to get reported for overnight exemplary pointing with EasyFarm.

Please let's not start with the usual charade of disingenuous rhetorical questions, comparing uncomparable things. It's not about being more or less dangerous, or about being the tipping scale. Anything that is obvious should carry a disclaimer.
The stuff you cited, with the exception of superwarp that is written to be as client-like as it can be, and with the addition of jazero, fleehacks, and the likes, are all straight out bots or explicit exploits, are extremely obvious to bystanders, and do get people reported all the time. Heck, there's japanese twitter accounts that specifically publish info on NA players that use such tools.

Due to the way autotargeting works, an addon such as this one, while an amazing qol for sure, falls in the same category of "very obviously not humanly possible, caveat emptor, you'll get reported", and to be ethical it should be disclaimed as such. That's all.
(at least until such time where it stops being obvious to bystanders, which is not entirely impossible)

I won't dwell into how accepted it has become to bot exemplar points at night so that easyfarm gets put in the same bucket at superwarp, we can have this discussion in another thread and not pollute this one further.

I certainly didn't mean for my post to come across as a disingenuous rhetorical question. I am not pondering about the ethics. I'm not trying to "getcha". In fact, I was looking for maybe some enlightenment from somebody who does understand the guts of these things.

Your big bold statement gave me pause and made me think that this is inherently different than something like JAZero, Anchor, or HealBot. Is this particular addon, AutoTargetAssist, fundamentally different from the addons I mentioned? Not rhetorical. Not an attack. It seems like you might know the answer. Is this some sort of different flavor of packet handling or are you simply emphasizing that commonfolk can eyeball this pretty readily?

I do really like the populated mob hp bar list, but for now I'm not using the addon's auto target feature

From my limited testing, the addon is slower than a real human switching targets and accounting for a delay before the original mob dies.

Eg, WS on a mob, switch targets quickly via 'switch target' menu, original mob dies and you're already swinging at something else.

It's good for selecting new targets more smartly than autotarget. Faster than humans, not necessarily, depends on the player.

I tried in a Dynamis D last night and it couldn't keep up with the lag. I had to tap out after a few minutes of use because it simply would not target the next thing.

Maybe under better conditions it would operate a little cleaner. I was 6 boxing and EST primetime has been exceptionally laggy for me the past few weeks.

Unfortunate.

It does only effect the visual state of your client, but that's kind of what people want: to avoid the clunky disengage and reengage state changes on their client. S>C communications are only every 400ms for people not using packetviewer, and the server won't tell someone else you disengaged and reengaged in the same communication, so there's always at least a 400ms gap in disengage>reengage. Preventing others from seeing you disengage 100% of the time isn't possible unless you can predict when the mob will die, because sometimes the server will send a packet to other people before a round trip to you occurs.

I don't have any obvious reason, as I don't use windower. However, like I said, windower's packet lib has the size wrong. That could be related, I don't know if packetviewer validates size as well as id.

This can be potentially fixed too, you often get discarded packets in instances and the same packet has to be sent 2-3x before it reaches server. If the packet is triggered by client logic, it will be resent every interval until the server acknowledges it. When you inject using windower, this doesn't happen, so any time a packet has to be resent the injected ones attached to it get discarded and lost. As a result, you're going to see this behavior very frequently in instances where server load is high.

The auto target clunkiness was one of my biggest pain points in recent content.. Good work addressing this, it’s been long overdue.

I remember complaining about this years ago and suggesting they overhaul the auto target AI at the last AMA. They said they would look into it and never did. Another one of those annoying things the players have had to address that should have already been a thing.

I can't speak for other addons, but ATA doesn't do anything special that I know of. It uses the standard packets library included in windower 4. It doesn't break or change any game functionality like JAZero or Anchor. The closest equivalent would be React. It's reacting to death messages and sending target change commands. What would be easily noticeable would be things like your character disengaging when your target dies and instantly re-engaging to something behind them. Maybe not as glaringly apparent as Anchor, for instance, but still worth a warning.


Without being there to speak to the exact conditions, there are scenarios where it may seem like the addon is completely breaking down. For instance: if someone else is far away pulling a group of mobs, and sleeps them all before you get in range, then none of those enemies will be on ATA's enmity list because you weren't in range to receive the action packets of party members acting on them, or the enemies acting on a party member.

It's also just likely due to congestion and messages getting lost. If you do feel like it's packet loss you can invoke //ata next which will force the addon to go through it's target selection logic again and re-send the packets. You can use this command when engaged to something (it will pick a different target than what you're engaged to), or even with nothing targeted at all. If you invoke //ata next or //ata nextdiff when you are not engaged then the addon will only change your target client side, and you can send the engage command through normal client methods (menuing or /attack). This would let you get the benefit of the smarter selection of targets in the chaos while letting the client handle re-sending any lost engage messages.


I briefly thought about something like this. Trying to somehow handle if a message got lost automatically. But I decided that my own ignorance in trying to engineer something like this would potentially cause far more problems than benefits. I opted to just include the previously mentioned commands so that the user can decide if they want to make the addon try to select a target again.

R E S U B S C R I B E

Be back soon gotta take care of some crap then it's back to galka afk life and I'll respond to your tell three hours late

Another thing I've noticed trying this addon is when it chooses a target, switching to another target via the 'Switch target' menu item does not work.

You are stuck on the target ATA chose until it is dead or you manually disengage and re-engage on something else.

Switching targets is sometimes needed when it chooses a target other people have also switched to. Disengaging and re-engaging is a big slowdown in this case.