|
From: Josh D. <jos...@gm...> - 2022-01-10 15:37:13
|
Hi James, Gotcha. 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) Kind Regards, -- Josh Davidson On Mon, Jan 10, 2022 at 10:28 AM James Turner <ja...@fl...> wrote: > > > On 10 Jan 2022, at 15:14, Josh Davidson <jos...@gm...> > wrote: > > Hi James, > Yes, absolutely, the idea would be drop in replacement to *every* FG > aircraft that is falling back on the generic. > > Maybe I didn't be very clear what I meant by configuration, I am talking > about not something that faces the user. > > > No, you were clear, I am just making doubley sure. > > > Example: Developer is start to make a plane, but he is not ready to make a > AP. To facilitate testing, he use generic. He adds altimeter C++ instrument > and notices that the generic AP don't follow. So, he simply can in his -set > add a configuration option, for example, > "/autopilot/settings/use-altitude-instrument" and the generic will now > start using the altimeter instrument rather than the /position/altitude-ft > which is not barometric. > > > Please use /autopilot/config/ foo for this, ‘config’ is the convention > name in most places. I’d also recommend for this, to make the path > configurable, this is what the EGPWS does: > > > i.e > > /autopilot/config/altitude-ft-source-path (a string) > > .. defaults to ‘/position/altitude-ft’ > > .. but the aircraft dev can set it to: > > /instruments/altimeter[2]/output/indicated-altitude-ft > > .. and so on. > > Both the EGPWS and TCAS instruments do a pretty good job of this to be > agnostic of other aircraft systems. > > Kind regards, > James > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |