quest_globals broken?
 

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?

The only thing in the changelog is around build 933/934:
I've never messed with globals, so I cannot help verify what's going on. Sorry.

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

angelox, do you use windows or linux?

Ang is a penguin kinda guy.

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.

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.

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 :D :D :D

(i actually use virtuals for work - testing software)

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. :)

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

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.

I was just starting to dig in to this too, I actually replaced these lines with the old ones;
I found two instances, it compiles but still does the same, so i guess there's more to it like you say -

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

For MySql5x-
For MySql4x
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

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.

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

was changed to

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.

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.

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.

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

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

The problem still is there, quest_globals poofed.

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.

Angelox I regret to inform you that I've destroyed your quests for the tutorial :p
I'm in the process of re-writing them to flow like the live server does.. if you're around... im gonna be playing with them on the Allendium EQ server here as soon as i boot it back up :)

No problem, you should try and keep the names of others who worked on them in there also - aside from self-satisfaction of acompishment, the only other reward you get here is some recognition.
And, I hope you feel inclined to become more of a "public servant" and post for all. EqEmu is in desperate need of programmers, zone-spawners, perl-questors , in a "public" manner.

Unfortunately i had to write all but 1 of them from scratch. I built the quest globals into them this time around. So now you have to speak to arias, then absor, then vahlara etc etc till you have finished the orientation... then you speak to arias again and get the kobold charm just like on the live servers. :)

once i have all the other quests finished i'll release them in a zip pack

Sorry, no time. It's the 'What was not important enough to priorize the whole year but must be done in 2006 ... somehow' time at work. I still try not to do overtime work but I am in no mood to sitting in front of a computer after work.

I sympathize, eq4me. We had so many v1's out the door the last month, and my own product I am the lead on (just shipped last Fri), I barely had time to harass the noobs here lately. I think we're clear to have a life until Jan 2nd, to start meeting the unrealistic Q1 sales goals.

I'll take a look at it again later today, been called into work to fix a mail server issue even though I was on holiday. So I know exactly what you guys are on about. :)

Ok, there were three places that deleted from global_quests by time, there are others which don't use time and don't seem to be relevant in this situation. Using your test data Angelox, and assuming you were trying to get an infinite timeout, then I believe I have achived the objective with the patch which can be found at;

http://www.totalcynic.plus.com/globa...o-expire.patch

This requires patch -p1 to be used, but what doesn't :)

Give this a try, and if all is well and no one objects, then I will submit it into the development area for inclusion in a future release. It just makes the expdate of 0 never timeout, and also includes the SQL fixup for MySQL 5.1 with the items query.

I would, though, recommend using a timeout as this allows for the code to automatically manage the data set, and helps keep the number of rows in the table down, which helps to speed up look ups. If your doing a direct insert into global_quests have you tried using something like "UNIX_TIMESTAMP(date_add(now(), INTERVAL 7 DAY))" for the value of expdate, which sets it to 7 days into the future.

Hope this helps.

Thank you! I will be testing and will tell you how it worked.

Sorry to be late on this-
I have patch, but I guess I don't know what I'm doing (common coming from me), as It doesn'y work, I did look at the patch file and changed the lines I saw there.
Maybe in the future (if you still want to do this) compress/post the changed files and Ill replace here.
I've tested as best I could, and here's the results;
when i first logged in the zone, The table held out, intact. Then I went to an Npc that use QGlobals, and hailed;
just a snip;
This made the quest global for $name, and spawns two more npcs that use quest globals;
one of the two;
What normaly happens is She gives you a charm, then spawns the "emoters" so you get the emotes as you start the dungeon - she sets a global, so you don't get dupe messages, and the emoters change already set global flags so she doesn't keep spawning more emoters, when they "depop", they set globals back again. for the next player who hails the npc. This slows the emotes down and make them appear on and off, and usually to new players.

