Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.

@deathlock I need your help testing some changes I made for @timmy this week. I can add the change to include cures as part of the heal check for interrupt checking. Willing to do some testing for us?
@Naturesong Yes, but you still have to include all required tags, like Heal HP Check.
INI:Heals1=Word of Health|98|Cond1 Cond1=${Group.Injured[80]} > 2
Journeyman's Boots, or will it continue to check the rest of the statement regardless?It has to evaluate everything. There could be OR operators that would result in a TRUE result even though 1 component was FALSE.Question about how KissAssist parses conditions.
I tend to use a lot of conditions, so looking at whether or not I can reduce the processing required when they are parsed.
Does it parse all the parts of the condition and then calculate the result True/False?
Or, does it return False as soon as it parses a false argument?
Example:
[CODE lang="ini" title="Multi part conditional statment"]Cond9=${FindItemCount[Journeyman's Boots]} > 0 && !${Me.Buff[Journeyman Boots].ID} && ${Spell[Journeyman Boots].WillLand}[/CODE]
Will it return False as soon as it discovers noJourneyman's Boots, or will it continue to check the rest of the statement regardless?
Cond1=${Me.ActiveDisc.ID}
Cond2=${Me.PctHP} < 75
Cond3=${BurnAllNamed}
Cond4=!{Cond[1]} && {Cond[2]} || {Cond[3]}
It doesn't necessarily have to parse the whole thing, just to the firstIt has to evaluate everything. There could be OR operators that would result in a TRUE result even though 1 component was FALSE.
One thing you can do to consolidated is when you are reusing the same variable in multiple conditions, you can make it it's own condition and then reference that condition as a variable. Something like this:
Code:Cond1=${Me.ActiveDisc.ID} Cond2=${Me.PctHP} < 75 Cond3=${BurnAllNamed} Cond4=!{Cond[1]} && {Cond[2]} || {Cond[3]}
&&, which prompted my enquiry. But if it processes it that way, then I'll leave my conditions as is.Cond1=${Me.ActiveDisc.ID}
Cond2=${Me.PctHP} < 75
Cond3=${BurnAllNamed}
Cond4=!${Cond[1]} && ${Cond[2]} || ${Cond[3]}
Cond5=${If[!${Cond[1]} && ${Cond[2]},True,${Cond[3]}]}
Cheers for the explanation, that helps.The whole condition is evaluated, it is how the MQ engine works. You could break up your condition into smaller parts and have each part terminate at that point. Here is an example:
INI:Cond1=${Me.ActiveDisc.ID} Cond2=${Me.PctHP} < 75 Cond3=${BurnAllNamed} Cond4=!${Cond[1]} && ${Cond[2]} || ${Cond[3]} Cond5=${If[!${Cond[1]} && ${Cond[2]},True,${Cond[3]}]}
What Cond5 is doing is evaluating !${Cond[1]} && ${Cond[2]} and if it is true then return True. Nothing more gets evaluated, unless !${Cond[1]} && ${Cond[2]} evaluates to False. Then ${Cond[3]} is evaluated and returned.
Cond1=${Me.ActiveDisc.ID}
Cond2=${Me.PctHP} < 75
Cond3=${BurnAllNamed}
Cond4=!${Cond[1]} && ${Cond[2]} || ${Cond[3]}
Cond5=${If[!${Cond[1]} && ${Cond[2]},True,${Cond[3]}]}
Cond6=${If[${Me.ActiveDisc.ID} &&${Me.PctHP} < 75,True,${BurnAllNamed}]}
This is great. Love it!You don't have to use Cond1 ... Cond3INI:Cond1=${Me.ActiveDisc.ID} Cond2=${Me.PctHP} < 75 Cond3=${BurnAllNamed} Cond4=!${Cond[1]} && ${Cond[2]} || ${Cond[3]} Cond5=${If[!${Cond[1]} && ${Cond[2]},True,${Cond[3]}]} Cond6=${If[${Me.ActiveDisc.ID} &&${Me.PctHP} < 75,True,${BurnAllNamed}]}
You can also Nest ${If[]}
${If[${Me.ActiveDisc.ID} &&${Me.PctHP} < 75,True,${If[${BurnAllNamed},True,False]}]}
You can also sub 1 and 0 for True and False.
This could of happened with any character using a pet and using DPS. The issue was that after mob death CombatReset was not getting executed, and the next mob coming into camp was being considered the same as the last mob killed. This action was causing the Master of the pet to send in the pet on incoming mobs, and if the character was a melee character, to charge after the mob before the mob made it to camp.
The above statement only happened in locations where mobs were being pulled very...
You are the #AwesomeSauce. And you answered the question I didn't know I wanted to ask. So thank you for that one as well.yes, comment it out with a ;
[Mez]
; Use MezOn=3 if you ONLY want AOE Mez (this is how i run it)
MezOn=3
Like so.
This did it. Thanks Amarth. This makes all the difference./addimmune ${Target.CleanName} should work.
I'm having a big of a headache finding writeups on conditionals in KA, so i figured I'd ask here
is this a valid condition in KA?
Cond21=${Target.CleanName} == "a decaying skeleton"
${Target.Name.Equal[Klandicar]}
you could change your "burn" to be in dps section, and leverage spawnmaster's SpawnMaster.HasTarget with predefined lists of named mobsIs there a place to add mob names to not treat them as named?
So if i did this to avoid burns firing on raid trash, then id need to put the raid mobs that I want to count as "named" into my spawn list in spawnmaster.ini?you could change your "burn" to be in dps section, and leverage spawnmaster's SpawnMaster.HasTarget with predefined lists of named mobs
well, you could always do an event for it, but it would require some learning.Any plugin or some kind of autoclicker in kissassist that would allow turning in quest item to a newly spawned quest mob? like epic turn ins to Marl Kastane for sk epic? He's not even rendering before despawning, the turn ins are so fast.
I've set the following on my bard (puller), to try and get him back pulling quicker as I dont want to wait for him to get to full mana, but KA seems to glitch.
[CODE lang="ini" title="Med to 50%"]MedOn=1
MedStart=20
MedStop=50
MedCombat=0[/CODE]
This is him at 100% mana.
View attachment 50160
Not sure what's going wrong here.
Endurance also nearly 100%My bard is always low on endurance. I think KA also considers endurance in that section of the macro. Not 100% sure though.
MedOn=1
MedStart=20
MedStop=100
Cheers for you attention to this.Ok looking at the code The monk may of continued medding because someone in the group now needed to med and the monk has GroupWatchOn turned on. If Medding is interrupted the group member that has GroupWatchOn turned on will return back to the med routine and then check who in the group has the lowest stats to continue medding for, but the character will call out their own stats. I will see about adding in an extra call out that gives a more accurate reason the character is continuing to med.
