Problem - Tank has one OOR mob targeted, while getting beat by others.

[tms]

Ok, this one i need to explain a bit.

Lets say the bard pulls 3 mobs, lv 1, lv 10, lv 10. The bard uses an AoE or DMG Shield while hitting one of the Lv 10 mobs.
The Lv 1 mob get low on health from AoE and DMG Shield and starts to run.

Lv 10 mob dies and the bard targets the Lv 1 mob, who's OOR meanwhile.

Now, the bard will just stand there, the runner targeted, while the second Lv 10 mob is beating him. He will do nothing until he is dead.

There should be an check, if the mob is to far away, the tank should just forget the mob, but atleast should react on the mobs in camp hitting him.

 

[Dretski]

It happens to me sometimes too, leaving my toons dead usually.

 

[Razkle]

um don't let him run? If you let a mob run away you need to reevaluate how your camp is set, this is kiss not kisc (Keep-it-super-complicated)

Change your strategy, add a root at 15% to one of your DPSers and hold the mobs so you can finish the 3 hour task of killing that level 10....

Ok, sarcasm aside, seriously I used to have this happen in grounds and added ROOT/SNARE to my Druid and problem solved.

Sometimes rethinking a problem is all it takes, it is not anything KISS is doing wrong, it is something your toons need to adapt to.... Root em, Kill em, KISS em!

 

[tms]

um don't let him run? If you let a mob run away you need to reevaluate how your camp is set, this is kiss not kisc (Keep-it-super-complicated)

Change your strategy, add a root at 15% to one of your DPSers and hold the mobs so you can finish the 3 hour task of killing that level 10....

Ok, sarcasm aside, seriously I used to have this happen in grounds and added ROOT/SNARE to my Druid and problem solved.

Sometimes rethinking a problem is all it takes, it is not anything KISS is doing wrong, it is something your toons need to adapt to.... Root em, Kill em, KISS em!

Cool advise, now tell me how you handle this with an lv 10 bard.

Beside this, it dont work, because KISS snares the mob currently attacked by the MA. The mob who runs was never attacked by the MA.
Think a bit out of the box, not everyone uses kiss for high lv groups, sometimes it's used with 2 low level chars.

 

[mroutlaw]

well I would say use /switch and snare both after first ones snared switch targets and kill the second ,? not sure because what you are asking for I don't think it would ever do unless you had vinlash then it would be a mess

 

[winnower]

does switch work on tank?

I've had problems with tank just picking up close mobs on the initial target acquisition. Like I did plane of time phase 1, with 5 toons in tank/hunter mode, and they would lock onto mobs outside their area.

 

[TreeHuginDruid]

Ok, this one i need to explain a bit.

Lets say the bard pulls 3 mobs, lv 1, lv 10, lv 10. The bard uses an AoE or DMG Shield while hitting one of the Lv 10 mobs.
The Lv 1 mob get low on health from AoE and DMG Shield and starts to run.

Lv 10 mob dies and the bard targets the Lv 1 mob, who's OOR meanwhile.

Now, the bard will just stand there, the runner targeted, while the second Lv 10 mob is beating him. He will do nothing until he is dead.

There should be an check, if the mob is to far away, the tank should just forget the mob, but atleast should react on the mobs in camp hitting him.

(cough) Bard mezz the mobs tank (main assist) not actively engaged on..... so they are there stuck in camp until MA cycles to next mob.

Crowd control is more than just keeping the adds from beating on group... its also to control they stay in MA's melee engage distance.

Setup bard's single and group mez SONG... and number of mobs in campradius that will trigger group mez spell.
Refer to the documentation to correctly define these items in your KissAssist_ToonName's.ini for [Mez section]

Mez Documentation

Make the changes and please report back... ticket upgraded waiting on user response.

And UPGRADE kissassist to new patch please! 8.2.6

 

[tms]

The moment i wrote this, 8.2.5 was the most current version.
And if the Bard is the MT/MA he's not CC'ing Mobs. Plus the lv 10 bard dont have an mezz.

Also, this dont work if the MT/MA ist an Warrior, and he's solo.

You seem always to think KISS is only used by full groups of lv 105 chars.

It's a bug, and it's not that hard to fix i think. Just need a range check to not standing and get beaten to death.

The hints are allways how to work around it, but in some setups at some levels you cant work around it.

If KISS is just not for such cases, the beginner guide should maybe not use an lv 1 cleric to show how KISS is for all levels ;P

 

[ctaylor22]

Here would be my fix. I have not tested this, but it should work. Find the SUB Assist routine and around line 777 you will see this code, I have highlighted the changes. This requires that you have at least 2 auto haters in your extended target window.

Ok here is the revised /if's that should work for any situation. I will explain below the code.

                /if (${MobCount}==1 && (!${XTSlot2} || (${XTSlot2} && !${Me.XTarget[${XTSlot2}].ID})) && ${AggroTargetID}) {
                  /if (${DebugCombat}) /echo DEBUGCOMBAT Assist: ${MobCount}==1 && ${AggroTargetID}
                    /squelch /target id ${AggroTargetID}
                    /delay 10 ${Target.ID}==${AggroTargetID}
                    /if (${DebugCombat}) /echo DEBUGCOMBAT Assist: Single target: ${AggroTargetID} ${Spawn[${AggroTargetID}].CleanName}
                    /goto :validatetarget
                }
                | More than one mob
                /if ((${MobCount}>=2 || (${XTSlot2} && ${Me.XTarget[${XTSlot2}].ID})) && ${AggroTargetID}) {
                    | Check if named incoming an target if true else assign closest target.
                    /for n 1 to ${XSlotTotal}
                        /if (${Me.XTarget[${n}].TargetType.Equal[Auto Hater]} && ${Me.XTarget[${n}].ID}) {
                            /if (${Me.XTarget[${n}].Named}) {
                                /squelch /target id ${Me.XTarget[${n}].ID}
                                /delay 10 ${Target.ID}==${Me.XTarget[${n}].ID}
                                /goto :validatetarget
                            }
                            /if (!${ClosestMobID}) /varset ClosestMobID ${Me.XTarget[${n}].ID}
                            /if (${Math.Distance[${Spawn[${ClosestMobID}].Y},${Spawn[${ClosestMobID}].X}:${CampYLoc},${CampXLoc}]}<${Math.Distance[${Me.XTarget[${n}].Y},${Me.XTarget[${n}].X}:${CampYLoc},${CampXLoc}]}) /varset ClosestMobID ${Me.XTarget[${n}].ID}
                        }
                    /next n
                    /squelch /target id ${ClosestMobID}
                    /delay 10 ${Target.ID}==${ClosestMobID}
                    /goto :validatetarget
                }

The first /if checks if there is at least 1 mob in camp AND(&&) you don't have a second Auto Hater defined in you XTargets OR(||) if you do have a second Auto Hater defined AND(&&) there is NOT(!) an ID in that slot and you have an AggroTargetID(Basically there is a mob in the first Auto Hater Xtarget slot) then do this. What this will do for you is when you have a second mob ID in the Xtarget slot this code will be skipped. This is what you need for when only 1 mob is in camp and the other has run away from camp and is no longer being counted in MobCount.


Now the Second /if checks for if that there are 2 or more mobs in camp OR(||) you have a second Auto Hater in your Xtargets AND(&&) there is a mob in that slot AND(&&) you have an AggroTargetID. This fixes the issue when you have 1 mob in camp(MobCount<2) OR(||), The one standing next to the Tank beating on him and the other mob, who ran away, is not in range and is not being counted in MobCount. Even though the mob who ran away is no longer being included in the MobCount the (${XTSlot2} && ${Me.XTarget[${XTSlot2}].ID}) will acknowledge that there is more than 1 mob, even though it is not in range. Now when this block of code is executed the Closest Mob should be picked up, you know the one beating on the tank.

Give it a try and let me know how this works or not work.

Have fun!

 

[TreeHuginDruid]

Logically sound as usual Chris... waiting on 8.2.7 code and want to get this added to it..... but of course... gotta snatch a lizard by the tail and confer.

 

[Maskoi]

This needs to be tested.