Idea - Idea for Kissassist: pullAt=xx - Pull next mob before combat is over (1 Viewer)

[DadBod]

Hi Maskoi & others

I am new to MQ2 & Kissassist, but I must say I am loving it, it has brought EQ back to me, and I am having so much fun. So thanks!

As I said, I am a noob, so maybe this idea is already possible, or it has been discussed before (could not find the threads in that case).

The idea is:

If a condition is set, for example

PullAt=20

AND there are no other mobs on the extended target list/no adds in camp

Then the Puller breaks out from the group and pulls next mob when current mob health reaches 20.

When I play with "human puller", this is what the puller normally does, and it reduces inactive time to almost zero, giving all those melee arms something to do :-).

BR
Iblis

 

[Maskoi]

I am looking at implementing chain pulling in the next version.

 

[DadBod]

A bit of Thread Ressurection:

Has there been a development with this feature request? :-).

BR
Ibliz

 

[Infinite Monkeys]

This would be really nice and something that could patched in from other mac if the authors don't mind. I'd take a stab at it but every time I open KA and see that giant smear of text I look at it for a minute then just close it lol

 

[wackawacka]

Maskoi does a really good job at making comments and marking what is going on in KA file. You shouldn't be scared!

 

[ctaylor22]

I started to do this once, but there is a lot to consider, I put it aside when I got to the point where my Puller had no buffs, because of never stopping long enough to get them, same for the other toon's in my group it was constant killing, so know one was buffing. There was also an issue with Groupwatch=1 issues and pulling more than 1 mob at a time. Would have to track Mana and Endurance using a different number than currently used. It is currently hardcoded at 20%.

There were some other issues to overcome, but it has been a while since I last looked at this. I may revisit this latter, but for now I have another issue I am trying to solve.

 

[BlankStare]

Make sure it pulls when the LAST mob is at 20%, and not just "one of the 5 mobs in camp is at 20%, go pull some more!!!1"

 

[ctaylor22]

Make sure it pulls when the LAST mob is at 20%, and not just "one of the 5 mobs in camp is at 20%, go pull some more!!!1"

I had already gotten that part figured out, that is how I found out you can NOT depend on xtarget or ${AggroTargetID} when checking for mobs in camp. If you have a mezer and the mob gets mind wiped then the mob does NOT show up on the xtarget list and is ignored, not only by the puller, but also the tank. This is a problem within vanilla Kissassist still today. I get reminded of this on a regular basis when my group stops killing and there is a mob in camp but the XTarget list is empty. I have to target the mob manually and press attack to start the ball rolling.

I started a new routine, just for the puller, to check for mobs in camp. Can't use the current code without some major mods. At the top of the current pull routine has a check for mobs in camp and aborts the pull and returns to camp. Incorporating chain pulling can be done, but it sounds a lot easier than it is going to be.

 

[DadBod]

I was wondering if the following rules/parameters would be likely to delimit a behaviour that works, based on above statements:

- Chainpull a limited number of times before taking a short buff-break (eg ChainpullSeriesSize=5, ChainPullBreak=20, means that chain-puller will chainpull five times, then take a 20 seconds break from chainpulling, allowing for Buffing, things to calm down, etc)
- ChainPullWithMobInCamp=0/1, means that puller will not chainpull if an NPC that is not on the hate list is within camp radius

- - - Updated - - -

A bit of background behind my request: where my toons stand now, there is about a mob kill a minute. The combat part of that minute is around 15 seconds. So pulltime is around 45 seconds, or 75% of the time, while kill time is 25%. It means that theoretical ceiling is 4x the current XP pr time unit, but a mere 1,5x improvement would still be fantastic, 50% more XP :-).

 

[ctaylor22]

Well that sounds good, but it won't work as intended. I toyed with the whole how to keep puller and group buffed. What has to happen is the puller has to check for buffs before pulling next mob. If a buff is close to dropping, lets say 2 minutes. Then hold pulls, finish clearing camp of adds, now find the buffs about to drop and drop the buff(s). Now wait in camp till you get the buff(s). That means that there has to be a list of buffs to check against to know that you are properly buffed.

I originally set it up to have a hard coded list to check against, but that defeats the whole K.I.S.S. montra. Then I had an idea, why not use the buffs listed in the Kissassist_buffs.ini file, this works as long as know one from outside your group cast a buff on you. Why is it that every druid thinks you need a damage shield? More than once I would check on my group and the puller would be standing around waiting for a Buff. 90% of the time it was a damage shield from a character class not in my group. Now if there was a way to look up the name of the caster who cast the buff and check it against your group, then I can see a way around this. The TLO Buff has no reference to castersName or anything like that. I know I have seen the casters name somewhere in EQ I just can't remember where I have seen it.

There is a lot to consider when implementing chain pulling, I have been working with it trying to keep the K.I.S.S. Standard, because what ever I do. I am in hopes Maskoi will adopt it as part of the standard Kissassist.mac. Believe me it has to be Super Simple or he won't even consider it. I know I will finish this one day and share it with the rest of you, but it would be great if it was just part of KISS.

 

[Maskoi]

Kiss keeps track of the buffs you have on plus your blocked in a ini, KissAssist_Buffs.ini, file so other toons can see if you need that buff or not.

