New Bot Group Based Raid System

[WildcardX]

I will soon remove the BotRaid system from the server code and many of the existing "#bot group order" commands in favor of the logic I just committed this morning that is essentially group based raids for bots as EQ raids were before the raid system was added to the game. Please see this link for details:

http://code.google.com/p/projecteqemu/source/detail?r=1032

This code is a first draft. Please report any bugs with this system ONLY to this thread.

It is my intent that after this system is stabilized, I will then turn my attention to integrating bots with the server's standard raid interface that characters now use while also keeping this new group based system in place.

Enjoy!

[WildcardX]

I assume there are no problems with this new code? Cool!

[prickle]

I haven't had a chance to test out the raiding aspect with the bots and the new code. However, the one part of the new bots code that I was able to test was with zoning. On my system (Ubuntu Linux), the bots go "stupid" after zoning. They forget to follow you, and don't seem to behave normally. The only way to make them behave properly is to camp them and then respawn them after zoning.

Dunno if this is just me that's seeing this because I haven't seen anyone else mention it yet.

[WildcardX]

What rev were you using when this happened? This sounds like a bug I fixed in rev 1033. If you are unsure, I'd recommend getting the latest code out of the repo today and try again.

[So_1337]

Two midterms this week and some more next; I'll test this ASAP, sorry I've let my priorities get skewed temporarily =P

[prickle]

That was happening with rev 1035.

I updated to rev 1036 last night, but didn't have time to personally test it out.

I'll be able to test rev 1036 (or whatever the latest is when I get home) tonight though.

[SCROFT]

That was happening with rev 1035.

I updated to rev 1036 last night, but didn't have time to personally test it out.

I'll be able to test rev 1036 (or whatever the latest is when I get home) tonight though.

I play on prickles server and just tested this... they still will not follow after zoning.

I logged in... spawned in a cleric and verified he followed me to the zone... and zoned to another zone... after zoning the cleric was there and continued to buff me but would not follow me... i then spawned in a enchanter... this enchanter started buffing but also would not follow me.

So i figure when i zone somehow the fact that i am the group leader is lost?

Why they will buff me... but not follow me?

My guess anyways hope this helps narrow down the bug.

rev1036 BTW

[prickle]

in case it helps:

$ gcc --version
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[leslamarch]

Just tested on fresh PEQ DB with REV 1036 and I'm not seeing this problem at all, Tested on my Home windows environment. I zone to about 10 different zones and bots all responded great.

[SCROFT]

Just tested on fresh PEQ DB with REV 1036 and I'm not seeing this problem at all, Tested on my Home windows environment. I zone to about 10 different zones and bots all responded great.

Thanks for the follow up... we will check over our setup and see if we missed something.

[WildcardX]

The code responsible for making sure the bot responds to you after it zones with you is this one little code block:

if(g->GetLeader())
activeBot->SetFollowID(g->GetLeader()->GetID());

If the bot doesn't follow you or respond to you after it zones with you, then carefully review your group_id and group_leaders tables and make sure the records match up and that you have all the required SQL updates for these tables.

I hope this helps you.

[prickle]

ok... I've had some time with them now... (still haven't had a chance to check the raiding aspect though)

I did the following after I got home from work:

Redid DB with PEQ DB Rev1008:
-sourced system-drop.sql
-sourced peqdb_Rev1008.sql
-sourced 1022, 1027, 1030, and 1036 sql files

Recompiled SVN Rev1036:
-verified the strings of code you indicated above are in the bot.cpp file
-added -DBOTS to the zone/makefile file
-added bot.o botRaids.o to the zone/makefile.common file
-changed march=i686 to march=athlon64 in all makefiles

copied binaries to server directory

launched server

Testing bots:
-summon wizard bot
-check group_id and group_leader tables: updates when group forms
-verified bot follows me around the zone
-issued #bot gate pok command
-bot casts teleport
-group zoned into PoK bot no longer follows me around the zone
-issue #bot gate cobalt command
-bot casts teleport
-group zoned to cobalt scar
-bot still does not follow

-camp bot
-spawn bot
-recheck group_id and group_leader tables IDs correspond with each other
-bot follows around zone

