quest_globals broken?

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