Bug - KA Cleric TLP Error "Minor Healing"

[LurkMcGurk]

I don't even use Minor Healing on my TLP clerics but it is spitting out an error about it, unsure why. I don't have much time to debug it now as I am busy with work, but I wanted to bring it to your attention if nothing else.

Error:

http://i.imgur.com/mCdFl2y.jpg

Occured after starting my bots when I woke up after patch day

My Clerics INI:

[General]
KissAssistVer=8.5.5
Role=Assist
CampRadius=30
CampRadiusExceed=400
ReturnToCamp=0
ChaseAssist=0
ChaseDistance=25
MedOn=1
MedStart=55
MedCombat=0
LootOn=0
RezAcceptOn=1
AcceptInvitesOn=1
GroupWatchOn=0
EQBCOn=0
IRCOn=0
MiscGem=8
HoTTOn=0
CampfireOn=0
CharInfo=Cleric|60
CastingInterruptOn=0
[SpellSet]
LoadSpellSet=0
SpellSetName=KissAssist
[Buffs]
BuffsOn=1
Buffs1=NULL
Buffs2=NULL
Buffs3=NULL
Buffs4=NULL
Buffs5=Death Pact|MA
Buffs6=NULL
Buffs7=NULL
Buffs8=NULL
Buffs9=NULL
Buffs10=NULL
Buffs11=NULL
Buffs12=NULL
Buffs13=NULL
Buffs14=NULL
Buffs15=NULL
Buffs16=NULL
Buffs17=NULL
Buffs18=NULL
Buffs19=NULL
Buffs20=NULL
RebuffOn=1
CheckBuffsTimer=20
PowerSource=NULL
[Melee]
AssistAt=95
MeleeOn=0
FaceMobOn=0
MeleeDistance=75
StickHow=snaproll
AutoFireOn=0
[GoM]
GoMSHelp=Format - Spell|Target, MA Me or Mob, i.e. Rampaging Servant Rk. II|Mob
GoMSpell1=NULL
GoMSpell2=NULL
GoMSpell3=NULL
[AE]
AEOn=0
AERadius=50
AE1=NULL
AE2=NULL
AE3=NULL
AE4=NULL
AE5=NULL
[DPS]
DPSOn=0
DPSSkip=20
DPSInterval=2
DPS1=NULL
DPS2=NULL
DPS3=NULL
DPS4=NULL
DPS5=NULL
DPS6=NULL
DPS7=NULL
DPS8=NULL
DPS9=NULL
DPS10=NULL
DPS11=NULL
DPS12=NULL
DPS13=NULL
DPS14=NULL
DPS15=NULL
[Aggro]
AggroOn=0
Aggro1=NULL
Aggro2=NULL
Aggro3=NULL
[Heals]
Help=Format Spell|% to heal at i.e. Devout Light Rk. II|50
HealsOn=1
Heals1=Divine Light|45
Heals2=Complete Heal|60
Heals3=NULL
Heals4=NULL
Heals5=NULL
Heals6=NULL
Heals7=NULL
Heals8=NULL
Heals9=NULL
Heals10=NULL
Heals11=NULL
Heals12=NULL
Heals13=NULL
Heals14=NULL
Heals15=NULL
XTarHeal=0
AutoRezOn=0
AutoRezWith=Resurrection
HealGroupPetsOn=0
[Cures]
CuresOn=0
Cures1=NULL
Cures2=NULL
Cures3=NULL
Cures4=NULL
Cures5=NULL
[Burn]
BurnText=Decepticons Attack
BurnAllNamed=0
Burn1=NULL
Burn2=NULL
Burn3=NULL
Burn4=NULL
Burn5=NULL
Burn6=NULL
Burn7=NULL
Burn8=NULL
Burn9=NULL
Burn10=NULL
Burn11=NULL
Burn12=NULL
Burn13=NULL
Burn14=NULL
Burn15=NULL
UseTribute=0
[Pull]
PullWith=Melee
MaxRadius=350
MaxZRange=50
PullWait=5
PullRoleToggle=0
ChainPull=0
ChainPullHP=90
ChainPullPause=30|2
PullLevel=0|0
[AFKTools]
AFKHelp=AFKGMAction=0 Off, 1 Pause Macro, 2 End Macro, 3 Unload MQ2, 4 Quit Game
AFKToolsOn=0
AFKGMAction=1
AFKPCRadius=150
CampOnDeath=0
ClickBacktoCamp=0
[Merc]
Help=To use: Turn off Auto Assist in Manage Mercenary Window
MercOn=0
MercAssistAt=92

 

[eqmule]

I can explain this one:
Funny enough, this bug (in kiss) is due to a bugfix in mq2 core...
So you have this code in mq2:

case Book:
		if (ISINDEX())
		{
			if (PCHARINFO2 pChar2 = GetCharInfo2()) {
				if (ISNUMBER())
				{
					// numeric
					int nSpell = GETNUMBER() - 1;
					if (nSpell < 0)
						nSpell = 0;
					if (nSpell < NUM_BOOK_SLOTS)
						if (Dest.Ptr = GetSpellByID(pChar2->SpellBook[nSpell]))
						{
							Dest.Type = pSpellType;
							return true;
						}
				}

and before the fix it didn't check if

if (nSpell < 0)

and if it was less than 0 it wouldn't set it to 0, it would just go on and check

pChar2->SpellBook[-1]))

well the result of that check would be NULL and kiss would not get a result, HOWEVER since its really bad to do

pChar2->SpellBook[-1]))

on an array, since all arrays start at 0... I fixed that in the source so now if nSpell is less than 0 it sets it to 0...
That means that doing a ${Me.Book[-1]} will actually do a ${Me.Book[0]} and in your case that will return the spell Minor Healing which must by logic mean is the first spell in your spellbook...

Ok so I uhm don't know if I should try to be backward compatible and just return false if nSpell is less than 0 in which case kiss will work again, or if I should just stick to the bugfix and macro writers (which relied on a buggy core for years) should be forced to update their macros, in this specific case a

/if (${1stPart.Equal[0]}) /goto :SkipBuff

would probably be the right thing to do in the macro above the line that errors out:

/if (${Me.Book[${1stPart}]}) {

since

${1stPart}

clearly IS 0

mkay? I'm going to have to discuss this with macro authors.

 

[Wink-]

It's never too late to do the right thing! I manage a crappy VB app at work that our system is built on and when I make breaking upgrades, I make it squawk at them in the first update and then give a little time before I put out the hammer patch.

 

[eqmule]

yeah I have done that too with some stuff I was sure going to affect users, like there is code in mq2 that spits out "Someone didn't read changes.txt, fix ur macro" and so on, but this time it wasn't as clearcut, anyway expect an update to this during the day, we have decided on a fix that's backwards compatible for macros as well as actually not corrupting the stack in core even if a tlo is being misused.

 

[ctaylor22]

/if (${1stPart.Equal[0]}) /goto :SkipBuff

would probably be the right thing to do in the macro above the line that errors out:

/if (${Me.Book[${1stPart}]}) {

since

${1stPart}

clearly IS 0

mkay? I'm going to have to discuss this with macro authors.

The /if needs to be

/if (${1stPart.Equal[null]})  /goto :SkipBuff

The value read from the ini file is null by default, and null in MQ does not equal 0.

 

[Maskoi]

This is a core MQ2 Error. It is fixed and a new release will be uploaded soon.

DON"T EDIT KISS.