7 minutes ago, JRBarrett said:

Unlike many MSFS users, I am not disappointed by the state of the default ATC. I concluded long ago that NO flight sim developer has the ability to produce a built-in ATC system that is worth a pile of poo. FSX/P3D and X-Plane are little better in this regard.

I don't quite follow your comment in your second sentence. There are a few ATC programs for FSX/P3D that are a substantial improvement on the default.

It may be a very long time before independent ATC programs become available for MFS. One necessity for Radar Contact is the data provided by MakeRunways. Pete Dowson has been asked if a version for MFS might become available but he's struggling to find the data. Until the SDK covers that aspect of the sim it looks like users are going to have to use the default ATC.

14 hours ago, BrianW said:

With some autopilots like the KAP-140 using a remote baro reading is only an installation option.  If it's not installed that way you're required to set it on the unit itself.  If there's a baro button on the autopilot have you tried verifying or setting it there?

Brian, you are correct.  In the real world I fly both "standard gauge" + KAP 140 and G1000 + GFC700 equipped aircraft.  The KAP140 has a separate Baro setting feature to enable you to ensure the altimeter and autopilot have the same baro set, whereas the G1000/GFC700 only requires to to set it once on the G1000.

Paul

Just now, Ray Proudfoot said:

I don't quite follow your comment in your second sentence. There are a few ATC programs for FSX/P3D that are a substantial improvement on the default.

It may be a very long time before independent ATC programs become available for MFS. One necessity for Radar Contact is the data provided by MakeRunways. Pete Dowson has been asked if a version for MFS might become available but he's struggling to find the data. Until the SDK covers that aspect of the sim it looks like users are going to have to use the default ATC.

I am speaking strictly of the default ATC created by the same developers as the flight sim itself. 3rd party add-ons that create automated ATC are an entirely different matter. I used Radar Contact for many years and found it to be first rate - but it was developed by a real-world ATC controller.

I believe that kind of r/w expertise and experience is essential to created a realistic automated ATC system. Asobo would have been better served to have outsourced the entire MSFS ATC system to a developer who specializes in that sort of thing, like the folks who created Pilot2ATC.

Jim, thanks for clarifying. Default ATC is something only the casual pilot would use through choice. Once you've used a 'serious' ATC program reverting to a default would be a serious disappointment.

RC had the input of two real-world controllers. Doug Thompson (FAA) worked in the US (forget which centre) and Pete Pitman (Swanwick) provided the ICAO rules for the UK and much of the world. How their expertise would be welcomed by any new programmer.

We also used the mathematical skills of another Brit - John Burgess - who did all the trigonometry required to know where aircraft are relative to each other. That takes serious skills and perhaps explains why there are so few good ATC programs around.

Although it's a bit off-topic for this thread, I think it's a great pity that JD didn't release his source code to the community when he made RC4 freeware. There is another issue with getting RC4 working with MFS apart from makerunways - the display necessary for interaction doesn't work and I'm not sure if that can be fixed without modifying the source. What would have been even better would be if the WIP RC5 source were available for someone to take on development.

@ConstVoid, doesn't MFS use SimConnect? RC4 on P3D uses that to display its menu.

On the point of releasing the code I agree 100%. Written in VB but that's more than adequate when speed isn't important.

I run RC4 on a networked PC and use ShowText to display the RC menu. WideFS achieves that. Sorry for deviating off-topic. Better leave discussion there.

18 minutes ago, Millingp said:

Brian, you are correct.  In the real world I fly both "standard gauge" + KAP 140 and G1000 + GFC700 equipped aircraft.  The KAP140 has a separate Baro setting feature to enable you to ensure the altimeter and autopilot have the same baro set, whereas the G1000/GFC700 only requires to to set it once on the G1000.

Paul

The KAP-140 (which debuted in 1996) was created at a time when very few GA analog altimeters had the ability to output their indicated altitude electronically, thus the need to for the autopilot to have its own altitude sensor.

The G-xxxx uses its own dedicated air data module which receives pitot and static pressure and outside air temperature and outputs indicated and pressure altitude, and indicated and true airspeed for use by all components of the system, including the autopilot. 

