some1

Piper H350 Holidays 😎

The stock autopilot toggle ('Z' key by default) will work too.

It's probably happening because the GNS530/430 reads the aircraft heading from your (misaligned) HSI 😉

The available cockpit options are: no gps, GNS430, GNS530, GNS530+GNS430, PMS 750, TDS 750Xi. Green or gray panel.

Works now, thanks!

Hi Dave, thanks for continuing updates. With the beta3, the altitude from the flightplan file loads correctly. But if I import directly using the new feature "Import Simbrief", then the cruise altitude does not match. Simbrief shows FL340, while the imported plan shows FL300 in P2ATC.

Pilot2ATC does not import altitude from the following flightplan. It seems that .000 in the <CruisingAlt> tag is treated by the program as invalid data. Full flightplan I used: <?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="AceXML" version="1,0"> <Descr>AceXML Document</Descr> <FlightPlan.FlightPlan> <Title>EETN to ESSA</Title> <FPType>IFR</FPType> <RouteType>HighAlt</RouteType> <CruisingAlt>28000.000</CruisingAlt> <DepartureID>EETN</DepartureID> <DepartureLLA>N59° 24' 48.00",E24° 49' 57.00",+000135.00</DepartureLLA> <DestinationID>ESSA</DestinationID> <DestinationLLA>N59° 39' 7.00",E17° 55' 7.00",+000138.00</DestinationLLA> <Descr>EETN to ESSA created by SimBrief</Descr> <DepartureName>Lennart Meri</DepartureName> <DestinationName>Arlanda</DestinationName> <AppVersion> <AppVersionMajor>11</AppVersionMajor> <AppVersionBuild>282174</AppVersionBuild> </AppVersion> <ATCWaypoint id="EETN"> <ATCWaypointType>Airport</ATCWaypointType> <WorldPosition>N59° 24' 48.00",E24° 49' 57.00",+000135.00</WorldPosition> <RunwayNumberFP>26</RunwayNumberFP> <ICAO> <ICAOIdent>EETN</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="PETOT"> <ATCWaypointType>Intersection</ATCWaypointType> <WorldPosition>N59° 30' 40.00",E23° 8' 31.00",+022000.00</WorldPosition> <DepartureFP>PETO1T</DepartureFP> <RunwayNumberFP>26</RunwayNumberFP> <ICAO> <ICAORegion>EF</ICAORegion> <ICAOIdent>PETOT</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="LUPET"> <ATCWaypointType>Intersection</ATCWaypointType> <WorldPosition>N59° 38' 25.00",E19° 52' 35.00",+028000.00</WorldPosition> <ICAO> <ICAORegion>ES</ICAORegion> <ICAOIdent>LUPET</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="XILAN"> <ATCWaypointType>Intersection</ATCWaypointType> <WorldPosition>N59° 39' 33.50",E19° 4' 33.80",+019900.00</WorldPosition> <ATCAirway>L77</ATCAirway> <ICAO> <ICAORegion>ES</ICAORegion> <ICAOIdent>XILAN</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="SA570"> <ATCWaypointType>Intersection</ATCWaypointType> <WorldPosition>N59° 36' 16.00",E18° 41' 42.30",+013700.00</WorldPosition> <ArrivalFP>XILA5T</ArrivalFP> <RunwayNumberFP>26</RunwayNumberFP> <ICAO> <ICAORegion>ES</ICAORegion> <ICAOIdent>SA570</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="TEB"> <ATCWaypointType>VOR</ATCWaypointType> <WorldPosition>N59° 31' 54.10",E18° 12' 11.90",+005600.00</WorldPosition> <ArrivalFP>XILA5T</ArrivalFP> <RunwayNumberFP>26</RunwayNumberFP> <ICAO> <ICAORegion>ES</ICAORegion> <ICAOIdent>TEB</ICAOIdent> </ICAO> </ATCWaypoint> <ATCWaypoint id="ESSA"> <ATCWaypointType>Airport</ATCWaypointType> <WorldPosition>N59° 39' 7.00",E17° 55' 7.00",+000138.00</WorldPosition> <RunwayNumberFP>26</RunwayNumberFP> <ICAO> <ICAOIdent>ESSA</ICAOIdent> </ICAO> </ATCWaypoint> </FlightPlan.FlightPlan> </SimBase.Document>

Ok, thanks for clarification. EDDM airport may be a bit unusual because they use transitions connecting directly to the last enroute waypoint, without a STAR. I was actually pleasantly surprised that Pilot2ATC recognised that and selected correct terminal procedure combination.

Hello, I'm fairly new to the program so I'm not sure if that's a bug or program limitation, but when flying EDDM NAP26 approach transition in MSFS, I did not receive vectors to ILS after DM459. I continued as instructed by the chart for a while, but eventually turned back after 10 or 15 nm and the ATC communication resumed automatically when I got near the IAF. Here are the logs: https://easyupload.io/yupo5b

