|Engine Module Type String||CrashRecovery|
|Module Type Usage||Single Type|
Recovers the engine from an error state caused by a module malfunctioning. While the crash recovery module is taking over the action the engine is still up and running. Hence a crash recovery module can be used to do live debugging of the engine. Developers can use here a powerfull module to provide them with debugging functionality and the gamer can chose a simple recovery module that allows him to continue to play even in case of a problem if this is possible. In some severe cases it is not possible to continue safely. This is at the discretion of the crash recovery module.
One of the main strength of the Drag[en]gine is the fact that the game engine is still up and running during a catchable error condition. This way the state of the engine can be examined using various sources.
One is the Exception Trace provided by the game engine and written to by the failing module. The trace contains informations interesting for the programmer but not so usefull for a user.
Another possibility is to examine the entire Module Systems about the current state. Typically a summary of the running modules and their loading states is provided but more information can be added for developing purpose.
A third way is to use the Module Parameters which allow to check out or alter working parameters of a module. Those parameters are designed to be used by more advanced players to fine tune the working of modules. Parameters are usually save to use by the player. Parameters can have only a restricted value type which is why there exists a more complex system.
At last to provide a sort of standard debugging utility every module is required to expose a Command Interface. This interface allows the user to send a formatted text command directly to the module receiving a text response which can then be displayed. Every module has to support at least the 'help' command. This way informations can be queried or set without having to program complex Crash Recovery Modules but is restricted by what commands the module exposes. This way is designed for developers to debug their modules without having to mess with the Crash Recovery Module.
If an error is detected the engine switches into recovery mode. In this mode the Graphic System is put into headless mode and all other Single Systems are put into a sort of sleep mode. In this state the engine is put on halt but still up and running. The Crash Recovery Module now displays a set of windows to the user guiding him through the recovery process. This usually consist of at least a summary of the running state of the module systems. The user has to be able to change at least the currently used module for each Single System or to restart them. After dealing with the problem the Crash Recovery Module has to make sure that all Single Systems are up and running. The engine will not continue running if not all Single Systems are working. Once this is done the engine continues running from the point it let off. Furthermore the user can decide to shutdown the engine instead of trying to continue running. This is required to avoid a recovery-loop in a situation where a module is continuously failing.