Quest Error Log & Other Changes
Posted: Fri Jun 01, 2018 10:05 pm
I'm working through a few items in the QuestMachine code this weekend. The first change I'm making is to redirect all quest exceptions, information, and errors to their own log: "quest_log.txt".
You will find the quest_log file in the persistent data path (same place as save games and settings.ini). Incidentally this is the same place the "output_log" file will be placed after the upgrade to Unity 2018.1.2f1 in a couple of weeks, so both logs will be in the same place.
Just like the output log, the quest log file will be cleared every time you start the game. Any errors caught during compilation or execution will be redirected to the quest log file instead. I'll also update any Debug.Log() quest-related output to use this location and add some more detail where possible.
The second change is wrapping both quest compilation and execution in try/catch blocks. Any exceptions encountered during quest execution will be redirected to the quest log from the usual output log target.
The main benefit of improving exception handling is to help prevent bad quests causing problems in other systems (e.g. talk system is very sensitive to dud quest data). If a quest crashes, it will be terminated instantly so that downstream systems don't end up with bad data from failed quests. There are loads of reasons a quest can go bad, including just basic stuff like syntax errors and logic problems when writing them. My goal is to minimise problems from as many of these as possible.
Basically, I'm working towards creating a kind of "execution sandbox" for the quest system, something should have done from the start.
You will find the quest_log file in the persistent data path (same place as save games and settings.ini). Incidentally this is the same place the "output_log" file will be placed after the upgrade to Unity 2018.1.2f1 in a couple of weeks, so both logs will be in the same place.
Just like the output log, the quest log file will be cleared every time you start the game. Any errors caught during compilation or execution will be redirected to the quest log file instead. I'll also update any Debug.Log() quest-related output to use this location and add some more detail where possible.
The second change is wrapping both quest compilation and execution in try/catch blocks. Any exceptions encountered during quest execution will be redirected to the quest log from the usual output log target.
The main benefit of improving exception handling is to help prevent bad quests causing problems in other systems (e.g. talk system is very sensitive to dud quest data). If a quest crashes, it will be terminated instantly so that downstream systems don't end up with bad data from failed quests. There are loads of reasons a quest can go bad, including just basic stuff like syntax errors and logic problems when writing them. My goal is to minimise problems from as many of these as possible.
Basically, I'm working towards creating a kind of "execution sandbox" for the quest system, something should have done from the start.