KissAssist Release KissAssist (2 Viewers) 12.002.039

[Synk]

Not sure what exactly is causing it but characters which are out of group from the MA in the more recent versions seem to try and add NPCs to xtarget presumably to help assisting which is fine, however over time this results in PCs occasionally being added to xtarget (related to assisting and maybe my MA having a PC on target at the moment it does?) until it floods my xtarget and creates assisting problems because the xtarget is full of PCs until I go through and clear it all manually.

I also tend to run my characters in a raid setup which results in autohater working for out of group characters. So on a similar note setting the assist targets to xtarget seems a bit redundant for out of group characters in this situation not sure if theres a way to check if you are in a raid or not for this option.

This change is wrecking havoc on my guild on LJ and RF, anytime we raid we all have to constantly reload our macros, pause, and just flat out end it to get things moving. It seems like it was retroactively added to Kiss11.09 as well because 09 had been running excellently but when we tried to rollback to 9 it now has the same problem as 10. Is there anyway to revert this change because we all use xtarget healing extensively and that is very hard to use now since our xtargets keep filling up.

1)All mezzers eventually just stop mezzing, macro reload fixes it but within 10minutes to 60 minutes, they stop (usually chanters first)
2) Debuffers (with debuffall) are significantly slower if their top xtargets are in another location (IE raid force is split up)
3) Xtargets slowly fill up over time with PC's and corpses, we have to end our macros and clean out the xtargets to fix this
4) Mezzers regularly mez the wrong mobs (as in they will mez the mob the MA is killing until it hits the mez stop threshold)
5) Assisters will attack the wrong mobs occasionally (usually if the MA has died and gets rez'd they just go rogue and start killing stuff)
6) Debuffers who also have healson set to 1 are not healing very much anymore, very unreliable

 

[ctaylor22]

I am struggling with MezImmune too. As far as I can tell, despite using KA 10 and 11 for the past four months, and running a boxed enchanter for almost that entire time, not a single mez immune mob's name has been auto-added to the kissassist_info.ini file. Do I have to manually add those names? I know I can, but do I have to? When looking at the KA11 macro under mezimmune it has a call stating thus:

/call BroadCast ${IRCOn} ${EQBCOn} g "MEZ Immune -> ${Spawn[${MezID}].CleanName} <- ID:${MezID} Adding to MezImmune list."

and on the line before it there's an ini call:

/if (!${MezImmune.Find[${Spawn[${MezID}].CleanName}]}) /ini "${InfoFileName}" "${Zone}${If[${Me.InInstance},_I,]}" "MezImmune" "${ImmuneAdd}"

So, I'm assuming it is supposed to add to the ini file, but for some reason it has not done so for me to date.

There are 2 checks for Mez Imune mobs, the first you have to manually enter into the ini file. The mobs you enter into the ini file should be mob names that are always mez immune. Now for mobs that have a chance of being mez immune, KISS keeps a list of those mobs that are Immune to mez, and checks that list when trying to mez, so NOT to keep trying to mez a mez immune mob.

 

[ctaylor22]

This change is wrecking havoc on my guild on LJ and RF, anytime we raid we all have to constantly reload our macros, pause, and just flat out end it to get things moving. It seems like it was retroactively added to Kiss11.09 as well because 09 had been running excellently but when we tried to rollback to 9 it now has the same problem as 10. Is there anyway to revert this change because we all use xtarget healing extensively and that is very hard to use now since our xtargets keep filling up.

1)All mezzers eventually just stop mezzing, macro reload fixes it but within 10minutes to 60 minutes, they stop (usually chanters first)
2) Debuffers (with debuffall) are significantly slower if their top xtargets are in another location (IE raid force is split up)
3) Xtargets slowly fill up over time with PC's and corpses, we have to end our macros and clean out the xtargets to fix this
4) Mezzers regularly mez the wrong mobs (as in they will mez the mob the MA is killing until it hits the mez stop threshold)
5) Assisters will attack the wrong mobs occasionally (usually if the MA has died and gets rez'd they just go rogue and start killing stuff)
6) Debuffers who also have healson set to 1 are not healing very much anymore, very unreliable

