Weird Bug with quest Globals

[LordKahel]

Using build 1062.

I am unable to save a Quest variable with the setglobal command if my duration is "F" .

Here is a test quest and the log results.

With this code :
sub EVENT_SAY {

if ($text=~/hail/i) {

quest::say("Hail to you, lesser being!");

} elsif ($text=~/Set/i) {

quest::say("Setting your stupid var human !");
quest::delglobal("AVAR");
quest::setglobal("AVAR", 1, 0, "Y50");

} elsif ($text=~/Get/i) {

quest::say("Here is your results ".$qglobals{AVAR});

}

}

I get this result And i can see the AVAR entry in the quest_globals table:

[Sun Dec 09 17:49:24 2007] Clearing quest memory cache.
[Sun Dec 09 17:49:27 2007] You say, 'set'
[Sun Dec 09 17:49:27 2007] Herald Telcha says 'Setting your stupid var human !'
[Sun Dec 09 17:49:29 2007] You say, 'get'
[Sun Dec 09 17:49:30 2007] Herald Telcha says 'Here is your results 1'

If i change the duration to 'F' or 'f' like this :

sub EVENT_SAY {

if ($text=~/hail/i) {

quest::say("Hail to you, lesser being!");

} elsif ($text=~/Set/i) {

quest::say("Setting your stupid var human !");
quest::delglobal("AVAR");
quest::setglobal("AVAR", 1, 0, "F");

} elsif ($text=~/Get/i) {

quest::say("Here is your results ".$qglobals{AVAR});

}

}

I then get this result and the AVAR entry is not in the quest_globals table:

[Sun Dec 09 17:49:58 2007] You say, '#reloadquest'
[Sun Dec 09 17:49:58 2007] Clearing quest memory cache.
[Sun Dec 09 17:50:00 2007] You say, 'set'
[Sun Dec 09 17:50:00 2007] Herald Telcha says 'Setting your stupid var human !'
[Sun Dec 09 17:50:03 2007] You say, 'get'
[Sun Dec 09 17:50:03 2007] Herald Telcha says 'Here is your results '


If i change it back to a duration like Y5 it will work and the AVAR entry will be saved in the table.

Every quest and the c++ code show that using "F" will put a unlimited duration but it doesnt work for me.

Any idea will help .
Thank you for your time.

[LordKahel]

Disregard my post , I found what was causing the problem.

The expdate column was set to not accept NULL values. I changed it to permit NULL and it work perfectly now.

[AndMetal]

I was actually running into the same issue. As a matter of fact, after looking through the zone logs, I saw this line:

setglobal error inserting pop_poj_mauvin : #1048: Column 'expdate' cannot be null

After doing some research, it appears that the "expdate" column was changed in the PEQ DB on 11/14/2007 (see Diff of /peq_db/quest_globals.sql (http://peq.cvs.sourceforge.net/peq/peq_db/quest_globals.sql?r1=1.1&r2=1.2)) to accept NULL values. However, it is part of the "load_empty_users.sql" file, which I know I didn't run when updating my DB.

After changing the column in the database manually to accept NULL values (while the server was still running), my quests globals were able to update for quests that use the F duration (PoP flags, etc).

[cavedude]

After doing some research, it appears that the "expdate" column was changed in the PEQ DB on 11/14/2007 (see Diff of /peq_db/quest_globals.sql (http://peq.cvs.sourceforge.net/peq/peq_db/quest_globals.sql?r1=1.1&r2=1.2)) to accept NULL values. However, it is part of the "load_empty_users.sql" file, which I know I didn't run when updating my DB.

Yeah, that column is correct on CVS but hasn't worked its way into a release yet. The next release of the db will have it current. :)

[AndMetal]

Actually (and I had to double-check to make sure I saw it correctly), the load_empty_users.sql file from peq-ykesha-release.zip DOES include the change. However, unless you clear out your users, then load them back in (which I personally did NOT do), the change won't be made (which is the problem I had).

I guess the simple solution would be to add a line somewhere to alter the table, like in load_system.sql, etc, to reflect the change. Then again, the "better" thing might be just to post a notice that you may have to change it manually. *shrug*