Luke Kolin

You are correct. They are distinct data in MSFS, and can be different. My preference was to have a single offset but I realize we can't do this if they will be different, and my code path doesn't look too ugly (but give it time - it's only 6:30am here!) You are correct to remove in FSUIPC6. Sorry for the extra work. Cheers

What is the difference between the two?

Sorry, let me check. Excessive multitasking today. Cheers

It certainly is, all the way back to FS9 IIRC. It's under [General], it's just atc_model rather than icao_type_designator. Cheers

Thanks, but I don't seem to be getting anything at 0618h. Cheers

Is offset 0618h available in FSUIPC6? I understand that you are winding down development, but this would be very helpful for those folks using WideFS. I don't believe it's available directly. If it is not available, could it be added? Cheers

That's helpful. Is this part of the log expected: 662000 Lua threads being terminated: 662000 1 = "D:\Program Files\FSUIPC6\tfdimd11.lua" 662000 LUA: "D:\Program Files\FSUIPC6\tfdimd11.lua": killed It feels like an unclean shutdown. Cheers

I have a LUA script for my aircraft that runs and handles custom actions for button presses. I've registered a shutdown handler to run when the sim shuts down, and it is being called correctly. The last three lines in the shutdown handler are as follows: event.cancel("HandleShutdown") ipc.log("TFDi MD-11 Button Handler shutdown (" .. btnCount .. " buttons, " .. updCount .. " LED updates)") ipc.exit() When P3Dv5 shuts down, the handler is called correctly, and I can see the last log line execute. However, in the log I see a 2150ms wait time, then the LUA thread gets killed. Should it not be dead already given the ipc.exit()? Full FSUIPC log attached. Cheers FSUIPC6.log

Thanks John! This looks good at first glance. Cheers

XP and MSFS/P3D report flaps completely differently. XP is "percentage of full flaps" so the last detent is 100%, and flaps up is 0%. You need to create something custom for each aircraft to map the percentage to a flaps setting. Cheers

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

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

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

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

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