Luke Kolin

It looks like turning off LUA debugging kills it. Maybe a race condition? I'll add more logging later today. Cheers

I'm enclosing a log. I started FSUIPC7 separately, after MSFS was running It looks like the first iteration through the loop was exponentially slower. I'm going to take out the debug options and see if it gets killed again, if not I'll chalk it up to the ipc.display call. Cheers FSUIPC7.zip

I had forgotten about that, but I would strongly urge an enhancement to this functionality - the modification that I made to Pete's original Lua script was to add optional filter substrings so I could automatically include and exclude LVARs based on name. This would avoid a fair bit of work adding entries to the INI file one LVAR at a time. I'm attaching my FSUIPC7 log the second time around. It appears that Lua execution is very, very very slow. I terminated the sim before the script did a single execution to completion. Cheers FSUIPC7.log

I am using a modified LVAR logging script with the ability to selectively include/exclude LVARs. It works fine in FSUIPC6 and below, but attempting to run in FSUIPC7 and MSFS gives me no data. I tried removing the ipc.display() line (I vaguely recall that may be unsupported in MSFS), but it doesn't log to the FSUIPC log and I see the script getting killed even though I don't trigger a LuaKill. Is there something obvious I am missing? Cheers FSUIPC7.log LogLVars.lua

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