Pete Dowson

As I already said, the PMDG controls are all listed in the PMDG documents for your aircraft. I don't use PMDG so I can't tell you what custom controls do what, you have to work it out yourself from the information PMDG provides. Haven't you yet even looked in the SDK folder in your PMDG aircraft installation? There'll be a file there of type ".h", and the controls are all listed at the end of that. I cannot support PMDG products -- that's their job. What I've done is provided a way to use what they provide. You work out the correct control number and parameter, and use them in the <custom control> assignment facility in FSUIPC. Pete

The one called "AP Master" is the AP toggle switch control for most aircraft. Some add-ons may use different methods. For FS controls like this one you can find the correct name (as used by FS internally) by enabling Event logging in FSUIPC, operating the control by mouse or FS short-cut, and looking in the FSUIPC Log to see which control name (and number) is logged. Custom controls are mainly used by PMDG aircraft, and the values have to be derived from the documentation in the aircraft-specific SDK installed for those aircraft. Pete

Test with a default aircraft. Maybe PMDG have programmed in some realism -- maybe uneven wear and tear on the engines and controls. Always test things with default aircraft. No idea. But you should also realise that analogue inputs are rarely exactly the same every time no matter how precisely you position them. I don't understand why you insist on them being aligned perfectly, it isn't a realistic proposition. If you really want exactly the same inputs to FS for every throttle position then use the Throttle Sync hot key method. Then, when that's engaged, FSUIPC copies throttle 1 to all engines and it won't matter where the others are. Pete

What indicates "hot brakes"? There's certainly nothing in FS which will do so, and since FSUIPC only handles FS values, it is impossible for FSUIPC to have anything to do with it. If PMDG have programmed in code for simulating hot brakes then they are the only people who will know why and how to fix it. FSUIPC itself doesn't do anything. It certainly doesn't do any braking. it does no throttle changing, no yoke moving, no rudder, no nothing. It only obeys what you tell it to do. If you have assigned brakes in FSUIPC or in FS and then calibrated them wrongly, whether in FSUIPC or in Windows Game Controllers, then they may well be applied even when you aren't pressing them. It is up to you to calibrate them correctly so there is no braking with your feet off the pedals. Other add-on companies seem to always blame FSUIPC because it's an easier get out for them rather than applying themselves. Pete

You'd be better off posting in Paul's own subforum (above: the one for the .NET DLL). I'm not sure how you (or the .NET DLL) are handling the requests, but provided the 40 requests are all sent by one Process call, that that's a pretty negligible load, especially at such a low rate as 10 per second. There are plenty of FSUIPC clients doing a much larger batch of requests much more often, even up to 50 times per second. Maybe he's running your application on the same PC as FS and that is either short of memory or the extra processing on the same processor is affecting performance. There's no free lunch in computers. There's just so much power and memory available and when overloaded you are going to notice a degradation somewhere. Pete

Yes, this is the problem with analogue inputs, especially generated by cheaper potentiometer devices. No two are ever identical. If the positions aren't too dissimilar you are actually getting something which is quite realistic as the types of control in the real aircraft are rarely the same after a while -- especially those like the older Boeings using mechanical and hydraulic links. Yes. There are facilities to calibrate them at more points than just minimum and maximum thrust. Please look in your FSUIPC User Guide, refer to the section called CALIBRATING MULTIPLE THROTTLE, PROP & MIXTURE AXES TO "LINE UP", on about page 50. Pete

Thanks. The log shows why the previous versions didn't get the MFDs: 312 Checking: \\?\hid#vid_044f&pid_b351#8&31a00d26&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} 312 Usage=5, UsagePage=1, =Game Controller 312 Product= F16 MFD 1 Up till now all the joystick type devices I've seen the Usage number for have been 4, not 5. I extended to allow 5 as well as a result of researching these on the Internet. I think the numbers were extended quite recently. Anyway, I've released FSUIPC 4.964f as a general interim release now. Thanks for your help! Good. Thanks for the confirmation! Pete

I've peered through the code, and the only thing I can see which will make this difference between 4.964 and 4.964e is that the usage identification returned for those MFD devices is not one I recognise as a Game Controller. I've searched the Microsoft DirectInput data on-line and I've added some more usage checks into 4.964f for you to try for me. Unfortunately I still cannot guarantee this will work correctly, but at least with some extra logging I've added I'll know why. Unfortunately HidScanner doesn't include the very information I needed for this -- an oversight, evidently. So I'd be most grateful if you would kindly download FSUIPC4964f_TEST.zip and test that for me. Please show me the LOG no matter what the result it. Please back up your INI file first. Thanks, Pete

