quest_globals broken?

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

[eq4me]

Originally Posted by Angelox

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

...

The problem still is there, quest_globals poofed.

There are more changes in embparser.cpp. See my two last posts.

[Angelox]

Originally Posted by eq4me

There are more changes in embparser.cpp. See my two last posts.

You fix them for me and I'll test?
Believe me, my time is *much* better spent with MySql database and Perl quests.