pdubost

Thank you John, I have tested several controls and it works perfectly. Much more powerful than the rotor brake scheme. I can now set my MCP dials from my Vrinsight much more efficiently! Great ultra reactive response as usual ! Cheers Pierre

Thank you John for your support. This makes perfect sense. Looking forward for this new release. Regards Pierre

Hi John I read on the PMDG forums that some users are actually using these documented controls using AAO under MSFS. For example control 84136 for setting the MCP heading with a heading value . I do not have AAO, so I could not check it personally. Regards

Hello John This is the error I am getting when sending a control to the PMDG SDK : 2548172 Exception 1 "ERROR", Ref 5714, Index param 2 on TransmitClientEvent, object=1, id=83645 (????), data=0 Thanks Pierre

PMDG's SDK documentation seems to indicate that we can use controls as in FSX or P3D. On the other end, it appears that all controls above 69632 generate an error in the fsuipc log. Do we need to enable something in FSUIPC ?

Patch confirmed by Microsoft within 7 days which fixes the SimConnect issue (Aug 27th development update)

Waiting for this patch, MSFS 2020 is not usable by "real simmers" : It is just an arcade game, not a flight simulator ! Shame on Microsoft and Asobo not to put priority for fixing it ! In the meanwhile, I will go back to my old FSX ! But still thanks to you for coming out with FSUIPC on day one.

It is really unprofessional for MS to general release a version which has not been tested by beta testers or third parties. It spoils the initial experience of FS2020 despite your considerable efforts to release FSUIPC on day 1. It should be easy to fix as it was working before. Hopefully ASOBO will expedite the fix for this MAJOR bug.

Thanks Pete for the explanation ! I did not realize that there is a magdev field (optional but mostly always filled) in the airport bgl file. I guess that the base magdev.bgl file is only used by default if that airport.bgl field is not filled. I used the " Magvar corrector" program from aero.sors and it does fix correctly the runway magnetic heading with the current magnetic deviation. The name of the runway remains unfixed (e.g. in TFFR heading 116 but rwy 11 !). I will use an Excel formula to fix it automatically in runway.csv by computing the runway name from the current magneting heading, and that should close the RAAS issue. thank you again for the very helpful advice ! regards Pierre

Hello Pete Thanks for your quick response, but I am still confused. My understanding was that the airport BGLs contained rwy TRUE headings. For example, if I look at TFFR, it reads 100,90 ° rounded to 101. Then the magnetic variation is added (I assumed from the Magdev.BGL file) to compute the runway Magnetic heading. The airport.CSV file from MakeRwys for TFFR shows a magdev of 14° (2004 data?) leading to a rwy heading of 115° for rwy 11. Did you get this 14° also from the bgl file ? The real magdev in 2013 in TFFR is 15° leading to a rwy heading of 116° for rwy 12. thanks for your help ! Pierre

Hi Pete I am new on this forum, and want to thak you for your outstanding software products. I have a question on MakeRwys, trying to fix the "wrong rwys" issue in RAAS in the PMDG777; I am getting incorrect magnetic deviation, and therefore incorrect rwy magnetic heading and rwy names even after I ran your MakeRwys program. I have the latest Magdev.bgl file from easyNavs installed in Scenery/Base/scenery. My question is where do you get the magnetic deviation information ? Thanks Pierre