Board index FlightGear Development Nasal

Listener not firing - why? 10Hz nasal poll-loop a solution?  Topic is solved

Nasal is the scripting language of FlightGear.

Listener not firing - why? 10Hz nasal poll-loop a solution?

Postby benih » Thu Jun 01, 2023 11:54 am

Hi, regarding https://github.com/hbeni/fgcom-mumble/p ... 1571756021 i have two questions, and hope, someone more capable than me can hint me in the right direction.

I register listeners to properties, but the listener does never fire the method, and thus the string is never updated.
For "operable" this is understandable, because it is a tied prop, but the others should work in my opinion...


The other question is related to the "fix"; currently i call the refresh method every 1/n seconds (at a rate of 10Hz by default).
is that harmful in this case, or is the code reasonably lightweight to not make a real difference (i read and set just a bunch of props)?


Thanks for your time and help :)
Last edited by benih on Fri Jun 02, 2023 8:36 am, edited 1 time in total.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Listener not firing - why?

Postby benih » Fri Jun 02, 2023 8:26 am

benih wrote in Thu Jun 01, 2023 11:54 am:The other question is related to the "fix"; currently i call the refresh method every 1/n seconds (at a rate of 10Hz by default).
is that harmful in this case, or is the code reasonably lightweight to not make a real difference (i read and set just a bunch of props)?


A quick test did not show any detectable difference in FPS.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Listener not firing - why? 10Hz nasal poll-loop a soluti

Postby Richard » Sun Jun 04, 2023 12:53 pm

First thing is to create a simple standalone example that shows the problem as listeners should work fine for strings, unless the underlying property is tied (i.e. the property is backed by a C++ variable). However even tied properties can support listeners - it just needs some extra C++ and so a standalone example is essential in tracking down what is actually going on.

Generally I'd expect the performance hit from a 10hz providing that the amount of work is minimised; i.e. to simulate a listener

something like;

Code: Select all
var lastV = "----"; # set to something to ensure called the first time
var currentV = "";
var propV = props.globals.getNode("/some/property");

check_for_updates(){
  currentV = propV.getValue();
    if (currentV  != lastV){
        lastV = currentV;
       update_method(currentV);
    }
}

udploop = maketimer(1/refresh, nil, check_for_updates);
udploop.start();


looking at the lines https://github.com/hbeni/fgcom-mumble/b ... 72C4-L80C6 this is doing more work than it should; firstly it should only do things when values change (see above), but also should not use expensive operations.

Code: Select all
72 var update_udp_output = func() {
73      FGComMumble_radios.update_radios();
74      var out_prop = props.globals.getNode(mySettingsRootPath ~ "/output/udp",1);
75      var str_v = [];
76      foreach (r_out; FGComMumble_radios.GenericRadio.outputRootNode.getChildren("COM")) {
77        append(str_v, r_out.getValue());
78      }
79      out_prop.setValue(string.join(",", str_v));
80    }


Line 73: not sure how expensive this method is
Line 74: ideally this would be called outside of the loop as a getNode is a costly/slow operation.
Line 75: move this to a module level variable to reduce GC
Line 76: if this is mostly static it would benefit from being in a cached array (as getChildren is a costly/slow operation)

Generally it is better to have a few uS every second rather than big work every 10 seconds; so in that sense a 10hz timer is right; although if the value is only likely to change once in a while then maybe a 5 second timer would be more appropriate.

With addons I think it is important to make the code as efficient as possible as obivously each addon will increase the load slightly.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Listener not firing - why? 10Hz nasal poll-loop a soluti

Postby benih » Mon Jun 05, 2023 11:02 am

Thanks for the feedback!
the problem is, that the loop really is meant to get the "right" state, which may change suddenly (like the user pressing the PTT button) and this needs to be handled "nearly instantly".
The best solution would be a listener, but that is not working like I assume. Most probably i do something wrong with the initialization or so.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Listener not firing - why? 10Hz nasal poll-loop a soluti  

Postby benih » Fri Jun 16, 2023 12:52 pm

Just to keep you updated:
  • The reason this does not work was, that if you have a property defined and make an alias to it, a listener to the aliased prop will not fire, despite its value changing.
  • There was discussion on the mailing list
  • The result is, that code was added very recently, that you can tell the alias() function to also honor the listeners, so listeners to aliased props will fire then
  • The other thing is, without the parameter, you always need to use the base property if you want to use listeners
  • Regarding the question for the workaround using a 10Hz nasal timer; that is generally a hacky solution. The exception could be a timer that just polls a prop which should be not an big issue.

Marked as solved :)
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit


Return to Nasal

Who is online

Users browsing this forum: No registered users and 7 guests