Pete Dowson

You posted it late yesterday. They are VERY busy at present (4.4 is imminent, remember). Even in "slacker" times I don't see immediate responses which it would be -- bear in mind they aren't retired hobbyists and have workng hours (and the US not in Europe). How many developers give you same day responses let alone within hours as it would have had to be to arrive before now? They aren't all as daft as me -- I sohuldn't do it really. i spend more time typing (and mis-typing) answers here than I do anything else! Pete

If it is a good reliable network try using UDP protocol for WideFS instead of TCP. It is more efficient, but has less error checking and doesn't guarantee order of frames being maintained. Just have Protocol=UDP in the WideClient.INI files instead of Protocol=TCP. Pete

Yes, of course. And I'm not on holiday! 😉 FSUIPC5 is okay as it is -- it doesn't use any hacks into the code in P3D4 as it used to in the 32-bit world, so it doesn't need changes for every release. There will be an FSUIPC 5.15 release though, but only to consolidate a number of relatively minor changes into a formal release. Pete

Yet, you mean ... even I don't get immediate responses! 😉 Pete

The PFC driver is written by myself and is in daily use here with PFC quadrand, yoke, pedals and centre console and it works fine as it has done for years. There's something else wrong with your system. How long have you had the quadrant? If you had it from new, as I had mine, they are most helpful. I could understand better if it were second or third hand. Pete

