A local weather system (v1.4 available)

[Thorsten]

The lines of the strange message you did not quote

Code: Select all

Compatibility layer: Checking available Nasal APIs:
(this may cause harmless error messages when hard-coded support is lacking)
##########################################
(...)


contain the explanation: The Nasal script checks if a hard-coded vector support for terrain sampling is available, since it isn't an error is generated, and the script concludes that no support for vectors is available. It is just as the script says (why doesn't anyone believe it?), the error is entirely harmless and unrelated to any problems you have with global weather.

Problems with the global weather menu have been discussed on the developer's list for a while - I thought it has been resolved in the latest GIT version, but I may be wrong.

[Hooray]

To further clarify: The errors you are seeing are not critical at all, it's exactly like Thorsten says: The Nasal script tries to see if certain features are available or not. So what it is doing is trying to execute code that utilizes these features, if the feature are available the code will not show any errors at all, if the feature are not available, the code will trigger an exception in Nasal space, this will be caught and evaluated.

This allows the local weather system to query its runtime environment dynamically. The patch is absolutely irrelevant, if you don't have it, it doesn't matter: there is a Nasal based "fallback" (the default routine) that will be used instead. However, IF the routine was detected, the local weather system will "notice" this and consequently use this routine. This could for example have a positive effect on frame rate.

Please understand that this is not at all related or specific to this geodinfo patch that I created some time ago: You can disable the "offending check" easily, just go to $FG_ROOT/Nasal/compat_layer.nas, line 128, column 4 and comment out the corresponding call:

Code: Select all

_setlistener("/sim/signals/nasal-dir-initialized", func {
   print ("Compatibility layer: Checking available Nasal APIs:");
   print ("(this may cause harmless error messages when hard-coded support is lacking)");
   print ("##########################################");
   features.geodinfo_supports_vectors= check_geodinfo_vec ();
   print("features.geodinfo_supports_vectors=", features.geodinfo_supports_vectors);
   print ("##########################################");
   print("Compatibility checks done.");
});

But let me state clearly again: this particular patch is not relevant or important at all, you don't need it. There is now hard coded support in git for doing what the patch was supposed to address. And so you can also safely remove the check if you want to.
However, please keep in mind what this code is really doing: It ensures a high degree of portability for this and future versions of the local weather system, as well as future versions of FlightGear. - regardless of the feature being used.

By doing what the script does, it can basically try to tell what version of FlighGear is being used (and even use experimental features in Git), so that it can make the corresponding decisions for making use of certain features or not. This allows the local weather system to theoretically work with past and future FlightGear versions pretty easily, it's just a matter of using this consequently.

Please, *do* remove the check if it still confuses you, but please also try to understand what this is generally all about: backward portability, something that FlightGear has traditionally been pretty bad at, so far.

If you are a Linux/Unix user, the concept should not be that complicated to understand: every configure script is basically doing the same thing to examine the runtime environment: try to build/run code and see if it works or not, with the exception being that the corresponding errors are redirected to a file instead of STDOUT then.

If people are still having problems with this, I can provide a patch for the FlightGear logging system, so that it can be temporarily "muted" when doing such checks, that should be a fairly easy thing to do.


Thorsten, if you agree, I would suggest to ask one of the core developers to disable this check for the time being, especially because it is currently causing so much confusion due to issues with the global weather system, but also because it got sort of depreciated already. So I guess it will simply be better to keep this check disabled right now. We will however need to find a way for dealing with those "issues" for future portability checks. What do you think?

[grtux]

The lines of the strange message you did not quote

...............................;;
Problems with the global weather menu have been discussed on the developer's list for a while - I thought it has been resolved in the latest GIT version, but I may be wrong.

No, at home, it does not work, does anybody else noticed it ?

Don't mind, i have a backup of the old menu, which is working.
To me the real weather is the most important.
And as an option a lot realistic of scenarii, which could be very accurate, reproducing the real, and sometime exceptional, weather conditions ( done by expert)

@Hooray

thanks, i will remove the call, no problem

Gérard

[Torsten]

If people are still having problems with this, I can provide a patch for the FlightGear logging system, so that it can be temporarily "muted" when doing such checks, that should be a fairly easy thing to do.

Have a look at globals.nas:

Code: Select all

##
# Print log messages in appropriate --log-level.
# Usage: printlog("warn", "...");
# The underscore hash prevents helper functions/variables from
# needlessly polluting the global namespace.
#
__.dbg_types = { none:0, bulk:1, debug:2, info:3, warn:4, alert:5 };
__.log_level = __.dbg_types[getprop("/sim/logging/priority")];
var printlog = func(level) {
    if(__.dbg_types[level] >= __.log_level) call(print, arg);
}


