Claude Troncy

Thanks Pete for your comments. Claude

Bonjour Pete, May be your informed opinion could help me understand this: -Same computer -Two disk with the same OS windows 7, one for P3D stable, and the other for development and test. On one system the restart of P3D on the fly is very quick, on the other it is very long. I don't see any reason for that, so if you have an idea ? FSUIPC log Quick Load between 1966 and 1778 Long Load between 24008 and 1934 Merci Cheers Claude

😃😃 Everything seems to be OK now and FSIPanel is happy with the new runways files. Again thank you very much Pete. Claude

Hi Pete, Thank you very much, the airport magvar are now well reflected for each runway, but in the runways.xml, it seems that the <Hdg> and <ILSHdg> tags don't reflect the correct magnetic heading, and whatever the magvar is, these value don't change. Cheers Claude

Thank you Pete. You don't have to apologyze. You make such a great job for the world of FSX... P3D. Take your time to fix the problem. I wish you nice holidays. Cheers Claude

Yes all airports have this problem. I only change the MagVar in the global airport section and it was reflected by MakeRwys for all the runways. In fact I do not find any MagVar data in the runway subrecord. Where is this data ? Claude

Hi Pete, I made a mistake! In fact with fsaerodata, the MagVar should be 0.780 I investigate with an hexa editor in the different files. - In the files situated in the 3 sceneries at the top, the MagVar is coded as 0.780 - But in the file APX48140.bgl (provided by fsaerodata) they did not change the initial P3D MagVar, and is -2.00 That explain the difference in the files generated by MakeRwys. Now if I modify the fsaerodata APX48140.bgl with the correct MagVar 0.780 instead of -2.00 then all the date made by MakeRwys are coherent and FSIPanel is happy. When FSIPanel is not happy the A/C is positionned far to the left or the right of the runway axe and after the A/P doesn't capture the ILS (PMDG 737 NGX) I am going to send an email to fsaerodata asking them why there is an inconsistency, between the MagVar values in their files. I hope they will not say that the MagVar in the top sceneries must overide the one in the APX48140.bgl. Again thank you for helping me to understand where the problem was. Cheers Claude

Bonjour Pete, So the infos are for LFPO MakeRnwys detects LFPO airport in 4 files, the last three, which are at the top of the sceneries doesn't have any MagVar at all. Cheers Claude

I perfectly understand. -2.00 is expected. I tried too and the file looks strange, but I think it is in this file (or the other two) that MakeRwys find the wrong value 0.78 associated with the airport. But is it really an airport ? When the 3 sceneries are not active then MakeRwys find the correct value in Scenery\0601\scenery\APX48140.bgl. This file is also provided by fsaerodata and overwrite de initial one. Claude

I know that with aero.sors the problem is identical. https://www.fsipanel.com/forum/viewtopic.php?f=6&amp;t=233 That means the problem is not in the data provided by aero.sor and fsaerodata. As the problem doesn't seem to be with MakeRwys, I am going to check again with FSIPanel. Nevertheless I'll try the aero.sors data and let you know. Merci Claude

I agree with you. That is incomprehensible. OK I attach them. Thanks Claude FSAD_comms.BGL LFPO.BGL LFPO_SIDS.BGL

Continuing the investigation I found that fsaerodata adds 4 sceneries at the top Extract of MakeRwys_Scenery.cfg If one of FSAD_Approaches, FSAD_Approaches1 or FSAD_Comms is active then Runways.xml (LFPO data) is construct with the first one which is active. If none is active the data from the standard BGL file "Scenery\0601\scenery\APX48140.bgl" is used. In all case Runways.txt and I suppose r4.csv are built using the standard BGL file "Scenery\0601\scenery\APX48140.bgl" Cheers Claude

What is strange is that the bgl file detected in the runway. txt and in the runway.xml is not the same. See my first post Claude

Hi Pete, So I deleted three files . r4.csv, Runways.xml and Runways.txt. I then run MakeRwys and for LFPO - In r4.csv the MagVar is -2.00 - In Runways.txt MagVar is -2.00 - In Runways.xml MagVar is 0.780 The three files have the same "Date modified" value. Without fsaerodata all the MagVar values are equal to -2.00 Cheers Claude

