Pete Dowson

This is most definitely a sign of the USB connection "going to sleep"., and the only known cause of that is power. In Windows device manager go through ALL the USB devices lised. Disable the power management wherever that option exists. Don't just choose one. Incidentally in the esrlier posting you say but then Which is true? They cannot both be! Next time you post with this still occurring, please besure to include or attach the FSUIPC5.LOG please. Pete

You DO realize that this is the same as in real aircraft? The thrust delivered from a specific throotle lever position is rarely the same on both. It's part of the pilot's job to mointor what is going on and make the sort of adjustments you made. Check some real world cockpit videos and you'll see. You can make use of the FSUIPC calibration feature for syncing the positions of the throtties at specific places on their axis ranges. This is described in the user documentaion. There is also the more drastic FSUIPC throttle sync control, whicch I think is available also as an FSUIPC hotkey, to sync throttles by copying Throttle 1 to 2 (and 3 and 4), ignoring the other setting. Pete

What have you changed in the interval between "then" and "now"? Generally FSX does this when the previous run ended with an error - i.e either crashed or actually failed to end normally and had to be forcibly terminated. FSUIPC is one of the last components to terninate as it has lots of dependencies to check and tidy up, so often Windows blames it as the culprit. It should correct itself after a few retries, but otherwise re-running the FSUUIPC installer should do it, as it "fixes" the registry entry which 'remembers' the crash. Just make sure you run it "as administrator". Pete

FSUIPC can blend input from a tiller axis with that from the rudder pedals, but of course this blending only applies if you have a separate axis for the tiller. It is blending the inputs to give more control to the tiller at low ground speeds, more to the rudder pedals as GS increases. Both are using the rudder axis. By calibrating them separately give can have a more gentle rudder control in the central areas, whilst the tiller is more proportional to the tiller position. With a separate tiller you can either use that facility, or, with P3d now, assign to the Steering axis control instead. That might give more “nose wheel” action, but I doubt it will be more than the rudder gives. Without a separate tiller axis you can’t really do much. You could try assigning the one rudder input to both rudder and steering axes -- FSUIPC allows for multiple axis assignments (up to 4), but I don't know what the results would be like. There's no blending because they are going to different functions in P3D. Pete

Yes, this is what I was asking, really. I assumed he found that the normal axis controls for Spoilers did not work with that add-on. I don't think Mouse Macros can work with axes as there's no way provided by L-M to tell it how the axis is moving. Whilst FSUIPC could read the mouse positions on press and also on release, it cannot do anything with them! If he's only got buttons to use for thise, with no speare exis, then he could try the separate Toggle controls for Arm and Deploy. Pete

With P3D4.4 and FSUIPC5 then the MS Gauges SDK is not relevant. The Mouse Macro facility uses additions provided by L-M in answer to one of my requests. These identify each mouse-sensitive area in a cockpit by a unique number - x40000170 in the case above. With most buttons and switches the action recorded (the number after the comma) is just left mouse click. Others can be recorded, but sometimes the switch demands different actions -- maybe right click, or press and release, or double click, or, as John suggested, even a "drag whilst pressing". You'd know more about this -- for instance, does the switch action occur as soon as you click , or only after release? And so on. With switches or dials which need more complex mouse actions, FSUIPC cannot really record them all for the one action. The actions codes are listed on page 38 of the Advanced users guide to FSUIPC5. Take a look there. If the correct code, or sequence, is not clear for how you use the mouse, then some experimentation with the macro definitions will be needed. John's suggestion of a separate macro for the press and release is good, but I wonder how P3D4 determines how it should be dragged. There are Move and Wheel down, Wheel up codes too. But there's no way in the mouse macro mechanism to tell P3D to move from position x to position y. If the "sb" in your macro name is referring to "speedbrake" then have you tried just assigning to the available P3D "spoiler" controls? It is probably an axis NOT a button or switch. If so then mouse Macros are not really suitable at all. You need to either use axis controls on an axis or lever input, or buttons for INC and DEC. Otherwise, if Aerosoft have ignored the normal controls, and experimentation with mouse action codes doesn't give you any working results I can only think that an L:Var solution be sought. You should also ask in the A320 section of the Aerosoft support forum -- someone has probably sorted it out before now. In fact, for virtually all the buttons and switches there's a contribution from a user in the User Contributions subforum, but axis controls are, of course, noticeably absent. Pete