You could send your messages out through printlog with a log-level of "warn", so it only gets printed on request of the user.

[Hooray]

You could send your messages out through printlog with a log-level of "warn", so it only gets printed on request of the user.

Well, thanks - but the issue is not Nasal
The errors are coming from the C++ side of things. Without having looked at the code in question so far, I was thinking of extending the SG_LOG macro so that it can be muted by setting a property, i.e. for code that is known/supposed to cause errors. It would probably be sufficient to introduce a "NONE" log level for this, and then set the log level dynamically.

[Torsten]

That's not Nasal? Am I on the wrong track?

Please understand that this is not at all related or specific to this geodinfo patch that I created some time ago: You can disable the "offending check" easily, just go to $FG_ROOT/Nasal/compat_layer.nas, line 128, column 4 and comment out the corresponding call:

Code: Select all

_setlistener("/sim/signals/nasal-dir-initialized", func {
   print ("Compatibility layer: Checking available Nasal APIs:");
   print ("(this may cause harmless error messages when hard-coded support is lacking)");
   print ("##########################################");
   features.geodinfo_supports_vectors= check_geodinfo_vec ();
   print("features.geodinfo_supports_vectors=", features.geodinfo_supports_vectors);
   print ("##########################################");
   print("Compatibility checks done.");
});

[Hooray]

Well, yes and no: The code you are quoting is obviously the Nasal source code, and YES it does contain some conventional "print" calls (you are right, we should probably use log messages for those, too), those calls are however not directly responsible for the error messages that grtux posted, or that you'll probably see yourself once you run FlightGear without said patch. Those are indeed ERROR messages, issued by the fgfs core:

Warning: invalid line segment passed to IntersectVisitor::addLineSegment(..)
nan nan nan nan nan nan segment ignored..

PS: Given the confusion this has meanwhile created, I would indeed suggest to disable this particular check for the geodinfo API, it seems this particular patch isn't going to be needed anymore due to your terrain sampler work, so we can consider the check depreciated. Just comment out the corresponding line, or even the complete call to the checker routine, to calm down people... still, we will need to do something along those lines for finding new/modified Nasal APIs in the fgfs core at some point. Except of course, if you should prefer to hard code every conceivable feature in C++ space, instead of improving the Nasal APIs some more

[Thorsten]

Just briefly from my side:

