Problem - Kissassist_info not pulling nameds

[pascualito]

What im doing wrong? Im using Kissassist 12 CAN YOU HELP ME for some reason when i use kissassist_info, my puller is pulling all mobs i write on the line, but not the named....
i tried in other camps and also on Cobalt Scar Zone, still no lucky. If i want named be pulled i need type NULL in line "MobsToPULL"
Thanks in advance :-)
-------------------------------------------
[The Western Wastes]
MezImmune=List up to 10 mobs. Use full names i.e. a green snake,a blue tiger,a wide eye ooze or NULL
MobsToPull=a brood hatchling,Pastletlith the Temperate,a brood caretaker,a brood assitant
;an exiled efreeti,Blasphemous Steel
;Bliddlethliclaus,an exiled kedge,bliddlethliclaus
MobsToIgnore=List up to 25 mobs. Use full names i.e. a green snake,a blue tiger,a wide eye ooze or NULL
MobsToBurn=Bliddlethliclaus
PullPath=Place holder for path file. Not yet impletmented.
PullLocsHelp=Y,X|Range. Ignore mobs in this area
PullLocs1=0
PullLocs2=0
PullLocs3=0
PullLocs4=0
PullLocs5=0
---------------------------

 

[Hylander]

What are your pull levels in ka12 ini ?

A brood assistant. (Spelling error)

 

[pascualito]

Sorry for the spelling mistake, the same happens in other camps with other nameds
Heres my PUll settings

[Pull]
PullTwistOn=1
PullWith=Sonic Disturbance
PullMeleeStick=0
MaxRadius=550
MaxZRange=100
UseWayPointZ=0
PullWait=15
ChainPull=0
ChainPullHP=25
PullPause=90|1
PullLevel=0|200
PullArcWidth=360
PullRadiusToUse=100
PullRoleToggle=1
PullOnReturn=0

This one fails too...

MobsToPull=an exiled efreeti,Blasphemous Steel
Thanks again for your time)

 

[Cannonballdex]

If anyone sees this in the future, the solution is to add a # to the beginning of the named in your ka_info ini. Thanks @ctaylor22 for the solution.

 

[ctaylor22]

Should be:
MobsToPull=an exiled efreeti,#Blasphemous Steel

 

[pascualito]

Thanks !!!for help

 

[B_I_G__D_A_D_D_Y]

Should be:
MobsToPull=an exiled efreeti,#Blasphemous Steel

I see from the post Question - - Using KA.info to Pull, but Won’t Pull Nameds | RedGuides: EverQuest Multi-boxing Community that this new requirement to add a "#" symbol is due to "Looks like there is an issue in MQ2 with exact spawnsearch using names that is causing this issue."

Is this a bug that will be fixed soon? Or a new requirement going forward? I know I would never think guess in a million years that I needed to prefix a mob's name with a pound symbol...

 

[ctaylor22]

From what I found out from talking to the MQ2 devs, that when doing an exact match spawn search lookup, you have always had to include the # symbol if the mobs display name has the # symbol in the name. I also thought that # symbol was not needed, but I was proven to be wrong. In the past I never used the # symbol before, and things worked. So I am not sure what changed, but from this point on everyone should start including the # symbol if the Mob has the symbol in it's name.

I will add this. When using the MobsToPull entry, the spawnsearch uses exact match by default, so if you wanted NOT to use exact match, then you could use an * at the end of the names Like:
MobsToPull=an exiled*,#Blasphemous Steel
or
MobsToPull=an exiled efreeti,Blasphemous Steel*

The first option will find mobs with "an exiled" in the name and any mob that names exactly matches #Blasphemous Steel.
The second option will find mobs who name exactly matches "an exiled efreeti" and any mobs with "Blasphemous Steel" in the name.

 

[pascualito]

Im sorry but not work... with #, i will check again using * and i will report

 

[Cannonballdex]

