Pete Dowson

BTW I moved your post to this, the Support Forum, so it can be answered. The FAQ subforum is for long term reference material. By "working" do you mean the AddOns menu has FSUIPC listed, and that b clicking on it you get the options screen showing? If so, then that's fine. Did you use your FSUIPC4.INI file renamed as FSUIPC5.INI? If so, and you didn't re-install Windows as well, then the assignments will be the same. Does FSUIPC recognise the throttles in the Axis assignments tab? The Network settings in your Windows won't have been changed just by installing P3D4 and FSUIPC5. So what else have you changed? Yes, and you can use that with FSUIPC5 just by copying it into the P3D4 Modules folder and renaming it FSUIPC5.INI. That way you retain all your settings. I'm afraid I know nothing about SIOC. I thought ProSim had its own SIOC drivers. Where does FSUIPC or WideFS come in? No, it is a DLL, a module which runs only inside P3D4. It can't be used outside of P3D4 at all. WideFS client PCs just have WideClient.exe installed and configured to recognise the server (the P3D PC). But if that was all working with P3D3 and FSUIPC4 then it doesn't need changing. It stays as it was. The version of FSUIPC doesn't matter. I'm afraid I don't know SIOC at all, or how it uses FSUIPC. You do really need either SIOC support or, probably more appropriately, ProSim support. But as I say, provided you've not changed the Client PC, and provided you've not reinstalled Windows or changed the Network, then it should all work as it did before. The version of P3D and FSUIPC is not relevant to this. Pete

It is possible, but only with some programming. FSUIPC with WideFS does this sort of thing, but then you'd need to write a program to interface to FSUIPC. If you wanted a more direct method you'd need to write a program running alongside P3D to use Simconnect to extract the data you need and send it in whatever format you are expecting. I don't think there are any features actually built into P3D in the way you imply is provided directly in X-Plane (with no add-on like XPUIPC?).Possibly with P3D you could adapt to their multi-PC network linking system. it isn't really an area I've ever invetstigated. You'd be better off asking Lockheed Martin over in their Support Forum -- https://www.prepar3d.com/. Pete

They don't change, not until you set them using the associated button! Then they stay at those values and are saved in your settings file (FSUIPC INI) as the calibrated values to be used. Pete

Are you using Paul Henty's .NET DLL here? If so, I should move this into his Subforum just above. I can't really with programming his DLL. There are ways you can check that the offsets do contain what you expect. Eith use the "monitor" facility on the right-hand side of the Logging tab. just enter up to 4 offsets, select the type, and the values (up to a limited length, at least) will show in the FSUIPC LOG. You can also check any (or all) offsets by using the utility program "FSInterrogate" which you'll find in the FSUIPC SDK. Please also always state which versions you are using -- version of FS, version of FSUIPC, and, if used, version of the .NET DLL. Provide the full version numbers. Pete

FSUIPC itself never tries to "control" AI. That's just a facility for external applications -- RCV4 in your case, AIseparation for others (or both of course). Pete

There will no doubt be another release from John soon. He's not available today, but I worked on the problem this morning and found the bug. Turned out to be a relatively simple (read "stupid") error which only shows up when large numbers of AI controls are sent via FSUIPC. In fact this error has been there for as long as the facility has existed -- so FSUIPC4 as well as FSUIPC5. It just happened that the error only causes a crash with a certain memory arrangement which of course changes with each build. Pete

I've moved your support question to the support forum so it can be answered. I'm afraid you provide no information to enable us to help you. Version of Flight Sim? Version of FSUIPC? And the FSUIPC install log, FSUIPC log and FSUIPC INI files you have found should be appended please. They contain vital information to help us see what you've done and what is happening. Pete

Must be the function that LVar performs in the aircraft model -- for the AP ALT adjustment. you were changing that setting and iterpreting the change for your toggle as well. My MCP is part of my PFC cockpit, and my own driver for it handles all that by program. The only rotaries i have which are outside of the cockpit are a couple of GoFlight RP48's, which have 4 rotaies each. The GoFlight firmware in the device looks after acceleration -- turn it fast and you get a different button number indication. Sothey effectively have 4 button presses each. The acceleration using a rotary is really the same as for a single button provided you remember two things: 1. The button indications you see alternate between "on" and "off" for each successive "click". So you need to handle the change not whether it is on or off. 2. The presses will arrive fast if you turn it fast. May be too fast for your aircraft gauges to keep up. You might need to start with a parameter you can easily change when testing to only act on every nth change in the 'fast' mode (i.e. when they are arriving with less than say 500 mSecs apart). With Lua it is likely that you'll miss some anyway, because only one occurrence is queued for each event registered. To handle that a bit more predictable you might want two event.button calls registered per button -- one for "when pressed" and the other for "when released". They can refer to the same function in your program of course. Pete

Which numbers "stay the same"? The axis value being read is displays at the "IN" value, on the left. Is that "staying the same"? If so then the axis is probably not assigned to that function. Check in the Axes tab. Move your joystick and see if that sees it, and the IN numbers there change. Then look below to see what you assigned it to. Pete

