20,741
edits
Advanced weather: Difference between revisions
m
→Development
m (Updated download link to latest version (see newsletter)) |
m (→Development) |
||
| 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] | ||
* 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>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> | ||
* 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>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] | ||
| Line 116: | Line 116: | ||
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that. | * for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that. | ||
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe. | * excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe. | ||
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94801] | * to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though). | ||
== Feature requests on the C++ side == | == Feature requests on the C++ side == | ||