Storage of GPS variables

[COBS]

Edi

I did the BMP myself using both mspaint and freeware paint.NET , I doen't have photoshop.
The MFD's and Radar should have buttons across the top but I avoid them in an attempt to get the instrument as high
as possible on the panel , also buttons reduce the display area.
I label the buttons where ever possible as a memory prompt as an aid for users that fly a lot of different aircraft in the sim.
Some developers put the button labels on the display while that is authentic it puts clutter on the precious display
real estate , I prefer to avoid that and make the display area as readable as possible.
My previous panel uploads were in 4x3 Aspect Ratio monitors , I recently got a Wide screen 16x9 Aspect Ratio monitor ,
the above shot is the first time that I have posted a wide screen shot.
My next upload will be for both Aspect Ratios.
The wide screen needed a new wider BMP , the HUD to be re calibrated , and the Radar touchscreen display Lat/Long
nomination to be re calibrated to give extreme precision.

I just do that panel for my own style of flying , I wanted it to be much more than just 6 primary instruments ,
I wanted a systems approach that gives the pilot a wide range of capabilities , a massive amount of information if
he requires it , and to explore some real world capabilities that might be useful and fun to use.
I enjoy my flying , and with that panel you can do some amazing things if you want to.

I tend to fly extremely fast 400-550 kts at very low altitudes 200' agl or less often weaving between trees , and
that panel makes it easy to do , the radar display terrain contour depiction enables you to fly very low even at
night or in zero visability.
The Mission Adaptive Flight planner , Stand Off , Radar and Pave Tack are all early parts of a targetting system that
I am trying to evolve for precision weapons delivery.

It is enjoyable exploring where you can go with ideas and instrument and systems creation , you just never know
what might be around the next corner , the possibilities are endless.
Fortunately I get a lot of help and ideas at forums such as this one , and that helps to compensate for my lack of
script writing abilities , I would be totally lost without that valuable help.

Cheers
Karol

 

[rpmc]

That's the easy part , the hard part is storing the GPS string Variables.

You have all the options now so it's just a matter of deciding what you like best.

There's usually more than one way to do something in a complex gps gauge such as yours and it will involve trade-offs. When I look at your NearestAirport pages, I don't see the need to store any gps strings other than perhaps airport Ident, which can be stored into a single L:Var (using a 4 place shift register) and recalled in order to re-generate pages 2, 3, and 4 on the fly. There is a couple cycle delay when you do that ICAO transfer, but the database query can be performed, the calculations re-done, and the page re-rendered so quickly, that I would never bother with trying to store sting information like Name and City. It's easy to store numerical data such as runway selection from page 2 into an L:Var if you need to keep track of that. This would always be my first approach.

Even the NearestAirport list - I would always re-generate when needed. There is a bit longer delay retrieving all that information, but that is mitigated by limiting the amount of data retrieved, especially NearestAirportMaximumItems.

I still advocate taking the plunge, if you want to call it that, and installing XMLTools. My prediction is that you will find a lot of new XML capability if you do that, and the new doors opened to you will make it completely worth it. I was able to make an XML TCAS overlay utilizing the XMLVars array forming capability, something that could not be done without XMLTools. But even if you had XMLTools (and hence XMLVars class) installed, my advice about storing gps strings would be the same - I argue that it is not necessary. I feel that you are over-complicating that part.

Keep up the good work!

Bob

 

[EduHir]

Wide screen 16x9 Aspect Ratio monitor

That's great!

It is enjoyable exploring where you can go with ideas and instrument and systems creation , you just never know
what might be around the next corner , the possibilities are endless.

Yeah, that's one important point!

Edi

 

[COBS]

Edi

I have it working , it's just the simple version , it does not use stored strings .
It doesn't have the flexability of storing airport/runways to memory or the independance of page 1, 2 and 3.
I'm still testing it but so far it works fine.

I changed the method that I used ,
Will describe it in next post .
Will also Zip and attach the full instrument within next couple of days , some of it's detail might be of
use to you.
It is fun to fly and use.

Cheers
Karol

 

[COBS]

Following is basics of the page 3 .