I was talking about YOUR "lever" which appears to be more like a centre-sprung yoke axis! Evidently not! 😞 Pete

MakeRunways does NOT mess up anything! It cannot. When used it generates files of its own which other programs can optionally use. It never writes to anything except the files it makes itself. If you don't use it it does nothing at all. It cannot. If you don't want to use it, just remove it from the simulator's main folder. Pete

By "no results" what do you mean? You say the axis is recognised and gives the normal full range or -16384 to +16384. I would have though the problem is that it returns to center when released, so how will the speedbrake stay where you want it? It isn't like a throttle axis which would work, more like a spring to centre yoke axis. Pete

But 14 decimal digits, where each digit can go from 0 to 9. A 16-bit word has 16 binary digits, with each digit going only from 0 to 1. So the range of numbers your 16-bit Unsigned Word (UW) can handle is 0-65535. I am pretty sure that your value of 86.54463907825 will be written as 86 or maybe 87 (I don't remember if it is rounded, but probably). So, what is your Arduino or whatever expecting to read? Maybe it wants the double floating point format which 86.54463907825 would suit? For that you use 8 bytes and ipc.writeDBL. Or perhaps it needs a 32-bit floating point value, in which case use ipc.writeFLT. You need to know what the receiver is expecting! "Offsets" are just places in memory, where stuff like data can be stored. Nothing magic. They don't do any work. In your case they are just being used as postboxes. Pete

Oka, that's good. But in FS/P3D generally, a normal joystic operation of the speedbrake will deploy full spoilers. It was, and as far as I know still is, a little 'bug' in the sim coding. It may of course be fixed in a paticular add-on aircraft, and possiby L-M has fixed in in the recent P3D releses. I don't know, I've not tried it recently. But why not do the same with an axis.. It should be fine. Pete

Easiest way with two buttons is have one assigned to "spoilers arm toggle" and the other to "spoilers toggle". The aircraft model should limit in flight spoiler action to its flight speedbrake value. Use the arm when preparing for arrival. There are separate ON and OFF controls for these two, but you can't do everything with those on just two buttons. Otherwise, if you want it to move to specific values you would need to either use the INC/DEC controls, bearing in mind that the ARM point is only a bit above the off. You could get more sophisticated with a Lua plug in, setting specific values according to circumstance, but that needs proper working out and programming. It really is more realistic to use an axis. Why does the axis you tried on the joystick not work. Note: do not test speedbrake action on the ground. They will deploy immediately you move it. Pete

That's not relevant to P3D4 in any case. It would have had no effect either way. If there's no wxstationlist.bin file then FSUIPC5 did its job and deleted that file at the end of the last sessio. It will be created again, so I'm now wondering if the mast copy, the once it is generated from, is corrupt. in case it is, please replace the copy in your main P3D4 folder, subfolder "weather", by the one attached. In the SimConnect log file, I still see MANY add-on DLLs being loaded and run: 0.04501 DLL Loaded: Path=".\CMeteoXml.dll" Version="2.0.0.1" 0.04648 DLL already loaded: Path=".\CMeteoXml.dll" 0.04650 DLL Load Failed: Error=-2 Path=".\CMeteoXml.dll" Didn't you disable these entries, one in each DLL.XML? also, one other add-on seems to have slipped though: 0.04781 DLL Loaded: Path="Captain_Sim\bin\cs.sound.dll" Version="<Unknown>" My worry is with that CMeteoXML one. Do you know where it comes from, why it is on your PC? The Simconnect log and the new FSUYIPC log do definitely confirm to me that something is badly wrong in P3D itself. These entries in the FSUIPC log: 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1146, Index param 2 on MapClientEventToSimEvent for "ENGINE", id=65554 [0x10012] 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1149, Index param 2 on MapClientEventToSimEvent for "XPNDR", id=65556 [0x10014] 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1152, Index param 2 on MapClientEventToSimEvent for "EGT", id=65558 [0x10016] 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1153, Index param 2 on MapClientEventToSimEvent for "SMOKE_TOGGLE", id=65559 [0x10017] 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1154, Index param 2 on MapClientEventToSimEvent for "STROBES_TOGGLE", id=65560 [0x10018] 4594 Exception 7 "NAME_UNRECOGNIZED", Ref 1158, Index param 2 on MapClientEventToSimEvent for "ADF", id=65566 [0x1001E] 4610 Exception 7 "NAME_UNRECOGNIZED", Ref 1161, Index param 2 on MapClientEventToSimEvent for "HEADING_GYRO_SET", id=65568 [0x10020] 4610 Exception 7 "NAME_UNRECOGNIZED", Ref 1162, Index param 2 on MapClientEventToSimEvent for "DME", id=65569 [0x10021] 4610 Exception 7 "NAME_UNRECOGNIZED", Ref 1164, Index param 2 on MapClientEventToSimEvent for "GEAR_TOGGLE", id=65570 [0x10022] 4610 Exception 7 "NAME_UNRECOGNIZED", Ref 1165, Index param 2 on MapClientEventToSimEvent for "ANTI_ICE_TOGGLE", id=65571 [0x10023] etc (loads of Exception 7's", are the conotrls which become unusable -- because Simconnect doesn't recognize them! Oddly, looking at the SimConnect log equivalent to this time: > 4.66209 [131, 1128]MapClientEventToSimEvent:EventID=65537, EventName="DEMO_STOP" > 4.66211 [131, 1129]MapClientEventToSimEvent:EventID=65538, EventName="SELECT_1" > 4.66211 [132, 5]AddToDataDefinition:DefineID=-86050082, DatumName="IS SLEW ACTIVE", UnitsName="Bool", DatumType=1, fEpsilon=0.000000, DatumID=2 > 4.66212 [131, 1130]AddClientEventToNotificationGroup:GroupID=3, EventID=65538, bMaskable=1 > 4.66214 [131, 1131]MapClientEventToSimEvent:EventID=65539, EventName="SELECT_2" > 4.66214 [131, 1132]AddClientEventToNotificationGroup:GroupID=3, EventID=65539, bMaskable=1 > 4.66215 [131, 1133]MapClientEventToSimEvent:EventID=65540, EventName="SELECT_3" > 4.66216 [131, 1134]AddClientEventToNotificationGroup:GroupID=3, EventID=65540, bMaskable=1 > 4.66217 [131, 1135]MapClientEventToSimEvent:EventID=65541, EventName="SELECT_4" > 4.66218 [131, 1136]AddClientEventToNotificationGroup:GroupID=3, EventID=65541, bMaskable=1 > 4.66218 [132, 6]AddToDataDefinition:DefineID=-86050082, DatumName="PLANE LATITUDE", UnitsName="degrees", DatumType=3, fEpsilon=0.000000, DatumID=3 > 4.66219 [131, 1137]MapClientEventToSimEvent:EventID=65543, EventName="DEMO_RECORD_1_SEC" > 4.66220 [131, 1138]MapClientEventToSimEvent:EventID=65544, EventName="DEMO_RECORD_5_SEC" > 4.66221 [131, 1139]MapClientEventToSimEvent:EventID=65546, EventName="MACRO_BEGIN" > 4.66222 [131, 1140]MapClientEventToSimEvent:EventID=65547, EventName="MACRO_END" > 4.66223 [131, 1141]MapClientEventToSimEvent:EventID=65548, EventName="MINUS" > 4.66224 [131, 1142]MapClientEventToSimEvent:EventID=65549, EventName="PLUS" > 4.66224 [131, 1143]MapClientEventToSimEvent:EventID=65550, EventName="ZOOM_1X" > 4.66225 [131, 1144]MapClientEventToSimEvent:EventID=65552, EventName="SOUND_TOGGLE" > 4.66226 [131, 1145]MapClientEventToSimEvent:EventID=65553, EventName="FULL_WINDOW_TOGGLE" > 4.66227 [132, 7]AddToDataDefinition:DefineID=-86050082, DatumName="PLANE LONGITUDE", UnitsName="degrees", DatumType=3, fEpsilon=0.000000, DatumID=4 > 4.66228 [131, 1146]MapClientEventToSimEvent:EventID=65554, EventName="ENGINE" < 4.66230 [131] >>>>> EXCEPTION=7, SendID=1146, Index=2 <<<<< > 4.66230 [132, 8]AddToDataDefinition:DefineID=-86050082, DatumName="PLANE ALTITUDE", UnitsName="feet", DatumType=3, fEpsilon=0.000000, DatumID=5 > 4.66231 [131, 1147]AddClientEventToNotificationGroup:GroupID=3, EventID=65554, bMaskable=1 < 4.66233 [131] >>>>> EXCEPTION=3, SendID=1147, Index=2 <<<<< > 4.66234 [131, 1148]MapClientEventToSimEvent:EventID=65555, EventName="SIM_RATE" > 4.66235 [131, 1149]MapClientEventToSimEvent:EventID=65556, EventName="XPNDR" < 4.66240 [131] >>>>> EXCEPTION=7, SendID=1149, Index=2 <<<<< etc there are some that it does. In the first 20 controls request, the only two to fail were ENGINE and XPNDR (in re). I think a portion of, probably, "CONTROLS.DLL" (a part of P3D) has becomne overwritten in memory. I think that's where the table of these names is kept. If you cannot remove all add-ons, then I would suggest doing complete uninstall and fresh install of P3D4. Then test it with no addons, Then FSUIPC5. Then start adding things one at a time, testing each time. It's really the only sure way. Pete wxstationlist.bin

I think the "button" you refer to is a "hat", and whilst FSUIPC does allow yo to program it as a set of 4 or 8 bittons (one for each of up to 8 directions), it is best programmed as an AXIS, like your yoke, and assigned to "Pan View". That is what the assignment in P3D would have been. Pete

The offsets reserved for users are 66C0 to 66FF. Others, just because they have no assignment listed, are not necessarily free for any unauthorised use. Do you know what sort of values that L:Var supplies? Have you logged it? Try the Lua logging plug-in supplied for a real-time log. Have you double-checked your coding at the other end, in the Arduino or Mobiflight (which I don't know). Pete

If it only happens in specific areas of the overall movement it is most likely the device -- a dirty potentiomenter or bad connection. But if it isn't the device then it is likely you have multiple assignments. Did you assign in FSUIPC or in P3D? If in FSUIPC have you made sure that controllers are disabled in P3D (last option in the Controls menu). Also test with a default airraft in case it is something to do with that particular add-on aircraft. Pete

A lot of the action, including sounds, may be handled internally to the gauge providing the switch. Did you get a list of them before, from FSUIPC? Did you try monitoring them using the supplied Lua plug-in to do this. You can see in real-time when the change, so you know what values to try as parameters. Ah, was that the live monitoring Lua plug-in? I assume you've tried FSUIPC mouse Macros? I know they don't work with many add-ons, but you don't know till you try. So, isn't that what you want? with "SET" you have to provide the value to be set as the parameter when you assign the macro. Otherwie you need to follow "Set" with ",n" to set the value n (decimal). If all else fails to achieve exactly what yo want, I think you need to talk to the add-on author. Pete

On P3D4 with FSUIPC5, the displays use SimConnect windows, and can't be set with a user title. Their position can be remembered. FSUIPC stores that (but optionally and defaulted off because of Windowed mode / Full Screen changeover problems with it), I think the problem is simply that the plug-in only exists for a fraction of a second. Display windows are closed when the requesting plug-in closes. if you want to see it, try adding an ipc.sleep(5000) at the end, so it hangs around for 5 seconds. (The sound request won't delay its termination -- that only initiates the sound). Pete

The only add-ons which it may be worth trying to disable are RAASPRO (in the ProgramData one), and CMeteoXml, whatever that is. Note that you have CMeteoXml loading twice, which can't be good. There are entries for it in both DLL.XML files. To disable entries without having to remove them, just change the False to True in the <Disabled> line. But before doing that let me check to see what could be causing these errors: 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1146, Index param 2 on MapClientEventToSimEvent for "ENGINE", id=65554 [0x10012] 14281 Exception 3 "UNRECOGNIZED_ID", Ref 1147, Index param 2 on Group 2 AddClientEventToNotificationGroup for "ENGINE", id=65554 [0x10012] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1149, Index param 2 on MapClientEventToSimEvent for "XPNDR", id=65556 [0x10014] 14281 Exception 3 "UNRECOGNIZED_ID", Ref 1150, Index param 2 on Group 2 AddClientEventToNotificationGroup for "XPNDR", id=65556 [0x10014] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1152, Index param 2 on MapClientEventToSimEvent for "EGT", id=65558 [0x10016] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1153, Index param 2 on MapClientEventToSimEvent for "SMOKE_TOGGLE", id=65559 [0x10017] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1154, Index param 2 on MapClientEventToSimEvent for "STROBES_TOGGLE", id=65560 [0x10018] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1158, Index param 2 on MapClientEventToSimEvent for "ADF", id=65566 [0x1001E] 14281 Exception 3 "UNRECOGNIZED_ID", Ref 1159, Index param 2 on Group 2 AddClientEventToNotificationGroup for "ADF", id=65566 [0x1001E] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1161, Index param 2 on MapClientEventToSimEvent for "HEADING_GYRO_SET", id=65568 [0x10020] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1162, Index param 2 on MapClientEventToSimEvent for "DME", id=65569 [0x10021] 14281 Exception 3 "UNRECOGNIZED_ID", Ref 1163, Index param 2 on Group 2 AddClientEventToNotificationGroup for "DME", id=65569 [0x10021] 14281 Exception 7 "NAME_UNRECOGNIZED", Ref 1164, Index param 2 on MapClientEventToSimEvent for "GEAR_TOGGLE", id=65570 [0x10022] etc It is because the names haven't registered that the assignments fail later. The odd thing is that the Controls List is generated from the numbers and names provided BY P3D when requested, and that list is perfect. I might have to add more logging, but this is looking suspiciously like a corrupt installation of P3D. Either that, or it is being corrupted in memory after loading. Now there is one things which I know can cause such corruption, with unpredictable consequences: bad weather files. The problem is that they are binary file and a read and processed without any chgecks being provided (yes, I have repeatedly asked L-M to fix this, to no avail so far). So, another thing to try before I have to modify FSUIPC for extra logging: delete wxstationlist.bin from the P3D4 AppData folder (don't worry, another will be made), and delete, or move out (if you want to preserve them) all the .wx type files from the P3D4 Documents folder (where the flights are stored). Let me know if that makes any difference. Oh, there is one more thing also: a SimConnect log, so i can see if it is actually receiving the Name Registration requests. Because strnagely, though if they fail, an error should appear in that FSUIPC log, there are no such errors, It looks just as if all of those requests succeeded. To get a Simconnect log please put this file into the P3D4 documents folder, naming it simConnect.ini: [SimConnect] level=Verbose console=No OutputDebugString=0 file=E:\Program Files\Lockheed Martin\Prepar3D v4\Modules\simconnect%u.log file_next_index=1 file_max_index=9 This will create files named SimConnect1.log ... (etc).. in the Modules folder, with a LOT of lines! Try it, and ZIP up the result for attachment. Again, keep the session VERY short, because the file will get huge! If neither of these steps help or get enough information, then it will be more complicated. Pete

You do know WideFS is really for Client PCs to receive from and send to the Server PC, not for Client to Client interchanges? I think you seem to misunderstand this. What is "TSR"? The only TSR I know of is some now obsolete and unsupported software written by my friend Thomas to improve on Project Magenta cockpit software. On which PC is the overhead? Comp 3? Is there a TSR support forum you can use, as your questions would seem more appropriate to them. Does TSR use FSUIPC at all? I'm not really sure where your WideFS network comes in. You say you get an error about a registered FSUIPC being required. What is that message from, TSR software? Is your FSUIPC registered? The only file you supplied appears to be one of the WideClient.INI files. However it is severly corrupted. Each parameter line must have a nme=value structure. None of those have. If you've just removed them for some reason, please scrap thge file and let WideClient build a new one. If you want further help here you need to supply: FSUIPC4.LOG file from the FSX Modules folder FSUIPC4.INI file from the same place WideServer.LOG from the same place WideClient.INI files from both clients WideClient.LOG files from both clients Just ZIP them up together, then they will be small enough to attached. Pete

Please note that if you read my reply above very soon after I posted it, i have revised the last part slightly to add parameters which will give me more logging. Pete

Why not ZIP files up like most folks? With simple text files like these they Zip up really small! What about the "hundreds" of PAN_VIEW controls? I don't see many of those. This: 17969 \\FLIGHTSIM\Prepar3D v4\SimObjects\Airplanes\Carenado DO228_100\DO228.air 17985 ### The user object is 'Dornier Do228-212 CyberAvia' is an add-on aircraft. Next time please test with a default P3D4 aircraft, because many add-on aircraft do some strange things themselves, like sending lots of controls (that's the reason for the "TimeToSelect" facility normally being enabled). I wouldn't be surprised if this aircraft is sending those controls. In the first part of the log I see that you used Gear controls through FSUIPC and the Gear control was definitely sent to P3D4. (Of course if you were on the ground it would have no effect anyway). You didn't have "Extras" selected for logging this time, so no SimConnect errors were reported (but I see that you did this later). Can you leave that set and re-run in case I can see Simconnect errors when FSUIPC requests Simconnect to register its ID numbers for the controld. This part: 103235 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 103235 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 103235 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 103563 KEYDOWN: VK=51, Waiting=0, Repeat=N, Shifts=0 103563 .. Key not programmed -- passed on to FS 103563 *** EVENT: Cntrl= 65540 (0x00010004), Param= 0 (0x00000000) SELECT_3 103860 KEYUP: VK=51, Waiting=0 103860 KEYUP: VK=68, Waiting=0 shows why, in this case, Aircraft Exit 3 didn't operate -- there were intervening controls before the '3'. this is what the "TimeToSelect" facility in FSUIPC is intended to prevent. There was an earlier Exit attempt, for exit 1, which should have worked (though Exit 1 is defaulted in any case): 63844 KEYDOWN: VK=68, Waiting=0, Repeat=N, Shifts=0 63844 .. Key not programmed -- passed on to FS 63844 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 64141 KEYDOWN: VK=49, Waiting=0, Repeat=N, Shifts=0 64141 .. Key not programmed -- passed on to FS 64141 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 Or in this case did you delete lines beween those? Else I don't know why there's a space line. (I wish you'd just ZIP files and leave them intact). Ah, you didn't try setting that to 0 as I suggested! Yes, as I stated in response to your earlier log, yesterday which also had "Extras" enabled. Do you not read all my replies? Please do so now. You missed this: Well, that is more interesting, as it shows that the controls being sent by FSUIPC are rejected with a SimConnect Error. e.g. 113282 Exception 1 "ERROR", Ref 2811, Index param 2 on TransmitClientEvent, object=2, id=65570 (GEAR_TOGGLE), data=0 Now that's a puzzle. But unfortunately you again omit vital data. See this line: [Continuation log requested by user] That means you pressed the "New Log" button, which starts a new log after renaming the main one, with more start-up information. So that start up data is missing. Please do NOT do this! Surely you had no reason to start a new log? Please append the complete ORIGINAL log, do not start a new one! and this: About the doors. It occurred to me that FSUIPC does intercept and resend the aircraft exit control so it can prevent other controls making the 1,2,3 or 4 selection afterwards lose association. If the re-sending of the control is rejected in the same way as those Gear controls, then this could explain your doors problem. You can switch that facility off by finding this line in the INI file: TimeForSelect=4 and setting 0 instead of 4. The big puzzle, though, is why SimConnect is rejecting the controls. I need more logging! Please add these lines to the [General] section of the INI file: Debug=Please LogExtras=x400 Then do a re-run with a default aircraft. Keep the session short as the log will get huge very quickly. Just try your GEAR controls. No need to keep retrying. Then supply the FULL log (Zipped), and also the "controls List for P3D4 ...txt", which you'll find in the FSUIPC documents subfolder. You can ZIP that too. It is generated from information supplied by P3D4 at run time and updated automatically on every P3D4 update. One last question, for now. Is it possible that there are other add-on DLLs installed and still running? These can be loaded via the P3D Add-Ons.xml methods or via a file called DLL.XML, with one of these in the P3d4 Appdata folder and another in the P3D ProgramData folder. You can stop all the AddOns.xml ones loading by renaming the Documents subfolder Prepar3 v4 Add-Ons, but this will not stop the others. FSUIPC is loaded by an entry in the AppData copy of DLL.XML. Pete

About the doors. It occurred to me that FSUIPC does intercept and resend the aircraft exit control so it can prevent other controls making the 1,2,3 or 4 selection afterwards lose association. If the re-sending of the control is rejected in the same way as those Gear controls, then this could explain your doors problem. You can switch that facility off by finding this line in the INI file: TimeForSelect=4 and setting 0 instead of 4. The big puzzle, though, is why SimConnect is rejecting the controls. Pete

Well, use of that offset is reserved for virtual buttons, so needs an external driver or Lua plug-in to drive the bits. Who provides that? I'm sute Saitek don't -- they dn't use FSUIPC at all. ASN and GSX have no effect. LINDA installs Lua plug-ins, and it uses ipcReady.lua to load things, so you'd need to remove those too. If you use the FSUIPC logging to log events then you'll see that using the assignment direct in P3D and in FSUIPC both send exactly the same control. You should test that with FSUIPC still installed, but with no assignments -- just remove or rename you FSUIPC5.INI file. Then it is absolutely sure that FSUIPC itself is not responsible for sending or interfering with anything. The Logging just logs what it sees. If strange things still happen you most certainly still have an FSUIPC application program doing things, or a Lua plug-in. You changed this? It's normally Shift+E ("Toggle aircraft exit" control, being its proper name) followed by 1, 2, 3 or 4. Well, that is more interesting, as it shows that the controls being sent by FSUIPC are rejected with a SimConnect Error. e.g. 113282 Exception 1 "ERROR", Ref 2811, Index param 2 on TransmitClientEvent, object=2, id=65570 (GEAR_TOGGLE), data=0 Now that's a puzzle. But unfortunately you again omit vital data. See this line: [Continuation log requested by user] That means you pressed the "New Log" button, which starts a new log after renaming the main one, with more start-up information. So that start up data is missing. Please do NOT do this! Surely you had no reason to start a new log? Please append the complete ORIGINAL log, do not start a new one! Pete

Before trying to answer, I will pont out that you buried you support question in a reference subforum. If you want answers to specific questions about FSUIPC on your System you do need to post here, in the Support Forum. I moved it for you. And all these things are assigned in FSUIPC? But they work with no FSUIPC present? In this case they are all assigned in P3d, not FSUIPC. And if nothing is assigned in FSUIPC, and there are no FSUIPC applications or plug-ins telling it to do things, then it cannot possible interfere with any P3D operation. It is only sitting there receiving data from SimConnect and storing it into the offsets incase any application or plug-in wants to read it. You really should have controlllers disabled in P3D if you are assigning in FSUIPC. Otherwise P3D can still automatically assign functions to buttons on controllers it recognizes. Offset 3360 has no FS control function. It is just the last 32 bits of the 288 bit area used to signal "virtual" buttons. And LINDA is a very complex beast and uses many methods of which I have no idea and cannot support. I suggest that either you test assignments and FSUIPC in general without LINDA, or any of its lua plug-ins, OR seek support from the LINDA folks. Why are all these lines crossed out? Am I not supposed to see them? The first part I don't know in any case. It isn't anything to do with FSUIPC. Looks like LINDA maybe? Reading under the crossing out I see there a correct button recognition and the resulting assigned FS control being sent to P3D. The rest is up t P3D. If that control isn't working (it is sent to SimConnect in the normal correct way), then either your aircraft is broken, or another application is intercepting that control in SimConnect (a programmable facility in that part of P3D). Rather than merely show such a small part of the log please next time append the Log as you have with the INI file. There is a lot more useful information there which you haven't provided! In your INI file you have these two lines inserted into the [General] section: !1=[Auto] 1=lua HIDSwitch The !1= part makes that line a comment. Did you intend for "HIDSwitch.lua" to run automatically? To test without LINDA you will need to move "ipcReady.lua" and "inda.exe" out of the Modules folder. I see from the INI file that the GEAR TOGGLE assignment which was shown as working in your crossed out inclusion is in fact the ONLY button assignment. So your described button problems are all down to another add-on which is only operating when FSUIPC is installed -- maybe LINDA? Pete