#bot group guard doesnt work when 3 or more ppl in group

[dfusion111]

Bots don't sit still when using this #bot group guard command anymore, but its only when there are 3 or more ppl in the group. No Idea what caused this to change as far as I can tell the command has not changed so it must be somewhere else in the bot code or ai process. Any ideas, or a possible solution or alternate command?

Im using 2260 at the moment, previous versions did not have this problem, think it started somewhere past 2207, but finding the cause has not been easy...

[bad_captain]

I have it on my list to look at, but I've been working on mercs recently. Once mercs are up and running, I should be able to chrck on this, if someone hasn't figured it out yet.

Does it matter if the number of people in the group are clients or bots?

[dfusion111]

Does it matter if the number of people in the group are clients or bots?

First I want to say thanks for checking into this when you have a chance, I'm kinda stumped by this one. And no it doesn't seem to matter, I thought it was when there was at least 2 bots, but some players have told me they only have 1 bot in the group of 3 and it does this. So 3+ members in a group causes it. Oddly, if its just 1 bot, 1 player, the command works great... just that 3rd member+ makes them disobey

[c0ncrete]

what exactly do you see happening?

is everyone in the group using the command for their bots?

[c0ncrete]

the only thing i can see that would be causing an issue is that not all bot owners are using the command, as it currently checks for ownership here:

if(botGroupMember && botGroupMember->GetBotOwnerCharacterID() == client->CharacterID()) {

if you want the group leader to be able to issue the command to all bots in the group, regardless of ownership, you should be able to use this instead:

void Bot::BotGroupOrderGuard(Group* group, Client* client)
{
    if (!client || !group)
        return;

    Mob* leader = group->GetLeader();
    int32   cid = client->CharacterID();

    for (int i = 0; i < MAX_GROUP_MEMBERS; i++)
    {
        if (!group->members[i] || !group->members[i]->IsBot())
            continue;

        Bot*   bot = group->members[i]->CastToBot();
        uint32 oid = bot->GetBotOwnerCharacterID();

        // verify command was issued by bot owner or group leader
        if (cid != oid && client->CastToMob() != leader)
            continue;

        bot->SetFollowID(0);
        bot->WipeHateList();
        bot->Say("Guarding here.");

        if (!bot->HasPet() || !bot->GetPet())
            continue;
        bot->GetPet()->WipeHateList();
    }
}

it looks like the #bot botgroup guard command may have unexpected results when you have a bot-only group whose members are owned by more than one client as well, but that's probably a fairly rare occurrence.

[dfusion111]

Thanks, Ill try this when I get a chance.

[dfusion111]

Unfortunately it didn't work...

The problem is with the cleric bots mainly. Its like the ai ignores the fact they are guarding and moves them into range to cast a healing spell. When the combat ends, they remain in that spot guarding. Its only during combat, but only when 2 bots are in the group. The bot guards fine as long as its the only bot in the group, as far as I can tell, players told me they only had the 1 bot and a couple players and this happened, but I cant repeat that. It seems to work fine as long as its the only bot in the group. As soon as I add a 2nd bot, say a rog, and it becomes engaged in combat, the cleric bot moves into range, ignoring its command to guard. Before it would stay put, not caring if we are out of range dying, only when moved into its casting range would it start healing. I don't think the problem is in the command itself, but in the ai where it is casting a spell and checking the range, moving them into range(and ignoring the guard command) but I cant seem to find it.

[c0ncrete]

oh, ok. that's because there is no check for GetFollowID() in the out of combat part of Bot::AI_Process(). if you want to keep a bot from doing anything at all when told to guard, until given another command, you can add the stuff in red here:

// AI Processing for the Bot object
void Bot::AI_Process() {
    _ZP(Mob_BOT_Process);

    if(!IsAIControlled() || !GetFollowID())
        return;

[c0ncrete]

or... you can add the lines in red here:

// AI Processing for the Bot object
void Bot::AI_Process() {
    _ZP(Mob_BOT_Process);

    if(!IsAIControlled())
        return;

    int8 botClass = GetClass();
    uint8 botLevel = GetLevel();

    if(IsCasting() && (botClass != BARD))
        return;

    // A bot wont start its AI if not grouped
    if(!GetBotOwner() || !IsGrouped()) {
        return;
    }

    if(GetAppearance() == eaDead)
        return;

    Mob* BotOwner = GetBotOwner();

    // The bots need an owner
    if(!BotOwner)
        return;

    try {
        if(BotOwner->CastToClient()->IsDead()) {
            SetTarget(0);
            SetBotOwner(0);
            return;
        }
    }
    catch(...) {
        SetTarget(0);
        SetBotOwner(0);
        return;
    }
    
    if(!GetFollowID()) {
        if(GetArchetype() != ARCHETYPE_MELEE) {
            if (GetManaPercent() < 100)
                BotMeditate(true);
            else
                BotMeditate(false);
        }
        return;
    }

this should cause any bot that isn't pure melee to meditate if they are set to guard and have less than 100% mana. code compiled, but otherwise untested.

[dfusion111]

Well it works, but now they wont heal if your close to them, they simply do nothing like you said. Before they would stay still, but heal you when you got into spell range and your hp was low. Not sure if that's possible, that would be like it was before.

Thanks for the help, making progress at least

[c0ncrete]

you probably want to look at EntityList::Bot_AICheckCloseBeneficialSpells() then. it gets called by Bot::AI_IdleCastCheck() and is passed a float for range (iRange), but it doesn't look like it's checked anywhere before the bot in question is instructed to cast a heal. i'm not sure off the top of my head if that would cause the bot to run into range and heal or not.