|
From: Josh D. <jos...@gm...> - 2022-01-10 17:50:55
|
Hi James, Thanks. I will check these out - my C++ is a rusty tho, but I agree the first option would be a good feature to have. I very much appreciate your input! Kind Regards, -- Josh Davidson On Mon, Jan 10, 2022 at 11:05 AM James Turner <ja...@fl...> wrote: > > > On 10 Jan 2022, at 15:36, Josh Davidson <jos...@gm...> > wrote: > > I am not sure, if you can do such a thing in the confines of > propertyrule configuration, to "take" the property value from the string > and then read from it. Do you have any suggestion about it? (Nasal is not > an option, the rate of update is too slow, which would cause problems in > the control loop) > > > There’s two options there: > > - add a property-source-path feature to InputValue, which is the common > input stage for all the property-filter / AP modules > > (quite easy, and likely useful for a few other things) > > - use a Nasal helper to watch for the source path changing (likely, almost > never), and copy the values to /autopilot/inputs, and update an ALIAS > > > (This is close to what the EGPWS does: it defines input/ and output/ > subdirs, and these correspond closely to the real-world connections on the > device. So in this case the main AP rules would reference > /autopilot/inputs/altitude-ft, and the Nasal helper would ensure whichever > property is pointed to by config/altitude-ft-prop-path is aliased to > /autopilot/input/altitude. > > Kind regards, > James > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |