Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation

[Thorsten R. <tho...@sc...>]

> Thorsten -- that's exactly what I did 15+ years ago, when I found places
> that FlightGear didn't do a good job simulating real life (e.g. magnetic
> compass errors, VSI lag, VOR scalloping, turbulence, etc. etc.). Instead  
> of
> just making one-off tweaks like the consumer sims did, we (as a team)
> emulated entire systems like the vacuum, pitot-static, and electrical
> systems, so that failures would be realistic.

Not sure I share your view of what a realistic electrical system does or  
that it is  a good idea to make failure modes other than sensors general  
rather than airplane-specific, but that's a side note.


> In the RNAV age, we need to do the same thing; it's just that it's a  
> bigger
> job.  FlightGear will still be great for people who want to practice the
> mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but
> will slip further and further behind for people who want to use it for  
> real IFR practice.

I still don't see what your point is.

* after looking into the G1000 manual, it's my considered opinion that it  
is possible to use canvas to render it with decent performance on  
mid-range modern hardware (not on 10 year old computers though), that I  
have a decent picture how it needs to be organized and that the Shuttle  
MDU code (using Richard's framework to organize everything into pages and  
the optimization techniques we've learned to use for the pages themselves)  
exemplifies this

* the example of the CDI switchover you gave is a subset of what the  
spacecraft automated systems solve all the time - it's easy to code GNC  
based on 'modes' and define conditions to enter/leave the modes

* the example of the radius to fix is again the same as the Shuttle HAC  
intercept/ follow

=> so there's example code for what you need which can be studied and  
adapted to the specific airplane (I don't think a general AP for all  
planes ever really worked, and things like RNAV to ILS sure depend on the  
specific airplane/AP). In addition, I can help anyone who wants to start  
coding it with the design.

So if your point is that the people interested in using FG for IFR  
practice need a jump-start to get coding - I believe we have that, there's  
code examples and experience available. You can basically start by looking  
into Richard's MFD canvas wrapper and go from there.

If the point is that you believe the whole community should focus on this  
and make it a priority, I have to disagree - to me and my FG use cases a  
modern GPS is at best a 'nice to have' feature waaay down my priority list  
(apart from spaceflight, I'm mainly interested in the VFR experience).  
Personally I'd rather see FG re-structured to support more than one JSBSim  
FDM - but I'm not expecting everyone to jump in to support this either.  
Let's agree we can all have different perspectives on what FG needs  
urgently next.

And if your point is that I should mainly be doing this because I know how  
- after spending a year hacking the Shuttle avionics in, I sure don't want  
to start the same with a G1000... so  sorry, it's gonna be someone else's  
turn :-)

* Thorsten