Advanced weather: Difference between revisions

m
→‎Development: remove more obsolete items
m (→‎Development: remove more obsolete items)
Line 109: Line 109:


* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]
* <del>We need to add an option to completely disable the local weather system, so that it doesn't run at all, or even better so that it doesn't even get loaded (this is possible by explicit rather than implicit loading using the io.nas module, see next item). This should make it much easier to do troubleshooting, and it would be easier for users to tell if their problems are related to the local weather system or not. [http://flightgear.org/forums/viewtopic.php?f=5&p=96439#p96439]</del>
* <del>We should seriously think about moving the local weather system to its own directory, either as a sub directory within $FG_ROOT/Nasal, or possibly even directly in $FG_ROOT/LocalWeather ? The local weather system is becoming one of the most complex systems ever implemented in Nasal, and so it is only good and natural to modularize it even further to keep everything organized (i.e. split code into distinct modules), however the $FG_ROOT/Nasal directory is getting increasingly cluttered due to this ((I am getting the impression that if we had an active Nasal maintainer, that person would rightly complain about this ...because the local weather stuff is not really a part of the "standard library" but instead a completely new system)). It would be better to move everything to a dedicated directory, and only leave a small wrapper script in $FG_ROOT/Nasal that handles loading/unloading of complete systems, loading the corresponding modules explicitly (rather than implicitly due to being located in the $FG_ROOT/Nasal directory) using the helpers available in the io.nas module. The neat thing about using this approach is that it would also be trivially possible to enable/disable the complete local weather system just by setting a property during startup. In addition, it would help keeping things organized. This is especially because the $FG_ROOT/Nasal directory is -by convention- considered to be the "library" directory, but addons like the local weather system (or the bombable addon) are complete systems, which would better live in separate places.</del> (implemented by ThorstenB)
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358]
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358]