It worked a little with your fixes, but is still broken.
this works one time;
The emoters delete their globals but do not make new ones, so they never appear again.

this works;
quest::delglobal("amote");
this doesn't
quest::setglobal("amote","2","3","F");

And even with the global set it goes to a flag where you keep getting duped with charms.

Here's the full pl so you understand the globals I did there;

http://www.nahunta.org/~angelox/files/Vahlara.pl

Ax, let me chime in for a moment. I ran the Wizard Epic quest, Camin NPC in Erudnext to be exact. He sets a quest global when you hand him 1000pp. Before my test, I had no records in the table. After handing him the 1kpp, a record was inserted:

The PL file that set this looks like this:
(assuming D30 means 30 days?)

To delete the global, you hand him Ro's Breath (item 14330):
This is where my test fails. The handin of item 14330 is true, but the test if $wizepic seems to be failing. I feel the int($wizepic) value is not getting set.

I removed that check, and the script (including the delglobal) works perfectly.
So, this worked:
I noticed the $itemcount uses curly {} instead of parens. Must be some perl'esque thing.

I also turned on #mlog setcat QUESTS on to see what shows up. I am getting feedback in eqemu_quest_zone.log that looks like this:
Confident I created the last 2 warnings by putting curlies {} around $wizepic just to see what happened.

Not completely sure what that means. I'm a bit sleepy, so the test on int($wizepic) is the only thing I find that's failing right now. Does this jive with what you're finding?

It works somewhat, just doesn't work right, and deletes all your globals, if you have any in place at start up

add this to the quest for debug.

that's a line i use frequently when trying to figure out if npc's are setting and reading globals properly... just make em say the variable with it :p

Where is the command to actually read quest_globals table tho? Or is it assumed, if I my charID is interacting with NPCID, and there IS a quest global set, then read it? I'll try setting that value on the Camin script.

Ax, I didn't restart the server/world with the global set. Is that what you're talking about? With the global for Camin set, I was zoning in and out, and the global stayed until I tried the hand-in that apparently did not pass it's "if". I think in my case, the $wizepic was not being read properly, or is the wrong value.

(another thing, it seems any class can do the wizard epic. woot!)

Ok, I re-read everything in this thread, so I can stop looking at stuff everyone else has already looked at. I am curious about one of the changes in embparser.cpp, around line 218 where we start processing existing quest_globals.

This used to read as just a plain select statement, and I assume the expdate value was calculated later. However, now it reads with an IF() in the statement - and my question is, "IF(expdate<UNIX_TIMESTAMP(),1,0)" on the SELECT would give no results, since a currently active quest_globals expdate should be > UNIX_TIMESTAMP. Right? So this whole if (result) fails. Thus, the ExportVar will never happen at the "if(expired != 0)" check. Am I not reading this right?

This could explain why I am not getting results from a set quest_global. And I wonder how this effects deleting existing ones, since I believe the comparison in the select is backwards? Know what I mean?

globals seem to be working fine for me on the 934 build

if you change a quest file you can reload it by using the #reloadquest command

that will cause the zone to clear out any perl scripts in it's cache and reload the quest files

Aerewen, I remember you said they worked for you 934+, but if you read c++ better than me, please take a look at that section of code yourself. It doesn't look right to me, but I admit I could be missing something. And, the way my eyes see it matches what I see testing quest_global functionality.

I haven't been able to reproduce Angelox' situation exactly, but that's because I was on a tangent. I'll try again this weekend, see if I can get more precise steps. Something absolutely was changed on 12/3, and Ax says it ain't workin after that, so I believe him. :)

the only issue i have found after testing this for like 5 hours is this:

if you have multiple npc's using a quest global and one of them deletes that global, the other npc's will still show that global cached.

example:
Arias sets a global "intro" to value of "1" when hailed. Then when you hail Absor, he responds with something and deletes that global. If you hail absor again he will respond with his normal text since as far as his perl file knows, that variable is unset. Arias however will continue to respond as if the global is still set because he never called a delglobal command which would have told the perl quest system to undefine that variable.