So, the bot responds to buff and travel commands after zoning, but they refuse to follow me around the zone. Trying to use #bot group order follow to make them follow me does not work. They seem to respond to most bot orders (e.g. bot group summon, etc) but they refuse to follow me after zoning.

The ~only~ thing that makes them follow me around a zone after zoning is making them camp and then respawning them.

[WildcardX]

That is consistent with what I posted about the bot not getting a Group Leader and so its follow id doesnt get set. I wish I knew what you might not have done. I'll look over more about what you posted in detail later tomorrow and think on it some. Maybe I can figure out what you may have missed. The fact that I have the bots running around with me zone after zone and that another experienced community member such as laslamarch has this running as expected, makes me think there is a config error here that is easy to do.

[WildcardX]

Can you post the SQL for your group_id and group_leader tables DDL? I dont know if your savy enough to do so, but if you are that might help shed some light on this situation.

[prickle]

I'm playing with a full bot party right now this is what's in the two tables right now:

mysql> select * from group_id;
+---------+--------+-------------+
| groupid | charid | name |
+---------+--------+-------------+
| 109002 | 1 | Nunyscleric |
| 109002 | 6 | Nunyas |
| 109002 | 11 | Pusher |
| 109002 | 17 | Tanku |
| 109002 | 27 | Rogue |
| 109002 | 32 | Punchy |
+---------+--------+-------------+

mysql> select * from group_leaders;
+--------+------------+---------+--------------+
| gid | leadername | marknpc | leadershipaa |
+--------+------------+---------+--------------+
| 109002 | Nunyas | | |
+--------+------------+---------+--------------+

[prickle]

this is after zoning:

mysql> select * from group_id;
+---------+--------+-------------+
| groupid | charid | name |
+---------+--------+-------------+
| 109002 | 1 | Nunyscleric |
| 109002 | 6 | Nunyas |
| 109002 | 11 | Pusher |
| 109002 | 17 | Tanku |
| 109002 | 27 | Rogue |
| 109002 | 32 | Punchy |
+---------+--------+-------------+
6 rows in set (0.00 sec)

mysql> select * from group_leaders;
+--------+------------+---------+--------------+
| gid | leadername | marknpc | leadershipaa |
+--------+------------+---------+--------------+
| 109002 | Nunyas | | |
+--------+------------+---------+--------------+
1 row in set (0.00 sec)

[Shin Noir]

There's been an issue with group leadership for a bit from what I know. Like, EQEMU related bug. Losing group leader is a common occurance from what I've seen, reforming and creating groups is typical.

[WildcardX]

Pricke,

Did you also add -DBOTS to your world\makefile?

[WildcardX]

Prickle,

What is the makeup of your group in the example you posted? Was it 2 characters and 4 bots?

[prickle]

hmmmmm.... I was only aware of needing to add -DBOTS to the zone/makefile ... I didn't know about the world/makefile

I'll add it, recompile, and report back tomorrow...

The group is 1 player (me --Nunyas) and 5 bots

[prickle]

well, just added -DBOTS to my world/makefile and then followed that up with 'make clean' and 'make' from the top level build directory.

I'm still getting the same results. bots still forget to follow me after zoning.

/confused

[WildcardX]

Want to try re-applying this SQL to your group_id table just in case its not there?

ALTER TABLE `group_id` DROP PRIMARY KEY, ADD PRIMARY KEY USING BTREE(`groupid`, `charid`, `name`);

[WildcardX]

Aside from checking your SQL, which sounds like you already have, the only thing I can offer is the following method that actually does the bot zoning:

// Load and spawn all zoned bots by bot owner character
void Bot::LoadAndSpawnAllZonedBots(Client* botOwner) {
if(botOwner) {
if(botOwner->HasGroup()) {
Group* g = botOwner->GetGroup();
if(g) {
uint32 TempGroupId = g->GetID();
std::string errorMessage;
std::list<uint32> ActiveBots = Bot::GetGroupedBotsByGroupId(botOwner->GetGroup()->GetID(), &errorMessage);

if(errorMessage.empty() && !ActiveBots.empty()) {
for(list<uint32>::iterator itr = ActiveBots.begin(); itr != ActiveBots.end(); itr++) {
Bot* activeBot = Bot::LoadBot(*itr, &errorMessage);

if(!errorMessage.empty()) {
safe_delete(activeBot);
break;
}

if(activeBot) {
activeBot->Spawn(botOwner, &errorMessage);

g->UpdatePlayer(activeBot);

if(g->GetLeader())
activeBot->SetFollowID(g->GetLeader()->GetID());
}

if(activeBot && !botOwner->HasGroup())
database.SetGroupID(activeBot->GetCleanName(), 0, activeBot->GetBotID());
}
}

// Catch all condition for error messages destined for the zone error log
if(!errorMessage.empty()) {
// TODO: Log this error message to zone error log
}
}
}
}
}