The feature check and resulting error message is in because I was under the (false) impression that the vector support would be in GIT and that therefore GIT users would not see any error message at all. This particular check will be removed in the next release (I haven't gotten around doing so), but it's supposed to be replaced by a less noisy check for the hard-coded presampler.

I agree with Hooray that having mand maintaining backward compatibility where possible is valuable. So I would be very much in favour of having some less noisy tool to check available hard coded support at runtime.

[grtux]

Hi,

Again with the live weather.

In spite of the last commit :
Commit c082f069ffae364225c64b08e89cccaf781407c3

the live data is longer not working.
However, i have been able to make it working with :
=> 1/ recover the old Nasal code which was in gui/dialogs/weather_scenario.xml
=> 2/ overwrite with it, the existing nasal code which is in gui/dialogs/weather.xml
=> 3 /insert the following code in gui/dialogs/weather.xml ( copied from the old gui )

Code: Select all

 <button>
          <legend>Apply</legend>
          <equal>true</equal>
          <binding>
              <command>nasal</command>
              <script>apply()</script>
          </binding>
          <binding>
              <command>dialog-apply</command>
          </binding>
      </button>
     
      <button>
          <legend>Instant-Apply</legend>
          <equal>true</equal>
          <binding>
              <command>nasal</command>
              <script>apply()</script>
          </binding>
          <binding>
              <command>dialog-apply</command>
          </binding>
          <binding>
              <command>reinit</command>
              <subsystem>environment</subsystem>
          </binding>
    </button>


before

Code: Select all

<checkbox>
        <name>metar-updates-winds-aloft</name>
        <property>/environment/params/metar-updates-winds-aloft</property>
        <label>Update winds aloft</label>
        <live>true</live>
        <binding>
          <command>dialog-apply</command>
          <object-name>metar-updates-winds-aloft</object-name>
        </binding>
        <name>aloft</name>
      </checkbox>


With that, everything is right.

I suspect something wrong within the new weather nasal code, sorry i could not find the bug.

Anyhow the button are more ergonomic, we know exactly what we are doing ( automatic system are often ghost )

Gérard

BTW: i can give the nasal code which works, if wanted

[Hooray]

I suspect something wrong within the new weather nasal code, sorry i could not find the bug.

If you are talking about the "local weather system", I don't think this is related at all.

However, you can easily see for yourself by completely disabling the local weather system, I don't think there is currently such an option (?) - but you could simply rename the LW related Nasal files in $FG_ROOT/Nasal/ to *.txt files, that would prevent them from getting loaded and run. If your problems still appear, it's obviously not related to LW.

I think we will need to add an option to be able to disable LW using a property, at least during startup - preferably even at runtime (using a listener).
I already talked to Thorsten about restructuring some things, so that the $FG_ROOT/Nasal folder doesn't get more and more cluttered as the LW system is getting more and more modular...
I suggested to move the local weather system to a dedicated folder either as a sub directory within the Nasal directory or possibly even outside the Nasal folder (e.g. $FG_ROOT/LocalWeather ?). The only thing that we would then leave in $FG_ROOT/Nasal would be a small wrapper script that provides control capabilities for loading and unloading the LW system dynamically. That way, we would end up with a less cluttered $FG_ROOT/Nasal folder and the LW system would get its own "home" within the base package, where we can keep all file and continue modularizing the system.

For adding a new command line option, we could just add options to $FG_ROOT/options.xml and $FG_ROOT/Translations/strings-default.xml:

Code: Select all

diff --git a/Translations/strings-default.xml b/Translations/strings-default.xml
index 3988548..3fa2770 100644
--- a/Translations/strings-default.xml
+++ b/Translations/strings-default.xml
@@ -299,5 +299,9 @@
  <trace-read-desc>Trace the reads for a property;</trace-read-desc>
  <trace-write-desc>Trace the writes for a property;</trace-write-desc>
  <log-level-desc>Specify which logging level to use</log-level-desc>
+
+ <!-- Local Weather Options -->
+ <local-weather-options>Local Weather Options</local-weather-options>
+ <disable-local-weather>disable the local weather system, so that it does not even get loaded</disable-local-weather>

 </PropertyList>
diff --git a/options.xml b/options.xml
index 25e3d8b..6dfcbf7 100644
--- a/options.xml
+++ b/options.xml
@@ -1111,6 +1111,16 @@
    </option>
   </section>

+  <section>
+    <name>strings/local-weather-options</name>
+
+    <option>
+     <name>disable-local-weather</name>
+     <description>strings/disable-local-weather</description>
+    </option>
+
+  </section>
+
  </options>

 </PropertyList>

So that we see a new option when running fgfs --help --verbose:

Debugging Options:
--enable-fpe Abort on encountering a floating point
exception;
--fgviewer Use a model viewer rather than load the entire
simulator;

--log-level={bulk,debug,info,warn,alert}
Specify which logging level to use
--trace-read=property Trace the reads for a property;
multiple instances can be used
--trace-write=property Trace the writes for a property;
multiple instances can be used

Local Weather Options:
--disable-local-weather disable the local weather system, so that it
does not even get loaded

And then add a corresponding line to $FG_SRC/Main/options.cxx to the fgOptionArray[]
This would be the most elegant thing, however it would require a very small C++ patch. For the time being, just using --prop:/sim/startup/disable-local-weather=1 would be easier, because it requires not C++ changes.

To be honest, I find it surprising that it is at all necessary to add command line options to the C++ source code, especially if they just set properties, this could be completely XML configurable:

Code: Select all

<option>
     <name>disable-local-weather</name>
     <description>strings/disable-local-weather</description>
       <property>/sim/startup/disable-local-weather</property>
       <type>bool</type>
       <value>true</value>
       <default>false</default>
     </option>


In other words, define an option:

• "--disable-local-weather"
• get the translation from "/strings/disable-local-weather"
• set the property "/sim/startup/disable-local-weather"
• make it type "bool"
• set the value to "true" if the option is specified
• set the default setting to "false" if not specified

That would seem useful for many other configuration settings, and users could then directly add those to the base package, without C++ patches.
Many of the options in the fgOptions array could then be moved to options.xml instead.


In Nasal, we would then just see if /sim/startup/disable-local-weather was set or not, and accordingly prevent the startup() function from being run:

Code: Select all

diff --git a/Nasal/compat_layer.nas b/Nasal/compat_layer.nas
index a91a0cc..b52cb60 100644
--- a/Nasal/compat_layer.nas
+++ b/Nasal/compat_layer.nas
@@ -121,6 +121,7 @@ var check_geodinfo_vec = func {
   return 0;
 }

+if (! getprop("/sim/startup/disable-local-weather"))
 _setlistener("/sim/signals/nasal-dir-initialized", func {
    print ("Compatibility layer: Checking available Nasal APIs:");
    print ("(this may cause harmless error messages when hard-coded support is lacking)");
@@ -129,7 +130,7 @@ _setlistener("/sim/signals/nasal-dir-initialized", func {
    print("features.geodinfo_supports_vectors=", features.geodinfo_supports_vectors);
    print ("##########################################");
    print("Compatibility checks done.");
-});
+}) or print("not running compat_layer.nas (local weather disabled)");

 # this is now where we can simply refer to features.geodinfo_supports_vectors
 # for checking if vector support is available or not - to use the most appropriate
diff --git a/Nasal/local_weather.nas b/Nasal/local_weather.nas
index 21badfc..c177120 100644
--- a/Nasal/local_weather.nas
+++ b/Nasal/local_weather.nas
@@ -3239,6 +3239,6 @@ setprop(lwi~"ipoint-number",0);
 # wait for Nasal to be available and do what is in startup()

 _setlistener("/sim/signals/nasal-dir-initialized", func {
-       startup();
+       if (!getprop("/sim/startup/disable-local-weather")) startup() or print("not running local-weather.nas (local weather disabled)");
 });


Once the local weather system has its own sub directory, we could the script not just prevent from running, but also from being loaded this way.

[Torsten]

There is a directory $FGDATA/Environment for environment related things, so maybe $FGDATA/Environment/LocalWeather would be a good choice. Please don't create LocalWeather in the root directory.

[Thorsten]

I think we will need to add an option to be able to disable LW using a property, at least during startup - preferably even at runtime (using a listener).

Isn't that a bit academic? Apart from initializing properties in its own subspace in the tree (needed for the menu to function) and setting listeners to these properties (needed to parse menu changes) it doesn't actually do anything unless you tell it to. So actually what would you like to disable at runtime or startup? The menu entries?

It's off by default already - you can set a property to switch it on at startup if you like, but more off doesn't really make any sense, then you might as well delete it.

The whole point of Torsten's changes to the environment system is that interpolation and METAR execution is also not on by default, but waiting for the user to take action - so now we have what I think is reasonable - two systems which are off at startup and wait for user input to switch one of them on.

[Hooray]

Yes, maybe it is sort of academic.
But my thinking was that there has apparently been a lot of confusion regarding the local weather system.

Several people have obviously linked issues to the local weather system that were not at all even related to the local weather system.
Maybe these were unfortunate circumstances (i.e. two weather related components being modified at the same time), still I think the possibility for future misconceptions is not going to decrease, especially not due to the increasing complexity of the local weather system, which is already doing so much more than all of us would have considered possible a year ago.

Thus, having an option to completely disable the local weather system at runtime, or even to prevent it from getting loaded would be a sure way for showing people if local weather is the culprit or not.
I have illustrated how this could be made to work above, and I have in fact started a local branch to do exactly that, not because I like the idea (or the work involved) or because I think local weather is so buggy, but rather to provide a good proof for telling people that their issues are not related to the local weather at all.

I am convinced that this is the right thing to do; just consider the AI traffic system: for a very long time people were experiencing apparently AI related issues and even crashes, unfortunately the AI system could not be fully disabled to prove people wrong, that reflected badly upon the whole AI system - now that the AI traffic system can be mostly disabled, it is getting clear that many of those crashes were not really related to the AI system, i.e. consider the QNaN issues that were repeatedly discussed here, many of those were previously linked to the AI system, wrongly so - as we know now.

It's a matter of defensive programming, I guess.

[Thorsten]

Thus, having an option to completely disable the local weather system at runtime, or even to prevent it from getting loaded would be a sure way for showing people if local weather is the culprit or not.

That's what the button 'Clear clouds' or the function clear_all(); are doing - they switch it off at runtime.

It all then boils down to the question - do people believe that it's really off after they pressed the button? And if you have a property - will that make people more certain that it's *really* off? I mean - really off? More off than it actually was?

If someone's mind is capable of linking local weather with e.g. an animation problem in the 2d clouds, then at some point there is nothing I can do about that (but with Nasal there is always an easy way to make absolutely sure - move the files out of the folder).

I'd frankly spend my time fixing issues that need to be fixed rather than do cosmetics on issues that are essentially working. Ultimately we can package it in a very elegant way, but right now I don't think that's high up on the priority list.

[Torsten]

In the long term, I'd like to have just one weather system in FlightGear and combine "Global Weather" and "Local Weather" into a single "Weather". I envision a system which is easy and intuitive to control by the average user and has the capabilities to tweak any single molecule of air for the advanced weather-maker.
In the mean time, we should try to make it as unconfusing as possible that two systems coexist, however this could be done - I don't know.

One idea springs to my mind when reading the preceding posts: How about renaming "Clear Clouds" to "Disable Local Weather" if this is, what the button actually does?

Good luck for compiling your binary from git!