borgfan

I've now read that the premium aircraft actually do have the aircraft.cfg (and other) files DRM protected and stored in "cgf.fsarchive". I assume that they are extracted at runtime in some manner, but effectively reading or changing aircraft.cfg for these aircraft is outside our control.

Is the missing aircraft.cfg a feature of the DRM protection in premium versions of the SIM, or its there but you can't see it ? I've only the standard version.

Thanks for this John, its exactly what I need to update my acars application. Hopefully Asobo will make path reporting more robust in the near future. In the interim, as an experiment I've written a function to traverse the package folder to locate all aircraft.cfg files and then extract the relevant icao entries based on the aircraft title provided by FSUIPC. Problem is that it takes an appreciable time doing this, ~18 secs on my PC and therefore not really suitable for a production system. Appreciate the effort you've put into this Gerard

Triple confused .... I'm running the MS Store version and just checked the value of 0x3c00 using FSInterrogate2std. Result was the full path to aircraft.cfg. Also confirmed in the FSUIPC7 logfile. 110141 Aircraft loaded: running normally now ... 115938 User Aircraft ID not supplied -- trying default 188813 D:\MSFS2020\Official\OneStore\asobo-aircraft-c172sp-as1000\SimObjects\Airplanes\Asobo_C172sp_AS1000\aircraft.CFG I'm not aware of any updates being applied and I haven't changed my system in any way. No magic involved so I can only assume that MS must be playing silly b....rs with invisible online changes.

Thanks for the help, unfortunately I don't see an easy way forward for what I want to do. It seems that there are so many installation varieties that contribute to a confusing mess. As I have only a small SSD for my 😄 drive, I installed the MS version on 😧 This resulted in d:\MSFS2020 (my choice of name) containing the Community and Official folders. Using the various offsets I get: 3c00 - Air file path SimObjects\Airplanes\Asobo_C172sp_AS1000\aircraft.CFG 3e00 - FS Path D:\MSFS2020\ 3d00 - Aircraft title Cessna Skyhawk G1000 Asobo 3500 aircraft model TT:ATCCOM.AC_MODEL C172 3160 aircraft type TT:ATCCOM.ATC_NAME CESS When looking at the FSUIPC7 logfile I see for example: 8156 SimConnect_Open succeeded 8172 Running in "KittyHawk", Version: 11.0.282174.999 (SimConnect: 11.0.62651.3) 8172 MSFS version = 11.0.282174.999 8172 Initialising SimConnect data requests now 8172 C:\Users\Mars\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\MISSIONS\Custom\CustomFlight\CustomFlight.FLT 8172 SimObjects\Airplanes\Asobo_C172sp_AS1000\aircraft.CFG 8187 User Aircraft ID 1 supplied, now being used 8234 Aircraft loaded: running normally now ... 8437 System time = 03/09/2020 11:18:30, Simulator time = 11:18:04 (10:18Z) 8437 Aircraft="Cessna Skyhawk G1000 Asobo" 65984 -------------------- Starting everything now ---------------------- 1254031 Sim stopped: average frame rate for last 1246 secs = 29.4 fps 1254031 Max AI traffic was 23 aircraft 1254031 ------------------------------------------------------------------- 1263703 D:\MSFS2020\Official\OneStore\asobo-aircraft-c172sp-s1000\SimObjects\Airplanes\Asobo_C172sp_AS1000\aircraft.CFG 1264093 flights\other\MainMenu.FLT 1288234 === QUIT notified! Saving "Previous Flight" ... 1293765 MSFS no longer running - exiting Note that line 1263703 contains the full pathname of the aircraft.cfg. When I first tried MSFS a week ago, offset 3C00 did provide the full pathname to the .air file. I suspect the results of 3C00 changed after the MSFS patch. For me 0x3E00 - the path to the \packages location in "c:\users\...\packages" is an empty folder, probably because my packages are installed in d:\ I'd be wary then of using this location within LINDA to list aircraft as it wont work in a custom install. Hope this makes some kind of sense!