The fact that you can see your bot after it zones with you and it has spawned tells me you have gotten to this part of the code...

if(activeBot) {
activeBot->Spawn(botOwner, &errorMessage);

so i think for you, its just a matter of something not coming together as expected for the next two statements:

g->UpdatePlayer(activeBot);

if(g->GetLeader())
activeBot->SetFollowID(g->GetLeader()->GetID());

If you know how to debug this, then I'd recommend making sure that GetLeader() isn't returning a null value. if it is not, then I'd make sure that the same object returned by GetLeader() isn't returning a value from GetID() that is 0 .

I'll keep thinking on this for you.

[prickle]

I just noticed this line in the 1030_botzoningsupport.sql file

DROP TABLE IF EXISTS `botactives`;

The 1027_botactives.sql file creates this table, and then the 1030 update removes it. Is this correct? From looking at the bots.sql file, this seems correct too me, because the latest bots.sql file does not create the botactives table, but I thought I'd check to make sure this is correct.


I looked through the bot.cpp file and all of the bits of code that you mentioned are in there.


I was just digging through the diffs on the bots.sql file in SVN over the changes from 1027 to current and I noticed this was added to the bots.sql file but not to the 1027 update sql file:

75 DELIMITER $$
76
77 DROP FUNCTION IF EXISTS `GetMobType` $$
78 CREATE FUNCTION `GetMobType` (mobname VARCHAR(64)) RETURNS CHAR(1)
79 BEGIN
80 DECLARE Result CHAR(1);
81
82 SET Result = NULL;
83
84 IF (select count(*) from character_ where name = mobname) > 0 THEN
85 SET Result = 'C';
86 ELSEIF (select count(*) from bots where Name = mobname) > 0 THEN
87 SET Result = 'B';
88 END IF;
89
90 RETURN Result;
91 END $$
92
93 DELIMITER ;

Not sure if this this will have an effect or not, but since it's not in my Database (i didn't source bots.sql, I thought the incremental update sql files would get me there) and I can't find anything else different, I thought I'd mention it...

gonna source it in right now and see if there's any difference...

[WildcardX]

Your right that the incremental SQL files are missing the creation of that function, but it isnt used for zoning bots. It is used primarily for supporting bots in ldon adventures.

[prickle]

ah... well shoot... /sigh

[prickle]

To answer your original question...

Raiding seems ok... I've been 2 grouping in ToV all day. sometimes 2 full groups and sometimes 1 full group and 2 half groups...The raid stuff seems to be working pretty well for me..

[prickle]

More info on my bot zoning issue:

Updated to 1038 last night

Here are the log entries:

eqemu_debug_world.log - log in from char select to ToV:
6667 [10.24. - 09:06:44] [WORLD__CLIENT] Checking inbound connection 192.168.1.70 against BannedIPs table
6667 [10.24. - 09:06:44] [WORLD__CLIENT] Connection 192.168.1.70 PASSED banned IPs check. Processing connection.
6667 [10.24. - 09:06:44] [WORLD__CLIENT] rvecchiolli: Logged in. Mode=(CharSel)
6667 [10.24. - 09:06:44] [WORLD__CLIENT] rvecchiolli: LS Account #1
6667 [10.24. - 09:07:28] [WORLD__CLIENT] rvecchiolli: Entering zone templeveeshan (124:0)
6667 [10.24. - 09:07:28] [WORLD__ZONE] [93] [templeveeshan] Setting to 'templeveeshan' (124:0) (Static)
6667 [10.24. - 09:07:28] [WORLD__CLIENT] rvecchiolli: Sending client to zone templeveeshan (124:0) at 192.168.1.135:7092
6667 [10.24. - 09:07:28] [WORLD__CLIENT] rvecchiolli: Client disconnected (not active in process)