Two things I noticed in your Lua. You define "LVarSet" several times but then use the literal name in your ipc.Lvar calls anyway -- except once. Second, are the LVars already existing in the aircraft you have loaded? They are shown by the Lvar logging? If "AB_AP_ALTSTEP exists, are you sure there isn't a matching "AB_AP_HDGSTEP"? Because I would have thought just "HDG" without the AP prefix would really be the actual current aircraft heading, not the AP dial. You can't create LVars in Lua, they are created by the code in your add-on aircraft. If all you want is a value for your use, to remember what mode you are in, you should use a Lua "GLOBAL" -- see the ipc.set and ipc.get functions. They use a global thread, parallel to your Lua thread, and shares those values to any running Lua thread. They will be remembered over each event calling your Lua functions. Pete

With a one button press for alternately using 1 step or 10 step, use the button flag and make it conditional. There's an example of toggling the button press action in the Advanced User's guide, thus: For every possible “normal” button (16 joysticks x 32 buttons = 512 buttons) FSUIPC maintains a “Flag” (F). Each time any button is pressed (goes from off to on) FSUIPC toggles its flag. This makes the buttons flag a sort of “latching” switch. You can test it in any parenthesised condition by preceding the condition by F, thus: N=CP(F+j2,b2) … This says the rest of this parameter is obeyed if the Flag associated with j2,b2 is set. A condition (F–j2,b2) tests for the Flag being clear. Note that the actual current state of the button j2,b2 is not relevant. All that matters is whether it last left its Flag set or clear. So for example 1=CP(F+4,2)4,2,C12345 2=CP(F-4,2)4,2,C54321 says alternately send control 12345 and 54321 each time Joy 4, button 2 gets pressed. Ah, maybe I didn't read it so deeply. Without me spending time trying to decipher the code, why doesn't the Lua tracve logging help you. The line numbers and variable values are shown. They don't help me because the Lua section you posted doesn't have enough line numbers -- the logged ones don't match. If you help me look at the part you think should "toggle" then I can maybe help. The LeoBodnar cards I use work with standar rotaries which send o press or release indication ("ground" or "live") for each click. They're the easier ones to handle. If your rotaries are of the phased type which need more decoding then I don't know whether the Bodnar microcode does the decoding or whether you have to. Assuming they are the former type, or the board does handle them okay, then obviously you can use the same method as in Triple Use to decide on the interpretation of the button on/off changes based on how fast they arrive -- slow = signle, fast = 10's. Though in the latter case you would probably discard some of the changes as on/offs will be arriving too fast for decient control. Pete

If you mean when you click the button to register the positions, then you have the order wrong. The numbers need to increase from left to right -- it won't accept any attempt to enter a number out of order. Left and Right on the calibration screen does not always correspond to left and right positions, eg for a Yoke. The left most number is the "minimum" value, which must be less than or equal to the "centre" values and those must be less than or equal to the "maximum" value. That's why they have those labels. There is no other cause of any "beeps" in that section of the options. Please follow the numbered steps shown in the User Guide for proper calibration. Pete

You are using the very first, buggy, version of FSX, released in 2006. You should really update to SP1 art least, or better SP2. i think these are still available for download. for example SP2: https://www.microsoft.com/en-us/download/details.aspx?id=8986 The Install log will be more informative for me. You'll find that in the Modules folder too. If you installed the currect SimConnect (the 60905 one or "RTM") then it should be fine. If you installed them all, just in case, then something went wrong. The error you are getting is described as meaning: Error 0x80004005 is translated as an unspecified error and is usually seen when the user cannot access Shared Folders, Drives, Virtual Machines and also when the Windows Updates fails to install. What's been changed? Do you mean you've been using FSX RTM with FSUIPC4 with no problems and have only now had this problem? Pete

There are assignable controls added by FSUIPC for this: Heading Bug Dec Fast (–10) Heading Bug Inc Fast (+10) These are in the drop-down list in Button and Key assignments. For a full list of the additional controls provided by FSUIPC, please check the list in the Advanced User's document. Pete

FSUIPC assignable controls are almost all just FSX assignable controls. The drop down list is actually generated by reading the list from FSX, so that it kept up to date with any changes. There are a number of specialised controls added by FSUIPC, complementing the fSX ones plus adding ones specific to FSUIPC facilities. The easiest way to find which controls to assign is as follows: 1. In FSUIPC's Logging tab, enable Event Logging (not the Axis Events). 2. Proceed to start the engines using the mouse of the displayed gauges/switches. 3. check the FSUIPC4.LOG (in the Modules folder) to see which controls were used. To make this easier to see, try running FSX in Windowed mode and, in the FSUIPC4 Logging tab, check the option for "console log". Then you can see what is happening in real time, in the on-screen log. Pete

Well, yes, it certainly should be! You are basically becoming part of the add-on aircraft. You mean the ipc.writes? That's rather odd. There's no built-in delay for those, though there would be for the LVar reads. Pete

There was one other thing about your experience too. DXDIAG. Isn't that where you ran DXDIAG and it failed, but then, after doing that, P3D ran okay? EXCEPT you found, from the logs , the many USB disconnects/reconnects which actually weren't noticed whilst flying ... ? Pete