Offset 0x3C00 is documented as providing the full path name to the current .air file and has worked fine except on MSFS where it gives a relative path from the simobjects folder, eg "SimObjects\Airplanes\Asobo_C172sp_AS1000\aircraft.CFG". Because of this I'm finding it difficult to locate and read the current aircraft.cfg. I noticed in the FSUIPC logfile a line containing the full pathname of the aircraft.cfg, I'd be grateful for a hint as to how this was constructed. I am reading the aircraft.cfg because at the moment the offsets for "ATC TYPE" and "ATC MODEL" (0x3160 and 0x3500) are not very useful. For example ATC TYPE is returned as "TT:ATCCOM.ATC_NAME CESS", clearly more than 24 characters and hard to use in its current form. I also noticed that the aircraft.cfg contains some new entries "icao_type_designator", "icao_manufacturer" and icao_model". These would be very useful if you could provide them as new offsets. I appreciate that the MSFS sdk is far from complete and we are all working around the rough edges, thanks for your help. Gerard

Thanks Paul, much appreciated. Gerard

Thanks Paul, I can can see how the lbs to kgs conversion could lead to the small differences arising, I guess I was just expecting that the empty weight would be a constant irrespective of whatever other weight changes were going on. I suspected that the empty weight was derived from gross weight but kind of hoped it was static as defined in the aircraft.cfg. No problem to work around. I was toying with creating a payload manager app and thus spotted the delays in updating changed values. I can easily just insert a small delay after executing a write change and so keep everything consistent, no problems there. Much appreciated. Gerard

I've been experimenting with managing fuel and payload using vb and your excellent dll but have come across a couple of oddities. Using your example code, I've observed that changing fuel level also changes the empty weight (by a small amount). I've tested this on FSX/Acc using the default C172 but see the same behaviour on P3d. I'm using VS2017. Also when I set a payload station value, write the change and then read the station again, the value does not seem to have been updated. payloadStations(0).WeightKgs = CDbl(txtPilot.Text) FSUIPCConnection.PayloadServices.WriteChanges() FSUIPCConnection.PayloadServices.RefreshData() txtPayload.Text = FSUIPCConnection.PayloadServices.PayloadWeightKgs.ToString("F2") However if I insert a short delay between writing the change and reading the new result, it seems ok. Any ideas on what might be happening? Thanks Gerard

Thanks Pete, I'll look at alternatives. Gerard

Hi Pete, In FSUIPC4 I can read the current flight Plan path & file name from offset 0130. This is documented as new to FSX. I am looking for a way to achieve the same thing using FSUIPC9 on FS9. Gerard

Hello, I'm a bit confused as to whether it is possible to read the currently loaded flight plan in FS9. The documentation seems to describe a path reading mechanism for flights but I think this excludes plans. The position is FSX is straightforward but clarification and a pointer in the right direction for FS9 would be very helpful. Tks Gerard

Hi Pete, I've been using the time of day indicator at offset 115E while running FSX (acceleration) + FSUIPC version 4.921f and suspect that the documented return values are inaccurate in the FSUIPC4 Offsets Status pdf document. I found that the offset returns 1=day 2=dusk 3=night and 0-dawn, Under FS9, the returned values are as documented 1=day 2=Dusk/Dawn 4=night. Guess this isn't a very widely used function, but thought it worthful just to post a clarification. Tks Gerard

Thanks a lot, much appreciated. Its hard to visualise how I could do without FSUIPC now that I'm starting to understand more of its potential. Best support in the business too :razz: Regards Gerard

Using version a registered version of 4.86 and the Carenado C182RG which only has tuning for ADF in whole numbers, I entered AutgoTuneADF=Yes in the .ini file and positioned the aircraft on the runway at EGAE. NDB EGT with frequency of 328.5 was tuned ( as 384), but the ADF needle didnt move indicating so signal received. I switched aircraft to the default C172 and noticed the decimal number on the Bendic ADF flickering rapidly between 0 and 5 (many times per second) but no needle movement. With AuoTuneADF disabled, I am able to tune the NDB correctly on 328.5 with the default C172. Would it be possible to confirm please that he autotuneadf feature does continue to work correctly as per the manual in FSX ? (I'm using FSX SP2) Tks Gerard