6,566
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
Switch to {{gitorious source}} to fix the broken Gitorious link.
Red Leader (talk | contribs) (→Status / related Commits (01/2016): Commit templates) |
(Switch to {{gitorious source}} to fix the broken Gitorious link.) |
||
| Line 177: | Line 177: | ||
** materials | ** materials | ||
* 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 {{flightgear commit|a52c0882}}. 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 {{flightgear commit|a52c0882}}. 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, {{gitorious source|proj=fg|repo=canvas-hackers-fgdata|commit=ad77a4db14a00103f30c9fb219d3dab72e479ca3|file=Boot/default.boot|text=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 | ||