20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
m
→Future Changes (post 3.2)
No edit summary |
|||
| Line 102: | Line 102: | ||
* Any systems with other threads need to be inerted during the reset. In particular any osgDB paged loaders, or TerraSync threads, need to be paused or audited for safety. TerraSync should be relatively simple (since it's a regular subsystem), osgDB interactions, especially with properties, will be harder. | * Any systems with other threads need to be inerted during the reset. In particular any osgDB paged loaders, or TerraSync threads, need to be paused or audited for safety. TerraSync should be relatively simple (since it's a regular subsystem), osgDB interactions, especially with properties, will be harder. | ||
** All animations and effects will need to be destroyed for sure, since they have property tree references. | ** All animations and effects will need to be destroyed for sure, since they have property tree references. | ||
== Future Changes (post 3.2) == | |||
Based on experimenting with [[Initializing Nasal early]] and [[FGCanvas]], here's some feedback to hopefully further simplify the whole process and make it more flexible in the future: | |||
* getting rid of singletons could help simplify the init process | |||
* lots of problems result from the ambiguity of resets vs. re-init/repositioning, it would make sense to extend SGSubsystem accordingly and expose two virtual methods to handle reset and repositioning explicitly per object, and not separately | |||
* making sure that all subsystems actually implement SGSubsystem would be helpful (e.g. NavDataCache) | |||
* there are a few subsystems that are intended to remain PERSISTENT per session, e.g. terragear, time, lighting, events - those should probably be put into a dedicated SGSubsystemGroup that isn't subject to reset/re-init at all, e.g. outside the actual subsystem_mgr ? | |||
* we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things, e.g.: | |||
** CORE: logger, prop-interpolator, performance-mon | |||
** AUDIO: sound, fgcom, voice | |||
** NETWORK: io, mp, http | |||
** VIDEO: gui, Canvas, CanvasGUI | |||
** SCENERY: tile-manager, lighting, environment, ephemeris | |||
** WORLD: ai, atc, traffic | |||
** AIRCRAFT: flight, controls, systems, instrumentation, hud, cockpit-displays, replay, history, autopilot, route-manager | |||
* init order is currently kinda fragile, it'd make sense to internally use each subsystem's bind/unbind and postinit() methods to ensure that cleanup is handled there, and not in fgPostInitSubsystems() or fgStartNewReset(), each run-level/group would then internally manage things. | |||
[[Category:Developer Plans]] | [[Category:Developer Plans]] | ||