pilotjohn

Thanks... if I send a control (say Fuel Selector 2 Set 16), is there some deterministic delay for the offsets getting updated? My plan is to create a generic fuel selector toggle script which when run will read the current tank value and increment it until it "works" (meaning the change is reflected in the offset) or it reaches to the end. I'm wondering if there's some upper limit for the "wait to see if it worked". Specific question, for which you may not have the answer, is why I see an event (fuel selector 1 off) when I switch something in the cockpit (mouse), but if I send that control, it doesn't actually cause the event to happen. On the DA62, sending fuel tank selector controls with appropriate values (like left/right main) work, but "off" is ignored.

Thanks... yeah, I use battery master toggle (which works for the battery), but this is the engine computer for the DA40/62 (which are like car engines in that regard). I would love to bind them to my generic "ignition" switch but alas, it doesn't seem like that will happen.

I'm working on a generic fuel selector toggle Lua (each button press cycles to the next "working" non-off tank setting). My plan is to set the next tank state and see if it worked (if so, great, otherwise mark as inop and try the next one). I see there are some offsets to read... FUEL TANK SELECTOR:1 RECIP ENG FUEL TANK SELECTOR:1 .. 4 TURB ENG TANK SELECTOR:1 .. 4 Before I go down this path... Are these really different? Is there a reason why there's no generic fuel tank selector 2..4?

Apologies for the naïve question, but if there are no events being triggered by a switch, is it possible to trigger the functionality some other way (Lvar)? Specifically the DA40 and DA62 have master switches for the ECU which I would like to bind to button. Has anyone managed to do this yet?

Great, thank you!

I have not tried it or looked when it happened. If it happens again I will check. These seem to happen at inopportune times (this time on short final), so didn't have a lot of time to troubleshoot (had a few pauses before I was going to crash). I was triggering Pause with direct (in-sim) bound default keys. This is the first time. I don't do long flights (pretty much all are <30 mins) and it seems these all take time to manifest themselves. There have no changes in my platform/peripherals, except the upgrade to FSUIPC 7.0.1 and the Profile specific assignment for piston aircraft. Ack.

This issue is similar to when FSUIPC would crash (and control would be lost), however this time there was no crash of FSUIPC, but MSFS would not react to input. You'll see a few pauses where I tried to troubleshoot, but it did not restore input. I had to quit FSUIPC and only after restarting it did controls start working again (without sim restart). The "prev" log is where MSFS stops responding to input. FSUIPC7_prev.zip FSUIPC7.ini FSUIPC7.log

Ack, will let you know if I see crashes.

Ok, so I can create a profile and remove the buttons/keys, which would then apply the generic profile?

What would you suggest for change calibration type based on engine type? For example, I'd like mixture to not have a "reverse" zone (e.g. cutoff) for piston engines, but should have one for turbines. Or would you suggest using profile specific settings? Is there a way to apply one certain aspect via a profile, like the mixture (but not, say, buttons)?

Ok, I removed AxisScanOnSimConnectOpen, and will let you know. My ipcinit and ipcReady simply launch some AutoHotkey scripts, the first to get FltPlan GO connected, the other to change my StreamDeck button profiles for the specific aircraft. FSUIPC7.ini

I've started experiencing new FSUIPC crashes with the latest patch of MSFS, that don't seem to be related to the transmit client errors. Faulting application name: FSUIPC7.exe, version: 7.0.0.0, time stamp: 0x5f9c2f1a Faulting module name: ntdll.dll, version: 10.0.19041.546, time stamp: 0x5b56177b Exception code: 0xc0000374 Fault offset: 0x00000000000fed29 Faulting process id: 0x5640 Faulting application start time: 0x01d6b061a31e5c25 Faulting application path: D:\IslandJohn\FSUIPC7\FSUIPC7.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: bba1c786-f4c1-4c87-9b49-07142d488354 Faulting package full name: Faulting package-relative application ID: FSUIPC7.log

I think that's a great idea, it makes it completely customizable.

This is an interesting feature. Any chance this could made so that these are based on the stall speed (e.g. a fraction) instead of absolute values?

It's offset 123E. Let me try to clarify what I'm trying to achieve. I have a button which I would like to use to toggle through available fuel tanks selections in sequence (e.g. L, R, Both, Aux L, Aux R for example). In order to do this, I need to programmatically determine which tanks are available in the aircraft through some FSUIPC offset. I see there's an offset for finding the number of tanks, but I didn't notice one for which tanks are available.

I see there's a "number of fuel selectors available in this aircraft" reading, but how can I tell which specific ones are available? I'd like to assign a key to sequentially toggle through them (except the off position) with a script, but I would need to know which ones I can switch to.

I was confused between the offset... I see, thanks.

You mean use 0x3F02 for the event trigger instead?

I have the following ipcReady.lua to switch my StreamDeck profiles based on aircraft (button layout). function onload(offs, data) acft = ipc.readSTR(0x3D00, 256) ipc.log("loading StreamDeck profile for: "..acft) if string.match(acft, "XCub") then os.execute('start D:\\IslandJohn\\Scripts\\sd\\profile_msfs_xcub.ahk') else os.execute('start D:\\IslandJohn\\Scripts\\sd\\profile_msfs.ahk') end end event.offset(0x3F02, "UW", "onload") This works well as it triggers right on the screen with the "Ready to Fly" button. However it also seems to trigger after I'm in the aircraft (as I started a takeoff roll for example). It also triggers on return to the main menu. Is this expected? Is there a better offset to use? I can always just keep state for last loaded profile, just curious.

Ack, will report back when/if it occurs again.

Here's another instance of FSUIPC crashing (and me, just before landing on a bush strip in strong winds:). This has "extras" logging enabled. I will now turn on UseAIClient=No. logs.zip

Ok, I'll start with Extras logging to not compound issues, until it occurs again (seems to be less frequent).

Yes, I'm just doing this for OCD reasons and to keep the numbering grouped in some way for compound buttons. 🙂 I assigned these, but haven't flow a plane to try them yet (I believe they're spoilers), and was not using them in this case (unless I accidentally pushed them). Ack, will do.

Well... I finally managed to catch this in the act again (FSUIPC crash) with the latest FSUIPC and 1.9.3.0, while also having SimConnect logging on. All logs and settings attached. logs.zip

This is awesome, as I couldn't find a way to toggle individual batteries. This works in the Baron for example, so great find! Unfortunately this doesn't seem to work for Toggle Avionics Master (if param is not 0, it does nothing). How did you do the "trace"?