Bonjour Pete and John, May be you can help ! I have just installed fsaerodata and it confuse FSIPanel, which use MakeRwys to build it's own database. Investigating the problem, I compared the runway.xml, and I found a difference in the magvar data. For LFPO it is -2.00 without fsaerodata and 0.780 with it. Nevertheless if I compare the two runway.txt (with and without fsaerodata), i do not see any difference both are at -2.00. **** Runway.txt --- with fsaerodata **** Airport LFPO :N48:43:23.9967 E002:22:45.9997 291ft Country Name="France" State Name="" City Name="Paris" Airport Name="Orly" in file: Scenery\0601\scenery\APX48140.bgl Runway 6 /24 centre: N48:43:39.9347 E002:20:20.1818 291ft Start 6 : N48:43:12.9826 E002:19:03.9770 291ft Hdg: 61.8T, Length 11961ft Computed start 6 : Lat 48.720020 Long 2.317014 Offset Threshold primary: 984 feet Start 24 : N48:44:06.8868 E002:21:36.3851 291ft Hdg: 241.8T, Length 11961ft Computed start 24 : Lat 48.735500 Long 2.360865 Hdg: 61.840 true (MagVar -2.000), Concrete, 11961 x 148 ft **** Runway.xml --- with fsaerodata **** <ICAO id="LFPO"> <ICAOName>Orly</ICAOName> <Country>France</Country> <City>Paris</City> <File>C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL</File> <SceneryName>FSAD_Comms</SceneryName> <Longitude>2.379441</Longitude> <Latitude>48.723324</Latitude> <Altitude>291</Altitude> <MagVar>0.780</MagVar> *** In R4.csv --- with fsaerodata **** The magvar is the same than the one in runway.txt but different thank the one in runway.xml LFPO,0020,48.717541,2.376687,291,20.340,7866,110.30,197,-2.000,48.727779,2.381833,0 I do not know if it is the source of the problem for FSIPanel, but is there something which could explain the difference between the xml and the txt file for the magvar data. Thanks for youy help Cheers Claude

Hi Pete, Of course you are right, it is obvious now that the script terminate before it has the time to display the window. What an idiot I am. I have 50 years of software development behind me, and it looks like a beginner's mistake. May be I am getting younger...😃 or NOT ! Thanks Pete Cheers Claude

Bonjour John, Print is here only to have a trace in the fsuipc log file. The script is called with a joystick button. I have of course use the console to trace the lua script, and have activate the lua log but nothing special in it. The script is this one The print "display" works and I can see it in the fsuipc log The display("HI") doesn't work The sound is played without a problem. Cheers Claude

Bonjour, I have this simple script No window appears on the screen and of course nothing is displayed even when I try the non simconnect window using the parameter NoMessageWindows=Yes in the ini file. What can I do investigate more ? Thanks Claude

Hi John, No as the axis assignement is done in P3D V4. I only want the calibration done by FSUIPC as I do with other axes. I do not have the 'Axis Steering Set' in the combo box. Yes I have this version installed. Cheers Claude

Bonjour, In P3DV4, I have the axis assignement "Axis Steering Set" assigned to the Rz axis of my Saitek X52 PRO. I cannot find it in the FSUIPC (V5.14) joystick calibration. When I move the Rz axis of my X52, nothing is displayed in the Steering tiler box. It seems that this axis is ignored ? I have no problem with the other axes. Any Idea ? Cheers Claude

Bonjour Jean you can find the 5.121.c in the updated module section here http://forum.simflight.com/topic/80977-updated-modules/ Cheers Claude

Thanks Pete. Everything is OK now with the 5.121c. Cheers Claude

Thank you very much. What I do not understand is why it was working in 4.0 ? LM has certainly change something. Claude

Same problem with the latest driver from Nvidia. Claude

No that did not work...... But I found something new ! I use DSR (4.00x (native resolution)) with my nvidia 1080. It is the best way for me to have less shimmering with a good AA. My native resolution is 1920 X 1200, P3D use 3840 X 2400 and the GPU downscale to the native resolution. When I do not use DSR, I do not have the problem, and everything is as it was in P3D V4.00. I will install the latest nvidia driver and see what happens. It is not a problem I can live like that, and wait for your interim update. There is no hurry ! Claude