If you can use offsets then it is possible, of course. There are three controls built into FSUIPC to allow keypresses to be sent to FS. Here, from the FSUIPC Advanced User's guide: 1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk) 1071 Key Press/Hold (param is Keycode + 256*Shift code, or JsBk) 1072 Key Release (param is Keycode + 256*Shift code, or JsBk) And in the Offsets Status document you'll find details of offset 3110 (8 bytes(. There you send the parameter to offset 3114 (4 bytes or 32 bits), and then the control number, 1070 or whatever, to offset 3110. You can do that, but then you need a program, or a Lua plug-in, to read that user offset and send the keypress. Easy enough, but the above is better if you can send more than just 0 and 1. Another way is to use the "virtual button" facilities, offsets 3340 and following. Just toggle one bit in any of those bytes then program key keypress for that button in FSUIPC. Virtual buttons are programmable just like real ones. This way you only need to write the one byte, 0 or 1 (alternately so that the button press or release is seen. You'd program press and release separately). Pete

Good past on the L-M forum -- succinct and to the point. Pete

Ah, so this is not an FSUIPC question, but a ProSim one! I use ProSim 2.08 at present, and that works for me with the main control axes assigned in FSUIPC, not in ProSim. But that it because my controls are PFC serial port ones and not seen by ProSim. I think ProSim folks do advise that you assign and calibrate in ProSim itself. I don't really want to look at logs which are clearly not really relevant when you've already identified your problem. However, a brief glance shows it to be virtually identical to the previous one, so my previous comments apply. It is perfectly possible for any FSUIPC application to prevent control axis inputs reaching the Sim. This is done by systems programs like ProSim in order to properly simulate the various subsystems. If you think this is not operating correctly in ProSim, then it is to their Forum you need to report. Pete

But the words were: "Basicly fsuipc right now can see all axes but There is that interruption between these software's." This tells me on the one hand that you solved the issue, but on the other that there's this "interruption" problem. I do not understand the use of the word "interruption" in this context. what exactly is wrong which you call "interruption"? Pete

Not really. All the logs for success show success. The logs for failure all show a hang in the scanning except the odd one where it was later, after all the scanning was okay. I'm not sure now what you are changing between each in any case. Pete

The log shows all the devices scan okay. The hange was after it loaded the default flight. Pete

That sort of Windows crash data would probably be of more use to L-M than me, So with no devices scanned it is okay! That shouldn't be the final test! There are more to narrow it down further. As I suggested earlier, I think you should test with: 1. No FSUIPC, devices plugged in, controllers enabled in P3D. 2. Same but using the other P3D mode (i.e changed the "direct" option) 3. Using completely different USB port(s). Going back a few emails, trying to find logs which sohwed things, you said but the Log file you attached showed a good session with a normal exit!! Confused! :-( Pete

The files you attached (and you should not really send me my own DLL!) show only a Microsoft SideWinder attached, which is recognised properly, and you have just one assignment for it, the elevator, assigned "Direct to FSUIPC": [JoyNames] AutoAssignLetters=No 0=SideWinder Precision 2 Joystick 0.GUID={357959C0-EF44-11E8-8003-444553540000} [Axes] PollInterval=10 RangeRepeatRate=10 0=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- You have no buttons assigned and no other axes. The log confirms this device was seen, and subsequently you moved the axis and the movements were also seen and acted upon: 202 ---------------------- Joystick Device Scan ----------------------- 218 Product= SideWinder Precision 2 Joystick 218 Manufacturer= Microsoft 218 Vendor=045E, Product=0038 (Version 1.8) 218 GUIDs returned for product: VID_045E&PID_0038: 218 GUID= {357959C0-EF44-11E8-8003-444553540000} 218 Details: Btns=8, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R255,U0,V0,X255,Y255,Z255 218 ------------------------------------------------------------------- 218 Device acquired for use: 218 Joystick ID = 0 (Registry okay) 218 0=SideWinder Precision 2 Joystick 218 0.GUID={357959C0-EF44-11E8-8003-444553540000} 234 ------------------------------------------------------------------- 18517 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -8639 (0xffffde41) AXIS_ELEVATOR_SET 18579 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -11676 (0xffffd264) AXIS_ELEVATOR_SET 18642 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -10496 (0xffffd700) AXIS_ELEVATOR_SET 18704 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -7447 (0xffffe2e9) AXIS_ELEVATOR_SET 18767 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -3295 (0xfffff321) AXIS_ELEVATOR_SET 18829 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -96 (0xffffffa0) AXIS_ELEVATOR_SET 18891 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 3419 (0x00000d5b) AXIS_ELEVATOR_SET 18954 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 6965 (0x00001b35) AXIS_ELEVATOR_SET 19016 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 10047 (0x0000273f) AXIS_ELEVATOR_SET 19079 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 12433 (0x00003091) AXIS_ELEVATOR_SET 19141 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 14429 (0x0000385d) AXIS_ELEVATOR_SET 19203 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 15346 (0x00003bf2) AXIS_ELEVATOR_SET 19266 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 15768 (0x00003d98) AXIS_ELEVATOR_SET 19328 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 15478 (0x00003c76) AXIS_ELEVATOR_SET 19328 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 14905 (0x00003a39) AXIS_ELEVATOR_SET 19391 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 14170 (0x0000375a) AXIS_ELEVATOR_SET 19453 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 11633 (0x00002d71) AXIS_ELEVATOR_SET So what really is the problem? You don't really seem to have described it. Pete

Are the WideClients set to interface specifically to the separate PCs running the sims (i.e. ia ServerName or ServerIPAddr, and Protocol parameters)? If not then natuarally they'll all attach to the one already running. WideFS does not use SimConnect. FSUIPC has no provision for Server name or IP. It runs on the server. Do you mean WideClient? If you specificy Name or IP address (and it should not matter which unless your PCs have multiple network lnks), then you must also specify the Protocol, as these parameters make WideClient ignore the broadcasts from the Servers and those include the protocol to be used ("ProtocolPreferred"). However, it might be worth trying ServerIPAddr and Protocol parameters, rather than ServerName and Protocol, as it does save a step in Windows which might get into a state (depending on routers, usually). It shouldn't really matter if you are specifiying the target PC fully, but it could be worth trying ot avoid and clashes. Pete

The PFC axis inputs should have a range approaching a maximum of 127. 80 for full is very poor. I think you should ask PFC about that. Nevertheless, whilst FSUIPC expects the PFC axis inputs to go from 0-127, and multiplies the values received accordingly, it will be capable a calibrating to the full sim range. Where are you seeing these "scaled outputs"? A value of 52590 in the 16 bits allowed is actually about -12946, so very different from the other values which are all positive. 52590 for an axis doesn't make sense. In the PFC driver, since it already knows those axes need reversing, it does it automatically. You can'tchange them in that tab. Only in FSUIPC. Your problem does really need PFC attention. I'm never heard of any such problems before with the quadrant, and that's over more yers than I care to count! Pete

Thanks. Pete

Yes, sorry -- typo. I was thinking that since you've been using 3.4 a while on your old PC wirhout these crashes, that checking it out on the new one would check whether it had a similar problem -- so pointing to something more hardware related than software (or maybe Windows of course!). One other thing: as well as the log with the extra logging (on a run which crashed, not a good run), the Joyscan csv file from that run would be useful. It would also show what stage in the FSUIPC scanning it got to. The file you supplied erlier shows a completed scan, not one crashing part way as the log does (there's no "prev" CSV, so you'd need to get that file before your usual re-launching. Also, I assume you have P3D4 set with controllers disabled. If so, then P3D4 is not scanning devices either. (Actually, I'm not sure whether it does that during loading or not in any case). P3D has two scanning modes -- normal DirectInput, like FSUIPC, and "direct" which I think means actual USB serial port interface use, much like FSUIPC's COM HID library facilities in Lua. So, there are all these variations to test, too, to try to pinpoint where the problem may lie. Pete

Same single rudder control input and assignment? If so, FSUIPC cannot do anything about that, no matter where you assign. Does it do the same with default aircraft? That would be wrong. There's an increasing rudder effectiveness on the ground as speed increases, and this is needed during the latter part of the take-off roll. Hence the blending facility in FSUIPC. Pete

They are all in the INI file: [JoyNames] AutoAssignLetters=No T=Saitek Pro Flight Throttle Quadrant (USB) T.GUID={D78B8DC0-E4DE-11E8-8012-444553540000} 0=Saitek Pro Flight Throttle Quadrant (USB) 0.GUID={D78B8DC0-E4DE-11E8-8012-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={D738B2D0-E4DE-11E8-800B-444553540000} 1=Saitek Pro Flight Yoke 1.GUID={D738B2D0-E4DE-11E8-800B-444553540000} U=Saitek Pro Flight Throttle Quadrant (USB) U.GUID={D78B66B0-E4DE-11E8-8010-444553540000} 2=Saitek Pro Flight Throttle Quadrant (USB) 2.GUID={D78B66B0-E4DE-11E8-8010-444553540000} P=CH PRO PEDALS USB P.GUID={D7388BC0-E4DE-11E8-800A-444553540000} 3=CH PRO PEDALS USB 3.GUID={D7388BC0-E4DE-11E8-800A-444553540000} Or is that your doing, editing? The log file is stopping, as before, in midst joystick scan. Very suspicious. See what happens if you unplug them all first. Then try one at a time. You said on the AVSIM Forum that it booted okay second and subsequent times. This suggestes something odd about initialisation of the devices causing DirectInput to crash. If you can nail it down to one device, see if waggling its axes or pressing its buttons before loading P3D makes a difference. You could also get more detals about the scanning by extra logging. Add these to the [General] section in FSUIPC5.INI: Debug=Please LogExtras=x200000 Do you have P3D4.3 in stalled o this new PC yet? If not and you plan to I'd do it now and test on that too. Because it might be a failing USB port (you could try moving them aound too, of course, to check that). Bear in mind that USB ports are paired -- i.e. same hardware chippery for pairs. Pete

Sounds like multiple assignments. If you are assigning in FSUIPC then disable controllers in P3D. if assigning in P3D remove all assignments in FSUIPC (delete the sections in FSUIPC5.INI, your settings). Why are you logging everything you can find? The log file you provided in just full of nonsense. Please only log things on request. Ininitally all that is required in the default logging. Additionally, please do NOT press the New Log button. That starts a new log, losing important initial information in the original. There's no information here about any assignments you made in FSUIPC. Where's your FSUIPC5.INI file? Not that is is quite so relevant until and unless you confirm where you are assigning and if you have disabled them in the other. Pete

It is programming. There is an example in the Lua plug-ins ZIP file, but you will need to read up on Lua language a bit. But previously you said: Since FSUIPC can see the axes, what is this other thing, "interruption". what do you mean by that? I asked you that back on the 15th! And what did Saitek support say? Because there's something wrong anyway. Both Stick and Throttle units are standard Joystick Devices, seen as such by Windows and therefore by P3D itself. Yet earlier you said Since all buttons and axes are ready by one operation in DirectInput, that makes no sense unless the unit is broken, which is why I pointed you to Saitek Support! And in any case if the Sim can't see the axis, nor can FSUIPC. Pete

In that case you have more than one assignment. If you are using FSUIPC to assign switches and axes you really do need to disable controllers in P3D, otherwise both will respond! Pete

Then they are giving slightly different brake pressures. Best to use them visually, keeping straight by watching where you are going rather that worry about whether the sim thinks tifferent or the same. No. Brakes are either off (0) or positive. Nrgative braking is a bit of a meaningless concept. Sorry, what do you mean "list on the right side"? The sim has separate Steering Set and Axis Rudder Set controls. both are listed in the drop-down on the LEFT side when you select "FS control" instead of "direct to FSUIPC". The direct method gives you "Rudder" and Tiller, but they both use the rudder to execute. The point of using those is the gradual transfer of effectiveness from one to the other as you speed up or slow down. More relaistic. the separate controls fed direct into the Sim both have full normal effectiveness all the time (though some add-on aircraft models do try to limit rudder angles at low speed). Why? Using an axis (especially a twist one) for steering is much nicer. I don't understand why you think there's a problem. Pete

Looks okay. Pete

Sorry, but you are still misunderstanding my suggestion! I'll try it step by step: 1. Disable controllers in FSX. 2. In FSUIPC options, go to Buttons & Switches options tab. 3. Press the button you want to use. 4. Use the Key press side of the assignments (NOT the control assignment side), and 5. Enter the key press whch works so that it is sent when you press the button! 6. Press OK and verify that it works. You are thereby using your FSX keypress assignment, not the Aileron Trim Set control in FSUUIPC, which we've all agreed doesn't work. Yes, you are -- I've lost count of how many times you've said the same things! 😉 Pete