People tend to miss the fact that FSX or FS2004 did not support Trackir like other games, which use proprietary Naturalpoint libraries. Microsoft merely exposed SDK which allowed cabin view to be moved, and the rest was done by Naturalpoint in their software. The same SDK functions that EZDOK is using in FSX by the way.

There is no conversion performed by P3D on the fly or during loading. If a texture file contains mipmaps, then the lower resolution mipmap will be used. Otherwise, if you have a 4k texture with no mipmaps, it will be shown in full resolution regardless of the setting.

That's not an indication of FSlabs performance unfortunately, fps on my system used to be noticeably lower with FSlabs than with PMDG offerings (https://www.avsim.com/forums/topic/545098-should-i-get-the-fslabs-a320/?do=findComment&amp;comment=3925402) Haven't had a chance to test the latest patch yet.

Still using it for every IFR flight.

Lockheed very rarely does changes to the SDK that break addons. Usually the only addons affected with minor p3d version change are those which change core p3d files or hack their way into the sim outside the SDK. In both cases it's the responsibility of the developers of those addons to warn you about the issues, as they are very well aware of the problem from the start, they don't even need a new p3d version to test. Some of the addons I've bought show a message when they detect incompatible p3d version and disable themselves automatically, so I can use the rest of the sim. But some crash the sim at startup with no warning. If you are unhappy with such treatment, you really should report that to the developers of those addons. 😉

On my system it's definitely the slowest of the "heavies". I recently did some testing because something didn't seem right, and sitting on a runway powered and ready to flight I get: FSL A-320: 32-35 fps QW B-787: 37-42 fps PMDG B-748: 41-43 fps PMDG B-737: 43-47 fps 30+ fps may sound quite good, but that is with a clean weather and not too busy airport. In flight it can easily drop below 20 fps. That's on a i7-8700k (4.7GHz), 32GB ram@3200MHz and GTX1080.

That's because there is no vertical speed hold function in this autopilot. It maintains constant pitch as set on the Flight Director, so the vertical speed will vary as you change your airspeed and altitude. Once you know what to anticipate, it's quite easy to use it to climb and descend. 🙂

Guys, on the autopilot subject, what are the issues you are experiencing? I don't think anything has been reported on the A2A forums.

Correct, we do not touch the camera, all effects go directly to the airframe.

It's a bit more complex than that. The "shimmering" that people see in the simulator usually comes not from geometry, but from the textures. Things like sharp, contrasting panel lines, high resolution labels, signs and gauges, etc. The cause is partially because in the simulators we use much higher texture density than in other games, partially because of the way P3D handles textures, partially because of old developer habits from FSX. Mipmapping the textures solves most of the "shimmering" effect, but in FSX it caused textures to look extremely blurry in many situations, and it wasn't possible to use textures bigger than 1024x1024 with mipmaps without config edits. That's why many addons are shipped without mipmapped textures. MSAA does not "see" textures, only geometry edges, so no matter how high you set the AA, it won't fix the shimmering. The modern post-processing AA like FXAA reduces shimmering, but noticeably reduces image quality. SSAA offers the best image quality, no matter the resolution, but at a high performance cost. Besides, it's also a matter of personal preference. Like screen tearing due to lack of Vsync, some people barely notice it, while other people can't stand it.

As far as I know, PMDG products do not require FSUIPC either, but that's probably best answered by PMDG staff. FSUIPC remains a convenient tool for custom controls mapping, but it has limited value for addon developers, as most of its functions (if not all) can be performed using FSX/P3D SDK directly.

Microsoft has officially dropped FSX support years ago. It does not mean that the simulator won't work in the newer Windows versions, it's just if you have an issue, their support line won't help you.

For me the aircraft works only if I load it straight from FSX menu, by selecting an aircraft and clicking Fly Now or loading a saved 747 flight directly. But it crashes FSX if I select 747 when flying another aircraft, even default C172, so loading 747 by going through the upper menu "Aircraft->select Aircraft", or "Flights->Load..." will crash the sim. Uninstalling KB4038788 or KB4040724 (which supersedes the previous update) fixes the issue. So far I observed it only in the PMDG 777, 747 and FSlabs A320. All other aircraft I own, including PMDG 737 seem to be unaffected.

The navigation using VOR and ADF is pretty standard. You don't have to use NVU calculator or INS systems during first flights, those were for flying over areas where navaids were scarce, like the vast spaces of the Soviet Union.

Great, thanks for the info.

Fixing it should be possible with the free version available on avsim too: https://stevesfsxanalysis.wordpress.com/2014/07/08/ftx-global-lights/