Luke Kolin

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

Don't run FS9 as Admin, or run your program as Admin. Cheers

GSX, like FSUIPC, is also a separate application. Cheers

Could it be a permissions issue? Is FS9 running as Admin? Cheers

This seems to match I've discovered... if the LVAR does not exist then the previous value that was in the offset is retained. I can work around this by clearing the offset block in advance (I'm only reading from 24 to 48 bits at a time, so a since 64-bit long write can clear them out in one operation). In a perfect world, I'd prefer them to be set to zero, but I can also see advantages to this behavior as well (I can write a default value to the offset prior to the read). At the very least, it may be helpful to annotate the programmers guide to note this behavior in the case of an uninitialized LVAR. I need to maintain compatibility back to FSUIPC4 🙂 so this is my preferred way to go. (Technically even farther, but I can no longer validate the FS2002/FSUIPC2 path and the FS9 path doesn't have GSX support). It's a testament to the great work that you and your father have done - I've been working on this application since the FS9 days and it's usually just a day or two of work to support a new simulator. It's a a great abstraction layer. Cheers

Sorry I wasn't more clear. I am not using Lua, I'm using offsets 0x0D6C and 0x0D70. To give the sequence of operations, I read the LVARs FSDT_GSX_BOARDING_STATE and FSDT_GSX_STATE to detect whether FSDT's GSX package is installed and operational. When called, I get the value of 1 back for the former, and 3 for the latter. I then ready FSDT_GSX_NUMPASSENGERS to see if a passenger count has been set by GSX. It also returns 3 What's interesting is that when I then fire up a LUA macro that selectively dumps LVARs to the SimConnect message window, FSDT_GSX_NUMPASSENGERS does not exist. It is curious and suspicious to me that the value returns is the same from the last LVAR successfully read. I'll try and make a test case where I manually set an LVAR, read it, then read an LVAR I know does not exist via the 0xD6C/0xD70 method. Cheers

This is helpful context. If an LVAR has not been created when I request to read it, then get_named_variable_value would return an undefined result? I think this matches what I'm seeing. I guess there's no way for FSUIPC to check if it has been initialized prior to the read? Cheers