|
From: Josh D. <jos...@gm...> - 2022-01-10 15:15:04
|
Hi Scott, Mostly what is required is I will need to finish it up and complete the remainder of the testing, then I will provide a demo file. Just a few files get changed in FGData, that it. 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. 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. Does that clarify? And if the setting is not present, it falls back on default behavior. Kind Regards, -- Josh Davidson On Mon, Jan 10, 2022 at 5:10 AM James Turner <ja...@fl...> wrote: > > > On 10 Jan 2022, at 01:24, Scott Giese <sc...@gm...> wrote: > > Yes, there is interest. Let us know then the demo is ready. > > You said you made a prototype. It would be good to understand what is > required to mature it into a solution that could be committed. > > So long as we are very strict about backwards compatibility (and of course > with opt-in enhancements for aircraft going forward), I agree this could > work well. > > I would be wary of adding many GUI config options to the default AP GUI: > the current dialog is not good but I’d be keen to avoid a whole set of > user-facing ‘autopilot config options’, rather make those something the > aircraft sets. > > Kind regards, > James > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |