KissAssist Release KissAssist 12.002.039

[Tiger]

Can someone help me out please? I have my toons succesfully asking for a mod rod. My mage correctly gives them one and also correctly gives himself one. The problem I have is my mage spams modrod spell on himself. This is the mage ini, he's level 62.

Buffs4=rod of mystical transvergence|alias|modrod
Buffs5=rod of mystical transvergence|summon|rod of mystical transvergence|1
Buffs6=rod of mystical transvergence|mana|80|50

Because the item name and spell name are the same, I assume what's happening is when he's under 80% mana he is casting the spell on himself, not clicking the rod. Can I use item ID instead of name to differentiate between the spell and item?

 

[Mikey02]

Do we replace alias with character names?

 

[toadwart]

Not sure what you're asking Mikey, could you be more specific please?

 

[freeferli]

One thing I was curious about, could we have something like a default ini file?

For instance, I most of the general section to be the same across my entire camp.
Maybe several defaults like

KissAssist_default.ini
KissAssist_cleric_default.ini

 

[taz6two]

Just wanted to say that KA12 is working wonderfully thus far for my Bard. I have him set as Puller and he is twisting, pulling and returning to group as expected.

 

[Tiger]

Is this me being thick? My mage will not summon and give pet toys correctly.

[Pet]
PetOn=1
PetSpell=servant of marr
PetFocus=NULL
PetShrinkOn=0
PetShrinkSpell=Tiny Companion
PetBuffsOn=0
PetBuffsSize=8
PetBuffs1=NULL
PetBuffs2=NULL
PetBuffs3=NULL
PetBuffs4=NULL
PetBuffs5=NULL
PetBuffs6=NULL
PetBuffs7=NULL
PetBuffs8=NULL
PetCombatOn=1
PetAssistAt=95
PetAttackDistance=115
PetToysSize=6
PetToysOn=1
PetToys1=fist of ixiblat|summoned: hand of ixiblat|summoned: hand of ixiblat
PetToys2=muzzle of mardu|summoned: muzzle of mardu
PetToys3=girdle of magi'kot|summoned: girdle of magi'kot
PetToys4=NULL
PetToys5=NULL
PetToys6=NULL
PetToysGave=Vonanab|fist of ixiblat:summoned: Hand of Ixiblat1|muzzle of mardu:summoned: muzzle of mardu2
PetBreakMezSpell=NULL
PetRampPullWait=0
PetSuspend=0
MoveWhenHit=0
PetHoldOn=1
PetForceHealOnMed=0

He gives just one fist and a muzzle. He does the same if I ask for toys on another character.

 

[eqtrader74]

I doubt that's KA12 specific on the pet toys. KA's multiline pet toys thing was more for when you summon a bag of weapons at higher levels. Also that belt spell is a ` instead of ' sign.

PetToys1=fist of ixiblat|summoned: hand of ixiblat
PetToys2=fist of ixiblat|summoned: hand of ixiblat
PetToys3=muzzle of mardu|summoned: muzzle of mardu
PetToys4=girdle of magi`kot|summoned: girdle of magi`kot

 

[Tiger]

I doubt that's KA12 specific on the pet toys. KA's multiline pet toys thing was more for when you summon a bag of weapons at higher levels. Also that belt spell is a ` instead of ' sign.

PetToys1=fist of ixiblat|summoned: hand of ixiblat
PetToys2=fist of ixiblat|summoned: hand of ixiblat
PetToys3=muzzle of mardu|summoned: muzzle of mardu
PetToys4=girdle of magi`kot|summoned: girdle of magi`kot

Brilliant, thanks a lot Working now.

 

[toadwart]

freeferli that's been asked before, but you cannot have a default ini for all levels, that's why the ini library exists. If you're talking two ini's it might be possible to do, with a significant amount of additional coding. But most people do not want all of those settings exactly the same for a variety of reasons. If you want them similar then you can create an ini that's blank entries for everything (I actually created one in the library, though I'll need to update it now) and use that as a template for all of your characters, and only change the spells/abilities for the characters thereafter.

 

[freeferli]

@toadwart ahh, ok

 

[ctaylor22]

Are there conditions on rezzing? Mostly so that I can only divine rez my tank.

Yes, you can. The condition is checked when verifying if what you are trying to rez with is ready or not. There are specific things you have to check.

RWCWho - Can be one of the following: status, ma, me, group, xtarget, rezall
RezType - Can be: rez, rezooc, rezcombat

For your divine rez just make sure you have RWCWho.Equal[ma] in the condition

Don't use Target in the rez conditions it won't work.

 

[ctaylor22]

Do we replace alias with character names?

No. The alias is used to assign one of the following to the buff entry:
Valid Item Aliases: modrod,modrodp,modrods,icenuke
Valid Spell Aliases: Symbol,Aego,Focus,Regen,Haste,Skin,clarity,Brells


What will happen is the character asking/begging for an item or buff will use one of the above aliases in their message. The caster will then check their buffs for a matching alias and if they find a match they will cast it.

 

[Mikey02]

Not sure what you're asking Mikey, could you be more specific please?

was looking at the lines below. Do we need to replace alias with our character name?

oops Ctaylor answered it

Buffs1=Wand of Pelagic Transvergence|begfor|1|alias|modrodp
Buffs2=Summoned: Small Modulation Shard|begfor|1|alias|modrods

 

[toadwart]

CTaylor may have to weigh in here. It looks to me like the last two entries are just flags so that KA knows how to handle it. The word "alias" is there as a flag to let KA know that the next word after the following pipe is the flag it needs to act upon. In order to differentiate between a spell vs an item.

I've not used that new piece of functionality yet, as I've not grouped with my mages in awhile, but I need to play with it a bit myself. But CTaylor has your answer, right above your question, and we both missed it.

 

[Cannonballdex]

Just curious about this, just tried the kissassist 12 on my mage.

MQ2 I have no pet. Magicians live longer when we hve pet.
Exchange: NULL slot not found
kissassist.mac@4300 (DoPetStuff): /exchange "${FocusPet}" ${FocusSlot}
kissassist.mac@10627 (WaitSubs): /if (${PetOn}) /call DoPetStuff
kissassist.mac@3298 (DoWeMed): /call WaitSubs
kissassist.mac@578 (Main): /if (${MedOn}) /call DoWeMed
kissassist.mac@4362 (DoPetStuff): /exchange "${FocusCurrent}" ${FocusSlot}
MQ2 ARISE Embodiment of Earth
MQ2 My pet is now: Jone from Embodiment of Earth
Exchange: NULL Slot not found

and then loops the errors again.

Happens when I list my earring as a Focus Item.

 

[ctaylor22]

@cannonballdex Do you have the slot name as part of the PetFocus entry? PetFocus=Bonespike Earring|rightear.

 

[Cannonballdex]

@cannonballdex Do you have the slot name as part of the PetFocus entry? PetFocus=Bonespike Earring|rightear.

No I didn't. Never did that before and never noticed the error. Will try this. thanks.

 

[B_I_G__D_A_D_D_Y]

Edited to Add that my hot key casts group invis and group ivu, not single target.

I am experiencing some odd behavior when the macro is running and I Invis my chars. If the characters are invis already when the macro starts I don't think there's a problem, it's only when I cast invis while the macro is running.

I'm running v12.001 dated 2/26.

If I use a hotkey to invis my characters the puller will stop pulling. If I click off the invis he will start pulling again. But my casters will no longer assist until I manually click off their invis too. In some cases they won't even assist then and I have to /end and restart the macro. It weirdly affected a mage and enchanter the most while not affecting my priest classes who do healing.

I wanted to double invis my bard so he could run around and pick up collectibles while the rest of the group was at a camp and killing. So I paused the macro on the bard and hit my key to double invis. Only later did I realize that the mage and chanter were no longer casting. I then ran some experiments and found this appeared to be consistent behavior. It's like the Invis check is locking out the pulling and the combat sections but not the healing. The puller is actually started in PullerTank mode and the other chars are all in Assist mode.

 

[foromoro]

I cant see if this has been answered, but can we just change the .ini to reflect version 12 of KA and go from there? Or do we need to craft a new ini with a new format?

 

[vsab]

I just ran the new KA and it updated the version number in the ini automatically. This release seems to gave been a major internal upgrade and not broken anything from KA 11

 

[Cannonballdex]

My fellowship campfire fails to place giving a message that I do not have enough members when I do. If I place the campfire manually it works. Never had an issue before with campfire placing. Is this something I can fix?

