On a general note regarding the choice of shutdown options:
If you run into problems with "deallocate memory" not related to an addon, (i.e. occurring without loading any modules not part of the Orbiter core), then let me know about it.
For developers, I would very strongly recommend the "deallocate memory" option during writing and testing your addon modules, to spot problems early.
Some other things developers are strongly encouraged to test:
Any other suggestions for useful generic tests for addon developers?
- "deallocate memory" is the cleanest option, because it tries to clean up allocated memory and reset its state in an orderly fashion
- the "terminate process" options are hacks to work around modules not cleanly shutting down
If you run into problems with "deallocate memory" not related to an addon, (i.e. occurring without loading any modules not part of the Orbiter core), then let me know about it.
For developers, I would very strongly recommend the "deallocate memory" option during writing and testing your addon modules, to spot problems early.
Some other things developers are strongly encouraged to test:
- make sure multiple instances of your module (if applicable) work ok, e.g. multiple simultaneous instances of a vessel class or MFD mode)
- for vessel addons: make sure that deleting a vessel instance works (you can delete vessels in the scenario editor)
- for MFD addons: if your MFD can reference an object (e.g. target a vessel), make sure that deleting that vessel while targeted by the MFD is handled gracefully
- for all addon types: make sure that jumps in simulation time forward and backward are handled ok (simulation time can be set in scenario editor)
Any other suggestions for useful generic tests for addon developers?