Did you see this post? Ignores changing XTarget when in raid.

 

[toadwart]

There are 2 checks for Mez Imune mobs, the first you have to manually enter into the ini file. The mobs you enter into the ini file should be mob names that are always mez immune. Now for mobs that have a chance of being mez immune, KISS keeps a list of those mobs that are Immune to mez, and checks that list when trying to mez, so NOT to keep trying to mez a mez immune mob.

I'm not sure I follow you Ctaylor. I understand what the mezimmune function is supposed to do (I think), but I'm not sure how to get it working right. You say I need to manually enter into the ini file, are you saying that if I encounter a perma-immune mob I should manually enter it into the kissassist_info.ini file for future reference, because it does not manually add it for me? Then in the future it won't try to mez the mob?

The second instance is that Kiss keeps a temporary list of mobs that are mez immune so that it does not try to mez them again as long as Kiss is loaded in memory, but it does not record it for future purposes? Or are you saying that some mobs are only immune to mez intermittently, and Kiss keeps a temporary file for them?

/tldr answer seems to be: Kiss doesn't write mez immune mob names to the info.ini file, you have to add them manually so that Kiss does not try to mez them in the future?

 

[ctaylor22]

/Burn checks for the existence of, and length of the BurnText flag or the burn command cancels out, but it isn't used anywhere else that I can find. Wouldn't it make sense to put it into the eqbc chat for the command rather than defaulting to the "Autobots transform" command? or remove it entirely unless it's being used in place of a BurnOn=1 command as the other sections use, in which case why not make it consistent?

