Incorrect Aircraft.CFG location

[Luke Kolin]

I am attempting to read values from the aircraft.cfg in FS2020 using FSUIPC7. It looks like it is not getting a correct value for the aircraft location (it is in the community folder) which therefore gives me the wrong path for the aircraft.cfg. Offset 618h would give me what I want, but it looks like FSUIPC7 reads that from the aircraft,cfg, so it appears that is empty as well.

Happy to provide more details - with the community folders there's a fair bit of redirection going on.

Cheers

[John Dowson]

15 minutes ago, Luke Kolin said:

It looks like it is not getting a correct value for the aircraft location (it is in the community folder) which therefore gives me the wrong path for the aircraft.cfg.

Do you mean in offset  0x3C00? What is the value in that offset, and which aircraft are you using? Could you add logging for that offset and show me the FSUIPC7.log file.
Note that this should be the full path name but sometimes its a relative path (reported to Asobo several years ago, but I haven't checked this for a while). This also may not ne available/correct for encrypted aircraft,

20 minutes ago, Luke Kolin said:

Offset 618h would give me what I want, but it looks like FSUIPC7 reads that from the aircraft,cfg, so it appears that is empty as well.

Yes, as the documentation says for this offset: 

ICAO Designator: Read from aircraft.cfg file (only available when 0x3C00 contains the full path to this file)

So it looks like MSFS is just not returning the full path of the aircraft,cfg file for the aircraft you are using.

Its even worder in MSFS2024 now aircraft are streamed...

Cheers,

John

[John Dowson]

See https://devsupport.flightsimulator.com/t/simconnect-requestsystemstate-aircraftloaded-returns-partial-path-of-aircraft-cfg/9041/6

John

[Luke Kolin]

3 hours ago, John Dowson said:

Do you mean in offset  0x3C00? What is the value in that offset, and which aircraft are you using? Could you add logging for that offset and show me the FSUIPC7.log file.
Note that this should be the full path name but sometimes its a relative path (reported to Asobo several years ago, but I haven't checked this for a while). This also may not ne available/correct for encrypted aircraft,

I did some more digging (and upgraded to 7.501) and here's what I found. Aircraft is the Headwind A330-900neo with an add-on Delta texture pack. If I use the base version of the aircraft, all is well. It reports the aircraft path as following:

d:\program files\fs2020\community\headwindsim-aircraft-a330-900\simobjects\airplanes\headwind_a330neo

... which is correct. I can read the file and offset 618h is populated and correct. Now if I switch to one of the add-on textures, the path is reported as

D:\Program Files\FS2020\SimObjects\Airplanes\Headwind_A330neo

... which obviously is not correct. The correct path should be as follows:

D:\Program Files\FS2020\Community\headwind-a339-Delta-Pack\SimObjects\Airplanes\HWD-A339_DAL3414

What I think is happening is that the aircraft.cfg that is in that folder is just a stub with the variant information, and has a reference to the parent like this:

[VARIATION]
base_container = "..\Headwind_A330neo"

Which may be confusing FSUIPC7?

Cheers

[John Dowson]

It is not confusing FSUIPC7. it is confusing MSFS. Offset 0x3C00 is populated from the path received in the 'AircraftLoaded' system event, If it is wrong for variants, then it should be reported to MSFS. I can take a look next week to see if I see the same issue and if so will report this, but I don't think there is much else I can do.

Cheers,

John

[Luke Kolin]

Thanks for the update. This is unfortunate. Is Asobo actually making bugfixes to FS2020 at this time?

Cheers

[John Dowson]

Hi Luke,

I don't have any aircraft that use the [VARIATION] section (with a relative path), so cannot really check this. As you have done this, maybe you could add this information to this bug  report: https://devsupport.flightsimulator.com/t/simconnect-requestsystemstate-aircraftloaded-returns-partial-path-of-aircraft-cfg/9041/6
Better to not mention offsets or FSUIPC - just refer to this as the data returned from the AircraftLoaded event. You can use the attached version (and enable logging for Extras) which will log the actual parameter received. Or you can attach the log file here.

John

FSUIPC7.exe

[Luke Kolin]

I did some basic switching around with the custom build you enclosed, and I also started to log three offsets to see if the tail code and aircraft ID were loaded. It appears that with the custom build, I'm getting back the parent aircraft.cfg, and the correct model and tail code in the offsets?? I started with the base model, then switched to the custom texture variants.

If there's a specific test case you want me to walk through, happy to do it.

Cheers

 

FSUIPC7.log

[John Dowson]

1 minute ago, Luke Kolin said:

It appears that with the custom build, I'm getting back the parent aircraft.cfg, and the correct model and tail code in the offsets??

But there is no functional difference in that build - the only difference is that the AircraftLoaded events (both on specific request and via a sim state change) will be logged with the parameter received. There should be no difference in the values received and/or held in offsets.
Note, as documented in that link, there is a difference in the value when specifically requested and when received from a sim state update.

So I am confused now. Compare both versions with the exact same test (i.e. don't just exit one version of FSUIPC and start the other - exit MSFS and repeat the test).
Then compare the values in the offsets - they should be exactly the same if the test was the same. The only difference should be in the log, where the log for the patched version will show the full values received from the AitcradtLoaded events,

You can also attach both log files here.

[Luke Kolin]

It looks like order of operations is significant. I tried a quick test case which was reversing the order of loading the aircraft - starting with the custom texture variant. It looks like FSUIPC may be getting two aircraft loaded events - one with the "main" aircraft.cfg that's an absolute path, then a buggy relative path. What's interesting however is that it gets the correct model ID from the first load, then overwrites it with an empty string subsequently.

Cheers

 

FSUIPC7.log

[John Dowson]

2 hours ago, Luke Kolin said:

It looks like order of operations is significant. I tried a quick test case which was reversing the order of loading the aircraft - starting with the custom texture variant. It looks like FSUIPC may be getting two aircraft loaded events - one with the "main" aircraft.cfg that's an absolute path, then a buggy relative path.

Yes - this is the exact issue in that bug report I have referenced several times - here are the first few lines:

Quote

SimConnect_RequestSystemState(AircraftLoaded) returns partial path of aircraft.cfg
for example, will get
“SimObjects\Airplanes\Asobo_Baron_G58\aircraft.CFG”

but
SimConnect_SubscribeToSystemEvent(AircraftLoaded) returns full path of aircraft.cfg

for example, will get

“F:\MyChosenFolder\Packages\Official\OneStore\asobo-aircraft-baron-g58\SimObjects\Airplanes\Asobo_Baron_G58\aircraft.CFG”

As FSUIPC can be started when the AircraftLoaded system event has already past, it also uses the RequestSystemState call.
However, you log does show an issue:

Quote

    58110 14976 State = AircraftLoaded: ''
    58110 14976 **** Empty name received in 'AircraftLoaded' state'
...
    87578 14976 AircraftLoaded Event: 'd:\program files\fs2020\community\headwindsim-aircraft-a330-900\simobjects\airplanes\headwind_a330neo\aircraft.cfg'
    87578 14976 aircraft.cfg path received: 'd:\program files\fs2020\community\headwindsim-aircraft-a330-900\simobjects\airplanes\headwind_a330neo\aircraft.cfg'
    87578 14976 d:\program files\fs2020\community\headwindsim-aircraft-a330-900\simobjects\airplanes\headwind_a330neo\aircraft.cfg
    87578 14976 **** Re-requesting 'AircraftLoaded' state as was empty
    87578 14976 Monitor IPC:0618 (AsciiZ) = [4]"A339"
    87578 14976 Monitor IPC:3C00 (AsciiZ) = [114]"d:\program files\fs2020\communit"
    87578 14976 State = AircraftLoaded: 'SimObjects\Airplanes\Headwind_A330neo\aircraft.CFG'
    87578 14976 aircraft.cfg path received: 'SimObjects\Airplanes\Headwind_A330neo\aircraft.CFG'
    87578 14976 SimObjects\Airplanes\Headwind_A330neo\aircraft.CFG
    87578 14976 Monitor IPC:0618 (AsciiZ) = [0]""
    87578 14976 Monitor IPC:3C00 (AsciiZ) = [50]"SimObjects\Airplanes\Headwind_A3"

The request done at 2nd bold timestamp 87578 should not really occur, but is happening as a flag is being set at timestamp 58110, but not being cleared at 1st bold timestamp 87578, so that request is unnecessary. I will correct this.

2 hours ago, Luke Kolin said:

What's interesting however is that it gets the correct model ID from the first load, then overwrites it with an empty string subsequently.

That is because it cannot open the aircraft.cfg file as the path is relative, so it resets the offsets read from this file.
Relative paths may be useful (and these may also get corrected at some point) so I will still add them if that is all that is available, but what I can do is add a check so that when a relative path is received, I can compare it (case-independent) to the end characters held in offset 0x3C00 and only update if they differ. This should preserve the full path when available, and only update to a partial path if that is all that is available.

I have to take the dogs out now - will make these changes either later this evening or tomorrow and provide you with an updated version to test.

 

[John Dowson]

Please try the attached (with Extras logging):  FSUIPC7.exe

Not had time to test but should be ok...will review tomorrow, Please attach log or confirm ok if you can test,

Regards,

John

[Luke Kolin]

Thanks John! This looks good at first glance.

Cheers