EOSERV Bug Tracker > Bug #131: Unknown Quest State prevents login

Bug #131: Unknown Quest State prevents login

Unknown Quest State prevents login
ID #131
Submitter Apollo
Product EOSERV
Severity Normal
Status CLOSED, FIXED
Submitted 19th Sep 2012
Updated 25th Sep 2012
Related SVN Revisions
Rev# Date Description
r352 25 Sep 2012 17:19:48 UTC Store unloadable quests/states as inactive quest records (bug #131), Allow shoddy conversion ...
Apollo Submitter 12 years, 32 weeks ago

When using modern builds of EOSERV over primative Vodka-esque stored quest database entries EOSERV will throw the following errors:

[ERR] Client caused an exception and was closed: XXX.XXX.XXX.XXX

[ERR] Runtime Error: Unknown quest state: <--yes really blank

EOSERV should possibly convert or ignore invalid states and attempt to repair at the first character Save() call.

Also noted, users moving from primative servers may launch EOSERV modern with some broken syntax that prevents the quests from working. It might benefit EOSERV to deactivate the player's quest if the state does not exist and report to error log rather than forcing a client exception to disconnect the player.

Comments

Sausage Developer 12 years, 32 weeks ago

The mixing of those two makes an interesting problem. If you copy all of your quests and 10% of them stop working, everyone who logs in will end up getting their progress wiped out (possibly leaving them stuck somewhere).

Apollo Submitter 12 years, 32 weeks ago

Stuck somewhere might be better than a no-login scenario. At least a logged in character can be administrated via command to return to the proper quest-state, other wise the server-op or whoever has raw database access would be required to manually edit the quest field to restore the player to normal gameplay.

Sausage Developer 12 years, 32 weeks ago

I'm not sure how your quest state ended up blank (that's the only reason the error message would be actually blank). It's probably worth looking in to why that is and correcting the records before-hand if it's significant. I'd put my money on Addison using blank states for finished quests, though I don't know.

To match the behavior of deleted quests I think that the states should be stored in case the quest is just temporarily broken, and automatically resume if the state is re-added. This depends a little on some code that would be added for bug #42 to stop/resume quests when they're removed/added at runtime.

I'm also adding a feature request for admin commands for viewing and setting quest states.

Updated Status to CONFIRMED

Apollo Submitter 12 years, 32 weeks ago

Found this in the error.log on the previous boot:

[ERR] Runtime Error: Unknown quest state: question;33

It seems EOSERV just destroyed the quest save after this.

Sausage Developer 12 years, 31 weeks ago

Confirmed to wipe out the quest state currently, changing "4,foobar,{};" in to "4,,{};" (which then gives the blank unknown quest state)

Sausage Developer 12 years, 31 weeks ago

Fixed in r352

Updated Status to CLOSED, FIXED

Add Comment

Please don't post unless you have something relevant to the bug to say.
Do not comment to say "thanks" or "fix this please".

Please log in to add comments. EOSERV Bug Tracker > Bug #131: Unknown Quest State prevents login