Question - Help w/Down - PullerTank needs to address XTarg

[Incognito]

Problem: PullerTank does not engage adds in camp. KA does not pull if adds in camp however everyone is assisting the PullerTank so it HAS to engage the XTarg, and it doesn't. I believe the problem is same for designated Tank as well but don't remember as I don't use Tank outside PullerTank much. Uncontested adds are the bane of my multi-boxing experience and I give up trying to solve it from inside KA.

Been playing around with a Down that will handle it. If I am present to witness the tpw, all I have to do is manually target the XTar with the tank. That's it. Then everything works problem solved.

Downshit requirements:

• Only fire when KA is running (don't want this firing at any other time)
• Tank not in combat (don't want to switch targets) (have to test for combat due to timing overlap between Combat/NonCombat mode switching even tho this is a Down)
• XTar is in range (say we evac'd, or some other reason we are now far away)
• XTar is not being addressed by another toon (if it's being handled, not sure I care - problem I am solving here is uncontested XTars)

What I've been playing with:

downshit1=/if (${Macro.Name.Equal[Kissassist]} && ${Me.XTarget[1].ID} && !${Me.Combat} && ${Me.XTarget[1].Distance} < 51 && !${Me.XTarget[1].Assist}) /multiline ; /tar ID ${Me.XTarget[1].ID} ; /bcg /echo ** Targeting XTarg1 << ${Me.XTarget[1].Name} >> **

I would love to add a test for the macro.name being null (in case not running KA). Had one, don't think it worked, took it out.

It seemed to have been working so I left it on overnight which was a disaster (don't ask).

The only time I didn't have probs with adds was when I had a tank merc out, auto-assist on, and everyone 'assisted' it. I've been trying to let KA manage the mercs so auto-assist is off. One reason I wanted KA to manage the mercs is because if the merc is on auto-assist it often engages too early and therefore out of range for the rest of the group to engage.

Any help is greatly appreciated!

 

[Wink-]

When I use pullertank, I have no problem assisting adds. Want to post your ini? My guess would be there is a radius problem.

 

[Pugs]

I use pullertank all the time and have no problem with adds the group kills one then the pullertank awakens the next one in camp and kills it rinse repeat until they are dead or we are dead. It you would post your Ini we could take a look at it. Or I might not understand your problem clearly

 

[ctaylor22]

It is important to have crowd control when using KA. No crowd control then lots of deaths.

 

[Incognito]

My INI is in constant flux; I'm always trying new/different things, tweaking etc. As such, a setting could be left in an ineffective state. Thx Wink and Pugs for reminding me of that as I did in fact have campradius set real small left over from when I was trying to keep the tank on a small leash to avoid the early engagement of incoming mobs (which lent to slowly but surely getting further and further from the rest of the camp - which I coined camp creep).

CT: I agree, but this wasn't so much the need for CC as much as the tank standing there not engaging adds. Since everyone else assisted the tank, everyone died without having moved a muscle. The fact that is was over and over again, well...

I hope a bard is an adequate CCer since I don't like robes (so ENC is out, but I make an exception for WIZ tho), I am raising one up now.

It seems to be resolved right now by resetting campradius to a normal value. I will watch it carefully since this last episode. I'm glad I don't have to resort to downs, so far I had been able to avoid it. I look forward to KA 9, and if the functionality isn't in it, then also MQ2Ifs implementation of KA 9.

 

[Warl0ck45]

as I have only tinkerd with KA some, and thus do not know how it establishes a camp, I am not very sure how much help this can be. But the MQ2Moveutil's has a /makecamp feature with numerous options. One of the things I put in on my edit of RD is a guard feature that, among other things, included

	/if (${ChatText.Find[guard here]} && ${Guard}) {
		/makecamp on
		/delay 1s
		/makecamp radius 10
		/delay 1s
		/makecamp leash 50
		/if (${ChatChannel.Equal[BC]}) {
			/BC [+g+]Guarding here Mastah!
			} else {
			/${ChatChannel} Guarding here Mastah!
			}
		}

with of course

Sub Event_Experience
......
	/if (${MakeCamp.Status.Equal[ON]} && ${Me.XTarget}<1) /makecamp return
......
	/return

The first set of a plugin control camp radius only 10 units wide, so the tank returns to roughly the same spot, and the leash keeps him from going farther then 50 via /stick. At the end of the fight he should return to the 10 unit circle, the XP part is to just insure he does return to camp (like say he was summoned out of radius)

You can set up a hotkey or add a sub or type in the commands by hand to use the leash and camp radius of MQ2MoveUtils to keep your tank close to your group. One of the reasons I worked on this guard feature was exactly what you are describing... the tank working his way away from the group (even with just default /makecamp on)

 

[ctaylor22]

There are 2 problems, 1 is when the tank stalls, that happens when the mobs get stalled outside of his meleedistance, not camp radius, for the tank campradius is what is used for him to return to camp. MeleeDistance is what he looks at when engaging Mobs. The second problem is with pullers. When a puller hangs it is because the mob gets stalled outside of campradius, and 90% of the time it is the tanks fault. You need to make sure the tanks campradius is not bigger than the pullers, matter of fact it should always be smaller than the pullers.

Now you have to consider the Tank will take off after the mob once it is MeleeDistance, so remember the tank will most likely be outside of campradius when a mob dies. Like you mentenioned above the tank will creep farther and farther from camp sometimes. With regular pulling this is normally NOT the issue, but with chain pulling this is a major issue, we even included code to stop pulling if the tank get 75 units or farther from camp. The puller getting hung was an issue with chain pulling when we first released chain pulling, but we fixed the issue by doing a different check. Now all things considered, this wasn't a perfect fix, but it is damn close.

What should be done to the normal pull section is the same thing we did to the chainpull section to fix the puller from hanging so much. Here is the simplest explanation I can give.

Currently when the puller gets back to camp he/she waits for the mob(TargetID) to get in Camp Radius. If the mob get stopped out side of that radius(Damn Tank), the puller just waits. So to solve this issue, just add a check for the mob to be in range of the tank as well as the campradius and problem solved, well mostly.

Here is the code in KissAssist sub routine waitformob:

                | I am PULLER TANK
                /if (${Select[${Role},pullertank]}) {
                    /if (${Math.Distance[${CampYLoc},${CampXLoc}:${Spawn[${MyTargetID}].Y},${Spawn[${MyTargetID}].X}]}>=${CampRadius}  && ${Target.Distance}>20) /goto :WaitForMob
                }
                | If I am PULLER and NOT chain pulling
                /if (${Select[${Role},puller]} && !${ChainPull}) {
                    /if (${Math.Distance[${CampYLoc},${CampXLoc}:${Spawn[${MyTargetID}].Y},${Spawn[${MyTargetID}].X}]}>=${CampRadius}) /goto :WaitForMob
                    /if (${MercOn} && !${MercAssisting} && ${MyTargetID} && ${Mercenary.State.Equal[Active]}) /call MercsDoWhat
                }
                | If I am PULLER and chain pulling
                /if (${Select[${Role},puller]} && ${ChainPull}) {
                    | Leave if multi mobs or no mobs 
                    /if (${MobCount}>=2 || !${MyTargetID} || (${Me.XTarget[${XTSlot}].ID} && ${Me.XTarget[${XTSlot2}].ID})) { 
                        /call PullReset
                        /return
                    }
                    /if (${Math.Distance[${Target.Y},${Target.X}:${Spawn[=${MainAssist}].Y},${Spawn[=${MainAssist}].X}]}>20 && ${Target.ID}==${Spawn[${MyTargetID}].ID} && ${Me.TargetOfTarget.ID}==${Me.ID}) /goto :WaitForMob                 
                }

What we need to do is add the second part in with the first part, so we check both conditions. This is what needs to be changed:

          | I am PULLER TANK
                /if (${Select[${Role},pullertank]}) {
                    /if (${Math.Distance[${CampYLoc},${CampXLoc}:${Spawn[${MyTargetID}].Y},${Spawn[${MyTargetID}].X}]}>=${CampRadius}  && ${Target.Distance}>20) /goto :WaitForMob
                }
                | If I am PULLER and NOT chain pulling
                /if (${Select[${Role},puller]} && !${ChainPull}) {
                    /if (${Math.Distance[${CampYLoc},${CampXLoc}:${Spawn[${MyTargetID}].Y},${Spawn[${MyTargetID}].X}]}>=${CampRadius} && ${Math.Distance[${Target.Y},${Target.X}:${Spawn[=${MainAssist}].Y},${Spawn[=${MainAssist}].X}]}>20) /goto :WaitForMob
                    /if (${MercOn} && !${MercAssisting} && ${MyTargetID} && ${Mercenary.State.Equal[Active]}) /call MercsDoWhat
                }
                | If I am PULLER and chain pulling
                /if (${Select[${Role},puller]} && ${ChainPull}) {
                    | Leave if multi mobs or no mobs 
                    /if (${MobCount}>=2 || !${MyTargetID} || (${Me.XTarget[${XTSlot}].ID} && ${Me.XTarget[${XTSlot2}].ID})) { 
                        /call PullReset
                        /return
                    }
                    /if (${Math.Distance[${Target.Y},${Target.X}:${Spawn[=${MainAssist}].Y},${Spawn[=${MainAssist}].X}]}>20 && ${Target.ID}==${Spawn[${MyTargetID}].ID} && ${Me.TargetOfTarget.ID}==${Me.ID}) /goto :WaitForMob                 
                }

So someone want to make the change and give it a try?

 

[Incognito]

Nice CT, I will play with the code this weekend.

Warl0ck, exactly what I was playing with, a combination of KA settings and the MoveUtils settings. The leash specifically seemed to help the most. I had on a hotkey (hell even messed with putting it in a down) to check tank dist and send a move mdist cmd if over set amount as well. It seemed to work but like CT was saying, it's all a kludge until we can get KA to handle these kinda things.

 

[Warl0ck45]

I missed the puller tank portion, sorry. What I get for checking posts when I can't get back to sleep, heh

 

[Incognito]

Testing this now - will report tomorrow night.

- - - Updated - - -

Oh and the bard as mezzer makes a real difference. Can't wait till it is 85 and gets AEMez.

- - - Updated - - -

It's better with adds so far, but there is a problem with a mez'd mob waking up and no one contesting it. It isn't all the time so it must depend where in the mac-cycle KA is when it wakes. I was hoping the puller would address it. All someone has to do is target it, it's in the XTarList. It's very reminiscent of the add problem currently being tested. Everyone is assisting the puller since the tank is a merc (in this case) not on auto-assist, so the puller needs to target the woken mob. Auto-assist on merc would work but I feel that is cheating at this point.

- - - Updated - - -

If the monk is en route to a pull, and the path pops along the way and aggros on him, he is smart enough to stop and bring the add back to camp without pulling his original intent. However, his target is still the mob 400 feet out, so everyone is waiting to assist on THAT mob not the one in camp chewing all their asses. I have also noticed the monk often has a corpse as a target during these situations so again, no one will assist.

- - - Updated - - -

Man but it is a sight to behold when everything is working right...

- - - Updated - - -

Haha, turned around just in time to watch the monk die while a corpse was targeted. Looking thru the scroll the last mez'd mob was 4 pulls ago.

 

[ctaylor22]

Never Ever Ever use a pure puller as MA for the rest of the group. You will always have issues with the others assisting on the wrong mob. The puller will always try and assist off the ma after returning to camp.

Here is something you can try to fix the issue with unexpected agro when running out to pull your target.

Find this section of code in sub Pull:

Add the highlighted line:

       :PullAgain
        /doevents BackOff  
        /if (${DPSPaused}) /return  
        | vars used to determine if we are stuck
            /varset X1 ${Int[${Me.X}]}
            /varset Y1 ${Int[${Me.Y}]}            
            /if ((${AggroTargetID} && !${ChainPull}) || (${ChainPull} && ${Me.XTarget[${XTSlot2}].ID} || (${Me.XTarget[${XTSlot}].ID} && ${Me.XTarget[${XTSlot}].ID}!=${BeginMobID}))) {
            /if (${DebugPull}) /echo Pulling 1.1
                /varset Pulled 1
                /varset MyTargetID ${AggroTargetID}
                /varset MyTargetName ${Spawn[${AggroTargetID}].CleanName}
                /target id ${MyTargetID}
                /if (${Navigation.Active}) /nav stop
                /if (${MoveTo.Moving}) /moveto off
                /if (${DebugPull}) /echo DEBUGPULL Pull Aggro detected 
                /goto :DonePulling
            }

Not sure why your mezzer is not remezzing mobs when mez drops. I use an enchanter not a bard and I don't normally have any issues.

 

[Incognito]

We got ourselves a running commentary now lol.

Ok 1, the bard is re-mezzing when appropriate. It stops once the other mobs are dead (in most cases, just one other as I moved the camp to a safer loc for this test).

2. The bard itself sometimes wakes the mezzed mob, again when appropriate, but not always.

3. In this particular grp line-up, the MA designation not being the puller confuses me. I have the monk who is now about 2 to 3 lvls higher than the mobs. I have the bard who is now about the same lvl as the mobs. I have my SHM who is about 9 lvls higher than the mobs. The monk happens to have a healer merc as its merc AA expenditure lends itself to healer. The SHM has the tank merc as its merc AA's lends itself to the tank and is the only J5 in the grp. The bard has a merc caster, which really isn't germane (as the caster wouldn't be considered for MA in the first place). Out of the lot, the monk makes the most sense as MA (to me). Yes the tank should be, but in this case the tank is a merc with auto-assist off, which makes it a bad choice for MA. Why? Because my SHM is controlling it. If my SHM doesn't engage, its merc wont, and might as well not even have a MA. The only alternative to the monk would be the SHM which seems... odd, and open to ridicule haha. However, given your comment above, I guess I will have to try it. I just don't trust the tank merc with auto-assist off, and having it on as mentioned previously lends itself to early engagement and camp-creep. Now in this case, it wouldn't be so bad since the merc is significantly higher in lvl than the mobs so if it had to solo the mobs it could. But solo often it would and if there wasn't such a large lvl spread would lead to tpw under normal play conditions.

4. If choosing the MA of the grp, and who is assisting who, is this complicated, doesn't that raise a red flag?

5. Ok, will insert the proposed code above and report back. I will have to scan thru the logic and see where/when ${MyTargetID} is being populated to gauge impact of the mod since the var assigment(s) surrounding that line is making choices off of {AggroTargetID}.

Back to testing...

 

[ctaylor22]

In the case of MA anyone can be MA other than the Puller, The puller role will always drop target and then assist, or try too. You may need to play with this some, with your group setup. Use your group window and make sure you assign the correct roles to your merc or PC that you want to be the Tank and MA.

1 other thought. If you are Not using Chain Pulling you might get away with the puller being MA, it can get messy when there are multiple mobs in camp. If chain pulling don't use the puller as your MA.

 

[Incognito]

Yes chain-pulling is off. I was never a fan of chains even before automation, maybe I'm too old for the stress lol.

EQ wont let you assign grp role MA to a merc. That would prolly save me headaches. But, if grp role MA is considered by KA, why the KA fascination with who targets who at launch? I have seen behavioral differences when targeting other than MA at launch but not across the board. I suspect that in somethings KA is interested in who was targeted at launch and in others looks for MA. Perhaps some consolidation is in order.

- - - Updated - - -

So far so good, mezz'd mobs are being addressed when its time to deal with them. Targeting seems good. Adds are handled. This just might be it!

Still using MA on Puller. SHM (with tank merc) is assisting puller, bard is assisting the merc tank who is marked as MT.

- - - Updated - - -

Had an add uncontested. Perhaps I'm not waiting long enough, but I hate watching inefficiency. I will try to wait longer next time.

- - - Updated - - -

In looking through some of your other posts, there seems to be not only repeat code mod suggestons, but also some I haven't thought of needing. Perhaps you could post a thread of various common snippets we could consider implementing while waiting for KA 9? I'm guessing you have a cheat sheet that you can C & P when ppl ask for certain things.

Mods seem to be working. Only once did I encounter an uncontested mob but I don't have particulars of how we got there. Trying to watch it as much as I can so I can figure out the conditions that cause it...

- - - Updated - - -

It appears that the bard takes on the role of waking up a mezzed mob when its time to address it. That's working well.

- - - Updated - - -

Once, the bard just simply let the mob's mez expire, running hp/mana regen in the meantime. When it woke, it attacked the bard and everyone addressed it as they should. This really seems to be working well. Now just to duplicate that one incident...

- - - Updated - - -

It gets stuck in some loop. Mob is killing the healer merc. No one is even aware of the mob, nor the fact that the healer is dying. SHM doesn't even heal her. Everyone is completely unaware of the situation. Its a bitch to duplicate and isolate the conditions that are causing this. It's rare too boot, but will cause a twp if I don't intervene. Mob is certainly in the XTarWin...

 

[ctaylor22]

That will normally be a range issue. The Healing routine is called from every possible routine it might be needed from, the only thing that will stop the healers from responding is, they may be invised or the character is out of range of their heal spells.

 

[Incognito]

Distance... hell I've messed so much with those settings...

• What would be good/default settings for:
• Campradius - happy right now with 50
• CampRadiusExceed - don't even want to tell you what I have that on
• MeleeDistance - still have that 75

That time I had the healer getting whacked by an uncontested mob, she was a distance from camp. I have no idea how she got there, and I figure she was within the 200 range of my heal, but that had more to do with uncontested mob than heal range. But range may have contributed to the uncontested nature. If I slim down CampRadiusExceed then everyone would be on a tighter leash, perhaps avoiding that situation (well, except for mercs).

- - - Updated - - -

NM about CampRadiusExceed, that just seems to break 'leash' and returntocamp, applies to those roles that venture out beyond camp, and in many cases the code addds +200 to it anyway. Lessening that will not keep the grp tighter. That role must be Campradius, which the healer was clearly out of (perhaps 150 at the time). I do however want to have that a set to a reasonable value, which I don't know.

 

[ctaylor22]

For my group Warrior(Tank), Monk(Puller), Cleric, Enchanter, Mage, Shaman

Class, CampRadius, MeleeDistance

Warrior, 35, 70
Monk, 35, 80
Cleric, 50, 110
Enchanter, 30, 110
Mage, 30, 110
Shaman, 30, 110

Here is my layout of my characters:

MSC
 E
 
MW

And there is no space between the Mage, Shaman, Cleric, and Enchanter. The Monk and Warrior start on top of each other in the Warriors Position about 3 units in front of the Enchanter. This setup works great for me.

 

[Incognito]

With those short melee distances, I assume you have turned off any of the AA/Dics/skills that throw the mob back, say for the mnk and war. Dragon Punch comes to mind...

- - - Updated - - -

Err I meant short Campradiuses (radii?).

 

[ctaylor22]

Take into consideration I use Chain pulling, and yes I turn off all knock back abilities, But this setup works really well for me, and I have been tweaking this group for a long time.

 

[Incognito]

I'm running seperate copies of EQ, but am I supposed to run separate instances of MQ2 as well? I don't even know if MQ2 will acquiesce to multi's, it's been so long since I multi-boxed...

 

[ctaylor22]

All your characters should be running on the same PC and running MQ from the same location. You can run the same EQ instance as well, but you don't have to.

 

[Incognito]

Thx for all your help, and patience CT! I count you an asset to RG!