Thanks for the investigation.
It does indeed seem that we need more fit for purpose functions and actually sync with the core on functions that may not have existed when the mod was ported over, or were not in the original core

Yeah there are a ton of core functions that could be used directly. I don't think Playerbots has any function that is limited to a creature search, and there are several in the core. I think the best general function for a creature grid search is GetCreatureListWithEntryInGrid(), which has overrides for a single entry or multiple entries. There is also GetCreaturesWithEntryInRange(), but I'm not sure why it exists as it appears to be the exact same in function.

To get a single creature directly, there is FindNearestCreature(), but that one doesn't work for trigger NPCs because it has a check for the creature being in the same phase as the searcher.

There are various other searches for GOs, dead creatures, etc. And of course, it's not hard at all for Playerbots to make its own search functions based on the filters and searchers in the Core.

I asked Claude to search core functions for searching and here is what I got.

AzerothCore Entity Search Functions

Templated Searcher Classes — GridNotifiers.h

Generic World Object Searchers

GameObject Searchers

Unit / Creature Searchers

Player Searchers

Checker / Predicate Classes — GridNotifiers.h

Hostile Unit Checks

Friendly Unit Checks

HP / Healing Target Checks

Generic Unit / AOE Checks

Creature Assist Checks

Player Checks

Dead Unit Checks

GameObject / Node Checks

Mining nodes, herb nodes, and fishing holes are all GameObjects.
Use NearestGameObjectFishingHole for fishing.
Use NearestGameObjectEntryInObjectRangeCheck / NearestGameObjectTypeInObjectRangeCheck for mining and herbalism.

Utility Checks

WorldObject Convenience Functions — Object.h

Cell / Grid Visit Functions — CellImpl.h

Map GUID-Based Lookup — Map.h

ObjectAccessor Global Lookups — ObjectAccessor.h

How They Compose

// Typical pattern:
Cell::Visit(cell_coord, Searcher(result, Checker(source, range)), radius);

High-level helpers like FindNearestCreature and SelectNearestPlayer internally
build a *LastSearcher + appropriate checker and call Cell::Visit for you.

Claude identified opportunities for replacement. (Note Im not endorsing any of these, just lazily applying the search capabilities of LLM to this topic.)

Replacement Opportunities

1. NearestCorpsesValue — Custom Dead-Unit Checker

Current: Defines its own AnyDeadUnitInObjectRangeCheck locally in the .cpp file.

// CURRENT (custom, defined inline)
class AnyDeadUnitInObjectRangeCheck {
    bool operator()(Unit* u) { return !u->IsAlive(); }
};

Replacement: Core already provides AnyDeadUnitObjectInRangeCheck (GridNotifiers.h:~605)
and AnyDeadUnitSpellTargetInRangeCheck (GridNotifiers.h:~618). Drop the custom class and use those directly.

2. NearestGameObjects — Custom GameObject Checker

Current: Defines its own AnyGameObjectInObjectRangeCheck locally, manually checking
isSpawned() and GetGOInfo().

// CURRENT (custom, defined inline)
class AnyGameObjectInObjectRangeCheck {
    bool operator()(GameObject* u) {
        if (u && i_obj->IsWithinDistInMap(u, i_range) && u->isSpawned() && u->GetGOInfo())
            return true;
        return false;
    }
};

Replacement: Core provides GameObjectInRangeCheck (~1599) and NearestGameObjectCheck (~693).
For node-specific searches use:

• Mining / Herbalism → NearestGameObjectEntryInObjectRangeCheck (~715)
• Fishing holes → NearestGameObjectFishingHole (~672)

The isSpawned() + GetGOInfo() checks are redundant — core checkers already handle them.

3. "nearest hostile npcs" — Flat List + Manual Sort

Current: Uses AnyUnfriendlyUnitInObjectRangeCheck to collect a flat list, then sorts manually
to find the closest.

Replacement: For single-nearest-hostile queries, use NearestHostileUnitCheck (~1185) with
UnitLastSearcher — it auto-narrows the range as it finds candidates, returning only the closest
without building a full list.

4. "nearest adds" — Broad Scan + AcceptUnit Filter

Current: Uses AnyUnitInObjectRangeCheck (all units) then filters in AcceptUnit() to exclude
the current target.

Replacement: AnyUnfriendlyAttackableVisibleUnitInObjectRangeCheck (~945) narrows the scan to
only visible, attackable enemies. NearestAttackableNoTotemUnitInObjectRangeCheck (~895) additionally
excludes totems and includes a built-in LOS check.

5. "party member without aura" — Manual Group Walk

Current: Iterates group references manually, checking each member's aura set.

Replacement: Core's FriendlyMissingBuffInRange (~826) is an exact match — finds any friendly
unit in range missing a specific buff. Drive it with UnitListSearcher instead of custom group walking.

6. "party member to heal" — Manual Group Walk + HP Compare

Current: Iterates group references and manually compares HP to find the lowest.

Replacement: Core's MostHPMissingInRange (~765) and MostHPMissingGroupInRange (~1508) already
solve this. Use UnitSearcher + MostHPMissingGroupInRange and drop the custom logic.

7. "party member to resurrect" — Manual Group Walk for Dead Members

Current: Iterates group references and checks !IsAlive().

Replacement: AnyDeadUnitSpellTargetInRangeCheck (~618) finds dead units valid for resurrection
spells. Use UnitSearcher to get the first eligible target.

8. "possible rpg targets" — Broad Scan + NPC Flag Filter

Current: Runs a broad AnyUnitInObjectRangeCheck over the full sight range, then post-filters
by UNIT_NPC_FLAG_* in AcceptUnit().

Replacement: Where NPC entries are known (e.g., specific innkeeper/flightmaster entry IDs),
NearestCreatureEntryWithLiveStateInObjectRangeCheck (~1322) or AllCreaturesOfEntryInRange (~1472)
can scope the grid search to exact entries, avoiding the broad scan entirely.

Replacement Summary