eqemu_error_zone.log (still no group):
no entries made during log in

zone-templeveeshan.log first zone in (no groups):
[Debug] Nunyas has a 14 percent chance of successfully being saved from death. Caster UnfailingDivinityAA rank was 0.
[Debug] Nunyas has a melee rune spell buff with 650 points remaining.
Unable to get group id, char not found!
Unable to get raid id, char not found!
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
0: 8D 01 00 00 40 00 00 00 | ....@...
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
0: 8D 01 00 00 80 00 00 00 | ........
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip1 (0x6c5e) Size=12]
0: 8D 01 00 00 00 00 00 00 - 00 00 00 00 | ............

[WildcardX]

What that log tells me is when you zone in (I presume your zoning into templeveeshan with a group with at least one bot in it), your server is unable to find your group id when it tried to execute this sql command:

RunQuery(query, MakeAnyLenString(&query, "SELECT groupid from group_id where name='%s'", name), errbuf, &result)

Its too bad we can't debug this for you.

Maybe you can edit your database.cpp file and change the logic that prints the error message "Unable to get group id, char not found!" to something like the following:


printf("Unable to get group id, char name %s not found!\n", name);


at least then you can be sure of what client or bot it is trying to get the group id for and then check to see if that exact name is in your group_id table.

[prickle]

There are the log entries made for spawning my bot and adding to group

MySQL Tables after spawning bot and adding to group (bot is Nukesalot leader os PC Nunyas):
mysql> select * from group_id;
+---------+--------+-----------+
| groupid | charid | name |
+---------+--------+-----------+
| 92004 | 16 | Nukesalot |
| 92004 | 6 | Nunyas |
+---------+--------+-----------+
2 rows in set (0.00 sec)

mysql> select * from group_leaders;
+-------+------------+---------+--------------+
| gid | leadername | marknpc | leadershipaa |
+-------+------------+---------+--------------+
| 92004 | Nunyas | | |
+-------+------------+---------+--------------+
1 row in set (0.00 sec)

[prickle]

The following is the log outputs after EVAC WITH bot group:

zone_templeveeshan.log (grouped evac):
[Debug] Zoning Nunyas to safe coords (-499.000000,-2086.000000,-36.000000) in templeveeshan (124)
[Status] Zoning 'Nunyas' to: templeveeshan (124) - (0) x=-499.000000, y=-2086.000000, z=-36.000000
[Debug] Client::AddMoneyToPP() Nunyas should have: plat:889 gold:78 silver:113 copper:87
[Debug] [WORLD__CLIENT] New connection from 192.168.1.70:49236
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: First opcode 0x7213 did not match expected 0x2792
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: Tried patch 6.2_world, and it did not match.
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: First opcode 0x7213 did not match expected 0x2ec9
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: Tried patch 6.2_zone, and it did not match.
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: First opcode 0x7213 did not match expected 0x4dd0
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: Tried patch Titanium_world, and it did not match.
[Debug] [NET__IDENT_TRACE] 192.168.1.70:49236: First opcode matched 0x7213 and length matched 68
[Debug] [NET__IDENTIFY] Identified stream 192.168.1.70:49236 with signature Titanium_zone
[Debug] [WORLD__CLIENT] New client from 192.168.1.70:49236
[Debug] Nunyas has a melee rune spell buff with 650 points remaining.
[Debug] Member of group 92004 named 'Nunyas' had an out of date pointer!!
[Debug] Member of group 92004 named 'Nukesalot' had an out of date pointer!!
[Error] HandlePacket() Opcode error: Unexpected packet during CLIENT_CONNECTING: opcode: OP_AnnoyingZoneUnknown (#311 eq=0x0000), size: 4112
Unable to get raid id, char not found!
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
0: 90 01 00 00 40 00 00 00 | ....@...
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip2 (0x63da) Size=8]
0: 90 01 00 00 80 00 00 00 | ........
[Debug] [CLIENT__NET_ERR] Nunyas: Unhandled incoming opcode: [OpCode OP_WeaponEquip1 (0x6c5e) Size=12]
0: 90 01 00 00 00 00 00 00 - 00 00 00 00 | ............

