• 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 (5 Viewers) 12.002.039

No permission to download
@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?
 
@ctaylor22, will the heals section take conditions?
i.e.
[CODE lang="ini" title="heal condition for group heal"]Heals1=Word of Health|Cond1
Cond1=${Group.Injured[80]} > 2[/CODE]
 
@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
 
@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

So this should work:
[CODE lang="ini" title="heal condition for group heal"]Heals1=Word of Health|80|Cond1
Cond1=${Group.Injured[80]} > 2[/CODE]
 
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 no Journeyman's Boots, or will it continue to check the rest of the statement regardless?
 
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 no 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.

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]}
 
It 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]}
It doesn't necessarily have to parse the whole thing, just to the first &&, which prompted my enquiry. But if it processes it that way, then I'll leave my conditions as is.
I got to thinking about it because I was using bash for a home project and started thinking about how it parses commands ...
KissAssist is pretty good, and I don't find having a lot of conditions slows things down noticeably. I was just curious.

I have gone down the path of building component conditions which are then used as building blocks but found that maintenance / changes became a bit of a headache.
 
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.
 
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.
Cheers for the explanation, that helps.

I really like Cond5, I did not realise you could do ternary conditions.
Unfortunately, because I often edit my ini's (still learning and developing) I found breaking up conditions into reusable component building blocks a bit of a headache maintenace wise. I keep missing components when I need to rename CondX to CondY.
In order to prevent the parsing of the entire line of Cond5, splitting out to building blocks (Cond1 ... Cond3) is required?
 
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]}]}
Cond6=${If[${Me.ActiveDisc.ID} &&${Me.PctHP} < 75,True,${BurnAllNamed}]}
You don't have to use Cond1 ... Cond3

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.
 
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]}]}
Cond6=${If[${Me.ActiveDisc.ID} &&${Me.PctHP} < 75,True,${BurnAllNamed}]}
You don't have to use Cond1 ... Cond3

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 is great. Love it!

ps. bugger, ran out of redcents to give =/
 
ctaylor22 updated KissAssist with a new update entry:

Misbehaving BLs and Mages

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...

Read the rest of this update entry...
 
I was wondering if there is a way to put a comment in a kissassist ini file? Specifically, I'd like to put a spell description after the spells I put in there so I know what affects the spells have.

~Respectfully
 
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.
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.
 
Is there a way to make a hot key to ignore a mob for mezzing?
I see in the instructions there’s /addimmune <text> but I’d like to be able to do it as I go instead of changing the KissAssist_Info.ini manually.

Thanks guys.

BB~
 
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"
 
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"

Code:
${Target.Name.Equal[Klandicar]}

that works. shamelessly stolen from @ShOeCrEw

i have not, however, tried anything w/ spaces in the name.
 
Cond21=${Target.CleanName.Equal[a decaying skeleton]}

.CleanName would work better for regular mobs in the zone. .Name will return a number at the end, like "a decaying skeleton01"
 
Not that I am aware of. The Macro uses ${Spawn.Named} to determine if the mod is a Named mob or not. MQNext determins if .Named is True or False, not sure if this can be fixed or not.
 
you could change your "burn" to be in dps section, and leverage spawnmaster's SpawnMaster.HasTarget with predefined lists of named mobs
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?
 
SpawnMaster is dependent on the mob you want to check. The mob has to be on your Target. KissAssist uses the Spawn TLO for anything is can before actually Targeting the mob. Cuts down on Target bouncing. Would be nice if you could pass an ID to SpawnMaster and then check if the passed ID is in the list. Would not take much to add the code to use SpawnMaster TLO for checking for nameds, but SpawnMaster would have to allow for more than the use of your current target.
 
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.
 
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.
well, you could always do an event for it, but it would require some learning.
 
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.

1691196244904.png

Not sure what's going wrong here.
 
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.

My bard is always low on endurance. I think KA also considers endurance in that section of the macro. Not 100% sure though.
 
My bard is always low on endurance. I think KA also considers endurance in that section of the macro. Not 100% sure though.
Endurance also nearly 100%
If I change it back to defaults, he stops medding (appropriate action):
INI:
MedOn=1
MedStart=20
MedStop=100
I think there is a logic error in the MedStop, but I cant see it.
 
Last edited:
That would be because your Monk was medding and got interrupted before he got back to Full endurance. I guess I left out the logic to check for that situation, but logic would dictate, that if you are interrupted when medding, that you would have less Endurance when you finished fighting and returned back to medding.

I will see about resetting the MeddingInterrupted if this situation is in effect.
 
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.
 
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.
Cheers for you attention to this.
I'll continue to test to discover a replicable isolated symptom. i.e. not group watch.
Clarifying the stdout messages will help for sure.
 
KissAssist Release KissAssist

Users who are viewing this thread

Back
Top
Cart