EQEmulator Forums - New Bot Group Based Raid System

Page 1 of 2

Show 40 post(s) from this thread on one page

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)

WildcardX

10-20-2009 12:16 PM

New Bot Group Based Raid System

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

10-21-2009 08:49 PM

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

prickle

10-22-2009 09:15 AM

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

10-22-2009 09:42 AM

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

10-22-2009 09:56 AM

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

prickle

10-22-2009 02:20 PM

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

10-22-2009 04:04 PM

Quote:

Originally Posted by prickle (Post 180373)

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

10-22-2009 05:50 PM

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

10-22-2009 06:02 PM

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

10-22-2009 06:18 PM

Quote:

Originally Posted by leslamarch (Post 180378)

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

10-22-2009 06:46 PM

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

Code:

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

10-23-2009 12:28 AM

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

10-23-2009 12:36 AM

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

10-23-2009 12:39 AM

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

10-23-2009 01:22 AM

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

10-23-2009 01:33 AM

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

10-23-2009 01:34 AM

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

10-23-2009 02:06 AM

Pricke,

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

WildcardX

10-23-2009 02:23 AM

Prickle,

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

prickle

10-23-2009 02:48 AM

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

10-23-2009 11:48 AM

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

10-23-2009 12:37 PM

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

Code:

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

WildcardX

10-23-2009 12:46 PM

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:

Code:

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

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:

Code:

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

10-23-2009 02:06 PM

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

Code:

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:

Code:

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

10-23-2009 02:28 PM

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

10-23-2009 02:34 PM

ah... well shoot... /sigh

prickle

10-23-2009 07:14 PM

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

10-24-2009 12:18 PM

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:

Code:

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

Code:

[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

10-24-2009 12:32 PM

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.

prickle

10-24-2009 12:37 PM

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

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)

prickle

10-24-2009 12:44 PM

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

prickle

10-24-2009 12:47 PM

Quote:

Originally Posted by WildcardX (Post 180464)

Code:

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

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

WildcardX

10-24-2009 12:58 PM

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?

prickle

10-24-2009 01:08 PM

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

10-24-2009 01:12 PM

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

prickle

10-24-2009 02:31 PM

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

prickle

10-24-2009 02:38 PM

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

10-24-2009 02:41 PM

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

10-24-2009 02:42 PM

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

prickle

10-24-2009 02:50 PM

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!

All times are GMT -4. The time now is 04:48 PM.

Page 1 of 2

Show 40 post(s) from this thread on one page