Pete Dowson

Rather strange if truly nothing had been changed. That generally suggests a hardware fault. Check if using F3 or F4 works okay with the CH hardware disconnected. If it was okay before then probably not. But we don't support out of date versions of FSUIPC, so if your FSUIP4 is earlier than 4.976 then please first update it and then we can check further. Pete

What is it doing, then? Have you tried the Lua logging option to see what it is doing. I thought it was Aileron and Steering you wanted to combine on the same axis? If it is just steering and rudder, then why bother? If you assign to both and calibrate both then FSUIPC will gradually change from steering to rudder as the ground speed increases. Pete

The logs show no connection made in any case, it isn't making one then losing it 'suddenly'. You are relying on Broadcasting working for you, For that you need both PCs to be in the same WorkGroup. Safer to set these parameters in the WideClient.INI: ServerIPAddr=n.n.n.n Protocol=TCP where n.n.n.n is the Network IP address of the FS PC. Pete

You'd need to do it via a Lua plug-in. It would need to be a plug-in running all the time (eg loaded by an [Auto] section entry, then assign using this facility: LuaValue <plugin name> to set the ipcPARAM variable to the given parameter, or the axis value when so assigned. The plugin would use event.param to react to an axis change and call a function which checked on ground or not (an offset) to determine which axis control to use. The only drawback is that you wouldn't be able to use FSUIPC's calibration. Simpler really to assign the axis to both controls -- steering does nothing in the air, and ailerons may not do too much damage on the ground. And you'd be able to calibrate them differently -- maybe steering only using a small part of the axis so as not to disturb the ailerons too much. Pete

No. FSUIPC is only recording what it sees arrive in FS. You need to start off with no other software running other than FSX with a default aircraft, then gradually add back your add-ons until the problem re-occurs. However, I think you started this thread off stating the your engine starting only went wrong after a Project Magenta update? So you should really report that to PM as a bug and meanwhile revert to the previous version. I wouldn't be surprised if those spurious controls were emanating from PM anyway. All I can help you sort out is why your assignment to Engine Auto Start is not working. You've not managed to test that with the logging enabled, so there's been no progress. You could also show me your FSUIPC4.INI file so I can check your assignment there. Pete

But the ipc.set in your VarOut.lua doesn't set anything: ipc.set("Var1") The syntax as documented is ipc.set(“name”, value) You are setting no value, same as nul. Pete

You weren't supposed to be looking for an offset, but a control event! Your 4.1 log has no logging options set, so that's a waste of time. But the 4.2 log is full of these controls: 3542828 *** EVENT: Cntrl= 66068 (0x00010214), Param= 0 (0x00000000) SPOILERS_ARM_SET 3542828 *** EVENT: Cntrl= 66832 (0x00010510), Param= 0 (0x00000000) FREEZE_LATITUDE_LONGITUE_SET 3542828 *** EVENT: Cntrl= 66832 (0x00010510), Param= 0 (0x00000000) FREEZE_LATITUDE_LONGITUE_SET Why is your position frozen and spoilers being armed? What is continually doing it hundreds of times per second? You seem to have some rogue software there! You need to start eliminating things you have running. At one stage to changed the logging from Events to IPC reads/writes. Why? There's no point! At no time whilst you had event logging enabled did you use the Ctrl+E keypress directly, or your assignment. So there is no useful information here at all, other than you have some very strange things going on -- why freeze the aircraft position? What is doing that? No, nothing to do with engine starting. More likely a result of this much more serious error: 216125 *** G3D bad pointer trapped and crash prevented *** which indicates either a corrupt install of FS, or some bad scenery or aircraft file. Also this [Continuation log requested by user] indicates that you are, for some reason, pressing the "New Log" button. Please do NOT do that. A continuous log is needed, not bits. To test things properly I suggest you start with a default aircraft and no other software running. With default FS settings CTRL+E+1 will generate the Engine Auto Start control with parameter 1. That's all you need to confirm -- the rest is up to whatever software you are using, and if that's not working you need to deal with their support. Pete