Personally I would like to see more things tested before pushed to live. If something isn't broke don't mess with it. If it is broke fix it. If you broke something that was working then go back and start over again. One minor change in a recent update is causing several problems across the board.

From Braniac on 5/22/2021

I mentioned in the chat but somebody should look at reverting this change that was introduced in the last patch
https://github.com/macroquest/macro...e922024715f9006e513d90d9aeda789a6c36b56eR3488

 

[pascualito]

I tried Booth and not worked :

Western Wastes - CoV

MobsToPull=an exiled kedge,Bliddlethliclaus*
either
MobsToPull=an exiled kedge,#Bliddlethliclaus

Normal mobs are been pulled but not named...

I can check anything u want...

 

[B_I_G__D_A_D_D_Y]

MobsToPull=an exiled kedge,Bliddlethliclaus*
either
MobsToPull=an exiled kedge,#Bliddlethliclaus

You probably already know this but as a temporary solution move your camp right into the middle of a pile of placeholders and adjust your pull radius to mostly only pull placeholders. Adjust the kissassist_info.ini file to pull ALL. It should eventually clear the area and if a named pops it will eventually pull it as well. It's not very elegant but I've had it work this way in the past.

 

[wymranar]

I was having the same problem earlier and created a post about it. The one that @B_I_G__D_A_D_D_Y referenced above. @ctaylor22 started helping me with the issue, but I still was having trouble pulling blasphemous steel in WW.

Eventually, this is what I had to do....


I did get everything to work, but I had to run a custom version of KA that @ctaylor22 sent me and set my mobs to pull up like this,

MobsToPull=an exiled efreeti*,Blosphemous Steel,Blasphemous Ste,lasphemous Steel,Blasfemous Steel,Blasphemous Sdeel,Blasphemous Steel*




I feel like I tried everything, but this was the only thing that would work in the end. I believe I’ve only ever run into this problem with that specific named. He does have a # in front of his name, for the record

 

[AmericanNero]

I had noticed this as well, but I was working on group survival routines within KA which hopefully will see the light of day.

Within Sub PullValidate, this code does the MobsToPull comparison. I hand checked a couple named mobs and the spawn search worked. If you insert a *, it uses Find rather than Equal.

Find returns a 1, whereas Equal returns TRUE. Both are valid responses, and are treated properly in the /if condition. Don't try to use #, it won't work.

[CODE lang="ini" title="PullValidate snippet"] /if (${MobsToPull.NotEqual[all]}) {
/for j 1 to 25
/if (!${MobsToPull.Arg[${j},,].Length}) /break
/varset mobCheck ${MobsToPull.Arg[${j},,]}
DEBUGPULL PullValidate: PFlag: ${PFlag} ${j} ${PVPullMob} PullList ${Spawn[id ${PVPullMob}].CleanName}/${MobsToPull.Arg[${j},,]} ${Spawn[id ${PVPullMob}].CleanName.Equal[${MobsToPull.Arg[${j},,]}]}
/if (${mobCheck.Find[*]}) {
/varset mobCheck ${mobCheck.Replace[*,]}
/if (${Spawn[id ${PVPullMob}].CleanName.Find[${mobCheck}]}) {
/varset skipFlag 1
}
} else {
/if (${Spawn[id ${PVPullMob}].CleanName.Equal[${mobCheck}]}) {
/varset skipFlag 1
}
}
/if (${skipFlag}) /break
/next j
/if (!${skipFlag}) {
DEBUGPULL PullValidate ${Spawn[id ${PVPullMob}].CleanName} NOT on MobsToPull List
/return 0
}
}
[/CODE]

 

[ctaylor22]

@AmericanNero,

Go look at the AlertAddToList routine. That is where the alert list is built for what mobs to search for. That code you listed most likely needs to be changed as well.

 

[ctaylor22]

