EQoffline, bots and more..

**Congdar** · #1 09-28-2008, 11:16 PM

ok, thanks for clearing that up... try this and let me know if it works. Just replace the entire ifdef

Code:

#ifdef EQBOTS

	// EQoffline: Remove the group if the leader is grouped
	Mob *clientmob = CastToMob();
	if(clientmob) {
		int16 cmid = GetID();
		if(clientmob->IsBotRaiding()) {
			BotRaids* br = entity_list.GetBotRaidByMob(clientmob);
			if(br) {
				br->RemoveRaidBots();
				br = NULL;
			}
		}
		if(clientmob->IsGrouped()) {
			Group *g = entity_list.GetGroupByMob(clientmob);
			if(g) {
				bool hasBots = false;
				for(int i=5; i>=0; i--) {
					if(g->members[i] && g->members[i]->IsBot()) {
						hasBots = true;
						g->members[i]->Kill();
					}
				}
				if(hasBots) {
					if(g->BotGroupCount() <= 1) {
						g->DisbandGroup();
					}
				}
			}
		}
		database.CleanBotLeader(cmid);
	}

#endif //EQBOTS

spider661 · #2 09-29-2008, 12:11 AM

ok that worked great.. now the bots leave group and group stays in tact now 1 more problem.. the player that owns the bots invites a player.. spawns bots and zones out and back bots gone group intact. so then i respawn the bots and try to invite them. says only leader can invite bots and kills them. but then i log on another char and try to invite them and it lets me..

so basically what happens is now the bots cant find the leader of the group even though the owner is still the group leader according to the game.

any ideals?

spider661 · #3 09-29-2008, 02:33 AM

i fixed it i just removed the group leader check when inviting bots.. i don't care if anyone in group can invite them leader or not.. and it seems to e working now. but i would still like to see a fix to the problem in case i decide to put leader check back in or if anyone else needs it

Angelox · #4 09-29-2008, 06:59 AM

I fixed a few exploits on mine;
for players who make armies of Bots and invite them as they fight and loose bots;
in command.cpp around line 8161;
replace

Code:

	if(!strcasecmp(sep->arg[1], "group") && !strcasecmp(sep->arg[2], "add"))
    {
		if((c->GetTarget() == NULL) || (c->GetTarget() == c) || !c->GetTarget()->IsBot())
        {
            c->Message(15, "You must target a bot!");
			return;
		}

With this;

Code:

	if(!strcasecmp(sep->arg[1], "group") && !strcasecmp(sep->arg[2], "add"))
    {
		if((c->GetTarget() == NULL) || (c->GetTarget() == c) || !c->GetTarget()->IsBot() || (c->IsEngaged())) //Angelox
        {
            c->Message(15, "You must target a bot and can't be engaged!");
			return;
		}

for players who kill players or any mob with the '#bot raid group create';
in command.cpp around line 8645;
replace

Code:

					c->Message(15, "You must have created your raid and your group must be full before doing that!");
				Mob* kmob = c->GetTarget();
				if(kmob != NULL) {
					kmob->Kill();
				}

With

Code:

				c->Message(15, "You must have created your raid and your group must be full before doing that!");
				Mob* kmob = c->GetTarget();
				if(kmob != NULL) {
					kmob->GetTarget();  //Problem? kmob->Kill() was here b4 Angelox
				}

And finally, Since th '#Bot update as it really doesn't work right (at least for me and what I got it doesn't), and is an exploit for no down time (this full heals the bot), I just quoted it out (I'm content to updates when zoning/re-logging the bot);
command.cpp, line 7202 replace;

Code:

c->Message(15, "#bot update [target] - you must type that command once you gain a level.");

with

Code:

	c->Message(15, "#bot update You must zone or re-log to see updated Bot"); //Angelox: removed for exploit (doesn't work right anyways

and quote out lines 8462 - 8486 (more or less)

Code:

/*	if(!strcasecmp(sep->arg[1], "update")) {
//        // Congdar: add IsEngaged check for exploit to keep bots alive by repeatedly using #bot update.
//	  // Angelox: Disabled it totally as it is an exploit for no down time 
        if(c->GetTarget() != NULL)
        {
            if(c->GetTarget()->IsBot() && (c->GetTarget()->BotOwner == c->CastToMob()) && !c->GetTarget()->IsEngaged()) {
                Mob *bot = c->GetTarget();
                bot->SetLevel(c->GetLevel());
				bot->CalcBotStats();
            }
            else {
				if(c->GetTarget()->IsEngaged()) {
					c->Message(15, "You cannot update while engaged.");
				}
				else {
					c->Message(15, "You must target a bot first");
				}
            }
        }
        else {
			c->Message(15, "You must target a bot first");
        }
        return;
	}
*/

This fixes are tested and running on a few mini-login servers, mad by request of the owners.

spider661 · #5 09-29-2008, 07:53 AM

wow nice fixes i did not even know that was doable but tested and yes that does kill players or npcs so thanks for that fix its in mine now.

Angelox · #6 09-29-2008, 09:05 AM

Quote:

Originally Posted by spider661

i fixed it i just removed the group leader check when inviting bots.. i don't care if anyone in group can invite them leader or not.. and it seems to e working now. but i would still like to see a fix to the problem in case i decide to put leader check back in or if anyone else needs it

The group fix by Congdar is great!
Tell me what you did to remove the group leader check.

leslamarch · #7 09-29-2008, 05:32 PM

does anyone have a good way already in place to limit bots to a certain status level?

**Congdar** · #8 09-29-2008, 06:01 PM

There's been some ideas posted. Limit by status, limited number of bots, quests to get a bot, etc. All good ideas waiting to be coded.

Angelox · #9 10-01-2008, 03:33 PM

This corrects another exploit -

Quote:

If you are using FD (Feign Death) and you have a group of bots, you can send the bots and they will get killed but you won't get involved in combat. After that, you can re-summon your bots and send them again...

In client.cpp at around line 1842 (on my client.cpp it's on line 1914)
replace this

Code:

#ifdef EQBOTS

		// there seems to be a bug where the hate list doesn't get cleared, even if
		// the mob forgets about the feigner.
		hate_list.Wipe();

#endif //EQBOTS

With this;

Code:

#ifdef EQBOTS

		// there seems to be a bug where the hate list doesn't get cleared, even if
		// the mob forgets about the feigner.
		hate_list.Wipe();

	// Angelox Added for FDead Exploit
	Mob *clientmob = CastToMob();
	if(clientmob) {
		int16 cmid = GetID();
		if(clientmob->IsBotRaiding()) {
			BotRaids* br = entity_list.GetBotRaidByMob(clientmob);
			if(br) {
				br->RemoveRaidBots();
				br = NULL;
			}
		}
		if(clientmob->IsGrouped()) {
			Group *g = entity_list.GetGroupByMob(clientmob);
			if(g) {
				bool hasBots = false;
				for(int i=5; i>=0; i--) {
					if(g->members[i] && g->members[i]->IsBot()) {
						hasBots = true;
						g->members[i]->Kill();
					}
				}
				if(hasBots) {
					if(g->BotGroupCount() <= 1) {
						g->DisbandGroup();
					}
				}
			}
		}
		database.CleanBotLeader(cmid);
	}

#endif //EQBOTS

What happens is FD, will clear the bots out, but not the group Which makes it a fair play.

I also added this check in groups.cpp, around line 834 ;
change this;

Code:

#ifdef EQBOTS

int Group::BotGroupCount() {
	int count = 0;
	for(int i=count; i<MAX_GROUP_MEMBERS; i++) {
		if(members[i] && (members[i]->GetMaxHP()>0))
			count++;
	}
	return count;
}

#endif //EQBOTS

to this;

Code:

int Group::BotGroupCount() {
	int count = 0;
	for(int i=count; i<MAX_GROUP_MEMBERS; i++) {
		if(members[i] && (members[i]->GetMaxHP()>0))
			count++;
	}
	return (count,database.GroupCount(GetID())); //angelox add
}

This enabled me to invite PC members to the group (first) then add bots. On zoning, the bots poof, but the PC group stays intact.

This is all tested, the PC group part i tested as best I could from two PC's in the Lan. Posted with my database for anyone who wants to try it out.
I'm planning on re-arranging my Bot SpellLists, so they match the ones in PEQ., Then the code will be made compatible with the PEQ database too.

**Congdar** · #10 09-29-2008, 09:42 AM

Quote:

Originally Posted by spider661

ok that worked great.. now the bots leave group and group stays in tact now 1 more problem.. the player that owns the bots invites a player.. spawns bots and zones out and back bots gone group intact. so then i respawn the bots and try to invite them. says only leader can invite bots and kills them. but then i log on another char and try to invite them and it lets me..

so basically what happens is now the bots cant find the leader of the group even though the owner is still the group leader according to the game.

any ideals?

This is a bug in group code, and not related to bots. There's a missing opcode for group leader it seems doesn't get updated when zoning. I thought KLS had fixed this but I guess not.

Angelox · #11 09-29-2008, 09:59 AM

Quote:

Originally Posted by Congdar

This is a bug in group code, and not related to bots. There's a missing opcode for group leader it seems doesn't get updated when zoning. I thought KLS had fixed this but I guess not.

What if you coded the bots to look in table 'group_leaders' for whoever is the leader.

**Congdar** · #12 09-29-2008, 10:12 AM

Angelox,
Nice fixes... I'll add them to my source, but I'm going to allow the update command but I'll fix it so it only works for what the actual update command was intended for... when you level up, you're supposed to be able to level up your bots with you, so I'll add a level check and that should be good.

The killing npc's and players bug is another nice find but is a good command when used as intended. I'll add code to make sure a bot is the target.

It would be nice to get the actual group code fixed, but using the bot leader's db table is a good workaround until then.

**Congdar** · #13 09-29-2008, 10:33 AM

hmm actually the reason I had the leader check was so two pc's in the same group couldn't summon bots and I think it needs to be that way. The bot leaders table only tells me who the leader of the bot is, not the leader of the group. So I have an idea on a new check for that. I'll get it updated today.

With these fixes I'll be releasing again real soon with all the suggestions from here since my 1129 release announcement.

All characters on the same account will now share the bots so each doesn't need its own army.
Some speed spells in dungeons are disabled (Selo's still working, is it supposed to for bards?)
The Chardok Monk Sniffer test has much better results
Bots should no longer equip items with level restrictions above them
Undead can now be taunted
Added a few more AA's

Angelox · #14 09-29-2008, 11:23 AM

Well, I got a few more that might interest you;
Selos and bard speed spells should not work in dungeons either, what I did was make up some new 'spell ids';
-=-=-=-=-=
spdat.h around 482 add;

Code:

bool IsSowTypeSpell(int16 spell_id);    //Angelox
bool IsFeralPackSpell(int16 spell_id);  //Angelox

-=--=-=-=-=
spdat.cpp around 708 add;

Code:

bool IsFeralPackSpell(int16 spell_id) {  //Angelox, works in dungeons
	bool Result = false;

	// Feral Pack
	if(spell_id == 4058)
		Result = true;

	return Result;
}

bool IsSowTypeSpell(int16 spell_id) {  //Angelox
	bool Result = false;

// Sow Types		Sow		  WolfForm	  ShareGreatWolf	   GreaterWolfForm	  SharWolf		Bard		     Bard		 EagleSow	
	if((spell_id == 278) || (spell_id == 425) || (spell_id == 3579) || (spell_id == 426) || (spell_id == 428)|| (spell_id == 717) || (spell_id == 2605) || (spell_id == 2517))
		Result = true;

	return Result;
}

I wanted to keep some sow spells in dungeons, but others no. My idea is to get things looking natural, the only group wolf I have available is the Feral Pack In dungeons (it is an LDoN dungeon spell), Thought it was pretty cool to have while working in dungeons. I also have some code (will post later) that enables the Druid to only wolf itself (then Sow everone else), and not the whole group. As when we played on live, most players didn't care to get 'Wolfed' all the time.

Once the above code is added, I then went to botAI.cpp at line 751 'case SpellType_Buff:'
entry, I added these to lines with your levitate check;

Code:

	  (IsSowTypeSpell(AIspells[i].spellid) && !zone->CanCastOutdoor()) ||
	  (IsFeralPackSpell(AIspells[i].spellid) && zone->CanCastOutdoor())) { //Angelox

Now it looks like this;

Code:

	// Put the zone levitate check here since bots are able to bypass the client casting check
	 if(IsEffectInSpell(AIspells[i].spellid, SE_Levitate) && !zone->CanLevitate() ||
	  (IsSowTypeSpell(AIspells[i].spellid) && !zone->CanCastOutdoor()) ||
	  (IsFeralPackSpell(AIspells[i].spellid) && zone->CanCastOutdoor())) { //Angelox
	  break;
}

The outcome of this is, when playing outdoors, you look over to the wolf in the group, and think 'Yep, there's the Druid'(sort of a classic look to a Druid). And when in dungeon, you get the numerous benefits of Feral Pack, which players really liked to have.
The Druid should Wolf first, then Sow for this to work.
And I have disabled all wolf forms but the one 'self only' in npc_spells_entries .
Still if you don't like my Druid wolf idea, the other code works for blocking choice spells in and out of dungeons

One problem needs to be solved with Illusions is, you can't equip a Bot while under the effect. I usually have all the gear ready and quickly hand it over before the bot casts the illusion.

Angelox · #15 09-29-2008, 12:11 PM

There's another piece I forgot about, if you want to make the druid 'self only" wolf work;
in spells.cpp around 2431 where you see

Code:

//Franck-add: can't detrimental spell on bots and bots can't detriment on you or the others bots
	if	((IsBot() && IsDetrimentalSpell(spell_id) && spelltar->IsBot()) ||
		(IsBot() && IsDetrimentalSpell(spell_id) && spelltar->IsClient()) ||
		(IsClient() && IsDetrimentalSpell(spell_id) && spelltar->IsBot()))
		return false;

I added to look like this;

Code:

//Franck-add: can't detrimental spell on bots and bots can't detriment on you or the others bots
	if	((IsBot() && IsDetrimentalSpell(spell_id) && spelltar->IsBot()) ||
		(IsBot() && IsDetrimentalSpell(spell_id) && spelltar->IsClient()) ||
		(IsClient() && IsDetrimentalSpell(spell_id) && spelltar->IsBot()))
		return false;

	int druid_sp [] = { 516,517,425,278,4058,4054,169 };
	if 	((IsBot() && spell_id == druid_sp[3] && level >= 20 && (GetClass() == DRUID) && spelltar == this)||
		//(IsBot() && spell_id == druid_sp[3] && !zone->CanCastOutdoor() && spelltar->IsPet()) ||
		(IsBot() && spell_id == druid_sp[3] &&  (spelltar->GetClass() == DRUID))) 
		return false;

This is so the druid will not be affected by sow from itself anything else.

reason for the big 'int druid_sp'
I have a big mess of code quoted out and re-made since one of Congdar's fixes (wouldn't work anymore) , I need to clean it all up, but keep it for new ideas.