The fix that i use is this:
you put that code into arias' quest file, then add the following line to the response absor gives when hailed with the global intro set to 1:

this assumes that arias' npc id is 189013 in the npc_types table.

this way absor will delete the global from the database with delglobal("intro") and arias will clear the cached version of it.

whether a fix is later implemented to cause npc's to update their globals whenever any sub EVENT_BLAH is triggered or not... this is a safe way to code your quests in perl for the time being and will not cause any conflict if a fix is later added.

Update:
After doing more extensive testing, using Camin in Erudnext as my guinea pig, I have come to discover that on the latest binaries (941, compiled on Linux FC4), the quest globals are in fact working as expected - at least in the setting and deleting of them. My initial problem was that Camin was not set to use qglobal in his npc record. Soon as I set that, his script read the variables perfectly and the quest could continue as designed.

I have not confirmed that the globals are deleted, either. After leaving a dynamic zone repeatedly, and even taking down the world and rebooting numerous times, the quest_global table remained in tact.

Sorry, Angelox. I cannot reproduce what I believe you are seeing. :(

I have numerous emails from people who can't even get 941 to work at all. Anyway, I have already devised a way to patch what ever source is put out, and will enable my quest globals to work (Hopefully, 942 will work for me, else I have to figure out what was broke after 940).
This is another problem eqemu has;
No testers - since everyone is busy doing "their thing", things like trying out new versions of the emu on their "custom server" is out of the question. In fact, many of the people have already altered the source code to benefit their on personal needs for their server. Now, I know you try, and I try, and a few others here try - this is very important, but what happens to the information we put out? who takes it in and makes the fixes?
If you're working on a project like this, you need "beta testers" , and the more you get, the better. Here are some reasons;Things/changes don't react alike on different computer setups, playing the game generates special feed back from the "game players" point of view. You can say; "I'm doing this because I think it's right", but you also need to be able to say, "I'm doing this because the players/users recommend it."
But , in our case, we have no beta testers, we have no "open source" database, all we have is a few servers that post what they did once in a while. And, we have somewhat of an "open source" emulator, which was more "open" when FNW was around (what happened to FNW?).
Who knows what other solutions there are?

Sometimes I wonder if SOE, is observing all this "progress" - I know I would If I owned SOE-EQ. Right now, the emulator is more beneficial than harmful to SOE; It's like a free "Demo' of the real EQ. you get to see a lot, but the real game for the gamers is on LIve.
As we stand now, we will never become no big "threat" to EQ live. I know you're thinking, "but Sony has all the updates and working expansions!" My reply is, how can Sony make a couple of "progression" servers with not even the Kunark expansion added, and the servers became so packed with players, you could hardly play?
No expansions at all, mind you. And when I played, it was *hard* exp was slow, just like the old times.
What are we doing wrong?

well for starters the emu doesnt already have an active base of like 700,000 players like soe does... and they spent a ton of time hyping it up, but the population on the progression servers died down a lot after the initial release.

i agree tho that there are too many people who are using the emu without helping the community with their changes, and that comes from the childish concept of, well i did all that work to make my server better than the others, so why share it.

I've spent the past 2 weeks revamping all the quests in the tutorial to emulate the live servers as best as we can. after this is pok. even on angelox's database theres a lot of missing npc's and doors, and god knows a TON of quests...

would i like to just say "Hey the allendium server is the closest to live in all of eqemu! Come play on my server!" yeah sure... part of me kinda wants the whole "OOOOOOOO AHHHHHHH" factor, but that's not what an open source project is about so once it's all done, ill be making SQL files to modify your ax_peq database into shape for the tutorial files i made. still workin on a little bug with ruga... he doesnt want to repop for some reason and i cant figure out if its a binary bug or database bug :p