EQEmulator Forums - New Bot Group Based Raid System

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Bots (https://www.eqemulator.org/forums/forumdisplay.php?f=676)

- - New Bot Group Based Raid System (https://www.eqemulator.org/forums/showthread.php?t=29827)

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

zone_templeveeshan.log (grouped evac):

Code:

[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:

Code:

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:

Code:

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:

Code:

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

Quote:

Originally Posted by WildcardX (Post 180464)

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:

Code:

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:

Code:

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...

This is bad:

Quote:

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?

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

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

it's there from my last compile:

Code:

:~/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...

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*

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.

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

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!

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

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.