Aha! Right. In that scan it sees all 4 devices! In the initialising scan but not when doing the Joystick ID scan. The main thing I see is that the MFDs are VID_044F&PID_B351, and VID_044F&PID_B352, and in the second loop they appear, thus: Checking: \\?\hid#vid_044f&pid_b351#8&31a00d26&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} Checking: \\?\hid#vid_044f&pid_b352#8&1c5fe7ed&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} Yet the registry doesn't cough up the details that you get for the Warthogs.contains It will be very interesting to see the fuller log for 4.964e. The two loops are now combined into one. Pete

Yes, I know it was (it says so in the fiile). But I don't understand how it could possibly have worked in 4.964 either, because the Joystick Scan for 4.964 doesn't list the MFD devices either. Without being recognised in the scan the devices won't be opened and so cannot be used -- at least, not by FSUIPC. Do you perhaps still have then assigned in P3D? Thanks. It would be useful to rerun, with the extra logging too, with 4.964 as well, and check that the assignments ARE in fact working, that all 4 devices ARE seen in the Buttons & Switches or Axes tabs in FSUIPC. I'd also like to see the INI from 4.964, because things are just not making sense at present. The problems I am trying to address with the changes here are NOT that any devices aren't being seen, but that the Joystick IDs aren't being sorted and corrected properly for those folks using Win8 or Win10 with installed joystick devices which somehow don't get assigned an ID. Previously I was having to recommend such users used the "JoyIDs" program to assign their own IDs so that FSUIPC would see them. These FSUIPC changes do that for you -- choosing numbers not already in use, and enforcing numbers already assigned in case something else has changed them (like JoyIDs can). Pete

Oh, another question. Is the 4.964 INI file different to the 4.964e one? I see that the MFD devices aren't recognised in the scan at all, in either version of FSUIPC, so I don't see how their assignments could work. It is during the scan that their DirectInput handles are obtained, and tabulated against ID number, so that they can be scanned. There's no other way they will be seen. The scan is an essential part of the process, it isn't just there to provide information in the Log file. Pete

The logs don't show me enough information I'm afraid. Please check the first message in this thread where it explains how to modify the INI file first to provide more logging. I really want to make this work correctly in all cases, so I do appreciate such testing. If you could please re-run the test with 4.964e after enabling the extra logging it will be most useful. I'll only need the LOG from that. Pete

Those are FS controls. FSUIPC does not process them, it only passes them on, same as if you assigned them in FS itself. As Thomas says, the add-on aircraft probably implements its own AP which doesn't use FS actions, or does but only internally. To see if it uses alternative FS controls just enable Event logging in FSUIPC and operate the AP war using the mouse. If it does use FS controls they will be logged. Pete

Very probably. Really most of the bad wind errors in FS9 and continued in FSX cannot be compensated for with minor fiddles. They need overriding using direct control, which is what Active Sky does so well. Pete

So you found the Log file, eventually. Were you looking in the wrong place? It appears the Lua you are using needs some other things you've not installed. I can't help with this -- you need to go to the support for whatever it is you are trying to use. It is not something I know at all. The 3 refers to line 3 in the Lua file you are loading, i.e. AvPlan-EFB.lua. It seems to refer to something called "vstruct" which isn't available. Well, you don't need a SimConnect log now you've actually found the FSUIPC4 log! However, for future reference, why do you think this is ta valid path? C:\Documents\FlightSimulatorX-SteamEditionFiles\ Do you REALLY have a folder named FlightSimulatorX-SteamEditionFiles in C:\Documents? Do you even have a C:\Documents folder? Seems all very unusual and non-standard. Use existing folders, not invented names for folders. Pete

Thanks! Yes, that confirms that it works the way it should. Thanks again! Pete

The part of the log you show me is just showing what FSUIPC read from the INI file, as it was at the time. he idea is that those assignments should be enforced, but I can't see that from what yo post. So, do you think I could see the whole log, please? At least to the end of the Joystick Scan section? Thank you. Pete

