20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
m
→Future Changes (post 3.2)
m (→Future Changes (post 3.2): https://gitorious.org/fg/flightgear/commit/0f14a2d73ba4a2f6447033e6a85d928896702b6c#c107382) |
|||
| Line 107: | Line 107: | ||
* getting rid of singletons could help simplify the init process | * getting rid of singletons could help simplify the init process | ||
* fixing up subsystems with non-default ctors: | |||
** performance-monitor | |||
** xml-autopilot | |||
** xml-proprules | |||
** httpd | |||
** events | |||
** materials | |||
* 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,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] | * 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] | ||