The Garmin system also has a dedicated electronic AHRS module which outputs pitch and roll information. Older autopilots would have to obtain this data from the analog attitude indicator and/or HSI, though many less complex GA autopilots simply take roll information only from the turn coordinator. This is the case with many STEC autopilots which replace the default turn coordinator with their own dedicated unit, and which have simple altitude hold only (no preselect).

55 minutes ago, Millingp said:

Ray, your absolutely correct.  That's the original point I was making and I agree it should be easily fixed by Asobo.

Paul

Not that easy as it doesnt seems to be an widespread issue. Probably why Adobo messes things up when trying to fix something actually, they'r trying to fix something thats not broken for everyone 

Yes MSFS uses FSUIPC and hence simconnect, but a few people have tried RC4 and have reported that the display doesn't show up. I've only had a half-hearted attempt so far, so I can't say for sure there's no way to get it working. Maybe the beta FSUIPC7 need tweeking.

(Sorry - just noticed your comment agreeing about off-topic, so I'll leave it now)

Edited October 9, 20205 yr by ConstVoid

33 minutes ago, JRBarrett said:

I am speaking strictly of the default ATC created by the same developers as the flight sim itself. 3rd party add-ons that create automated ATC are an entirely different matter. I used Radar Contact for many years and found it to be first rate - but it was developed by a real-world ATC controller.

I believe that kind of r/w expertise and experience is essential to created a realistic automated ATC system. Asobo would have been better served to have outsourced the entire MSFS ATC system to a developer who specializes in that sort of thing, like the folks who created Pilot2ATC.

Maybe a future Partnership serie! 

7 minutes ago, ConstVoid said:

Yes MSFS uses FSUIPC and hence simconnect, but a few people have tried RC4 and have reported that the display doesn't show up. I've only had a half-hearted attempt so far, so I can't say for sure there's no way to get it working. Maybe the beta FSUIPC7 need tweeking.

(Sorry - just noticed your comment agreeing about off-topic, so I'll leave it now)

Ask John Dowson on the FSUIPC forum. It may be something they can fix once a more stable SDK is available.

https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/

I will bow out now. 😁

11 minutes ago, leprechaunlive said:

Not that easy as it doesnt seems to be an widespread issue. Probably why Adobo messes things up when trying to fix something actually, they'r trying to fix something thats not broken for everyone 

A few of you with the problem should get together with the same airport, same time, same flight plan. If you all find the issue then give those facts to ASOBO and it should be enough for them to find the bug.

Just now, Ray Proudfoot said:

A few of you with the problem should get together with the same airport, same time, same flight plan. If you all find the issue then give those facts to ASOBO and it should be enough for them to find the bug.

We kind of already did that, he gave us a few parameters that we had to follow, and we had different results. We could go even further and specify the type of plane, time of day, location to see if that changes anything i guess. But those are the least likely things to influence the resultd but then again, MSFS is full of surprises 😄

17 minutes ago, leprechaunlive said:

We kind of already did that, he gave us a few parameters that we had to follow, and we had different results. We could go even further and specify the type of plane, time of day, location to see if that changes anything i guess. But those are the least likely things to influence the resultd but then again, MSFS is full of surprises 😄

'He' being an ASOBO representative I assume? The same aircraft, same time and same airport are absolutely essential to find a bug. It might be present in one aircraft but not another. If even two people could replicate the bug that is a big help to the people trying to locate the bug.

But yes, it could be present with all default aircraft and at many different airports but it's important to all start with the same conditions. Does MFS have historical weather so you can load specific weather for an airport for a specific time?

1 minute ago, Ray Proudfoot said:

'He' being an ASOBO representative I assume? The same aircraft, same time and same airport are absolutely essential to find a bug. It might be present in one aircraft but not another. If even two people could replicate the bug that is a big help to the people trying to locate the bug.

But yes, it could be present with all default aircraft and at many different airports but it's important to all start with the same conditions. Does MFS have historical weather so you can load specific weather for an airport for a specific time?

No, he means the OP 😄 and no MSFS doesnt have historical weather, it does have the customizable weather thingy but im always on live weather so il not sure the pressure can be set so we all have the same. I guess if we all take the same preset they would actually be the same across all users but considering the issue, we cant assume that either.