Pete Dowson

FSUIPC doesn't embody hardware drivers at all. It supports standard Joysticks, and does use the GoFlight driver for GoFlight device (inputs only). For things like Arduino I use simply lua plug-ins. the Lua library does support COM devices well, and it is easy to knock up short programs to send and receive messages to/from an Arduino and simulataneously deal with Sim variables, inputs and outputs. Check the Lua library document and the examples supplied in the ZIP. Pete

It might have helped providing us with an FSUIPC log file, with Button, Event and Lua tracing enabled. You can ZIP up the Log file and attach it to a reply here. HID com part reads are just effectively doing the same as the normal driver for joystick devices, it just reaches the user program through a different, dedicated interface. When you run your Lua program, is FSUIPC also scanning the device as a normal joystick? If so I wonder if that is causing some sort of problem at a lower level. Try de-assigning anything you have assigned to it in FSUIPC. It already should be unassigned in MSFS if you planned on using FSUIPC in any case. I really can't think of any other reason for the problem, but lets see logs. It's getting late here now, and I'm not really working tomorrow 9lots of more normal home things to do), but i might be able to try something on Monday -- just not with the same sort of device, I suspect. What is Vendor 0x1234 and device 0xBEAD? They don't seem to be officially issued values. Pete

I wish you had mentioned MSFS earlier. You should be posting in the FSUIPC Beta subForum above. FSUIPC7 is a Beta release whilst being developed. Additionally MSFS is in development(and is also effectively a Beta release. I am not in a position to support this. I use Prepar3D and any of you suggested solutions work fine for me -- but then the Lua plugin along with FSUIPC run as part of the SIM process. It's a lot different. Maybe John or Thomas will know what is so different, enough for such an enormous delay. Did you bother trying tracing to see what is going on? Pete Pete

Really? Not sure I understand. Which version of FSUIPC are you using? And why are you using the plug-in instead of assigning directly, if the device is recognised as a joystick? Is it because you are going to extend this to more than 32 buttons? I don't see anything wrong with your Lua code, though it would be more efficient just to have this in the function: function processButton(handle, data) local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonstate; end end How are you starting the plug-in running? via an [Auto]? One possible problem occurs to me, which may well be the cause of your delay. The event.com function will trigger when ANY data is received from the device, whether it is about buttons or whatever. Maybe your function is actually being alled very often but just doesn't have anything to do most of the time. You can check by using the Lua debug trace facility in the FSUIPC Logging options. There is a Lua example of reading and acting on buttons from a HID device, one which works well. See HIDDEMO.Lua, in the Examples plug-ins ZIP file. That certainly doesn't use event.com but does it by polling using event.timer -- by default it is currently set to check 25 times per second. Pete

If you want fixed settings on your throttle axis, rather than a continuous change, then instead of assigning on the left-hand side of the assignments dialogue, use the right hand side. Define regions corresponding to where you want the detents and assign to AXIS_THROTTLEn SET (n = engine number), with different parameter values: 0 for the idle region, then values between 0 and 16383 corresponding to the % thrust you want for each detent. i.e. 60% of 16383 = 9830 80% of 16383 = 13107 100% of 16383 = 16383 If you want all engines on the one axis, use AXIS_THROTTLE_SET instead. Not sure what you are getting at there? Pete

FSUIPC, like FSX and P3D, recognises joystick type devices, classified as such by the Identity details they supply to Windows. As it isn't such, you would need some sort of driver for it. It could probably be done using a Lua plug-in for FSUIPC -- see the HidDemo.lua example in the Lua Examples ZIP supplied with FSUIPC documentation. You might also checkout drivers such as SPAD or SPAD-Next, and LINDA. Pete

Currently the fix I use just that -- use more than one vJoy. They are easy enough to configure, after all. You can get FSUIPC to detect more than 32, but only by using a Lua plug-in to handle the USB inputs and direct the button presses to the Virtual Button offsets. There's an example in the Lua Examples ZIP provided. The 32-button limitation is unfortunately a well embedded and long-standing 'feature' of FSUIPC -- due to the use of the original "joy" interface in Windows dating back to "Windows for Windows 95". We've been concentrating in developments on maintaining compatibility across the range of FS-type simulators whilst still supporting new features. The changes it would need to allow the full DirectX complement of possible Joystick inputs to be detected directly (as opposed to using plug-ins) are pretty massive and could be very error prone. Now is not the time to consider such things with the amount of work still needed for MSFS (and with MSFS developers to get more things working). Pete

You can do it as you have been before -- i.e. via FSUIPC axis assignments. Do the assignments for both yokes "direct to FSUIPC calibration", and calibrate. The interface between FSUIPC and MSFS for axes is via control events, so MSFS doesn't need to be aware of the source of the inputs. Just be sure not to have them assigned in MSFS as well. Pete

Ah, I see. I am looking for view controls -- ideally pan left/right/up/down, but even a simple 2look left" and "look right" would help. It's really the only thing missing for my VFR cockpit. I'll try keypress assignment next. Pete

I thought you said Left and Right were working okay, but not Up and Down? I've not tried the eyepoint controls -- i thought they just shifted the pilot, not changed the view direction. I'll have to experiment with them. Pete

Can you tell me how you did that please? I'm still trying to find ways of changing views for my hardware cockpit. I've tried all the "cockpit" view controls and it seems they are not connected up in MSFS yet. Pete

Does that mean you tried it and it failed? No Install log, no Windows error? The differences between 4.974 and 4.975 were primarily related to late FSX-SE changes, and those were to do with recognising version number changes . Development of FSUIPC was effectively frozen after 4.97 in 2017, so I'm not sure there's anything for you to be sad about. Pete

As well as what Thomas says, you do really need to use the Installer. Just moving files is not sufficient to tell P3Dv5 to load and run FSUIPC. The Modules folder is not actually normally used with FSUIPC6 in any case. FSUIPC5 was the last to need such a folder. You can choose whatever folder you like when installing FSUIPC6. Pete

I don't know any reason why it shouldn't, but I've not had a WinXP system to test anything on for years. Certainly some of my programs will no longer work on something so old. Pete

There is a control "SIM RATE SET" which should do it. It never did anything in FSX, but you could see if it now works in P3D. I'm not sure what the parameter should be though. Whilst 1 sounds sensible, internally a sim rate of 1 is represented by 256, so it may well be 256. the larger number was to allow fractional sim rates -- like your 1/2 which would be 128. Assuming it still doesn't work, which is likely, then really you just need to be more careful to press your assigned button just the once -- I assume you've not set it to repeat? Pete

If it is a simple process of reacting to GSX events then possibly a Lua plug-in could do it all, more simply than having an external program interfacing to FSUIPC. Otherwise John is correct of course - better to use the FSUIPC SDK or the .Net client. To interface to FSUIPC use the FSUIPC SDK or Paul Henty's .NET DLL. The P3D SDK will enable you to use SimConnect, build scenery, and make aircraft models, but unfortunately the Local variables used in aircraft panels and add-in DLLs such as that from GSX are only available to other in-process programs -- hence FSUIPC which already has L:Var access built in. Pete

Ah, if the values are available via Lvars, then you can either use a Lua plug-in to read them, or program an FSUIPC interface into your program and use the offset facilities to request the LVars. The Lua facilities are documented in the Lua PDFs installed with the FSUIPC documentation, and the interface to FSUIPC is documented in the FSUIPC SDK. Or you could use Paul Henty's .NET DLL. Check this thread: Pete

Wouldn't it be better to ask this of the GSX authors, or at least on their forum? Not sure how you think this relates to FSUIPC? Pete

Okay, understood now ... John evidently understood it was this you were having problems with, and informed me privately. I was thinking more in terms of the use of the device(s) with assigned buttons. Pete

There are no delays from the PFC driver side. it simply sends it on after calibration (which is merely a short arithmetic calculation). The rest is up to the Sim. Is it just with that aircraft? What sort of delay are you talking about? I use a similar driver for my GA28R cockpit, one made by Aerosoft Australia and modelled on a Piper Arrow. Sadly there are no Piper aircraft at all available for MSFS at present, so i too try the C172 -- the bare bones version, as I have old-fashioned working analogue gauges in the hardware. I've not really noticed any delay, but I think it might depend on your expectations. Pete

Not sure I said anything to disagree with. The FSUIPC PTT facility was designed originally for Roger Wilco, and the standard method used by RW was adopted by Squawkbox and others. i have no idea how IVAO implement it, but if the FSUIPC PTT action doesn't work then you needed to find out what from IVAO, as I said. It looks like you've found that out now, and it appears they did not follow the standard way (which is actually a Registered Windows message) but offered a key press method instead. A lot of add-on programs rely on keypresses. FSUIPC doesn't cope with every such option in all such programs by inventing specific controls to send a keypress when it i just as easy to assign a keypress in the first place. Anyway, well done for finding the solution and thanks for posting the details for others. Pete

The Install log appears to indicate otherwise: Checking version of the FSX EXE:... Version 4.5.14.34698 which clearly indicates a version of Prepar3D version 4. This isn't surprising since the FSX install path in your Windows Registry gives SetupPath="C:\Lockheed Martin\Prepar3D v4\" This is confirmed by the sequence: How your Registry got in such a mess I don't really know. A complete uninstall of FSX and re-install should fix it. It would be quicker to edit the Registry directly, using RegEdit, but take care to make a Restore Point first, then using RegEdit go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 and edit the SetupPath parameter to point to wherever you put FSX. Pete

Yes. It's only supposed to ignore that option if you've not yet got a valid COM port set. I've just checked, and this is due to a difference in timing during loading. it looks like the option isn't applied early enough. I've modified the DLL for this. Please try this version and let me know: pfccom64.5051.zip Pete

There was no need for a picture! Why not just say you tried the PTT assignment I suggested? If the PTT assignment doesn't work it will because the version of IVAO software doesn't recognise its actions. I'm afraid you need to seek help from IVAO. I've never used any on-line ATC program myself. Pete

You are using Windows XP still? I hadn't noticed that in the Log, sorry. I'm actually a little surprised FSUIPC itself still works on XP. I don't think later versions of FSUIPC (5, 6, and 7) will run on anything earlier than Win 7. BUT if the 4.974 installer worked, I know of no reason at all for the 4.975 one to fail. The changes in the Installer are only related to the detection of later SimConnect and FSX-SE versions (specifically the final Beta release of FSX-SE by Microsoft). Is there nothing in the Windows Event Viewer? On the original problem, have you tried eliminating a possible weather file corruption? If not, try deleting all the .WX files in your FSX Documents folder, and deleting the wxstationlist.bin file in the FSX AppData folder. FSX will make a new one when it starts next. If that doesn't help then I really think that you should re-install FSX. Pete