quest_globals broken?

[Angelox]

I just realized, none of my Perl quests that refer to quest_globals table worked anymore - I had to revert all the way back to EqEmu version 0.7.0-856 in order to see them work again.
what happens is, as soon as I start to zone in, the tables go blank, and if I re-insert the lines, when I run quest::delglobal, quest::setglobal, or anything that touches the table, it "poofs" again and nothing happens.
I'm wondering if this has been changed or is just broken after 0.7.0-856. Also maybe someone can verify this?

[John Adams]

The only thing in the changelog is around build 933/934:

==12/03/2006
FatherNitwit: Fixed a few issues related to quest global expiration.

I've never messed with globals, so I cannot help verify what's going on. Sorry.

[Angelox]

I just duplicated this bug, with another machine that has WindowsXP with the windows EqEmu binaries and MySql 4.0

[Cripp]

angelox, do you use windows or linux?

[bufferofnewbies]

Ang is a penguin kinda guy.

[Angelox]

I got windows too, I have my dedicated MySql server under WindowsXP, and I have another Xp machine just so I can run stuff like GeorgeS programs. the eqemu server is on Linux and I have my Linux machine with the everquest client

EDIT
One WindowsXP carries the MySql4.0 just for testing my "conversions" - the other and the rest of my machines for that matter, carry MySql 5x.

[Angelox]

Now you're probably wondering , how/why did this crazy old man get all these machines? Well, Im sort of a "computer garbage collector", I still have parts laying around from years ago. People still bring me stuff (usually, drop off their trash), and trade for repairs. I build little "Frankenstiens" all the time.
The "why" part, I don't know yet.

[John Adams]

Heh, I'm with ya Ang... including the old man part. I only buy laptops - otherwise, all my PCs are glommed together from parts old and new (Fry's loves me). But, to one-up you slightly, I also run Virtual machines off 2 of my servers. muhaha... while they are not very powerful (6 virts share 1 PC), it looks impressive in my ADUC

(i actually use virtuals for work - testing software)

[bufferofnewbies]

5 systems and counting here also, we tend to get everyone's 'fix this' stuff and 'upgrade this' stuff.. which works out well, because we usually get the excess on the upgradeing part.

Just finished our last 'frank' here, and working on his bride now.

[Angelox]

I narrowed down the problem to where the bug started, in this post;
http://www.eqemulator.net/forums/sho...976#post128976

[totalcynic]

I am trying to take a look at this code base as a learning exercise, and so I just did a diff between 933 and 934 and found two points that delete items from the quest_globals table, one in zone/embparser.cpp and another in zone/questmgr.cpp. In the patch these were modified so that the condition in the SQL contained;

where expdate < UNIX_TIMESTAMP()

Previously this was either;

where expdate < %lu

or

where expdate < %i

where %i and %lu were equal to the return from Timer::GetTimeSeconds()

Now I am assuming that Timer::GetTimeSeconds() returns the number of seconds since the epoch, or equal to time((time_t *) NULL). I haven't checked this, but assuming this is the case, then it looks like FBW fixed the above to work as expected, while previously the code was broken and was most likely leaving the table untouched.

So I started looking at the insertion of the data. One of these points is in the function setglobal, now this is where I am a little confused. I can see that ./zone/parser.cpp has code which calls this function;

quest_manager.setglobal(arglist[0], arglist[1], atoi(arglist[2]), arglist[3]);

However, I believe that the above could be wrong with the 3rd option, but this is an assumption and without replicating the exact problem I could be totally wrong. Could someone let me know how to replicate the issue, I have the ax_peq database and quests so if its just a matter of following some simple steps that would be great.

Oh, and BTW thanks everyone for getting the emu this far. I have been looking at these forums for years, and know how much work you have all done. This is why I want to try and help if possible while I have a little time on my hands.

[Angelox]

I was just starting to dig in to this too, I actually replaced these lines with the old ones;

// "DELETE FROM quest_globals WHERE expdate < UNIX_TIMESTAMP() || (name='%s' && npcid=%i && charid=%i && zoneid=%i))" //New one
"DELETE FROM quest_globals WHERE expdate < %i || (name='%s' && npcid=%i && charid=%i && zoneid=%i))" //Old one

I found two instances, it compiles but still does the same, so i guess there's more to it like you say -

[Angelox]

Heres what happens; First, watch your quest_globals table in the database, make sure these rows are there;

For MySql5x-

INSERT INTO quest_globals VALUES (90,0,0,14,"quill","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (94,0,0,227,"krak","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (103,0,0,227,"peer","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (140,0,0,227,"grums","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (139,0,0,227,"kars","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (98,0,0,227,"hanr","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (109,0,0,227,"bres","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (110,0,0,227,"razo","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (113,0,0,227,"lava","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (138,0,0,109,"rage","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (141,0,0,111,"omica","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (142,0,0,111,"Tserr","2",0) ON DUPLICATE KEY UPDATE value=2;
INSERT INTO quest_globals VALUES (152,0,0,224,"Alina","2",0) ON DUPLICATE KEY UPDATE value=2;

For MySql4x

INSERT INTO quest_globals VALUES (90,0,0,14,"quill","2",0);
INSERT INTO quest_globals VALUES (94,0,0,227,"krak","2",0);
INSERT INTO quest_globals VALUES (103,0,0,227,"peer","2",0);
INSERT INTO quest_globals VALUES (140,0,0,227,"grums","2",0);
INSERT INTO quest_globals VALUES (139,0,0,227,"kars","2",0);
INSERT INTO quest_globals VALUES (98,0,0,227,"hanr","2",0);
INSERT INTO quest_globals VALUES (109,0,0,227,"bres","2",0);
INSERT INTO quest_globals VALUES (110,0,0,227,"razo","2",0);
INSERT INTO quest_globals VALUES (113,0,0,227,"lava","2",0);
INSERT INTO quest_globals VALUES (138,0,0,109,"rage","2",0);
INSERT INTO quest_globals VALUES (141,0,0,111,"omica","2",0);
INSERT INTO quest_globals VALUES (142,0,0,111,"Tserr","2",0);
INSERT INTO quest_globals VALUES (152,0,0,224,"Alina","2",0);

Now log in a character - when you go from the character screen to zone in, they should all (quest_globals inserts) disapear. If they don't, #zone to nadox, make sure my quests are installed (most use quest_globals). They should "poof" and this is where the problem starts. Not to mention quests that use quest_globals do not work. You'll know when you got it right, as the quest_globals inserts will stay.
When they "poof", at that point, you can kill the client and go back to the drawing-board

[eq4me]

There are at least two more changes:

http://eqemulator.cvs.sourceforge.ne...15&r2=1.9.2.16 (already found)
http://eqemulator.cvs.sourceforge.ne...4&r2=1.13.2.15

I just browsed the CVS for changes around that time. Someone should do an cvs diff what was changed on Dec 3. I dont have time right now.

Maybe it is just the changed expire checking part in embparser.cpp.

[eq4me]

Thinking about it the changes in this part do not make sense to me:

uint32 now = Timer::GetTimeSeconds();
...
...
uint32 expdate = atoul(row[2]);
   if(expdate > now)
      run_delete = true;

   ExportVar(packagename.c_str(), row[0], row[1]);

was changed to

uint32 expired = atoul(row[2]);
   if(expired != 0) {
       run_delete = true;
   } else {
       ExportVar(packagename.c_str(), row[0], row[1]);

First the variable expired was checked if it is greater than the current time. Now it is checked if it is equal to zero or not? I might be dead wrong but I bet 'expired' will never be zero if nothing in the "atoul(row[2])" part was changed.