MySQL Tables:
mysql> select * from group_id;
+---------+--------+-----------+
| groupid | charid | name |
+---------+--------+-----------+
| 92004 | 16 | Nukesalot |
| 92004 | 6 | Nunyas |
+---------+--------+-----------+
2 rows in set (0.00 sec)

mysql> select * from group_leaders;
+-------+------------+---------+--------------+
| gid | leadername | marknpc | leadershipaa |
+-------+------------+---------+--------------+
| 92004 | Nunyas | | |
+-------+------------+---------+--------------+
1 row in set (0.00 sec)

eqemu_debug_world.log:
6667 [10.24. - 09:39:12] [WORLD__CLIENT] New connection from 192.168.1.70:49233
6667 [10.24. - 09:39:12] [NET__IDENT_TRACE] 192.168.1.70:49233: First opcode 0x4dd0 did not match expected 0x2792
6667 [10.24. - 09:39:12] [NET__IDENT_TRACE] 192.168.1.70:49233: Tried patch 6.2_world, and it did not match.
6667 [10.24. - 09:39:12] [NET__IDENT_TRACE] 192.168.1.70:49233: First opcode 0x4dd0 did not match expected 0x2ec9
6667 [10.24. - 09:39:12] [NET__IDENT_TRACE] 192.168.1.70:49233: Tried patch 6.2_zone, and it did not match.
6667 [10.24. - 09:39:12] [NET__IDENT_TRACE] 192.168.1.70:49233: First opcode matched 0x4dd0 and length matched 464
6667 [10.24. - 09:39:12] [NET__IDENTIFY] Identified stream 192.168.1.70:49233 with signature Titanium_world
6667 [10.24. - 09:39:12] [WORLD__CLIENT] Checking inbound connection 192.168.1.70 against BannedIPs table
6667 [10.24. - 09:39:12] [WORLD__CLIENT] Connection 192.168.1.70 PASSED banned IPs check. Processing connection.
6667 [10.24. - 09:39:12] [WORLD__CLIENT] rvecchiolli: Logged in. Mode=(Zoning)
6667 [10.24. - 09:39:12] [WORLD__CLIENT] rvecchiolli: LS Account #1
6667 [10.24. - 09:39:12] [WORLD__CLIENT] rvecchiolli: Telling client to continue session.
6667 [10.24. - 09:39:13] [WORLD__CLIENT] rvecchiolli: Zoning to templeveeshan (124:0)
6667 [10.24. - 09:39:13] [WORLD__CLIENT] rvecchiolli: Sending client to zone templeveeshan (124:0) at 192.168.1.135:7092
6667 [10.24. - 09:39:13] [WORLD__ZONE] [93] [templeveeshan] Setting to 'templeveeshan' (124:0) (Static)
6667 [10.24. - 09:39:13] [WORLD__CLIENT] rvecchiolli: Client disconnected (not active in process)