To have multiple actions on one button you need to edit the INI file. A button can have as many assignments to it as you like, but to keep it easy for 99% of users, the dialog options screen only handles one (or two if you include button release). It is just a matter of finding the correct assignment for the first action, in the INI, and copying it with new numbered lines with the other "event" or control numbers. Your FSUIPC documentations is in the subfolder of the Modules folder oddly called "FSUIPC Documents". All the documentation is there, as well as useful examples of Lua plug-ins. This fact IS pointed out in the Installation document which you would have seen in the original ZIP file download. Should I assume, then, that you have never looked at the main User Guide either? The reason for the reference to the Advanced Users guide is that it is there where the format of the Button and Key assignments in the INI file is explained, and there are examples of multiple assignments as well as more sophisticated ones like conditional ones using flags and/or offset values. Pete

If FSUIPC is listed in the Add-Ons menu, then there MUST be both an FSUIPC4.LOG and an FSUIPC4.INI file in the same modules folder as FSUIPC4.DLL. I am therefore absolutely sure you are looking in the wrong place. Bear in mind that if you are still running with Windows Explorer folder options telling it to hide known filetypes, those files with just look like "FSUIPC4" and descriptions "text file" and "configuration settings" (or similar) respectively. The FSUIPC user guide tells you to turn that folder option off. Er. What is that? How did you arrive at such an invalid line? It needs to be a file path, so Simconnect knows where to put the log! The FAQ thread shows how to have them placed in the FS Modules folder, alongside FSUIPC, so all files are in the same place. This part of the FAQ thread file=path to FSX\Modules\SimConnect%01u.Log shows how, and all you needed to do was replace the "path to FSX" with the path you must already know, since you say you listed the files in the Modules folder, i.e.this path: C:\Program Files (x86)\Steam\steamapps\common\FSX so why invent "This PC/ localDisk (C:)/ ThisPC/ Local Disk/ " which honestly makes absolutely no sense, and even uses the wrong separators / instead of \? For the SimConnect log you can have it placed anywhere you like. For simplicity you could simply have file=C:\Simconnect%01u.log which would put them in the root of the C drive. It is just more convenient to have all the files in the same place, alongside FSUIPC. I think you need to be more careful in what you are doing. Check things and double check them. Work things out properly, or you'll just get into more of a mess. Pete

The fact there is no FSUIPC4.INI nor FSUIPC4.LOG file there shows that whilst FSUIPC may be installed there, it has never been actually run from that folder. Both files are written as soon as FSUIPC is started. What "banner"? In FSX, when it is ready to fly, take a look at the Menu bar. At the right there should be an entry called "Add Ons" and if you click it there will be the FSUIPC entry, which when clcicked shows the FSUIPC options. If that entry is not there, then FSUIPC is not running. In that case something may be wrong with the DLL.XML file in this folder: Otherwise, assuming you are actually running the installation of FSX you think you are, SimConnect is not loading FSUIPC for some reason. To diagnose that you will need to obtain a SimConnect log file. There is a thread in the FAQ subforum which tells you how to do that. You could also check the [Trust] section in the FSX-SE.CFG file(in the same folder as DLL.XML) If there are any entries for FSUIPC4 there, delete them in case they have been set to the wrong value. That can sometimes happen if you even just once deny permission for it to be loaded when SimConnect prompts you about it not having a certificate. (If you have never seen such a prompt, then this most certainly points to one of the other reasons, though). I see that, whilst you are running FSX-SE, not the Microsoft edition, the Steam edition is installed as if it is a parallel installation with FSX also installed. However, FSUIPC's installer failed to find FSX and so only installed for FSX-SE. Did you delete the Microsoft edition rather than uninstall it? That might lead to problems with other add-ons. FSUIPC itsefl should be able to deal with it, as I've come up against this mix-up before. Pete

Ok. Perhaps you could go back to the back-up INI (before the test here), and edit it to remove left-over assignments please -- just the device 4 ones I assume. Then I'd be grateful if you could repeat the test, but using FSUIPC4964e TEST Thanks! Pete

I just need to know which assignment was correct for the second Bodnar board -- 0 or 4? I see they both have Yoke assignments -- do you have two yokes? The throttle only appears on device 4. I'm going to upload a version 4.964e test DLL soon. I'd be grateful if you'd return to the backup INI file and re-run the test, please. Pete

