Bug #131: Unknown Quest State prevents login
| ID | #131 |
|---|---|
| Submitter | Apollo |
| Product | EOSERV |
| Severity | Normal |
| Status | CLOSED, FIXED |
| Submitted | 19th Sep 2012 |
| Updated | 25th Sep 2012 |
| Rev# | Date | Description |
|---|---|---|
| r352 | 25 Sep 2012 17:19:48 UTC | Store unloadable quests/states as inactive quest records (bug #131), Allow shoddy conversion ... |
11 years, 36 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
11 years, 36 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).
11 years, 36 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.
11 years, 36 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
11 years, 36 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.
11 years, 35 weeks ago
Confirmed to wipe out the quest state currently, changing "4,foobar,{};" in to "4,,{};" (which then gives the blank unknown quest state)
11 years, 35 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