quest_globals broken?

[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