1. In the Update section :-

           (L:RwyEndSelect) 0 ==
                if{ 360 (@c:WaypointAirportRunwayDirection, degrees) 180 - dnor d 0 == ? (>L:Selected_RwyMagHeading, degrees) }
            (L:RwyEndSelect) 1 ==
                if{ 360 (@c:WaypointAirportRunwayDirection, degrees) dnor d 0 == ? (>L:Selected_RwyMagHeading, degrees) }
      
    (L:Mark View,enum) 2 ==
      if{
           (@c:WaypointAirportRunwayLatitude, degrees) (>@c:GeoCalcLatitude1,degrees)
           (@c:WaypointAirportRunwayLongitude, degrees) (>@c:GeoCalcLongitude1,degrees)
             (@c:WaypointAirportRunwayLength, feet) 0.45 * (>@c:GeoCalcLength, feet)     
             (L:Selected_RwyMagHeading, degrees) (>@c:GeoCalcAzimuth1,degrees)
           (@c:GeoCalcExtrapolationLatitude,degrees) (>L:EndPositionLatitude,degrees)
           (@c:GeoCalcExtrapolationLongitude,degrees) (>L:EndPositionLongitude,degrees)
     
           (L:EndPositionLatitude,degrees) (>L:MarkPositionLatitude,degrees)
           (L:EndPositionLongitude,degrees) (>L:MarkPositionLongitude,degrees)      

           (L:MarkPositionLatitude, degrees) (>@c:GeoCalcLatitude1,degrees)
           (L:MarkPositionLongitude, degrees) (>@c:GeoCalcLongitude1,degrees)
           (A:PLANE LATITUDE,degrees) (>@c:GeoCalcLatitude2,degrees)
           (A:PLANE LONGITUDE,degrees) (>@c:GeoCalcLongitude2,degrees)
             (@c:GeoCalcBearing,degrees) (>L:BearingMarkPos,degrees)
             (@c:GeoCalcDistance,nmiles) (>L:DistanceMarkPos,nmiles)
        }

The first part generates the reciprocal of the currently chosen (toggled) runway end.

The first Geocalc part applies that reciprocal (Direction) to 0.45 x runway (Length) to generate Lat/Long of the
touchdown/ILS aimpoint at 5% from end of runway at whichever end is currently selected.

The second Geocalc part , calculates the Bearing/Distance to the currently selected touchdown aimpoint.

IMPORTANT The above in the Update were "RECIPROCAL HEADINGS" , the balance of the instrument uses ACTUAL selected Runway headings
for circuit quadrants , ILS , LOC graphics.