eqemu_error_zone.log:
7465 [10.24. - 09:39:24] HandlePacket() Opcode error: Unexpected packet during CLIENT_CONNECTING: opcode: OP_AnnoyingZoneUnknown (#311 eq=0x0000), size: 4112

[prickle]

What that log tells me is when you zone in (I presume your zoning into templeveeshan with a group with at least one bot in it), your server is unable to find your group id when it tried to execute this sql command:

RunQuery(query, MakeAnyLenString(&query, "SELECT groupid from group_id where name='%s'", name), errbuf, &result)

Its too bad we can't debug this for you.

Maybe you can edit your database.cpp file and change the logic that prints the error message "Unable to get group id, char not found!" to something like the following:


printf("Unable to get group id, char name %s not found!\n", name);


at least then you can be sure of what client or bot it is trying to get the group id for and then check to see if that exact name is in your group_id table.

Sorry, the first post with initial log in with NO GROUP. I was splitting it up into 3 posts instead of 1 long post. #1 zone in no group, #2 spawn bot setup testing group, and #3 evac/zone the group.

I'll have a look at the file you mentioned and see if I can find anything suspicious... though, I must admit C++ isn't a very strong language for me...

[WildcardX]

This is bad:


Member of group 92004 named 'Nunyas' had an out of date pointer!!


So this means your server has two different objects in memory for your client character as well as yours bot character.

Are you using any custom code? Anything about your server that is not straight out of the peqdatabase or eqemuserver repo?

[prickle]

the only things I change after an SVN check out are the following:

-march=i686 to -march=athlon64 (all makefiles)

And:

Add -DBOTS to the zone/makefile

Add bot.o and botRaids.o to the zone/makefile.common

=============

None of the CPP files have been altered.

I updated my DB to the peq rev1008 package and applied all SVN SQL files newer than it yesterday, but I just noticed the DB version table is still reporting 974 .... grrrrrr

I'll try redoing my DB again

[WildcardX]

Dont forget to add -DBOTS to your world makefile also..

[prickle]

it's there from my last compile:
:~/eqemubuilds/10232009/world$ cat makefile

HCC=$(shell ccache -V 2>/dev/null)
ifneq (,$(findstring version,$(HCC)))
CC=ccache gcc
else
CC=gcc
endif

LINKER=gcc
#the spaces on the end of these are important
OUT=-o
LINKOUT=-o
NOLINK=-c
DFLAGS=-DDEBUG=5 -DEQDEBUG=5 -DSHAREMEM -DCATCH_CRASH -DNO_PIDLOG -DFIELD_ITEMS -DIRC -Di386 -DAPP_OPCODE_SIZE=2 -DBOTS
WFLAGS=-Wall -Wuninitialized -Wwrite-strings -Wcast-qual -Wcomment -Wcast-align -Wno-deprecated

PERL_FLAGS=$(shell perl -MExtUtils::Embed -e ccopts)
PERL_LIB=$(shell perl -MExtUtils::Embed -e ldopts)
DFLAGS+=-DEMBPERL -DEMBPERL_PLUGIN -DHAS_UNION_SEMUN

MYSQL_FLAGS=$(shell mysql_config --cflags)
MYSQL_LIB=$(shell mysql_config --libs)

COPTS=$(WFLAGS) -g -march=athlon64 -O -pthread -pipe -I../common/SocketLib \
-DFX -D_GNU_SOURCE -DINVERSEXY -DWORLD $(DFLAGS) $(MYSQL_FLAGS) $(PERL_FLAGS)
LINKOPTS=$(COPTS) -rdynamic -L. -lstdc++ -lm -lz -ldl \
$(MYSQL_LIB) $(PERL_LIB)

all: world


include .depend

include makefile.common

.depend depend:
for f in $(SF); \
do \
i=`echo $$f | sed -e 's#.obj/#../common/#g' -e 's/\.o/.cpp/g' `; \
gcc -MM $(COPTS) $$i | sed "s#^[^ ]*:#$$f:#g"; \
done >.depend


wine:
$(MAKE) -f makefile.wine

Just ran the rev1008.sql file from the peq updates folder... testing it out now...

[prickle]

assumptions are killing me....
http://scienceblogs.com/insolence/facepalm.jpg

even though I used the used the "peqdb_Rev1008.sql" file during my updates last night, it did not apply the changes that were found in the "Rev1008.sql" file found in the updates folder....

Sorry to have wasted your time with my incompetence... *smacks forehead*

[WildcardX]

I'm not a linux guru, so maybe I am wrong here, but since your running i686 and athelon64, shouldn't you also change your "-Di386" option in your makefile to a "-Di686"? Just an observation and I dont know if i am wrong. Maybe some else here could confirm or correct me.

[WildcardX]

? Does this mean, prickle, that you have bot zoning to work for you now?

[prickle]

yes, that's exactly what it means

The "Rev1008.sql" update file made changes to my database that the main "peqdb_Rev1008.sql" file did not.

I will continue checking out the raiding/multi-group thing today


thanks again for all the help you've provided!

[WildcardX]

Cool. Glad you got this working and I don't view help you on this as a waste of my time.

[Domel]

Rev 1038
SoF client


I spawn 2 bots (Sk and Cleric) and everything works great zoning. Pet keeps weapon, buffs still on, etc. My spell awareness leadership doesn't work tho :(

I add in a 2nd client and my leadership kicks in but then things start to go wrong.
- If the 2nd client zones first, the bots get kicked from the group.
- If I zone first the bots follow fine, but when the 2nd client then zones it kills the SK pet and looks like it might respawn the SK, he dissappears then comes back. everyone is still grouped.

Thats all I have at the moment, will test more when I can.

Oh yea, I have never had any problems with the bots following me.