Weird Bug with quest Globals
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 : Code:
sub EVENT_SAY { [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 : Code:
sub EVENT_SAY { [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. |
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. |
I was actually running into the same issue. As a matter of fact, after looking through the zone logs, I saw this line:
Code:
setglobal error inserting pop_poj_mauvin : #1048: Column 'expdate' cannot be null 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). |
Quote:
|
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* |
All times are GMT -4. The time now is 04:57 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.