• 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 - Low numbered AA ability causing kissassist.mac errors

Joined
Dec 3, 2013
RedCents
Version of KissAssist.mac?
11.001
When did your problem start?
When I tried to use a low numbered AA ability with a large amount of spells in spellbook
Character Role?
  1. Assist
  2. Tank
  3. PetTank
  4. PullerPetTank
  5. Puller
  6. PullerTank
  7. Hunter
  8. HunterPetTank
  9. Petassist
What class is having this issue?
  1. Paladin
How often does this issue occur?
Always
If you attempt to use a low numbered AA ability (for example: Hand of Piety #180) and you have at least that many spells in your spellbook, kissassist will fail with an error indicating the conditional is invalid.

Hand of Piety = AA #180
Complete Heal = spell in 180th position in spellbook

Fail -> if (!Complete Heal & !NULL & !180 & !NULL & !NULL) {

It fails to parse 'C'. This happens in multiple places, anywhere you check for a spellbook entry and AA ability number.
 
The exact line is (under [Heals]):
"Heal8=180|40"

broken_heal.png

"Zealous Touch" is the 180th spell in my spellbook.

There is at least two different conditionals that can fail with this error, but I expect that there is more.
 
is there a reason you want to use the aa# and not just the ability name?

I've only seen very small couple of abilities that i needed to use AA # instead of the aa name - very extreme outlier
 
Using the name it never seems to fire (I usually start testing with a high number to test the spell can actually fire). I run into this issue a lot, so I started using AA # which has consistently worked for me.
 
Using the name it never seems to fire (I usually start testing with a high number to test the spell can actually fire). I run into this issue a lot, so I started using AA # which has consistently worked for me.
not that this fixes anything if it is broken, this might at least help you cast your spell

heals8=command:/alt activate 180|40
 
The main issue is that by specifying a number, Me.Book[#] and Me.CombatAbility[#] will return objects based on their slot/list number.
This is normally not an issue because the numbers are higher and those entries are empty and return NULL.

The problem you will encounter is you get different object types based on the input you supply.

For example:
"Light Healing" = ${Me.Book[Light Healing]} = int
"1" = ${Me.Book[1]} = spell

So if I provide the spell name I get back an int that can be parsed in a conditional. If I provide an int, then I will get back a 'spell' object that will fail parsing due to non-numeric value.

There may be many other ways to solve this issue, but the simplest I found was simply to wrap them in a Bool[]. If you get back an int or a spell, it will be TRUE, otherwise it will be FALSE.

There is at least three lines (if not more) that will have to be updated in order to support an input with a low integer: 2546, 2581, 9921 (based on version 11.001)
2546: /if (${castWhat.Find[command:]} || ${Bool[${Me.AltAbility[${castWhat}]}]} || ${Bool[${Me.CombatAbility[${castWhat}]}]} || ${FindItem[=${castWhat}].ID} || ${Bool[${Me.Ability[${castWhat}]}]} || ${Bool[${Me.Book[${castWhat}]}]}) {
2581: /if (${ReadyToCast}==5 && ${Me.SpellReady[${castWhat}]} && ${Bool[${Me.Book[${castWhat}]}]} && ${Spell[${castWhat}].Mana}<${Me.CurrentMana}) /call CastSpell "${castWhat}" ${WhatID} ${sentFrom} ${CastOnCorpse}
9921: /if (!${Bool[${Me.Book[${iniKey}]}]} && !${Bool[${Me.CombatAbility[${iniKey}]}]} && !${Bool[${Me.AltAbility[${iniKey}]}]} && !${FindItem[=${iniKey}].ID} && ${iniKey.NotEqual[banestrike]} && !${Bool[${Me.Ability[${iniKey}]}]}) {

I'm sure there are other issues using numbers, for example you want to use CombatAbility 4, which would also select book slot #4. Does it cast the ability or the spell? Depends on which one gets processed first.

My personal thoughts on this is to expand the 'spell name/item name/aa ability/etc' field to be a complex type: spell:light healing, item:breastplate, aa:180. This way there is no confusion, you know exactly how to process it. (I dont expect to see this, this is just my thoughts on what would be nice to support)
 
can some one help me please I am in game I have my MQ2 up and running but it wont let me type in the box Mac kissassist on any of my tune my power went out last night do to a TS but other then that don't know I rebooted my comp, still nothing
 
Ah thank you CTaylor22, I was mistaken that using the ID of the AA ability was supported. I've been using it for years without issue until now.
I don't know if it was once supported in the past or I did it on a whim and it worked. I tend to use the ID of the AA when it fails to cast properly using it's name.

In either case I was reporting an issue that isn't even supported, so this thread is mute.

To anyone that cares, you can simply specify '1' for spell/ability name (example: 'Heals1=1|100') and in theory it would cast spell book #1, use combat ability #1 or aa id #1.
Looks like it's just a side effect of the implementation though. Without the changes above it'll definitely fail if you have a spell in slot #1 of your book.
 
It is because of how the Book TLO works. When you provide the Name of the spell, ${Me.Book[Spell Name Here]} The Slot number of the spell is returned. When you use the Slot number ${Me.Book[1]}, The name of the spell in that slot number is returned.

There is a similar issue with CombatAbility. /disc accepts the Ability ID, but ${Me.CombatAbility[Disc Name Here]} returns the slot number of the Ability, in your Combat ability list. To get the actual Disc ID of your combat Ability you have to use ${Me.CombatAbility[${Me.CombatAbility[Disc Name Here]}].ID}

So using Numbers in place of spell/disc names can cause some issues.
 
Kiss only recognizes spell names in Sections.
Use the Command feature and a condition to use numbers
Heals1=Command:/alt act 180|cond1
 
Problem - Low numbered AA ability causing kissassist.mac errors

Users who are viewing this thread

Back
Top
Cart