Following is the Runway Heading toggle element.

   <Element>
      <Visible>(L:Mark View,enum) 2 == </Visible>
  <!--Button %.160 - 340.% Runway heading toggle display   Text-->
            <Element>
              <Position X="28" Y="10"/>
              <FormattedText X="55" Y="13" Font="Tahoma" FontSize="9" Tabs="3L,31L" LineSpacing="12" Adjust="Left" Color="#A1A9A6" BackgroundColor="#144114" Bright="Yes">
              <Font FontSize="12"/>
              <Color Value="#ED7300"/>
              <Color Value="#FCD116"/>
                <String>
                %((L:RwyEndSelect) 0 ==)%{if}%\{fnt1}%\{clr2}%((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - d360)%!03d!%{else}%\{fnt}%\{clr1}%((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - d360 )%!03d!% -%{end}%
                \t%((L:RwyEndSelect) 1 ==)%{if}%\{fnt1}%\{clr3}%((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - 180 - d360)%!03d!%{else}%\{fnt}%\{clr1}%-%((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - 180 - d360)%!03d!%{end}%      
                </String>  
              </FormattedText>
            </Element>

           <Element>
          <Position X="29" Y="25"/>
            <FormattedText X="38" Y="32" Font="Tahoma" FontSize="9" LineSpacing="9" Adjust="Left" Color="#00C0FF" BackgroundColor="#000030" Bright="Yes" Tabs="0,1L">
              <String>\t% ..^ ^..%
                      \n\t% Select%
                      \n\t%Rwy Hdg%
                    </String>
          </FormattedText>
       </Element>
</Element>

I hope that the above makes a little sense.

Cheers
Karol
EDIT:
The selection of a specific runway in page 2 is covered at the following link,
http://www.fsdeveloper.com/forum/threads/loop-selected-line-colour-highlighting.434094/

 

[EduHir]

Karol,
really thanks for the update!!

I added also the possibility to select an runway and to define a T/D zone.
But your approach is fantastic!!

I read some years ago that in FS9 the extrapolation does not work.
So i never thought about such a solution!
But your code also works in FS9??

btw i wrote a kind of runway advisory where i needed the deviation from the centerline in feet.
So may i offer you this part of code

       (L:NavM_POST_Rwy_Select,number) 0 >
       if{
         <!-- for sinus and cosinus USE  RADIANS -->
         (L:NavM_POST_Rwy_Heading,radians) (L:NavM_POST_RWY_Bearing,radians) - sin (L:NavM_POST_RWY_Distance,feet) * (&gt;L:NavM_POST_Rwy_DeviationC,feet)
         }

Your are hundred of miles away from the runway and you see how many feets you are away from the centerline!
Maybe you can use it.

And i like your bitmap! Looks so professional!!

Edi

 

[COBS]

Edi

Thank you for above code , I did want the offset in feet for a military application that I use in the sim,
it is also handy for use with cropduster aircraft who do repeated runs at uniform offset in feet.

The bitmap/shots help me sort out in my mind where the instrument is and where it's going , often it gets
complex and it's easy to loose track of where you are going with it , the shot helps a little.

Only just finalised the instrument a couple of minutes ago.
I will write some brief and rough notes , then Zip and attach it here , hopefully tomorrow.
I would be interested in your views and comments if you can test fly it.

Cheers
Karol

 

[COBS]

Edi

The instrument is in the attached zip it's title is,
DAT73

Sorry about the notes they are quick and rough , I have included some data screenshots to aid in it's use.
It should work fine in FS9.

I did not include my modified radar as you do not have FSX yet.
Please ignore the references to Stand Off as that primarily sets your runway touchdown to a radar projected view,
it is a neat feature.

I also included my other MFD as it has what I refer to a a "Mission Adaptive Flight Plan Editor" , it enables flight plan creation
in a totally flexible manner , it has 4 new stand off pages but no notes only the included screenshot ,

I need to add a 5th page to enable high resolution distance accuracy Lat/Longs for use in the Mark Position page.

I hope that there is something in there that is of value or use to you.

Cheers
Karol
PS ,
it would not upload screenshots , will post later,

 

[COBS]

Some shots

 

[COBS]

Hi Edi

Attached updated DAT73 zip , this xml goes into the previously supplied MFD folder.

During testing I noticed that the "Appr " Approach distance readout worked as required for the 2 rear quadrants , but ,
while conducting tests with the standard rectangular circuit it for some strange reason gave a readout during the last 30 degrees in the front left quadrant
approaching the abeam to touchdown point. It shouldn't have done so.
(For "Standard Rectangular Circuit" screenshot see reply #1 at following link http://www.fsdeveloper.com/forum/threads/circuit-width-a-better-way.430370/ )
I only want it to readout in the two rear quadrants.

I fixed it by placing the relevant code within Visability statements. It now functions as it should , only in the two rear quadrants.
In Notepad++ code is at line #1142
This only applied to the Page 3 section of the instrument.

I have not yet tested it in helicopters , but it should work in them as long as the glideslope is kept under about 80 to 90 degrees.
ie; range 3 to 90 degrees.

Is it working in FS9 ?

Cheers
Karol
Attached updated xml.
**xml only - complete instrument and notes at reply # 28 above**

 

[EduHir]

Karol,
thanks for the upload!
I'm a little busy, so i did just a short look to the gauges.
At all, it's a very nice gauge for military planes!!

I like the idea to show airplane heading and runway heading in one gauge. It makes the approach much easier!
I have an 1920 x 1080 screen. So the display doesn't proper work.

I use also very often right clicks.
So to prevent stopping the sim and opening this context window i use following code in any gauge with a bitmap.

  <Mouse>
<!-- overwriting rightclick -->
    <Area Left="0" Top="0" Right="240" Bottom="430">
      <Click Kind="LeftSingle+RightSingle">
      </Click>
    </Area>

This code must be written at the beginning of the mouse section.

During testing I noticed that the "Appr " Approach distance readout worked as required for the 2 rear quadrants ,

Now it took some time to understand.
Approach distance will only be shown if the plane is in the rear quadrants??
The idea with the quadrants is also interesting!
And the code is cool.
Maybe useable in my runway advisory. But no time at the moment.

At the end we need a docu!

Have you planned a total upload with plane, panel and sound?

Edi

 

[COBS]

Edi

I just realised that one of the screenshots has an error in it , have corrected it and is attached below.
SHEET 2,
Page 4 (Mark Position)
Buttons : M.1 , M.2 , FAR , and ORIG , the L and R (Left and Right) click functions are now swapped around.

Reason ; I found that we are hardwired to commonly use the Left click , as a result with those buttons I was hitting the
Left click and accidently over writing what was stored in those buttons.
The current arrangement overcomes that problem.

Regards the use of quadrants , it gives this instrument really powerful features , namely
Circuit width distance , and Approach distance , they are at right angles to each other ,
their value can be demonstrated by flying along a constant value of either one of them , they aid or allow you to
manoeuvre in a fully informed manner to an intercept with the runway heading for a approach run in to a
landing .
(What it basically means is that you can choose the distance from the Touchdown position that you wish to intercept the 'Runway Heading' at .
You might want to intercept the runway heading and be lined up at exactly 7.3 nm to Touchdown , this set up allows you to maneouver in an informed manner to that exact intercept .)
See :-
An in use example
in page 2 of my notes , by flying that example their use will become clear.
Similar to above "Orientation aspects" schematic screenshot , which also tries to relate flightpath to quadrants.

Their use in transition from En route to Circuit-approach is not limited to that example , they aid regardless of inbound angle
or circuit entry type that you might want to conduct , this instrument provides full spatial awareness of your situation
relative to the runway regardless of the aircraft's current heading.
Also take careful note of the Hollow grey arrow's relationship to the green background crosshairs as shown and flown in the
Standard Rectangular Circuit screenshot , when you get used to that relationship the instrument is really talking to you , very important.

Cheers
Karol

 

[COBS]

Intercept of ILS Runway Heading.
Usually if you are conducting a NAVAID ILS approach you have either , a STAR (Standard Terminal Arrival Route) , or a NDB , or a VOR ,
these aid in transition from your inbound course and the progressive turn to align with the runway heading prior to capture of the ILS.

The above instrument had a method whereby using both (A) Circuit width , and (B) Approach distances it was possible to intercept
the runway heading axis line , however it was cumbersome and complex to use.

To overcome that situation I added a "Intercept Position" facility to the instrument.

You decide the distance in nm (eg; 7.0 nm) prior to the touchdown aimpoint that you wish to intercept the runway axis line at.
Then enter and activate that distance.
The instrument will then give you , Bearing , Distance , and a blue steering arrow to the Intercept location , it also calculates the
height that you must descend to to precisely capture the glideslope at that location.
It's simple to use , and it makes the capture and alignment with both the runway heading and ILS much easier.

The following are the additions that were made :-

In the Update section,

              (L:RwyEndSelect) 0 ==
                if{ 360 (@c:WaypointAirportRunwayDirection, degrees) 180 - dnor d 0 == ? (>L:Selected_RwyMagHeading, degrees) }
            (L:RwyEndSelect) 1 ==
                if{ 360 (@c:WaypointAirportRunwayDirection, degrees) dnor d 0 == ? (>L:Selected_RwyMagHeading, degrees) }

    (L:Mark View,enum) 2 ==
      if{
           (@c:WaypointAirportRunwayLatitude, degrees) (>@c:GeoCalcLatitude1,degrees)
           (@c:WaypointAirportRunwayLongitude, degrees) (>@c:GeoCalcLongitude1,degrees)
             (@c:WaypointAirportRunwayLength, feet) 0.43 * (>@c:GeoCalcLength, feet)
             (L:Selected_RwyMagHeading, degrees) (>@c:GeoCalcAzimuth1,degrees)
           (@c:GeoCalcExtrapolationLatitude,degrees) (>L:EndPositionLatitude,degrees)
           (@c:GeoCalcExtrapolationLongitude,degrees) (>L:EndPositionLongitude,degrees)

           (L:EndPositionLatitude,degrees) (>L:MarkPositionLatitude,degrees)
           (L:EndPositionLongitude,degrees) (>L:MarkPositionLongitude,degrees) 

           (L:MarkPositionLatitude, degrees) (>@c:GeoCalcLatitude1,degrees)
           (L:MarkPositionLongitude, degrees) (>@c:GeoCalcLongitude1,degrees)
           (A:PLANE LATITUDE,degrees) (>@c:GeoCalcLatitude2,degrees)
           (A:PLANE LONGITUDE,degrees) (>@c:GeoCalcLongitude2,degrees)
             (@c:GeoCalcBearing,degrees) (>L:BearingMarkPos,degrees)
             (@c:GeoCalcDistance,nmiles) (>L:DistanceMarkPos,nmiles)
        }

        (L:Intercept Dist,enum) 0 ==
      if{
           (L:EndPositionLatitude,degrees) (>@c:GeoCalcLatitude1,degrees)
           (L:EndPositionLongitude,degrees) (>@c:GeoCalcLongitude1,degrees)
             (L:RunInDistance, nmiles) (>@c:GeoCalcLength, nmiles)
             (L:Selected_RwyMagHeading, degrees) (>@c:GeoCalcAzimuth1,degrees)
           (@c:GeoCalcExtrapolationLatitude,degrees) (>L:InterceptPositionLatitude,degrees)
           (@c:GeoCalcExtrapolationLongitude,degrees) (>L:InterceptPositionLongitude,degrees)

           (L:InterceptPositionLatitude,degrees) (>L:RunInLatitude,degrees)
           (L:InterceptPositionLongitude,degrees) (>L:RunInLongitude,degrees) 

           (L:RunInLatitude, degrees) (>@c:GeoCalcLatitude1,degrees)
           (L:RunInLongitude, degrees) (>@c:GeoCalcLongitude1,degrees)
           (A:PLANE LATITUDE,degrees) (>@c:GeoCalcLatitude2,degrees)
           (A:PLANE LONGITUDE,degrees) (>@c:GeoCalcLongitude2,degrees)
             (@c:GeoCalcBearing,degrees) (>L:BearingInterceptPos,degrees)
             (@c:GeoCalcDistance,nmiles) (>L:DistanceInterceptPos,nmiles)
        }

Overlay data in Page 3 of instrument,

    <!-- INTERCEPT position data OVERLAY    TEXT Display  -->
     <Element>
        <Visible>(L:InterceptDisplay,enum) 1 == (L:Intercept Dist,enum) 0 == and</Visible>
   <Element>
     <Position X="160" Y="32"/>
     <FormattedText X="41" Y="73" Font="Tahoma" FontSize="9" LineSpacing="10" Color="#2F912F" BackgroundColor="#242424" Bright="Yes" Tabs="0,1L">
     <String>
      \t%Intercept%
      \n\t%Dist% %((L:RunInDistance, nmiles))%!4.1f!%
      \n\t%* SET *%
      \n\t%Brg% %((L:BearingInterceptPos,radians) (A:GPS MAGVAR, radians) - pi - rddg dnor )%!03d!%
      \n\t%Dist% %((L:DistanceInterceptPos,nmiles))%!4.1f!%
      \n\t%at S-Ht%
      \n\t%((L:RunInDistance, feet) (L:Set_GSangle, radians) atg *)%!5d!%
     </String>
     </FormattedText>
    </Element>
    </Element>

In the Mouse section for * SET * switch,

 <Macro Name="Button18">(M:Event) 'RightSingle' scmp 0 == if{ 0.7 (&gt;L:LatLng_Indicator,enum)
                                                              (L:RunInLatitude,degrees) (&gt;L:ClikLatitude, degrees)
                                                              (L:RunInLongitude,degrees) (&gt;L:ClikLongitude, degrees) }
        (M:Event) 'LeftSingle' scmp 0 ==  if{ (L:Dnumber_SUM, number) 10 * (&gt;L:RunInDistance, nmiles) }
        (M:Event) 'MiddleSingle' scmp 0 == if{ (L:RunInLatitude,degrees) (&gt;L:RequiredWaypointLatitude, degrees)
                                               (L:RunInLongitude,degrees) (&gt;L:RequiredWaypointLongitude, degrees) }</Macro>
     <Area Left="161" Top="37" Width="35" Height="35">
      <Visible>(L:DAT37 mode,enum) 3 == (L:APT_Nrst_select, number) 4 == and </Visible>
     <Tooltip>Inter Dist</Tooltip>
     <Click Kind="LeftSingle+MiddleSingle+RightSingle" Repeat="Yes">@Button18</Click>
     <Cursor Type="Hand" />
     </Area>

1. Schematic of use and notes,

2. This shot is a follow on of above display , aircraft is 0. 1 nm from intercept location , and 7.09 nm from touchdown , nearly on ILS , comparison of the two S-Ht values indicates aircraft is 172' above glideslope .
The blue intercept arrow is rapidly turning to rear position as that location is being passed,

3. This shot shows the nearby Intercept location Lat/Long in the RH MFD it was given the flight plan Index number and added to the plan , it is visible on the Radar display as 00 ,
previously an intercept position for the far end touchdown aimpoint was entered and is visible as 02 on the radar.

Cheers
Karol

Attached updated xml.
Just drop the updated xml into MFD folder provided at reply #28.
**xml only - complete instrument and notes at reply # 28 above**
EDIT
Version 4 of DAT73 xml
corrects "agl" value in page 3 , and changes Intercept appearance.

 

[COBS]

Edi

At post # 26 you provided some code for "Deviation from center line in feet" , again thank you for that .

I have used that in Page 4 as a precise Offset in feet .
I also used your code in my "Quadrants" to get the "Circuit Width in nm " in both Page 3 and Page 4 ,
it's brilliant ..... !
It now gives rock solid circuit width distances that are totally stable and accurate , it is fantastic , my old Quadrant code
did give circuit width distances , but they were a little erratic at times , now it's perfect .

As well as the above I added ,
- DME slant distance to the currently selected Touchdown spot .
- a GS (glideslope) trend indicator , it is the ..... 'Set GS angle' minus 'current GS angle' displayed over a +/- 0.2 degree range ,
it gives advance warning of what the White GS bar is about to do movement wise .
It could be handy as most have trouble keeping the GS bar central when close in.
It is a tiny Red bar.

I also did a little work to improve the "MarkSW" , it is the small Icon sized switch that glows green when used .
The idea behind that remote switch was if suddenly the pilot wants to Capture a "Mark Position" he hits that button ,
then at his leisure he can open the MFD and the Mark Position will be displayed.
It's probably only useful for panel that can be customised , unfortunately the newer 3D panels in FSX are virtually impossible to customise
by adding switches or instruments .

I also created a PDF document that covers Pages 1 to 4 . ( AILA.PDF )
while this instrument is very simple to use and fly , it was very hard to do an adequate description in words , I hope the PDF is OK .
and
a PDF with a few airport ICAO's listed . ( Airports.PDF )

Please have a look at the new Quadrant/Circuit width code , it really is much better .

Will attach zip with updated xml's , just add them to the previously supplied MFD folder.
also the PFD documents.

Cheers
Karol
Attached ;
- Final updated DAT73 xml .
- AILA PDF , 16 pages of instrument operating notes .
- Airports PDF , 5 pages of global airport ICAO's for entry into Page 1 search facility .

EDIT 16JUN2017
Latest xml added ( DAT73v6.zip )
It removes the RED trend bar which was really useless .

 

[EduHir]

Karol,
fine that this code is helpful for you.
I'm a little busy with outdoor activities, so i read you AILA.pdf.
Your gauge became very complex.
And i like your multiplex digit entry window.
Also the idea with the stored runwaylist.
Thanks for the info and keep us informed, please!

Edi

PS. Do you work in real aviation?

 

[COBS]

Edi

It was never meant to be complex , I find it very easy to use , but I can hardly be a fair judge as I have
used the instrument a lot testing it during development , so it's always going to be easy for me.

Several points;
1. Page 3 and 4 are basically identical , the only difference is in the background method of determining the Touchdown aimpoint ,
one uses actual runways , the other any captured location , each display is essentially the same.
2. Those two pages are complimentary , they give complete global coverage of any surface , either land or water.
3. Long ago I placed a rotating compass rose into the instrument , but quickly removed it due to clutter .
Ideally it should have a compass rose under the crosshairs.
4. My AILA PDF notes might not be good enough , I tried to describe a lot of features and uses , and that might have made it
appear to be more complex than it actually is , I find notes always hard to write , generally I try to cover all possible users .
5. It would be fair to say that generally the cost of increased capability is increased complexity.

Observing various forums I have noticed that many regard that the only use of an autopilot is to fly Flight Plans , that is
certainly one use , but an equally important use of the autopilot is to temporarily free up the pilot so that he can attend to
other duties , and that is especially important in IFR work , get the autopilot to fly the aircraft on Hdg Hold or Wings Level
for several minutes while setting up instrument parameters , it's a common usage in RL .
As instruments and panels get more and more complex users need to use the autopilot as a Co Pilot at least ocassionally .

Cheers
Karol
Q : Do you work in real aviation?
A : Yes .