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/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382
m (→Future Changes (post 3.2): https://gitorious.org/fg/flightgear/commit/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382) |
|||
| Line 108: | Line 108: | ||
* getting rid of singletons could help simplify the init process | * 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-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,especially those that are separately handled by reset/re-init (e.g. FGInterpolator, NavDataCache) - see Tom's commit at [https://gitorious.org/fg/flightgear/commit/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382] | ||
* 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, [https://gitorious.org/fg/canvas-hackers-fgdata/source/ad77a4db14a00103f30c9fb219d3dab72e479ca3:Boot/default.boot using a boot script]). | * 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]). | ||