using line 10679
/if (${SpawnCount[pc radius 50 fellowship]}>=0) {
/call Bind_Campfire
as a workaround. obviously the check for fellowship members is not calculating correctly.

 

[toadwart]

@foromoro just run the new ka12 with your existing ini, no other direct change is needed. if you want to make use of some of the new functionality you'll have to look at the first posting and try to integrate those changes, but the under the hood changes should be automatic and will run with your existing ini.

 

[B_I_G__D_A_D_D_Y]

This is sort of a "wish list" thing. I know it's the math of the camp radius but I really dislike how my MT always runs out to meet an incoming mob, even one I've just pulled. I'd like to see my MT just stand there until the mob gets very close to me and then take that 1 step toward the mob to ensure he's in melee range. I know from a code standpoint it would get messy because I think you'd have to measure the movement rate and direction of the mob in relation to the existing camp. Now I just manually keep pulling the tank back and he sorta rubber bands until I have the mob in the position I want.

 

[Cannonballdex]

From another post, not sure if this helps your situation.

n Most all cases CampRadius should be smaller than MeleeDistance. MeleeDistance was created to give your Tank/PullerTank a buffer to engage a mob before it entered CampRadius. When setting up your camp, all characters should be within CampRadius of the Tank/PullerTank and the Tanks MeleeDistance should be large enough to activate /attack before the mob gets to Camp.

I set my CampRadius=35 and my MeleeDistance=75.

 

[B_I_G__D_A_D_D_Y]

From another post, not sure if this helps your situation.

I have really hesitated to mess with those numbers since I've read so many threads where groups wouldn't assist properly. Currently my MT has a MeleeDistance=85 and all my characters have a CampRadius=40. If I'm understanding you correctly and if I want the mob to get "deeper" into my camp before I engage I should change the MeleeDistance down to something like 50?

 

[Cannonballdex]

Correct, but should keep campradius number a little smaller to consolidate the camp a little and be sure that the tank engages first.

 

[B_I_G__D_A_D_D_Y]

Correct, but should keep campradius number a little smaller to consolidate the camp a little and be sure that the tank engages first.

Dropping MeleeDistance down to 50 made a huge improvement! Thanks!

 

[ctaylor22]

This is sort of a "wish list" thing. I know it's the math of the camp radius but I really dislike how my MT always runs out to meet an incoming mob, even one I've just pulled. I'd like to see my MT just stand there until the mob gets very close to me and then take that 1 step toward the mob to ensure he's in melee range. I know from a code standpoint it would get messy because I think you'd have to measure the movement rate and direction of the mob in relation to the existing camp. Now I just manually keep pulling the tank back and he sorta rubber bands until I have the mob in the position I want.

The biggest problem here is when you walk away from the PC to refresh that cup of coffee you just consumed, and you come back and half your group is dead. The reason the tank takes off after the mob is that there is NO guarantee the mob will always approach the camp from the same direction. If we wait until the mob is in Mobs MaxMelee radius + 1 before engaging the mob, then what do we do when the mob is detoured to your cleric/healer and the mob never comes closer than MaxMelee radius + 2?

You can get it close, to what you want, if you stand all your characters on top of each other and then start your tank standing just a hands width in front of the group. You should be positioned so you will be between the incoming mobs and the group. Now set your MeleeRadius so it includes everyone in group from where you start kiss. Make sure your campradius is always smaller than your melee radius so adjust accordingly. I normally target one of the mobs and use /echo ${Target.MaxRange} I then add like 10 to that number Then I add that to the radius I need to encompass the group, from my camp location. So if MaxRange = 12 and 15 radius to cover the group plus 10 pad . I would start with a Meleedistance of 37(12+15+10), then set my campradius to 25 or 30.

 

[surfdog21]

The biggest problem here is when you walk away from the PC to refresh that cup of coffee you just consumed, and you come back and half your group is dead.

You forgot to add the "God Dammit" part as you set your fresh coffee down lol!

 

[darkeros]

My fellowship campfire fails to place giving a message that I do not have enough members when I do. If I place the campfire manually it works. Never had an issue before with campfire placing. Is this something I can fix?

using line 10679
/if (${SpawnCount[pc radius 50 fellowship]}>=0) {
/call Bind_Campfire
as a workaround. obviously the check for fellowship members is not calculating correctly.

Same issue here, but with ver 11.005. Started after latest test patch.

 

[Cannonballdex]

The biggest problem here is when you walk away from the PC to refresh that cup of coffee you just consumed, and you come back and half your group is dead. The reason the tank takes off after the mob is that there is NO guarantee the mob will always approach the camp from the same direction. If we wait until the mob is in Mobs MaxMelee radius + 1 before engaging the mob, then what do we do when the mob is detoured to your cleric/healer and the mob never comes closer than MaxMelee radius + 2?

You can get it close, to what you want, if you stand all your characters on top of each other and then start your tank standing just a hands width in front of the group. You should be positioned so you will be between the incoming mobs and the group. Now set your MeleeRadius so it includes everyone in group from where you start kiss. Make sure your campradius is always smaller than your melee radius so adjust accordingly. I normally target one of the mobs and use /echo ${Target.MaxRange} I then add like 10 to that number Then I add that to the radius I need to encompass the group, from my camp location. So if MaxRange = 12 and 15 radius to cover the group plus 10 pad . I would start with a Meleedistance of 37(12+15+10), then set my campradius to 25 or 30.

Good stuff. I also like to /bca //camphere 1
While all my toons are buched up in my small radius, so they return back to camp after the mob dies. Otherwise they can end up all over the place.

 

[freeferli]

My spells is being removed from my ini file, the notes said that would happen, but then the log says that I should write spells to add them back. So I am confused if myspells is supposed to be in the ini now.

 

[ctaylor22]

My spells is being removed from my ini file, the notes said that would happen, but then the log says that I should write spells to add them back. So I am confused if myspells is supposed to be in the ini now.

Look at the bottom of the ini file. you will see the new [Spells] section at the bottom.

 

[Dragonslayer]

new Error Message since last MQ2 patch:
This occured already in Kissassist 11. A view minutes ago I swapped to Kissassist 12Beta. The Syntax-Error remains the same.
The Error Message pops up on all chars Identic. I have no own code at no place.
Anyone can give me a Hint what I shall do?

The System works, it just happenend occassionally, that I had to relaunch Kissassist on Bard, as he stopped melody once a while.
As I swapped to 12Beta a view minutes ago, can't report unexpected behavior in 12.

 

[ctaylor22]

Try deleting the KissAssist_Buffs.ini file. It may be corrupted. You would have to have several hundred characters creating entries in the file to exceed the 2048 Max length.

 

[drawthow]

Having a new problem this morning with kiss12 bard is pulling and getting hung up on corpses, will cycle between the tank and the corpse and not pull.

Any suggestions?

 

[darkeros]

CorpseRecovery appears to kick off immediately when someone dies, targets the corpse, tries to cast "Summon Remains" on the corpse until the character runs out of coffins, then quits. Of course this doesn't work because the ability works on a targeted alive character, not a corpse. When the dead character gets back in zone, it doesn't do anything because the summoning character is out of coffins.

Is this designed to only work if the person running CorpseRecovery is the puller and it would only summon their own corpse? Not other members of the group?

 

[Dragonslayer]

Try deleting the KissAssist_Buffs.ini file. It may be corrupted. You would have to have several hundred characters creating entries in the file to exceed the 2048 Max length.

Thank you, that worked well.

 

[ctaylor22]

CorpseRecovery appears to kick off immediately when someone dies, targets the corpse, tries to cast "Summon Remains" on the corpse until the character runs out of coffins, then quits. Of course this doesn't work because the ability works on a targeted alive character, not a corpse. When the dead character gets back in zone, it doesn't do anything because the summoning character is out of coffins.

Is this designed to only work if the person running CorpseRecovery is the puller and it would only summon their own corpse? Not other members of the group?

I checked for several things to make sure I was only summoning either my corpse or someone in my groups corpse, But it looks like I forgot to add the code to check if the group member was in the zone. I will correct that. My bad sorry.

 

[ctaylor22]

Having a new problem this morning with kiss12 bard is pulling and getting hung up on corpses, will cycle between the tank and the corpse and not pull.

Any suggestions?

Not sure why the bard would target the Tank, unless you have a buff to keep up on the tank? The Corpse would be the tanks target most likely. I foy can get me a debug log of that happening it shouldn't be that hard to trace down..