quest_globals broken?

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

[Angelox]

When it comes to c++, i'm still at the "what if" stage; you know, "what if i took this line here, and put it there ...", "ooops! doesnt work now" . Ok then, "What if ...", or "what if ...".
This can go on for days, and is an indicates i don't know a rat's-ass of what I'm doing .
Probably, it's sort of a "romantic" era of programing, when something actually works , it feels like a child finding the prized easter-egg in a Easter-hunt.
Eventually, all the pieces of C might begin to fall in place, then I'll move into the "What does this mean?" stage, which can be very annoying to some people.
Anyways, I hope you all figure it out. I must have made 50+ pl's that use quest_globals.

[totalcynic]

This maybe off base, but I think the reason that the items are getting deleted is because the expdate field should be set to the current time, in UNIX_TIMESTAMP format, + the number of seconds you want to retain it. Setting it to 0, as in the examples, will result in the code deleting the rows because of the condition.

Are you trying to create infinite timeouts ? If so then this would be a simple fix to the SQL, just with an expansion on the condition so that it read;

where (expdate < UNIX_TIMESTAMP() and expdate != 0)

This would allow for expdate=0 to be inifinite, assuming its just the timeout that is at fault.

[Angelox]

I made these changes in questmgr.cpp and compiled/tested

"DELETE FROM quest_globals WHERE expdate < UNIX_TIMESTAMP() and expdate != 0) || (name='%s' && npcid=%i && charid=%i && zoneid=%i))"

there was two entries like that so I changed it also,

"DELETE FROM quest_globals WHERE expdate < UNIX_TIMESTAMP() and expdate != 0) || (name='%s' && npcid=%i && charid=%i && zoneid=%i))"

The problem still is there, quest_globals poofed.