There's no way FSUIPC can be responsible for that. It it has detected and correctly responded to a device then that's it. There's nothing in it to change that unless you change assignments. The device itself must have dropped out or disconnected. That confirms it. The device itself is faulty, or maybe the connection or the USB port. FSUIPC cannot prevent FSX seeing a device. Pete

Good! I was starting to work out the next least compicated step before editing the Registry! 😉 Pete

It looks like you haven’t added the two lines to the [JoyNames] section as I suggested. Pete

Ok. The problem is that somehow, maybe due to a Windows crash at some time, your have two devices with the same ID. From your log notice: 297 Device acquired for use: 297 Joystick ID = 1 (Registry okay) 297 1=Saitek Pro Flight Rudder Pedals 297 1.GUID={7134F060-6779-11EA-8002-444553540000} 312 Device acquired for use: 312 Joystick ID = 0 (Registry okay) 312 0=Saitek Pro Flight Yoke 312 0.GUID={7134F060-6779-11EA-8004-444553540000} 312 Device acquired for use: 312 Joystick ID = 2 (Registry okay) 312 2=Saitek Pro Flight Quadrant 312 2.GUID={7134F060-6779-11EA-8003-444553540000} 312 Device acquired for use: 312 Joystick ID = 0 (Registry fixed) 312 0=Saitek Pro Flight Quadrant 312 0.GUID={7134F060-6779-11EA-8001-444553540000} The ID 0 is recorded for both your yoke, and (apparently) a second Saitek Quadrant. Do you have two quadrants, or is this a result of stuff left in your registry? Your assignments seem to indicate two quadrants, with the Yoke as ID 3, so how it became 0 as well is a mystery. The first thing to try is to edit the INI file here: [JoyNames] AutoAssignLetters=No <<<< change to Yes 0=Saitek Pro Flight Quadrant 0.GUID={7134F060-6779-11EA-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={7134F060-6779-11EA-8002-444553540000} 2=Saitek Pro Flight Quadrant 2.GUID={7134F060-6779-11EA-8003-444553540000} and add these two lines: 3=Saitek Pro Flight Yoke 3.GUID={7134F060-6779-11EA-8004-444553540000} Pete

You could try the proper control number instead. This is in the controls list: 66484 ANTI_ICE_TOGGLE_ENG1 There's also 66488 ANTI_ICE_SET_ENG1 for which I would guess a parameter of 1 sets it on, and 0 sets it off. For this one: 67012 ANTI_ICE_GRADUAL_SET_ENG1 I'm not sure at all what that does, if anything. As to why a keypress isn't working, you need to ask John. You should be posting in the MSFS subforum above for MSFS questions. Pete

It's quite unusual to find two different axes to give exactly the same values when seemingly exactly in the same position. In fact it is often similar in the real aircraft unless it is fresh from the factory, as things wear out at different rates. However, you can calibrate "sync" points in FSUIPC. See the section entitled CALIBRATING MULTIPLE THROTTLE, PROP & MIXTURE AXES TO "LINE UP" on page 40 (or close) in the User Guide. Pete

What is 'H' assigned to in MSFS? Which aircraft? What is '65732 + 72' supposed to do? As listed in the Controls list, 65732 is assigned to "EXIT"! Adding 72 to it changes it to 65804 which is "APP ATT HOLD ON" -- i.e attitude hold. Does your aircraft have such a facility in its autopilot? Did you turn the AP on first? Pete

No it isn't! As advised in the supplied documentation you need to turn off the Windows Explorer setting to hide filetypes. Trying to deal with files when their proper filenames are hidden will otherwise always present you with problems. ZIP the files, or just paste their contents into your message. They are all text files and ZIP up really small. Pete

Is it seen by anything? Windows? FS? If so, then perhaps a sight of these files from the Modules folder will show something useful: FSUIPC4.INI FSUIPC4.LOG FSUIPC4.JoyScan.csv Pete

Yes. For your functions to be called, the LINDA lua program must be including your Lua -- your code effectively becomes part of theirs. Pete

Okay. Your Lua is part of something LINDA does. It isn't logged as something being run by FSUIPC. Whatever this fragment of Lua does is obviously embedded into the LINDA system. What I said about "dev" as a variable, and Lua functions still applies, but your Lua fragment is inducted into whatever it is LINDA is doing. So, since I know nothing about LINDA and cannot support it, I suggest you ask your questions of the LINDA folks. In summary, within the FSUIPC and WideClient implementations of Lua, there are no global names or values associated with any hardware, whether it be VRInsight or not. Pete

Please post the Lua file itself, not a picture. Really there is no such thing as a global "dev" value. Not only that but you have no com.open in that pictured section so there can be no link to the device -- it isn't opened! And functions in Lua do NOT run themselves! They have to be called! Therefore that is not the (complete) Lua file you are running -- NOT a picture, the file! Show me the FSUIPC log file AND the Lua file it is loading. Otherwise there is no point in this thread continuing! Pete

'dev' only acquires a value as a result of a call to a function -- in this case some 'com.open' in your script. It is NOT a declared "global"! The code snippet is a function which must be called somewhere. Elsewhere in your script there must be a statement like dev = com.open and a call to your function 'Engage_Managed_Heading_Mode'! Please don't post code "snippets" and talk about them as if they show everything! Pete

The name ‘dev’ is just that. In Lua just as in any other programming language variables have names. It could just as well be named ‘Fred’ or ‘Jim’. It has the value returned bu the com.open function. That will be a number assigned by Windows for the opened device link. Next time it might be different. Pete

It does sound very much like you chose an installation path for FSUIPC which is protected by Windows, like somewhere in Program Files. You could try reinstalling to a more accessible folder, created perhaps directly under a drive name, like C:\FSUIPC7. Note that if FSUIPC is run "as administrator" then every FSUIPC client program also needs that status (and vice versa). Programs at differrent privilege levels cannot communicate via shared memory which is the way the FSUIPC interface works. Pete

This is because you haven't actually told FSUIPC what to do. The [Auto] section is for commands or controls for FSUIPC to obey. The line should have been: 1=Lua zelTripleUse "Lua" being the documented command or control to run a plug-in (as listed for assignment). You don't really want to use "LuaDebug". Just the standard Lua command is fine. You are just wasting resources and filling the log up with debugging information. The part between the -{ and }- is just annotation to help understand the assignments. No, the use of the Lua commands is documented in the document called "FSUIPC Lua Plug-ins.pdf". For help with Lua programming you can refer to the main Lua reference site "Lua.org" or, for the additions in FSUIPC the "FSUIPC Lua Plug-ins.pdf" document. All of the documentation supplied is for reference, not reading like a novel. You just look things up when you need to. Make good use of the Contents list where there is one. Perusing the FSUIPC User guide initially is a good idea, just to get an idea of what is available to you. FSUIPC is a bag of tools for you to use as needed. Everyone has different needs. Pete

That's weird if the correct controls are being sent! One other thing you can try, with the logging options still set, is operating the switch with the mouse and see what is logged then. Most standard cockpit controls use the controls too. There is another way to set the magneto switch position -- use MAGNETO1_SET and MAGNETO2_SET with parameters 0 - 4 for the successive positions. Maybe those settings would work more consistently? Pete

If you managed to assign your switches, as shown in the INI you provided, then with the correct options set in the Logging tab, they simply must be logged! Please show me such a log. Enable Button logging and event logging (not axis events). Strange. But why are you not testing on a default aircraft first? Different add-on developers do things differently. Maybe the A2A one needs L:Vars changed to operate the visual switch. Many of my switches are connected via Bodnar BU0836 boards. They are very reliable and versatile and I've never had any problems with any of them. Pete