the way to do it would be to write the toons spells from the buffs section in that list so the puller could check against it to see if he has it. if not wait unitl group buffs hims.

The write buffs sections in kiss though is some the most complicated code the macro why i never screw with it lol.

 

[ctaylor22]

Yea, I know how complicated it is, I have reviewed it many times, but the problem is when Someone casts a buff on you from outside your group. The buff gets written to the Kissassist_Buffs.ini. Now If I check My current Buffs and see that a buff is about to expire then check the Kissassist_Buffs.ini for the buff. The buff should be listed, so the Puller will just wait for the buff, but know one in the group will refresh it, because know one in the group is of the right class and/or Have the spell at all. My Favorite example is the Druid Damage shield, I don't run a druid or ranger, so when a Druid runs by and casts their Damage shield on the group, it just fooks things up. I don't want to block the buff, I may one day run a druid in my group and then I may want the buff.

I had thought about setting an alias that could be used, to write your current buff set to the Kissassist_buffs.ini file and then use that as a reference to refer too for re-buffs. I am just not sure what the easiest way to do this and keep it simple. If I had a way to reference who the caster of the buff was, it would be much easier. Oh and the other one is when someone of the same class as a caster in your group. Lets say a cleric, comes along and cast a spell that over wrights your clerics current buff. Not only does the cleric, in your group, keep trying to re-cast their spell, but the puller will just have to wait till hell freezes over before they will get that same buff. well at least from your cleric you have grouped.

 

[DadBod]

Thanks guys for caring, sounds complicated :-)

 

[eqgeek]

Can it be hard coded to just stop pulling every 30mins for buffs? Basically pause for 30s or so and let everyone buff every 30m.

 

[Maskoi]

Can it be hard coded to just stop pulling every 30mins for buffs? Basically pause for 30s or so and let everyone buff every 30m.

This is what I was planning and it is going to be a pause in pulling you can set something like

PausePull=30|2

Will pause every 30 min for 2 minutes., 15|3 every 15 min for 3 min, etc. and it will force a buff read for missing spells.

 

[PussyFoot]

Maybe also allow something like :

PausePull=30|RND|5

Where it will pause every 30 for random time, up to 5 mins.

 

[Maskoi]

KISS=Keep It Simple Stupid that doesn't sound simple

 

[GPS_Soldier]

Something else to think about when checking if you have other targets near you so that your puller keeps pulling or stops.

You can't always use Xtarget for your check if you have been mezzing. Some mez spells/songs wipe the memory of critters at times, so you would have to include some logic to check spawn of NPC within XXX distance of you as well.

 

[saar]

I have no issues when my chanter memblurs on a mez, my warrior hasnt missed a memblurred one yet.

 

[ctaylor22]

This is what I was planning and it is going to be a pause in pulling you can set something like

PausePull=30|2

Will pause every 30 min for 2 minutes., 15|3 every 15 min for 3 min, etc. and it will force a buff read for missing spells.

I had thought about doing something similar to that, but then why chain pull in the first place if your going to take breaks, you just cut your efficiencies for killing mobs. Now there are times where the group will have to stop to let the other members med and during those down times the buffing will be done as needed. The problem is when you have a group that never needs to med.

As far as using the whole 30|2 idea, why not just use PausePull=2 and have puller check his/her buffs and if any of the buffs are within the 2 minute range just have the puller stop pulling, drop the buff wait for the buff and then continue pulling, during this pause the other members will cast self buffs and whatnot. I just hate the idea of stopping every so often to wait for buffs that you may not even need. That's just sounds like a waist of playing time to me, but I am just stupid that way.

The other problem I ran into with chain pulling, is pulling mobs from long distances. There is a certain distance you can be from a mob to get the exp for killing that mob. If the puller is out of range when the mob dies in camp, the puller gets no exp. I found this to be annoying since my puller needed the exp more than the others in the group. I found pulling when the mobs HP was at around 90% and not 20% worked better.

Well that's just my 2 redcents.

 

[DadBod]

30/2 + chainpulling to me sounds like a huge improvement to no chainpulling.

 

[ctaylor22]

Something else I just remembered about chain pulling. There is never enough time for the looter to loot. You have to set up your looter to loot on a timer or while there are mobs in camp. I never tried to work on this issue, cause my mage would gradually run low on mana and the puller would pause while the mage was meding. This could be an issue for those Uber groups that never need to stop and med.

 

[Maskoi]

ninjadvloot has a setting to never loot during combat. set that to =0

 

[ctaylor22]

Just an Update. I have been working on this and have got a version of it working from the KA 7.4.1. Now when testing this I found an issue with using the base Kissassist macro and just adding in the code for chain pulling. After letting this run for a while I noticed my system not responding as I expected and stopped the Macro and the system kind of froze and Lagged for a bit. I let it run again for a while and the same thing happened, so I looked a little deeper and found an issue with the Routine CheckForAdds and Combat. The problem is that Combat calls CheckForAdds and in return CheckForAdds calls Combat. So after running KA nonstop for a while creates a problem, because there are always adds in camp when chain pulling.

Needless to say for chain pulling to be added to KA something will have to change. I started over and am changing KA so it still functions the same, but returns back from combat before calling checkforadds and vice versa. I have a bit of testing with this before I add back in the chain pulling code. Don't give up hope I am going to get this working one day.