• 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

Problem - Buffing Conditions - Checking for understanding

Joined
May 31, 2022
RedCents
4,210¢
Version of KissAssist.mac?
12.002
When did your problem start?
When I wrote the condition
Character Role?
  1. Assist
  2. Tank
What class is having this issue?
  1. Beastlord
  2. Paladin
  3. Shaman
How often does this issue occur?
Always
Can you reproduce the issue?
Yes
I use conditions like the following for buffs:
INI:
Buffs4=Center|Cond13
Cond13=!${Target.Buff[Center].ID} && ${Spell[Center].StacksTarget}
And this works pretty much all the time.

I have been working with low level characters recently and on a couple of buffs found some inconsistencies:
Some buffs at low level are basically the same, but are called different names, and cast by different classes. e.g.
Holy Armor: Increase AC by 4 (L1) to 10 (L6)
Scale Skin: Increase AC by 3 (L3) to 9 (L10)

These 2 buffs will overwrite each other, so I have a checks as follows:
[CODE lang="ini" title="Paladin"]Buffs5=Holy Armor|Cond14
Cond14=!(${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget}[/CODE]
and
[CODE lang="ini" title="Beastlord"]Buffs4=Scale Skin|Cond6
Cond6=!(${Target.Buff[Scale Skin].ID} || ${Target.Buff[Holy Armor].ID}) && ${Spell[Scale Skin].StacksTarget}[/CODE]
Now, these conditions work as far as recognising each other and not trying to overwrite.

But, when a higher buff in that line (Protect) is cast:[CODE lang="ini" title="Shaman"]Buffs4=Protect|Cond6
Cond6=!${Target.Buff[Protect].ID} && ${Spell[Protect].StacksTarget}[/CODE]
Both the Paladin and Beastlord will cast Holy Armor and Scale Skin respectively to no avail.
To try and isolate the issue I cut the conditions down to ${Spell[Holy Armor].StacksTarget} for the Paladin and ${Spell[Scale Skin].StacksTarget} for the Beastlord. Both toons continue to believe that their lower level buffs will stack (idiots!).

I see this also with the spell Strengthen not recognising that it will not stack with Spirit Strength..

I've not seen any issues with higher level spells, nor with other low level spells. I'm assuming currently that it's simply the EQ object not exposing the properties correctly, and as I move past those spells it'll resolve itself.
My question is, can anyone see if I am making a mistake, or if there is an issue with the part of MQ which the conditions query against.

The full ini's are here
Beastlord - Level 15 - Maximum effort!
Paladin - Level 15- Maximum Effort!

Thanks in advance for reading.
 
well lets look art this:
Cond6=!(${Target.Buff[Scale Skin].ID} || ${Target.Buff[Holy Armor].ID}) && ${Spell[Scale Skin].StacksTarget} === Bad Syntax

Should look like:
Cond6=(!${Target.Buff[Scale Skin].ID} || ${Target.Buff[Holy Armor].ID}) && ${Spell[Scale Skin].StacksTarget}

Again:

Cond14=!(${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget} == Syntax issues
should look like

Cond14=(!${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget}

but you have seperators there with ( or ) so what exactly are you sepreating the OR (||)
 
Cond14=!(${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget}

does not make sense. might as well remove skin scale from here and just check against its self
Cond14=!${Target.Buff[Holy Armor].ID} && ${Spell[Holy Armor].StacksTarget}

your just checking if Holy Armor is on your target and if it stacks
 
Cond14=!(${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget}

does not make sense. might as well remove skin scale from here and just check against its self
Cond14=!${Target.Buff[Holy Armor].ID} && ${Spell[Holy Armor].StacksTarget}

your just checking if Holy Armor is on your target and if it stacks
Correct.
Test for is it on the target, and does it stack.
The first part resolves to the correct answer, the "Does it stack" does not return correctly.
It returns a True, when clearly it does not stack. When cast, the following is displayed: "Your Holy Armor spell did not take hold (Blocked by Protect). Your spell would not have taken hold on your target."
Also checked via CondBuilder.Lua, and it clearly (incorrectly) shows TRUE for stacking.
 
well lets look art this:
Cond6=!(${Target.Buff[Scale Skin].ID} || ${Target.Buff[Holy Armor].ID}) && ${Spell[Scale Skin].StacksTarget} === Bad Syntax

Should look like:
Cond6=(!${Target.Buff[Scale Skin].ID} || ${Target.Buff[Holy Armor].ID}) && ${Spell[Scale Skin].StacksTarget}

Again:

Cond14=!(${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget} == Syntax issues
should look like

Cond14=(!${Target.Buff[Holy Armor].ID} || ${Target.Buff[Scale Skin].ID}) && ${Spell[Holy Armor].StacksTarget}

but you have seperators there with ( or ) so what exactly are you sepreating the OR (||)
No, the NOT ( A OR B ) section is correct.
Spell A and B will overwrite each other, so the test here is if either is present, don't cast, and since only one can be present, NOT (A OR B ) is correct.
The issue is the stacking test returns an incorrect result - say it will stack but does not when cast.
 
Nothing wrong with the syntax in the original post.
!(A or B) and C
this says if target doesnt have A and target doesnt have B, and A stacks on the target, then cast A

its the same as saying
!A and !B and C


maybe can figure out why from there if the stacking info from eq is wrong.

Code:
> /echo ${Spell[scale skin].StacksWith[protect]}
FALSE
stack check seems correct in game though. but i'm also on emu, spell data may be different.
 
Nothing wrong with the syntax in the original post.
!(A or B) and C
this says if target doesnt have A and target doesnt have B, and A stacks on the target, then cast A

its the same as saying
!A and !B and C


maybe can figure out why from there if the stacking info from eq is wrong.

Code:
> /echo ${Spell[scale skin].StacksWith[protect]}
FALSE
stack check seems correct in game though. but i'm also on emu, spell data may be different.
/echo ${Spell[scale skin].StacksWith[protect]} returns TRUE in game for me.
As does /echo ${Spell[holy armor].StacksWith[protect]}

I'll just put a note on the KA ini's I published so folks who look at them know it's not an error and they can work around it.
Cheers for looking at this for me KS1980 and aquietone.
 
Last edited:
Nothing wrong with the syntax in the original post.
!(A or B) and C
this says if target doesnt have A and target doesnt have B, and A stacks on the target, then cast A

its the same as saying
!A and !B and C


maybe can figure out why from there if the stacking info from eq is wrong.

Code:
> /echo ${Spell[scale skin].StacksWith[protect]}
FALSE
stack check seems correct in game though. but i'm also on emu, spell data may be different.your correct which is why i was trying to understand his seperator :)
 
I was hoping today's patch would have resolved this issue but sadly no. On a character with a Skin like Rock buff active, thinking about self-casting Center:

${Spell[Center].Stacks} returns FALSE whereas
${Spell[Center].StacksTarget} returns TRUE.

I'm especially baffled by why Stacks and StacksTarget (while targeting self) return different values. Looking forward to leveling past these issues; I have learned a whole lot from your KA .inis, Naturesong, especially your bandolier swapping stuff. Thanks!
 
Not sure, .WillLand returns the value of the buff slot it should populate.
WillLand seems to only determine whether the spell will land on the character executing the command. So for example, a Druid with Greater Wolf Form on, casting SoW with the following condition: !${Target.Buff[Spirit of Wolf].ID} && ${Spell[Spirit of Wolf].WillLand} won't cast SoW on anyone because ${Spell[Spirit of Wolf].WillLand} returns 0 whenever the Druid calls. So it works but doesn't help buff groupmates unless there's some kinda WillLandTarget member of the spell datatype.
 
Yes. You are correct. I went back and looked at my code trying to use .WillLand. I have been playing with some code in the CheckBuffs routine that uses DanNet to ask the character if the buff .WillStack. We have tried to stay away from .StacksTarget because it requires you to Target a character. This leads to Target hopping to much and gives away the fact you are using a macro. We try and attempt to do as much checking as we can without targeting them.
 
Yes. You are correct. I went back and looked at my code trying to use .WillLand. I have been playing with some code in the CheckBuffs routine that uses DanNet to ask the character if the buff .WillStack. We have tried to stay away from .StacksTarget because it requires you to Target a character. This leads to Target hopping to much and gives away the fact you are using a macro. We try and attempt to do as much checking as we can without targeting them.
This is looking like a more succinct and easier to read way to test for self buffs.
From
INI:
CondX=!${Me.Buff[Blessing of Swiftness].ID} && ${Spell[Blessing of Swiftness].Stacks} && ${Me.FreeBuffSlots} > 0
.. to ..
INI:
CondY=!${Me.Buff[Blessing of Swiftness].ID} && ${Spell[Blessing of Swiftness].WillLand}
 
This is looking like a more succinct and easier to read way to test for self buffs.
From
INI:
CondX=!${Me.Buff[Blessing of Swiftness].ID} && ${Spell[Blessing of Swiftness].Stacks} && ${Me.FreeBuffSlots} > 0
.. to ..
INI:
CondY=!${Me.Buff[Blessing of Swiftness].ID} && ${Spell[Blessing of Swiftness].WillLand}
Agreed, as well as group buffs!
 
Yes. You are correct. I went back and looked at my code trying to use .WillLand. I have been playing with some code in the CheckBuffs routine that uses DanNet to ask the character if the buff .WillStack. We have tried to stay away from .StacksTarget because it requires you to Target a character. This leads to Target hopping to much and gives away the fact you are using a macro. We try and attempt to do as much checking as we can without targeting them.
Looking forward to having all the ini's I published made redundant in one stroke.
No seriously, this functionality in KissAssist would reduce my Condition section, particularly on buffing classes to a more manageable level.

As well as likely solve the issue we're seeing with buff stacking.
 
Problem - Buffing Conditions - Checking for understanding

Users who are viewing this thread

Back
Top
Cart