Problem - Incorrectly functioning conditions and or syntax improvement

[tervalas]

Version of KissAssist.mac?

12.002

When did your problem start?

Happens a lot

Character Role?

1. Assist

What class is having this issue?

1. Wizard

How often does this issue occur?

Often

A) First, the 'incorrectly functioning condition':
Buffs6=Spellshield|Cond9 Cond9=${FindItemCount[Peridot]} > 0 && !${Me.Buff[Spellshield].ID} && ${Spell[Spellshield].Stacks} && ${Me.FreeBuffSlots} > 0

Still tries to attempt to cast spell even if no Peridot gems in inventory. Logically, it shouldn't even try if the first part of the condition is false.


B) Now, the syntax improvement question....is there a way to make the normal StacksTarget conditional work correctly all the time or am I stuck with some thing just not being able to tell if it stacks?
!${Target.Buff[Feedback].ID} && ${Spell[Feedback].StacksTarget}

Still tries to cast on characters with buffs that will block it.

 

[ChatWithThisName]

iirc conditions are checked prior to obtaining a target, unless you just happen to already have the intended target targeted prior to the conditions being check.
Target in this case means your current Target in game, not the intended target of the buff in question.

 

[tervalas]

iirc conditions are checked prior to obtaining a target, unless you just happen to already have the intended target targeted prior to the conditions being check.
Target in this case means your current Target in game, not the intended target of the buff in question.

Odd....since it cycles through targets to see if they need any of the buffs, it should have the target selected shouldn't it?

Especially because the initial part of the condition is checking that the target doesn't already have the buff?

Or are you speaking more about StacksTarget?

 

[ChatWithThisName]

Odd....since it cycles through targets to see if they need any of the buffs, it should have the target selected shouldn't it?

Especially because the initial part of the condition is checking that the target doesn't already have the buff?

Or are you speaking more about StacksTarget?

I see you're new as of October, so I understand that you might think that the INI conditions and their corresponding entries are part of the macro, but the INIs are player made and submitted to the repo for others to use.

Sometimes the conditions are not ideal use cases and may have things in them that seem like they should work the way the author of that INI intended, but may not be correct.

INIs are all user created, and not created by the author of the macro. With that said I refer you to my previous statement, that targeting doesn't happen until the macro believes all conditions have been met.

 

[tervalas]

So I did a couple tests.

Made sure once again the spell wouldn't stack.

Got "Your Feedback spell did not take hold on ####. (Blocked by Barrier of Combustion.)"

targeted the player again and tried /echo ${Spell[Feedback].StacksTarget]} and got TRUE.

But obviously it doesn't. So I think it is something I have to live with and just adjust my ini to get rid of things that may inadvertently think they can stack.

I see you're new as of October, so I understand that you might think that the INI conditions and their corresponding entries are part of the macro, but the INIs are player made and submitted to the repo for others to use.

Sometimes the conditions are not ideal use cases and may have things in them that seem like they should work the way the author of that INI intended, but may not be correct.

INIs are all user created, and not created by the author of the macro. With that said I refer you to my previous statement, that targeting doesn't happen until the macro believes all conditions have been met.

Oh, I understood the INIs are player made. Just figured as I found that conditional mentioned by multiple people as a means to prevent casting something that wouldn't stack that it was trustworthy to use it.

Would that also explain why ${FindItemCount[Peridot]} > 0 doesn't stop casting either? Thought I swear I've had some of those still work properly and not even try.

 

[ChatWithThisName]

So I did a couple tests.

Made sure once again the spell wouldn't stack.

Got "Your Feedback spell did not take hold on ####. (Blocked by Barrier of Combustion.)"

targeted the player again and tried /echo ${Spell[Feedback].StacksTarget]} and got TRUE.

But obviously it doesn't. So I think it is something I have to live with and just adjust my ini to get rid of things that may inadvertently think they can stack.


Oh, I understood the INIs are player made. Just figured as I found that conditional mentioned by multiple people as a means to prevent casting something that wouldn't stack that it was trustworthy to use it.

Would that also explain why ${FindItemCount[Peridot]} > 0 doesn't stop casting either? Thought I swear I've had some of those still work properly and not even try.

The FindItemCount should be correctly finding if the item is present. But are you sure it only needs one peridot for the spell you're casting?
FindItemCount should be searching yourself for an item, so regarding reagents, it's a perfectly reasonable to check to make, though if it requires more than you're saying to check for it could still try to cast it and fail thinking 1 is enough when it needs 2 or w/e.