Another puzzle, if you can explain please. Though there are only 4 devices identified (originally as 0, 1, 2, 3 but after the test 4, 1, 2, 3, neither arrangement matches your assignments. for example: [Axes.Prosim 737] RangeRepeatRate=10 0=0X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=1X,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 3=1Y,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 4=1R,256,D,3,0,0,0 -{ DIRECT: Rudder }- 5=4X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 6=4Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 7=4Z,256,D,4,0,0,0 -{ DIRECT: Throttle }- Here there are assignments to both device 0 AND 4, implying that there were actually 5 devices at one time (though I can't be sure, of course, because I don't see any assignments to devices 2 or 3). Pete

Well, it seems it found them and set the Joystick IDs okay, but has it changed your device 0 to device 4? I ask becuse this is logged before the scan: EnumDevices: 0.GUID={DC6ADB60-5F5B-11E3-8001-444553540000} EnumDevices: 1.GUID={7290ABA0-80F7-11E6-8003-444553540000} EnumDevices: 2.GUID={E3AFCAF0-288F-11E3-8008-444553540000} EnumDevices: 3.GUID={E3AFCAF0-288F-11E3-8006-444553540000} but this is what it finished with in [JoyNames] 1=Button Box Interface 1 1.GUID={7290ABA0-80F7-11E6-8003-444553540000} 2=BU0836 Interface 2.GUID={E3AFCAF0-288F-11E3-8008-444553540000} 3=Saitek Pro Flight Rudder Pedals 3.GUID={E3AFCAF0-288F-11E3-8006-444553540000} 4=BU0836A Interface 4.GUID={DC6ADB60-5F5B-11E3-8001-444553540000} This wouldn't do any harm if you were using JoyLetters. but as it is your button assignments on Device 0 won't work as it is now Device 4. I assume you restored your backup INI? I'm a bit concerned if it is moving Joystick IDs unnecessarily. I just need confirmation from you, please. Thanks, Pete

FSUIPC can't "lose the keyboard". It doesn't handle keyboards. The keys are detected as Windows messages just as in all Windows programs. there's no keyboard detection or polling. It is, for keys, just a normal Windows program. I think you must have some serious problems on yor system somewhere. Entering options screens and so on changes absolutely nothing in the way keys are seen. If a key is not programmed, the keypress is handled by FS instead of FSUIPC which doesn't touch it. The logging of key presses is not dependent on any assignments at all, it is simply notification from Windows/FS. No, that is not an interception. It is a CallBack from Windows. FSUIPC simply registers a function with Windows to be called whenever a HID device disconnects or reconnects -- ANY such device, not just the ones t deals with (the callback cannot be made so specific). When it gets the callback for a reconnection it re-runs the scan. There is no way I know that Windows will say a device is reconnected unless it has, even momentarily, disconnected and reconnected. When it disconnects, FSUIPC will lose access as its handle to the device becomes useless. That's why it has to rescan. How soon data becomes available isn't relevant to disconnect/reconnect indications. That's not a "disconnection". And most FSUIPC users now appear to be using Win10, and without any problems. Win8 and early versions of Win10 did appear to suffer from easy USB device loss, but according to all reports a fully updated Win10 performs okay. Once a device is acquired FSUIPC does poll it at intervals -- that's controlled by the PollInterval parameter in the main [Buttons] section of the INI file. That defaults to 25 mSecs (so 40 times per second). But polling isn't related to the disconnect/reconnect indications. The polling is performed by using the "GetDeviceState" DirectInput function. That returns the current (virtually instantaneous) values for all buttons, exes, sliders and POVs. There is a "JoystickTimeout" parameter in the INI file, but that dates back to the FSUIPC3 dats when the "joy" interface was used instead of DirectInput. That is now only still used for EPIC controller board connections, as it is too restrictive for most modern devices. You can get FSUIPC to make a full log of the joystick state reading attempts. Add these lines the the [general] section of the INI file: Debug=Please LogExtras=x1000 The log will become very large very quickly. From the symptoms you describe and the results you get, I strongly suspect some sort of Windows corruption, or even a motherboard problem. There is nothing I can do in FSUIPC to make hardware connections work any differently. It is totally dependent on the Windows DirectInput API (for HID devices) and the standard Windows keyboard handling for keys. Pete