The Burn Routine is no longer an Event. It has been changed to a Bind, so the BurnText check can be removed.

        /if (${IAmDead} || ${Me.Hovering} || ${CampZone}!=${Zone.ID} || ${BurnText.Equal[null]} || !${BurnText.Length}) {

        /if (${IAmDead} || ${Me.Hovering} || ${CampZone}!=${Zone.ID}) {

 

[ctaylor22]

I'm not sure I follow you Ctaylor. I understand what the mezimmune function is supposed to do (I think), but I'm not sure how to get it working right. You say I need to manually enter into the ini file, are you saying that if I encounter a perma-immune mob I should manually enter it into the kissassist_info.ini file for future reference, because it does not manually add it for me? Then in the future it won't try to mez the mob?

Yes. You should manually add the mob.

The second instance is that Kiss keeps a temporary list of mobs that are mez immune so that it does not try to mez them again as long as Kiss is loaded in memory, but it does not record it for future purposes? Or are you saying that some mobs are only immune to mez intermittently, and Kiss keeps a temporary file for them??

Yes and Yes. Kiss keeps a list of the Mobs ID's that are immune to mez. They are added to the list when the mezzer tries to mez the mob, but gets the immune to mez message, and the ID's are removed from the list ,when the Mob is killed or no longer found in zone.

/tldr answer seems to be: Kiss doesn't write mez immune mob names to the info.ini file, you have to add them manually so that Kiss does not try to mez them in the future?

You are correct, but

I can't remember what expansion it was, but in some zones, they added mobs that can be immune to mez, but only some of the times. Zones like Tempest Temple and Brothers Island are good examples, where it's a 50/50 chance if a mob will be Mez Immune or not.

KISS no longer writes mez immune mobs to the ini file. You can however use /addimmune ${Target.CleanName} to add your current target to the mez immune list in the info.ini file. You can also manually change the information in the info.ini file.

 

[Synk]

@ctaylor22 Thanks, I did see that post and I have made those changes. It has fixed issue #3 which is great, but the others remain, on TLP I routinely might have mobs not on my xtarget since we only have 5 slots, so if target acquisition is solely based on xtarget we're going to struggle sadly.

Also the other issues are still true like chanters mezzing the main dps target and such.

 

[okert2675]

Does KA11 conditions act similar to ohshits? or was the coding cleaned up to just prioritize healing routines? noticed a significant improvement in healing compared to 10.2.6 and continuing to fine tune, but still noticing some some heal choices I would not have expected based on the situation and the conditions.

 

[ctaylor22]

Healing has always been prioritized over other routines. There were a few changes made to the healing routines. Not sure if you are referring to HolyShits(MQ2Mele) or EQMules ohshits routine? Depending on your conditions, there are still a lot of checks that are done before and after a condition is checked, those checks could be changing the flow to be different than what you are expecting.

 

[sifun]

**** wiz fami leave fix ***

        | Ditch wizards familiar
        /if (${Bool[${Spawn[${Me.Name}`s familiar]}]} && ${Me.Class.ShortName.Equal[Wiz]}) /familiar leave

buff bug idk how to fix

Buffs6=Mana Flare|wiz

buff all group member

 

[eqtrader74]

Buff by class:

Buffs6=Mana Flare|class|wiz

 

[ctaylor22]

| Ditch wizards familiar /if (${Bool[${Spawn[${Me.Name}`s familiar]}]} && ${Me.Class.ShortName.Equal[Wiz]}) /familiar leave

If your Familiar is tied to buff in your buffs window you can use the remove Tag to drop your familiar. For a Familiar created using Greater Familiar would look like this:

Buffs1=Summon Greater Familiar|remove

 

[Beastmage]

Hate to sound like the noob i am.
I take it kiss11 doesnt autoupdate to that im still running KissAssistVer=10.2.6

So do i delete all of kiss folder and download the kiss 11 and start over or hows the best way to go about it. Is kiss 11 still in beta and will autoupdate when its out and i should wait tell then?

 

[LorDeth]

Hate to sound like the noob i am.
I take it kiss11 doesnt autoupdate to that im still running KissAssistVer=10.2.6

So do i delete all of kiss folder and download the kiss 11 and start over or hows the best way to go about it. Is kiss 11 still in beta and will autoupdate when its out and i should wait tell then?

You will have to download the kiss11.mac file as well as the ka10211.mac file if you have older kissassist (10) ini's and conditions..

dont delete the folder though, that wont help you at all..

so, download the files from the top right Download link in this thread, then copy those into your Release/Macros folder

then follow the instructions of the ka10211.mac file to convert your kiss 10 ini's to work with 11.. (https://www.redguides.com/community/threads/kissassist-10-to-11-conversion-macro.67216/)

then once those are done, do /mac kiss11 assist/tank/puller ETC based on what your role is.. same basic activity as before with kiss 10.. target the MA, run the mac with your role listed..

 

[Saetun]

Using this with my beastlord. He is chasing my tank as I run through the zone. He runs 30 feet, stops. Runs another 30 feet stops, etc... My tank never stops. The other toons in my group not using 11 never miss a step.

[MQ2Nav] Reached Destination *,*,* (about 30 feet)
[MQ2Nav] Stopping Navigation
[MQ2Nav] Navigating to Spawn: Tank (****)
[MQ2Nav] Reached Destination *,*,* (about 30 feet)
[MQ2Nav] Stopping Navigation
[MQ2Nav] Navigating to Spawn: Tank (****)
[MQ2Nav] Reached Destination *,*,* (about 30 feet)
[MQ2Nav] Stopping Navigation
[MQ2Nav] Navigating to Spawn: Tank (****)
[MQ2Nav] Reached Destination *,*,* (about 30 feet)
[MQ2Nav] Stopping Navigation
[MQ2Nav] Navigating to Spawn: Tank (****)
[MQ2Nav] Reached Destination *,*,* (about 30 feet)
[MQ2Nav] Stopping Navigation

What might be causing this, as it is unusable in the current form? I went back to 11.009 and this has gone away.

This is actually happening to my other characters now. Has EQ2Nav changed some how?

Did you ever find a fix for this with the current version? Having the same issue.

 

[deathlock]

Did you ever find a fix for this with the current version? Having the same issue.

No it is interment. I think it may have to do with lag or the macro being laggy. I use it on 6 toons on one computer.

 

[Casca]

Example from a random ini

DPS1=command:/stopdisc|99|cond1
Cond1=${Me.ActiveDisc.ID} && (${Me.XTarget}>=4||${Target.Named}) &&  ${Me.ActiveDisc.Name.NotEqual[Last Stand Discipline]} && ${Me.CombatAbilityReady[Last Stand Discipline]}

The community should be able to come with a standard list of most used conditions with the new system

You can only have 1 condition per entry

I did not write the original condition code. I never felt it was thought out well or fit into Kiss so I rewrote it to simply everything.

I just posted all the changes above

Can you use /stopdisc in a condition? Many other disc I'd like to use besides Last Stand/Culminating Stand. I always run Resolute Defense, it is always up. If I want to run another disc besides Culminating Stand, how would I do it other than having a bunch of DPS#=Command:/stopdisc for each different disc and then another DPS#=to fire off that disc? I'll do it that way, just wondering if there is a simpler way.

 

[eqtrader74]

Not in the conditions itself, you can only check things not activate them via conditions code, then use that in the DPS/Burn section entry for the trigger. You could combine some stopdisc conditions, but you need to check if the new disc you want to swap to is available in each case, so that could wind up being a very long condition. Can we use /multiline in command? That might be another way to combine stuff.

Maybe post what you'd like your warrior to do in a new thread. A bunch of conditions folks came together awhile back to help out on these original stopdisc/Last Stand codes. And the same code wound up it 3-4 of the current 110 warrior ini files, so if you have some more disc setups, we'd all love to hear them.

 

[Casca]

Only seen two warrior ini for 11. One of them only uses Last stand line disc and resolute defense. As far as I can tell, the other one that uses more disc that runs on the timer window only has /stopdisc set up to make it so Last stand line will be able to work, so really that ini also only uses last stand line and resolute.

I tried this. Me.XTarget is one so I can test it.

Cond2=${Me.ActiveDisc.ID} && (${Me.XTarget}>=1||${Target.Named}||${Me.PctHPs}<25) && ${Me.ActiveDisc.Name.NotEqual[Culminating Stand Discipline]}||${Me.ActiveDisc.Name.NotEqual[Fortitude Discipline]}||${Me.ActiveDisc.Name.NotEqual[Armor of Tenacious Runes]}||${Me.ActiveDisc.Name.NotEqual[Furious Discipline]}||${Me.ActiveDisc.Name.NotEqual[Warrior's Bastion]}||${Me.ActiveDisc.Name.NotEqual[Stormstrike Defense Discipline]}||${Me.ActiveDisc.Name.NotEqual[Strike Through]}

What I am trying to do is use all the other disc depending on adds, named and Last stand line is down or if just my tanks hitpoints dip below a point. The above worked, but only tested it on one other disc. Only problem is it will keep dropping Resolute Defense while it meets the conditions and if I put all the disc in there, I am thinking it will blow through all of them unless I make more /stopdisc cond.

 

[ctaylor22]

I think you can condense those ActiveDisc a little by using the Select command.

${Select[${Me.ActiveDisc.Name},Culminating Stand Discipline,Fortitude Discipline,Armor of Tenacious Runes,Furious Discipline,Warrior's Bastion,Stormstrike Defense Discipline,Strike Through]}==0

I would test it first, but I don't know why it wouldn't work.

 

[Casca]

I think you can condense those ActiveDisc a little by using the Select command.

${Select[${Me.ActiveDisc.Name},Culminating Stand Discipline,Fortitude Discipline,Armor of Tenacious Runes,Furious Discipline,Warrior's Bastion,Stormstrike Defense Discipline,Strike Through]}==0

I would test it first, but I don't know why it wouldn't work.

Only did one fight, but it clicked off Resolute and was able to run other disc. I think it will work this way and not blow through all the disc. For some reason earlier I was thinking my cond2 to /stopdisc, also activates a disc. I'll just have an overall #of mobs, tank is low HP, named=/stopdisc and then work within that for which disc to use.


Ok, this works for me too

${Me.ActiveDisc.ID} && (${Me.XTarget}>=3||${Target.Named}||${Me.PctHPs}<25) && ${Me.ActiveDisc.Name.Equal[Resolute Defense]}

Really, all I need for it to do is click off Resolute Defense. Most of the disc are short to very short duration. Any that goes over 1min can have a condition added for Culminating stand isn't up.

 

[eqplayer16]

Having an issue with mag on the latest Kiss11 build from discord. If the mag already has a mod rod / wand in inventory when the macro is started, she will just keep spamming spells to summon mod rod / wand.

 

[Chibz]

I apologize if this isn’t the right place to post this. I am wondering why the burn function was changed recently in Kiss11? I liked the burnallnamed function, could you possibly add a 0,1,2 command where 1 is burnallnamed and 2 is /burn activated?

 

[Maskoi]

Having an issue with mag on the latest Kiss11 build from discord. If the mag already has a mod rod / wand in inventory when the macro is started, she will just keep spamming spells to summon mod rod / wand.

Make sure your ini has the correct matching type of rod you are summoning like Glowing vs giant etc

 

[Maskoi]

I apologize if this isn’t the right place to post this. I am wondering why the burn function was changed recently in Kiss11? I liked the burnallnamed function, could you possibly add a 0,1,2 command where 1 is burnallnamed and 2 is /burn activated?

you can still activate burn with /burn

 

[eqplayer16]

Make sure your ini has the correct matching type of rod you are summoning like Glowing vs giant etc

Gah I had Large instead of Giant in there. Now it works even if I have the rods in bag when I start. Thanks!

 

[GeorgiaGeorgiz]

Recently, my warrior tank began being stubborn about camp loc. For many months, I could do camphere, then move to another loc and do camphere again and he would accept the new loc and stay there.

For about a week, he has refused to move from the camp loc. no matter what I do (except stop macro and restart it), he willl not move to another loc. He just moves a short distance and runs back. If I use mqp he will follow untill I do mqp again. He thens runs back to the camp loc.

I have chaseassist set to 0 and returntocamp set to 0 in the ini file.

I have had many wipes since this began. It is difficult to move throug mob areas without tank being ready to engage immediately without haviing to start the macro.

I use Kiss11.010 and I alwasy run the update utility before I start mq2.

 

[eqtrader74]

That sounds like ReturnToCamp is getting set back to 1. Double check you don't have two entries for it in your ini.

If you type "/ReturnToCamp 0" can you move them? (Or "/campoff" though I'm not sure if that's a default or custom alias for the same thing.)

Did this start after a particular KA11 update?

 

[GeorgiaGeorgiz]

/camphere [General] Turns off ReturnToCamp - Hit it again and it resets your camp loc.

Now it is not turning off ReturnToCamp and it does not reset the camp loc.

ReturnToDCamp isn't being changed. If I set the ini ReturnToCamp to 1, I can't get it to change so char will move. If I try to change ReturnToCamp, I get the message [MQ2] toggle ReturnToCamp. However, looking at ini file after this shows that ReturnToCamp was not changed and it has no effect. If I set ReturnToCamp to 0 in the ini file, the warrior will move without returning to camp and I can't change anything to make him return to camp.

The problem is I can't reset the camp loc. I have never had a problem with changing the camp location using /camphere. But camphere doesn't change camp location anymore, it says it changes the ReturnToCamp value but that isn't all it is supposed to do. It is supposed to turnoff the camp location or turnon a new camp location. The message that is returned isn't the same as it was a week or 2 ago. Now it says it is toggleing the ReturnToCamp value. Before, it would say something about camphere toggleing.

If I do "/set returntocamp 0" I get message returned "Set Autorun to: 'returntocamp 0' but the value in the ini file doesn't change and it has no effect on my char.

Campoff doesn't parse.

The last update to Kiss11, that I know of, was before this started.

 

[eqtrader74]

Maybe your aliases got changed. When KA11 is running, what does this command do? (This is what /camphere should do via KA's standard alias.)

 /togglevariable ReturnToCamp

or

/togglevariable ReturnToCamp 0

/togglevariable ReturnToCamp 1

You can check you alias lines via "/alias list" or in the MacroQuest.ini in your Release folder.

The toggles just temp reset ReturnToCamp, your ini will stay the same.

 

[GeorgiaGeorgiz]

/camphere [General] Turns off ReturnToCamp - Hit it again and it resets your camp loc

This is what camphere has always done. It does not turn off ReturnToCamp now and it does not reset the camp loc.

/togglevariable ReturnToCamp does not effect the char. He still returns to camp as before.


alias for camphere is /camphere /echo toggle ReturnToCamp

Is there another alias I should check. I don't see anything obvious.

 

[GeorgiaGeorgiz]

I downloaded Kiss11.010 again and no change.

 

[eqtrader74]

camphere is the alias, but saying "/echo toggle ReturnToCamp" I think just prints that to your MQ2 window as opposed to giving the command. /echo is just print to MQ2 window as far as I know.

Is there an alias entry for "toggle"? On mine that isn't a command, it needs togglevariable.

Try deleting the "KissAssistVer=11.." line in your ini and restart KA11. It should cause a version mismatch which triggers a full KA alias re-write. Does /camphere work after the restart? If not, does the alias for camphere still show the /echo command?

If that is still failing, try manually updating your alias entries. For my MacroQuest.ini I have these related entries. Try swapping/adding these in your MacroQuest.ini and restart MQ2.

[Aliases]
/camphere=/togglevariable ReturnToCamp
/campoff=/togglevariable ReturnToCamp 0

-------------

Testing these on my tank, I get these MQ2 window results when KA11.010 is running:

/camphere = "Setting (ReturnToCamp) to (Off)" or the alternating toggle of "New camp set to LocX, LocY. Setting (ReturnToCamp) to (On)"
/campoff = "Setting (ReturnToCamp) to (Off)"

/togglevariable ReturnToCamp = Same results as /camphere

/echo toggle ReturnToCamp = prints "toggle ReturnToCamp" in MQ2 window, but no effect as that's not a real command, just a print text command.

/toggle ReturnToCamp = Fails in EQ window (not MQ2 window) as "That is not a valid command."

 

[GeorgiaGeorgiz]

No entry for toggle or togglevariable

Deleted the kissassistver=11 did not change anything and that line did not get rewritten into the ini after starting macro in game.

Camphere still not working.


/camphere=/togglevariable ReturnToCamp was in macroquest.ini file. I added the other line I will restart mq

the other line did not show up in warrior's alial list after restart. I exit from editing any file I update so it won't lockout the file being assigned and updated by another program.



What you were getting from testing on your tank is about the same as I was getting before.

 

[eqtrader74]

Hmm, what exact MQ2 window message do you get now when you do /camphere?

Are you now getting the "(On)" and "(Off)" ones, but then the tank doesn't seem to care and just does what ever the ini was set to? Or you're getting some other MQ2 window response or the /echo thing?

 

[GeorgiaGeorgiz]

he is still getting [MQ2] toggle ReturnToCamp nothing else for camphere

 

[eqtrader74]

OK, maybe I'm not understanding aliases as well as I thought. So your /camphere is still aliased to "/echo toggle ReturnToCamp"

And when KA11 is running, what does MQ2 window do when you enter "/togglevariable ReturnToCamp" a couple times?

 

[GeorgiaGeorgiz]

yes /echo toggle ReturnToCamp.

nothing happens when I do togglevariable returntocamp

I do not get any response in any window.

 

[eqtrader74]

Well the good news is we've got it down to the alias being wrong. The bad news is I'm not sure at all why "/togglevariable ReturnToCamp" doesn't just do the same thing as /camphere should.

You can manually set the alias like this:

/alias /camphere /togglevariable ReturnToCamp

Then check "/alias list" and see if that's corrected. Try running KA11 and using camphere. Fail? Any message?

 

[GeorgiaGeorgiz]

Woo hoo. That worked. Thank you very much. Giving you as many redcents as they will allow for one day. hehe

I got the message [MQ2] >> Setting: (ReturnToCamp) to (Off).

Then to (On). hehe