Just a quick interjection (John will have to continue on this, because i'm off on holiday soon): The Hidcanner logs show devices connecting, disconnecting, and connecting again. This is very similar to problems experienced by Ray, another user here, which were eventually tracked down to a connected hub device which was incompatible with Win10. It too caused CTD the first time then not on restart, and the logs showed devices regularly connecting and disconnecting. Unfortunately, your FSUIPC log from the session where there was no CTD seems stopped after 10 seconds, so their may have been more if you let the session continue and provided a full log ... but even in those first 10 seconds I see: 7484 ***** A device has been attached! 7484 -------------------------------------------------------------------- and 8016 ***** This device has been removed: 8016 Device at "\\?\HID#VID_0835&PID_8502#8&1f938545&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" 8047 ***** A device has been attached! So -- try with NO HUBS attached, whether used or not. If the problem still exists then it must be a motherboard hub problem. Pete

The installer just "drops in" the DLL. The DLL is embedded indie. THe installer also updates the documentation. You don't need to re-register. Well, there's no tiller assignment, and the wheel was assigned to aileron and elevator!!! Yes, as I said. No, not unless the buttons were pressing themselves or had some sort of short. Buttons don't send signals except when used. Maybe you have buttons which are really switches and left "on" by defalut? You have "repeat whilst pres" assignments for trim actions on all three devices (i.e. as bad as the axis assignments): 3=R0,1,C65615,0 -{ELEV_TRIM_UP}- 4=R0,0,C65607,0 -{ELEV_TRIM_DN}- 12=R1,0,C65607,0 -{ELEV_TRIM_DN}- 13=R1,1,C65615,0 -{ELEV_TRIM_UP}- 8=R2,0,C65607,0 -{ELEV_TRIM_DN}- 9=R2,1,C65615,0 -{ELEV_TRIM_UP}- Not "maybe" delete the INI, definitely delete the INI ! I'm on holiday now till June 24th. Pete

If you did this, then re-assigned, how is it you have some many assignments to the same things? AILERON: 0=0X,256,F,65695,0,0,0 -{ TO SIM: AILERON_SET }- 5=1X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 7=2X,256,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- ELEVATOR: 1=0Y,256,F,65694,0,0,0 -{ TO SIM: ELEVATOR_SET }- 6=1Y,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 8=2Y,256,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- RUDDER: 2=0Z,256,F,65764,0,0,0 -{ TO SIM: AXIS_RUDDER_SET }- 9=2Z,256,F,65696,0,0,0 -{ TO SIM: RUDDER_SET }- You have three devices, 0 ("FDS-FC1"), 1 ("Racing wheel apex") and 2 ("BU0836"), and you have elevator and ailerons assigned for all three, and rudder to two of them. Furthermore, the Aileron and Elevator assignments for device 0 (which judging by the toe brake assignments is actually the rudder), are using the old FS98 type of control which operates completely differently, with a different range to be calibrated, than the standard "AXIS ... SET" controls. One of the rudder assignments is also like this, but not the one to device 0. I think you now do need to really delete the INI and start again. but only assign the right controls, not everything you have to all the flight controls. That makes no sense. First update to 4.974. Version 4.960, the one you are using, is very old now and cannot be supported. Please don't post again whilst using out of date versions. Pete

This is the AIseparation problem already discussed in another thread I think you'll find that everything is okay without AIseparation running. We think there's a problem in P3D4 with much slewing of AI Traffic, but we have to prove this to L-M. I think you'll find that there are in fact two or three errors irecorded in Event Viewer, the other two involving a .NET error in P3D. FSUIPC doesn't use .NET. Please refer to: If you have more information to add please do it there -- it is better for us to deal with this issue via one discussion and evidence thread. I've locked this one now. Pete

Can anyone following this problem please refer now to this thread, which is taling about the same problem but instigated via AIseparation instead of RC4: I'm closing this thread in favour of the joint one. Pete

Yes, It certainly seems so. It's related to trying to control AI in Slew mode via FSUIPC offsets 2900 & 2904. Pete

I think it must be very timing dependent, and it still appears to be a P3D problem. With 5.15 it may just be very infrequent. Yesterday I had AIseparation running for hours at Heathrow with lots of conflicts being listed and treated, and no crash. Before that I managed to generate one crash quite early one, but unfortunately that wasn't the Debug version and wasn't running under the debugger, so I couldn't track it to source. John is pondering what to do. He might write a separate program doing the same thing directly into SimConnect, not via FSUIPC, because then if we can force the crash we can present it to L-M as evidence. Note that all FSUIPC does when receiving these SLEW mode controls (or any controls for that matter), aimed at an AI aircraft, it simply sends it on to P3d for execution in exactly the same way as it does for any assigned controls for the user aircraft. The only difference is the ID of the 'object' being commanded. I'm off on holiday soon so John will continue this when he can. Pete

Not many Add-Ons use controls. PMDG boeings are the only ones which come to mind. They use <custom controls>" beyond the range used by FS/P3D. Pete