Here is a copy paste of the bug report in case that file does not work.
Bug Report: Followers don't retarget when raid Main Assist switches targets
Component: Sub CombatTargetCheck / Sub CombatTargetCheckRaid
Affects: Any raid (12+ characters across multiple groups), regardless of role
Severity: High for raid users — followers attack a single target and never switch even after the raid MA moves on, requiring manual intervention or a full combat reset to recover.
Summary
In raid format, non-MA characters never notice when the designated raid Main Assist switches targets mid-fight. They correctly assist onto the
first target in an engagement, then get stuck on it (or its corpse) until something external forces a re-target (e.g. /switch, a broadcasted target ID, or the mob despawning).
This does
not happen in pure group play with a properly set in-game Group Main Assist — that path works as designed. It is specific to raid mode, where the in-game
raid assist designation overrides/replaces the native group Main Assist flag, and the macro has no live mechanism that follows the raid assist target instead.
Root cause
There are three contributing issues, all in the same area of code:
1.
| Line ~2311, in CombatReset:<br>/if (!${IAmMA} && ${TargetSwitchingOn}) /varset TargetSwitchingOn 0<br><br>| Line ~8838, in role setup:<br>/if (${TargetSwitchingOn} && !${IAmMA}) /varset TargetSwitchingOn 0<br>
This is presumably intentional (TargetSwitchingOn appears designed to let the
MA react to a manually-changed Target.ID}), but it means followers have zero fallback to this mechanism — they're entirely dependent on the Group.MainAssist/raid-assist detection block in CombatTargetCheck working correctly.
2. The live retarget gate in
| Sub CombatTargetCheck, ~line 1353<br>/if (${Spawn[=${MainAssist}].ID} && ${Group.MainAssist.ID} && ${Spawn[=${MainAssist}].ID}==${Group.MainAssist.ID}) {<br> /if (!${IAmMA}) {<br> /if (${Target.ID}!=${Me.GroupAssistTarget.ID}) {<br> /if (${MyTargetID}!=${Me.GroupAssistTarget.ID} && ${Spawn[id ${Me.GroupAssistTarget.ID} npc].ID}) {<br> /varset MyTargetID ${Me.GroupAssistTarget.ID}<br> }<br> }<br> }<br> ...<br>} else {<br> | falls back to CalledTargetID / AttackCalled broadcast event only<br>}<br>
This is the sub that's actually called every combat tick (from inside Sub Combat's attack loop, and elsewhere). It only ever checks Group.MainAssist/Me.GroupAssistTarget. When in a raid, the native in-game Group Main Assist designation gets overridden by the raid assist designation, so Group.MainAssist.ID no longer matches Spawn[=${MainAssist}].ID}, and this whole block is skipped. Followers fall into the else branch, which only updates via CalledTargetID, populated by the AttackCalled event — i.e., it only works if something explicitly broadcasts a target switch and the follower's broadcast plugin (EQBC/DanNet) receives it. There is no native polling of raid assist state at all in the sub that's actually called.
3.
grep -n "call CombatTargetCheckRaid" kissassist.mac<br>→ (no results)<br>
CombatTargetCheckRaid is defined (~line 1420) but never invoked anywhere in the macro. Every actual call site goes to the group-only CombatTargetCheck.
Even setting that aside, the sub itself doesn't fully implement raid support:
/declare CIDCheck int local 0<br>/if (${Raid.Members}) {<br> /varset CIDCheck ${RaidTargetID}<br>} else {<br> /varset CIDCheck <br>}<br>| Check target matches MA if group mainassist assigned and MA is in group<br>/if <br>/if (${Spawn[=${MainAssist}].ID} && ${Group.MainAssist.ID} && ${Spawn[=${MainAssist}].ID}==${Group.MainAssist.ID}) {<br> ...<br>
CIDCheck is computed from ${RaidTargetID} but then never referenced again anywhere in the sub — the actual gate is still the same Group.MainAssist check as the non-raid version, so even a wired-up version of this sub would behave identically to CombatTargetCheck and still fail in raids. There's also a stray, condition-less /if line immediately above the real one, which looks like leftover/abandoned edit debris.
4.
| Sub InitData, line ~16240 (called exactly once, at line ~307, before the main loop starts)<br>/noparse /varset RaidTargetID ${If[${Me.RaidAssistTarget[${RaidAssistEntry}].ID},${Me.RaidAssistTarget[${RaidAssistEntry}].ID},${If[${Me.XTarget[${XTSlot}].ID},${Me.XTarget[${XTSlot}].ID},0]}]}<br>
InitData runs a single time during macro startup. RaidTargetID is therefore frozen at whatever the raid MA happened to be targeting (if anything) the instant the macro launched, and never refreshes. Even if CombatTargetCheckRaid were wired in and its CIDCheck value were actually used, it would still be stale for the entire macro session.
Net effect
There is currently no live path for a follower to detect that the raid Main Assist has switched targets:
- TargetSwitchingOn → forced off for non-MA.
- Group.MainAssist → not populated/matching once a raid assist designation is active.
- CombatTargetCheckRaid → dead code, and incomplete even if called.
- RaidTargetID → stale, computed once at startup.
The only thing that still works is the CalledTargetID/AttackCalled broadcast fallback, which depends entirely on something else explicitly sending a target-switch event (e.g. via the /switch bind) and the follower's broadcast plugin receiving it.
Suggested fix
In Sub CombatTargetCheck, poll ${Me.RaidAssistTarget[${RaidAssistEntry}].ID} live (not the cached RaidTargetID) and use it as an additional/alternate branch alongside the existing Group.MainAssist check, e.g.:
/declare RaidAssistTargetID int local 0<br>/if (${Raid.Members}) /varset RaidAssistTargetID ${Me.RaidAssistTarget[${RaidAssistEntry}].ID}<br><br>/if (${Raid.Members} && ${RaidAssistTargetID}) {<br> | raid assist path — compare against RaidAssistTargetID instead of Me.GroupAssistTarget<br> ...<br>} else /if (${Spawn[=${MainAssist}].ID} && ${Group.MainAssist.ID} && ...) {<br> | existing group MA path, unchanged<br> ...<br>} else {<br> | existing CalledTargetID/AttackCalled fallback, unchanged<br>}<br>
This mirrors the existing group-MA logic structure exactly, just sourced from the raid assist TLO instead of Group.MainAssist/Me.GroupAssistTarget, and polled every tick rather than cached once at startup. CombatTargetCheckRaid could then either be removed (since it's unused) or replaced by actually wiring this logic into it and calling it instead of CombatTargetCheck when ${Raid.Members} is true — either approach works; the important part is that something live actually checks raid assist state per-tick.
Reproduction
- Build a raid of 2+ groups (12+ characters), each group running KissAssist.
- Set the in-game Group Main Assist on a tank in one group as normal.
- Have a raid leader (or anyone with raid assist privileges) set a raid Main Assist / Raid Assist 1, which overrides the group-level MA designation.
- Engage a mob; followers correctly assist.
- Have the raid MA switch to a new target (e.g. mob dies and the next target is picked, or the MA manually retargets).
- Observe: followers in groups other than the raid MA's own group (and frequently even within it, once Group.MainAssist stops matching) continue attacking the original target/corpse and never switch, until /switch is broadcast or some other external trigger forces it.
Environment
- KissAssist version: v12.002 (KissRevision = 039, per the macro's own /declare KissRevision string outer 039), maintained for RedGuides by Ctaylor22.
- Tested in raid format only; group-only play with native Group Main Assist set is unaffected.
www.redguides.com
