• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver
KissAssist

KissAssist Release KissAssist 12.002.039

No permission to download
Join us with Level 2 access RedCents
Overview Commands Instructions Updates (69) Reviews (5) History Discussion
I use the emu version of VV. It comes with 11.001 kiss. Can I update to these newer versions of KIss without issue?
 
cotto8177 said:
I'm having an issue with |class|dru working to cast symbol only on the druid in group. It keeps casting just on the cleric :confused:
Click to expand...
can you share your ini or the actual line for the buff in your ini? (full ini prefarably)
 
cotto8177 said:
Buffs22=UNITY OF EMRA|DUAL|SYMBOL OF EMRA|CLASS|DRU

Used to work fine before but something has changed ...
Click to expand...
and you have no other buff entries that does unity of emra? that's why I asked to see the full ini - sometimes (I'm guily) we end up doing double lines hehehe
 
Sic said:
and you have no other buff entries that does unity of emra? that's why I asked to see the full ini - sometimes (I'm guily) we end up doing double lines hehehe
Click to expand...

Lol yeah that's the first thing I checked for was a duplicate and no duplicate - even changed it to one of the other classes in the group and still kept trying to cast on my cleric.
 
When pulling I noticed a problem where sometimes my guy would run up to a mob, then ran back to camp without having aggroed the mob - particularly if the mob is close when nav stops (eg you're almost standing on the mob). I don't have an extraordinarily large ping (~100ms), and the client has a whole core to itself so my frame rate is pretty good. I ended up editing the Pull with cast section to this:
Code: 
/delay 10
/goto :PullAgain
/delay 10

That seemed to fix it. What I would like to suggest is an INI setting, perhaps call it 'PullWaitTime', that has it delay by that amount in the pull section - if anybody else runs into the problem of the puller running up to a mob then running back without aggro, they could then edit that until the problem goes away for them (eg start at 1, then 2, then 3, etc.)
 
Multichar said:
When pulling I noticed a problem where sometimes my guy would run up to a mob, then ran back to camp without having aggroed the mob - particularly if the mob is close when nav stops (eg you're almost standing on the mob). I don't have an extraordinarily large ping (~100ms), and the client has a whole core to itself so my frame rate is pretty good. I ended up editing the Pull with cast section to this:
Code: 
/delay 10
/goto :PullAgain
/delay 10

That seemed to fix it. What I would like to suggest is an INI setting, perhaps call it 'PullWaitTime', that has it delay by that amount in the pull section - if anybody else runs into the problem of the puller running up to a mob then running back without aggro, they could then edit that until the problem goes away for them (eg start at 1, then 2, then 3, etc.)
Click to expand...

I have had the same issue, he will run all the way back to camp with nothing aggroed. I wonder if some kind of XTarget check would help, basically if he has no XTarget then it knows he doesnt have aggro.
 
Edit: Ok, I gave it a try - I removed the first /delay, so now I have this (put it in the section of the pull routine that your character uses, eg melee section or casting section):
Code: 
/varset PullDist ${Int[${Macro.Return}]}
/goto :PullAgain
/delay 50 ${Me.XTarget[1].ID}>0

Then I ended and reran KA. It worked, he ran up to a mob that normally he would run up to and run back before aggroing, only this time he delayed just long enough to aggro the mob. Once he had aggro he ran back to the group without continuing the delay.
 
Last edited:
Multichar said:
Edit: Ok, I gave it a try - I removed the first /delay, so now I have this (put it in the section of the pull routine that your character uses, eg melee section or casting section):
Code: 
/varset PullDist ${Int[${Macro.Return}]}
/goto :PullAgain
/delay 50 ${Me.XTarget[1].ID}>0

Then I ended and reran KA. It worked, he ran up to a mob that normally he would run up to and run back before aggroing, only this time he delayed just long enough to aggro the mob. Once he had aggro he ran back to the group without continuing the delay.
Click to expand...

I see the same issues when pulling certain areas, as well. Anytime the puller runs up suddenly on a non-kos mob that was previously out of line of sight (as an example), it will usually turn around and run back without agroing it.

Thanks for working out a solution. @Redbot @ctaylor22 is this something we can add to the general kiss file?
 
This is what *should* do this, it's declared near the top of the file:-

Code: 
/noparse /varset PullAggroTargetID ${If[${ChainPull}==0,${Me.XTarget[${XTSlot}].ID},${If[${Me.XTarget[${XTSlot}].ID} && (${Me.XTarget[${XTSlot}].ID}==${MyTargetID} || ${Me.XTarget[${XTSlot}].ID}!=${BeginMobID} || ${Me.XTarget[${XTSlot2}].ID}),${MyTargetID},0]}]}

In the various pulling subroutines, they check that variable e.g.

Code: 
/delay 10 ${PullAggroTargetID}

Which will evaluate the expression, and should be non-null if you have a mob in xtarget.

So theoretically, replacing those instances with

Code: 
/delay 50 ${PullAggroTargetID}

to increase the delay will have the same effect but retain the ChainPull logic.
 
vsab said:
This is what *should* do this, it's declared near the top of the file:-

Code: 
/noparse /varset PullAggroTargetID ${If[${ChainPull}==0,${Me.XTarget[${XTSlot}].ID},${If[${Me.XTarget[${XTSlot}].ID} && (${Me.XTarget[${XTSlot}].ID}==${MyTargetID} || ${Me.XTarget[${XTSlot}].ID}!=${BeginMobID} || ${Me.XTarget[${XTSlot2}].ID}),${MyTargetID},0]}]}

In the various pulling subroutines, they check that variable e.g.

Code: 
/delay 10 ${PullAggroTargetID}

Which will evaluate the expression, and should be non-null if you have a mob in xtarget.

So theoretically, replacing those instances with

Code: 
/delay 50 ${PullAggroTargetID}

to increase the delay will have the same effect but retain the ChainPull logic.
Click to expand...

Will adding a delay there impact the overall pulling responsiveness of kissassist? I think ctaylor and crew don't really like to use hardcoded delays if they can help it.
 
Sum1 said:
Will adding a delay there impact the overall pulling responsiveness of kissassist? I think ctaylor and crew don't really like to use hardcoded delays if they can help it.
Click to expand...

There already is one, this makes it larger but it's only called when you cast your spell/do melee or whatever at the point of pulling. It pales in significance compared to the "Looking for Close Range Spawns" CPU craziness you get if your maxradius is more than 500 or so (which I am guessing is using MQ2Nav to calculate distances?)
 
vsab said:
There already is one, this makes it larger but it's only called when you cast your spell/do melee or whatever at the point of pulling. It pales in significance compared to the "Looking for Close Range Spawns" CPU craziness you get if your maxradius is more than 500 or so (which I am guessing is using MQ2Nav to calculate distances?)
Click to expand...

Hrm, my issue when pulling was the guy would run to a mob (that is non-kos), stand on it for a split second, and then run back to group without casting or otherwise agroing it. Since it can still see it in kiss, it will Nav back to that same mob again to try again.... over and over and over .... sometimes it'll eventually get it, but usually not until looking SUPER botty for a while.

If I understand your point properly, increasing this delay won't help with that. Or will it?
 
Unfortunately I started things up this morning, and it was back to doing the old behavior again so apparently something else is coming into play and the delay that seemed to be working yesterday - wasn't today. I tracked down where I think the problem might be - it runs to mob, it stops, it doesn't cast, it runs back. Then it runs back to same mob again, and again fails to aggro mob. Eventually it does it sometimes.

Here's where I think the problem is:
Code: 
| Check for being to far from camp lose MyTargetID or path
            /if (${Math.Distance[${CampYLoc},${CampXLoc}]}>=${Math.Calc[${MaxRadius}*.95]} || ${PullNavTimer}==0 || !${Spawn[${BeginMobNavID}].ID} || !${Navigation.PathLength[id ${BeginMobNavID}]}) {
                /echo We have exceeded max pulling radius or timer or lost path to mob. Returning to camp
                /if (${Navigation.Active}) /nav stop

I added ${Navigation.PathLength[id ${BeginMobNavID}]} to the end of the echo, and it was 0.46. So, when it stopped running to mob it was 0.46 away from mob. I think what is happening is, if you test !1 or !2 or !3000 it resolves to false, but if you take !0.46 it resolves as true, the same as 0. If you keep running back to and forth to the same mob eventually I think it stops further away from the mob and then your chosen aggro spell is cast. If it stops too close to the mob then it aborts and runs back - if the mob is KOS just standing near mob might make it aggro, but for non KOS mobs you just run back and forth never casting your aggro ability.

Edit:

If Navigation loses its path it returns -1 for PathLength right? What if I change this line:
Code: 
/if (${Math.Distance[${CampYLoc},${CampXLoc}]}>=${Math.Calc[${MaxRadius}*.95]} || ${PullNavTimer}==0 || !${Spawn[${BeginMobNavID}].ID} || !${Navigation.PathLength[id ${BeginMobNavID}]}) {

to

Code: 
/if (${Math.Distance[${CampYLoc},${CampXLoc}]}>=${Math.Calc[${MaxRadius}*.95]} || ${PullNavTimer}==0 || !${Spawn[${BeginMobNavID}].ID} || ${Navigation.PathLength[id ${BeginMobNavID}]}<=0) {
 
Last edited:
Multichar said:
Code: 
| Check for being to far from camp lose MyTargetID or path
            /if (${Math.Distance[${CampYLoc},${CampXLoc}]}>=${Math.Calc[${MaxRadius}*.95]} || ${PullNavTimer}==0 || !${Spawn[${BeginMobNavID}].ID} || !${Navigation.PathLength[id ${BeginMobNavID}]}) {
                /echo We have exceeded max pulling radius or timer or lost path to mob. Returning to camp
                /if (${Navigation.Active}) /nav stop
Click to expand...

There's a DebugPull variable near the top of the file, turning that to 1 will print out this info (and more), which might help.
 
vsab said:
This is what *should* do this, it's declared near the top of the file:-

Code: 
/noparse /varset PullAggroTargetID ${If[${ChainPull}==0,${Me.XTarget[${XTSlot}].ID},${If[${Me.XTarget[${XTSlot}].ID} && (${Me.XTarget[${XTSlot}].ID}==${MyTargetID} || ${Me.XTarget[${XTSlot}].ID}!=${BeginMobID} || ${Me.XTarget[${XTSlot2}].ID}),${MyTargetID},0]}]}

In the various pulling subroutines, they check that variable e.g.

Code: 
/delay 10 ${PullAggroTargetID}

Which will evaluate the expression, and should be non-null if you have a mob in xtarget.

So theoretically, replacing those instances with

Code: 
/delay 50 ${PullAggroTargetID}

to increase the delay will have the same effect but retain the ChainPull logic.
Click to expand...


I edited the /delay 10 to /delay 50 but that didnt help. What I am observing is that on some pulls the puller does not actually target the mob. He Navs to the exact spot the mob is at, but he doesn't actually have him targeted so unless the mob is KoS, no pull action takes place. I watched him run back and forth to the same mob 4 or 5 times until a closer mob spawned that he then targeted. Any ideas what could cause this intermittently like that?
 
Jetanroth said:
I edited the /delay 10 to /delay 50 but that didnt help. What I am observing is that on some pulls the puller does not actually target the mob. He Navs to the exact spot the mob is at, but he doesn't actually have him targeted so unless the mob is KoS, no pull action takes place. I watched him run back and forth to the same mob 4 or 5 times until a closer mob spawned that he then targeted. Any ideas what could cause this intermittently like that?
Click to expand...

Try the change I mentioned on #332 if you're seeing the message 'We have exceeded max pulling radius or timer or lost path to mob. Returning to camp' when he is returning to camp.
 
Multichar said:
Try the change I mentioned on #332 if you're seeing the message 'We have exceeded max pulling radius or timer or lost path to mob. Returning to camp' when he is returning to camp.
Click to expand...

Still the same thing, about 50% of the time he doesnt actually TARGET anything. He Navs directly to the mobs location but he never had any target so there is nothing for him to aggro. He just runs up to the mob, pauses for a sec, then runs back to camp never having had a target and never getting aggro (mobs non KoS). With KoS mobs this wouldn't be a problem, running up to their feet like that would be more than enough to aggro.
 
What is happening, in most cases, is you get to close to pull the mob with you item(Bow, Throwing Knife, etc...) Kiss should be switching over to melee and running up to the mob and slapping it, then hauling ass back to camp. Not sure why the puller is not switching over to melee. It could be the event message has changed and we need to make a change. Next time this happens make a note of the message you are getting, it use to be, Your target is too close to use a ranged weapon! or that is what we are checking for. If there is a different message, we just need to add it.
 
There is something called "xtslot" in the general section of the ini that I don't see mentioned in the instructions. What is that used for?
 
i believe its to set the xtslot that kiss uses to handle mobs, so if you have a raid tank on xtslot 1, your mob on xtslot2 youd put xtslot=2 there, but i am not sure though, maybe @Maskoi and or @ctaylor22 could elaborate.
 
kaen01 said:
i believe its to set the xtslot that kiss uses to handle mobs, so if you have a raid tank on xtslot 1, your mob on xtslot2 youd put xtslot=2 there, but i am not sure though, maybe @Maskoi and or @ctaylor22 could elaborate.
Click to expand...

Ah yes, that would make sense. Thanks.
 
That is a place holder, for what XTarget entry was the first auto hater in the XTarget list when Kiss was started. When kiss ends kiss attempts to make sure that the XTarget entry, equal to xtslot, is set back to auto hater and then sets xtslot to zero.

If your system crashes or kiss ends abnormally then xtslot will not be zero, so when kiss is started back up it will attempt to reset XTarget[xtslot] back to auto hater.
 
ahh okay, to fix that bug some people experienced some time ago?, where their xtarget slot would randomly clear itself and stop being usefull?
 
ctaylor22 said:
That is a place holder, for what XTarget entry was the first auto hater in the XTarget list when Kiss was started. When kiss ends kiss attempts to make sure that the XTarget entry, equal to xtslot, is set back to auto hater and then sets xtslot to zero.

If your system crashes or kiss ends abnormally then xtslot will not be zero, so when kiss is started back up it will attempt to reset XTarget[xtslot] back to auto hater.
Click to expand...

Thanks for the info, I'll just leave it alone then.
 
Let's say I set afktools in the ini to pause macro when someone is in range. I also have the ini of mq2posse to /quit when someone is in range. What would happen? Will one of them override the other or will it pause first (from kiss) then issue the posse command to quit?
 
Tiger said:
Let's say I set afktools in the ini to pause macro when someone is in range. I also have the ini of mq2posse to /quit when someone is in range. What would happen? Will one of them override the other or will it pause first (from kiss) then issue the posse command to quit?
Click to expand...

Which one would you actually want to fire?
 
Sum1 said:
Which one would you actually want to fire?
Click to expand...

I'm not entirely sure yet, I'm just trying to get my ini files in order and wondered which would have priority. Ideally I'd like to pause the macro and give an email notification. I can do this in the ini file of mq2posse, I can pause the macro in the ini file of kiss but I don't think I can set it to give an email there.

I suppose the question I should be asking is, if I have kiss running with 0=/mqp 1=/gmail "some text etc" in the ini file of mq2posse, will kiss pause the macro and then I get the email from mq2posse?
 
Tiger said:
I'm not entirely sure yet, I'm just trying to get my ini files in order and wondered which would have priority. Ideally I'd like to pause the macro and give an email notification. I can do this in the ini file of mq2posse, I can pause the macro in the ini file of kiss but I don't think I can set it to give an email there.

I suppose the question I should be asking is, if I have kiss running with 0=/mqp 1=/gmail "some text etc" in the ini file of mq2posse, will kiss pause the macro and then I get the email from mq2posse?
Click to expand...

Not sure, but I know MQ2Posse can be setup to do a bunch of things... so it theoretically should be able to both email you and pause (or quit) the macro, if that's what you want.
 
From looking at the code, KA basically goes into a loop until the strangers go away. If you're in combat it will finish it (either half way through or adds come), but it won't go out of that loop e.g. no buffs, pulls etc., until there are no strangers in radius.

It also doesn't look like KA overrides your MQ2Posse commands. So it's a matter of which gets there first - and I suspect that will be the plugin. In that case, the plugin will pause your macro - which would stop heals, dps etc and would theoretically make you sit there getting beat on if there are adds in camp. If you're using mq2melee I suspect that would continue to beat on anything you've already engaged, though.

So I would say- don't use /mqp in MQ2Posse, but the mail would fire. What I'm likely to do is get my wizzie to /end then evac, or maybe run GTFO.mac, and let KA handle the pausing on my other toons.
 
You must log in or register to reply here.
KissAssist Release KissAssist
Next unread thread 🦁

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top
Cart

Cart

Total -