I think this would fix the PullValidate issue:

        /if (${MobsToPull.NotEqual[all]}) {
            /for j 1 to 25
                /if (!${MobsToPull.Arg[${j},,].Length}) /break
                /varset mobCheck ${MobsToPull.Arg[${j},,]}
                DEBUGPULL PullValidate: PFlag: ${PFlag} ${j} ${PVPullMob} PullList ${Spawn[id ${PVPullMob}].CleanName}/${MobsToPull.Arg[${j},,]} ${Spawn[id ${PVPullMob}].CleanName.Equal[${MobsToPull.Arg[${j},,]}]}
                /if (${mobCheck.Find[*]}) {
                    /varset mobCheck ${mobCheck.Replace[*,]}
                    /if (${Spawn[id ${PVPullMob}].CleanName.Find[${mobCheck}]}) /varset skipFlag 1
                } else {
                    /if (${mobCheck.Find[#]}) /varset mobCheck ${mobCheck.Replace[#,]}
                    /if (${Spawn[id ${PVPullMob}].CleanName.Equal[${mobCheck}]}) /varset skipFlag 1
                }
                /if (${skipFlag}) /break
            /next j
            /if (!${skipFlag}) {
                DEBUGPULL PullValidate ${Spawn[id ${PVPullMob}].CleanName} NOT on MobsToPull List
                /return 0
            }
        }

 

[AmericanNero]

More thinking needed...something else is also not working! Yeah I derped, because you *have* to use cleanname to match because mob names look like an_orc12.

 

[Coldblooded]

That is a beautiful writeup Nero - nice debugging.

 

[AmericanNero]

In an earlier post I thought I had found a solution, but on further testing found more problems. A small detail...the list we have things like: a goblin corpsenibbler,Fatso the Orc, but the real names are like "a_goblin_corpsenibbler10" or "#Fatso_the_Orc15" We use cleanname to strip out everything, but it doesn't solve the alert list problem. I discuss below.

To make MobsToPull work right, we should move away from the alert list, or rework how name matches are made.

-------------------

Sordid details.

The issue has three components.

1) Sub AlertAddToList

When KA is started, this is called within the Pull ini. If there is a MobsToPull list, it populates list alert 2. If any mobs included *, then the search is more loose, and does not require an exact match. E.g. if MobsToPull=a goblin corpsenibbler,goblin*,*goblin,*goblin*,#goblin,Fatso the Orc then the alert list would look like:
=a goblin corpsenibbler
goblin
goblin
goblin
=#goblin
Fatso the Orc

2) Sub FindMobToPull calls Sub FindMobNAV

Spawnsearch should get matches on all, provided the user typed names in correctly...if there really was a #goblin, BUT! Fatso the Orc, because its dirty name is #Fatso the Orc will not be found. Ok, easy enough... let's adjust the list so we add # and reload.

=#Fatso the Orc

Fatso pops. We see him with our beady little lootwhore eyes. The puller should pick it up on spawnsearch, then validate, and if its the nearest mob, pull it.

Sub PullValidate

PullValidate is called from FindMobNav, even though the search itself is limited to those very mobs. But it should work out...

Any of the mobs that had * will be compared using Find. Remember that we put #Fatso the Orc on the list this time. But the search uses .CleanName. Whoopsydoodles... Fatso the Orc != #Fatso the Orc. If we use .Name instead it works, but only IF you remembered to put # in front, which requires you edit your lists of mobstopull.

We are damned if we do and damned if we don't.

 

[AmericanNero]

Fixes: Find and replace two code segments. First, the following in PullValidate. Notice we are stripping out * and # and all comparisons are made using Find.

[CODE lang="ini" title="Sub PullValidate replacement code"]| ----------------------------------------------------------------------------
| SUB: PullValidate
| ----------------------------------------------------------------------------
Sub PullValidate(PVPullMob, int PFlag)
/declare j int local
/declare skipFlag int local 0
/declare mobCheck string local
/if (${MobsToPull.NotEqual[all]}) {
/for j 1 to 25
/if (!${MobsToPull.Arg[${j},,].Length}) /break
/varset mobCheck ${MobsToPull.Arg[${j},,]}
DEBUGPULL PullValidate: PFlag: ${PFlag} ${j} ${PVPullMob} PullList ${Spawn[id ${PVPullMob}].CleanName}/${MobsToPull.Arg[${j},,]} ${Spawn[id ${PVPullMob}].CleanName.Equal[${MobsToPull.Arg[${j},,]}]}
/varset mobCheck ${mobCheck.Replace[*,]}
/varset mobCheck ${mobCheck.Replace[#,]}
/if (${Spawn[id ${PVPullMob}].CleanName.Find[${mobCheck}]}) {
DEBUGPULL PullValidate Mob found: ${Spawn[id ${PVPullMob}].CleanName} ${Spawn[id ${PVPullMob}].CleanName.Find[${mobCheck}]}
/varset skipFlag 1
/break
}
/next j
/if (!${skipFlag}) {
DEBUGPULL PullValidate ${Spawn[id ${PVPullMob}].CleanName} NOT on MobsToPull List
/return 0
}
}
[/CODE]

Secondly in Sub AlertAddToList, we are populating alert 2 list, stripping out * and # again, and *not* using = which indicates exact match.

[CODE lang="ini" title="Sub AddToAlertList replacement code"]
| -------------------------------------------------------------------------------------s
| SUB: Add stuff to alert list
| -------------------------------------------------------------------------------------
Sub AlertAddToList(int whatlist, MvarList, IDvarList)
DEBUGN AlertAddToList List:${whatlist} Mlist: ${MvarList}
/declare k int local
/declare CleanMobName string local
| Clear ignore mobs alert from list before assigning from ini list
/squelch /alert clear ${whatlist}
/if (${MvarList.Length} && !${MvarList.Find[null]}) {
/for k 1 to 25
/if (${MvarList.Arg[${k},,].Length} && !${MvarList.Find[null]} && ${Debug}) /echo \atDEBUG ADD ${MvarList.Arg[${k},,]} to ${MvarList}
/if (${MvarList.Arg[${k},,].Length}) {
/varset CleanMobName ${MvarList.Arg[${k},,].Replace[*,]}
/varset CleanMobName ${MvarList.Arg[${k},,].Replace[#,]}
/squelch /alert add ${whatlist} "${CleanMobName}"
DEBUGN AlertAddToList Add ${CleanMobName} to Alert List ${whatlist}
}
/next k
}
[/CODE]

 

[pascualito]

This worked "TESTED"
[The Western Wastes]
MobsToPull=an exiled efreeti,Blasphemous_Steel,Blasphemous Steel,blas*

 

[Nedus]

You also should check what your max lvl pull is set to

 

[pascualito]

as a Bard
[Pull]
PullTwistOn=1
PullWith=Sonic Disturbance
PullMeleeStick=0
MaxRadius=1450
MaxZRange=200
UseWayPointZ=0
PullWait=15
ChainPull=0
ChainPullHP=25
PullPause=90|1
PullLevel=0|200
PullArcWidth=360
PullRadiusToUse=100
PullRoleToggle=1
PullOnReturn=0

 

[ctaylor22]

There are some zones that have mobs where you have to use the exact names match if you don't want to pull social mobs. Been a while so I can't remember specifics. If you drop using the exact match ability in the alert list, you may fix the immediate issue, but you will break alert list 3(MobsToIgnore).

 

[B_I_G__D_A_D_D_Y]

There are some zones that have mobs where you have to use the exact names match if you don't want to pull social mobs. Been a while so I can't remember specifics. If you drop using the exact match ability in the alert list, you may fix the immediate issue, but you will break alert list 3(MobsToIgnore).

Nothing is ever easy is it?!?!?

 

[AmericanNero]

Copy and paste the code, above, and your problem is over.

 

[AmericanNero]

It would be very helpful to know more detail about which zone(s) you need exact match for. I think the usefulness of the fix I provided, since it affects the entire game, probably outweighs that circumstance.