quest_globals broken?

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