20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
m
→Future Changes (post 3.2): https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381
m (→Future Changes (post 3.2): canvas PropertyBasedElement would managing RunLevels kept in SGSubsystemGroups, controlled via SGPropertyChangeListener) |
m (→Future Changes (post 3.2): https://gitorious.org/fg/flightgear/commit/a52c0882a14aa3e4e6edd3f94dab0d5f8f0270c3#c107381) |
||
| Line 109: | Line 109: | ||
* 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-we'd want to extend SGSubsystemGroup accordingly, to ensure it can delegate events to each member | * 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-we'd want to extend SGSubsystemGroup accordingly, to ensure it can delegate events to each member | ||
* 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 ? | * 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. | |||
* 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 | ||