EQoffline, bots and more.. - Page 52

**Congdar** · #**766** 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 · #**767** 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** · #**768** 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** · #**769** 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 · #**770** 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 · #**771** 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.

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

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

**Congdar** · #**773** 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 · #**774** 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** · #**775** 10-01-2008, 04:45 PM

Feign Death kills the bots? I can't agree with this fix. FD is a viable tactic to lower aggro. You would want your bots to continue the fight and you could rejoin the battle after the warrior bot regained aggro. Need to think of a better way.

The group fix... I fixed it already a different way... not sure what this is doing.

Since my release with the official 1129 code there has been massive feedback and suggestions both here and on my server forums. I've incorporated probably 99% of this and the current bot source doesn't really look much like the 1129 release. I'll probably be adding the bot source I have into the svn this weekend when I have some time and then there'll be a base to work from.

Angelox · #**776** 10-01-2008, 05:02 PM

Quote:

Originally Posted by Congdar

Feign Death kills the bots? I can't agree with this fix. FD is a viable tactic to lower aggro. You would want your bots to continue the fight and you could rejoin the battle after the warrior bot regained aggro. Need to think of a better way.

At the moment, it's an exploit , better than FD and continuously sending in the bots tell you win.
The whole FD idea, has evolved to please the customers. At first, FD had other intentions, such as someone staying back for a quick CR. When you FD, you pet went too. Now days, it does not.
Already the game is much easier with the bots, I'm able to do things i would have never have thought of unless I used the #gm. If someone has gotten into a situation where they have to FD (with a team of bots!), then they can make new bots and start over, instead of abuse the FD.

**Congdar** · #**777** 10-01-2008, 07:12 PM

FD classes have been doing so in battles to manage aggro for years. Bots shouldn't change that. I agree there's an exploitable situation, all I'm saying is a different solution would be better. If you make it this way then at least make a Bot::FDRule to disable it so monks with bots can continute to play eq the way they always have.

**Congdar** · #**778** 10-01-2008, 07:25 PM

Hey, I re-read the last part of your post. Before your fix post I already had implemented code so you can't spawn more bots or create more groups from already spawned bots when engaged. A FD check might be more easily added there if even needed with the engaged check.

Angelox · #**779** 10-01-2008, 08:25 PM

Quote:

Originally Posted by Congdar

FD classes have been doing so in battles to manage aggro for years. Bots shouldn't change that. I agree there's an exploitable situation, all I'm saying is a different solution would be better. If you make it this way then at least make a Bot::FDRule to disable it so monks with bots can continute to play eq the way they always have.

Ahh, Monks! I forgot about them, I was thinking about SKs and Necros only. Anyway, I didn't think of it as a permanent solution, just a filler tell something better shows up. At least the exploit got squashed out right away.
Could also toss in some exceptions; maybe a timer for FD while engaged, and un-limited time for FD while not engaged, so if you're in a fight and you stay on the FD too long, then they will all poof.
It's a combination problem where the player goes FD and when the bots gets killed, then they are 'not engaged' and he can quickly make another round of bots and send them in (all the time, he's FD)

**Congdar** · #**780** 10-02-2008, 09:06 AM

Quote:

Originally Posted by Angelox

just a filler tell something better shows up

I've got better stuff coming. I'm pretty excited about my next release. There's a lot of new features added from all the feedback plus I've closed up several exploits like those mentioned. I've also massively reduced lag from cpu hits the bot were generating during battles.