quest_globals broken?

[Angelox]

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

[Aerewen]

add this to the quest for debug.

sub EVENT_SAY{
  if ($text=~/hail/i){
    quest::say("wizepic is: $wizepic");
  }
}

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

[John Adams]

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!)

[John Adams]

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?

[Aerewen]

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

[John Adams]

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.

[Aerewen]

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:

sub EVENT_SIGNAL{
  if($signal == 1){
    $intro = undef;
  }
}

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:

quest::signalwith(189013,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.

[John Adams]

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

[Angelox]

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?

[Aerewen]

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

[John Adams]

I've already posted my "wish list of 2007", and it includes a request for sharing, testing, more development, and fix/enhancement repositories. We'll see how this pans out.