20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
→Future Changes (post 3.2)
m (→Future Changes (post 3.2): https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381) |
|||
| Line 110: | Line 110: | ||
* making sure that all subsystems actually implement SGSubsystem would be helpful (e.g. NavDataCache) | * 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, or maybe using a new GroupType ? | * 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, or maybe using a new GroupType ? | ||
* fgCreateSubsystems() in fg_init.cxx and subsystemFactory.cxx are now overlapping in functionality, and we've seen some inconsistencies here that may further complicate matters[https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381]. It would make sense to get rid of fgCreateSubsystems() and move this into scripting space by using the add-subsystem fgcommand APIs (have this kinda working in the [[Initializing Nasal early]] branch. | * fgCreateSubsystems() in fg_init.cxx and subsystemFactory.cxx are now overlapping in functionality, and we've seen some inconsistencies here that may further complicate matters[https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381]. It would make sense to get rid of fgCreateSubsystems() and move this into scripting space by using the add-subsystem fgcommand APIs (have this kinda working in the [[Initializing Nasal early]] branch, [https://gitorious.org/fg/canvas-hackers-fgdata/source/ad77a4db14a00103f30c9fb219d3dab72e479ca3:Boot/default.boot using a boot script]). | ||
* we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things Tom's Canvas code is already using the notion of a PropertyBasedElement which wraps SGSubsystemGroup and SGPropertyChangeListener. This means we could allocate/free groups of subsystems and treat them as run-levels e.g.: | * we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things Tom's Canvas code is already using the notion of a PropertyBasedElement which wraps SGSubsystemGroup and SGPropertyChangeListener. This means we could allocate/free groups of subsystems and treat them as run-levels e.g.: | ||
** CORE: logger, prop-interpolator, performance-mon | ** CORE: logger, prop-interpolator, performance-mon | ||