Pete Dowson

FSUIPC only recognises the first 32 buttons on any joystick device, numbered 0-31 in FSUIPC, 1-32 in FS. Pete

If your throttle axis "controls everything", I think you must have multiple assignments. Are you assigning only in FSUIPC? You need to check that controllers are disabled in FS. If this is a question specifically about FSUIPC assignment, then, as a strictly non-helo user (hate the things) I can only really say assign in whichever way works in FS. The controls won't be different, especially if you assign using the FS controls option rather than the "direct to FSUIPC" option. Some add-ons don't like the controls used in the latter method. But also this depends on whether you calibrate in FSUIPC or not. Pete

Leo Bodnar boards emulate standard joystick devices and are seen by FS and FSUIPC alike as standard sets of buttons and axes. If you use other software to intervene, as you have, I'm afraid I've no idea whiat would be going on. I think you need to go to support forums for "encoderkeys" and IOCKEYS" programs, whatever they are. Does Mindstar have any support? Pete

As before. What sort of connection does the quadrant use? It may need PFCFSX.DLL. If nothing in your quadrant is recognised, it won't show anywhere. PFCHid does not have assignments for the quadrant built into the Cirrus consoles. They are mostly automatic but ca be overridden in FSUIPC. Have you bothered to look at Axis Assignments in FSUIPC? Pete

Since the fix correctly operates by changing only the bits you specify, whereas previously, because of the bug, it affected other bits too, I suspect that one or other of the other bits are needed to change the visible switch. Try toggling all bits (255). It may be something to do with the way the gauges in that add-on are programmed. BTW, when 029C is written, no matter how, FSUIPC checks whether he value has changed, and if soit sends the control "Pitot heat set" (control number 66074)with a parameter of 1 if 029C is non-zero, or 0 if it is now zero. That is not changed by the Lua "togglebits" fix. I cannot understand what the gauge in your add-on can be doing to take different actions internally to that on the visible switch. That sort of thing might happen with mouse macros, but I can't see how it can react differently with standard FS controls. Pete

Your topic talks about "FSUIPC 4.939t", which is an old version. Please try installing the current supported version, 4,949. The Registration system has never been changed. You are making a mistake. All three parts must be as original -- name, email and key. Cut and paste if you aren't sure. Pete

I assume that's the limit set by FS? FSUIPC knows nothing about thaoe. Er, macros are simply sequences of actions. They aren't dependent on gauges. If you mean "mouse macros" they depend on the way the gauge is written, and operate switches and dials, they don't select views. View selection is by FS controls. Just checking, I see that FS supports controls "View camera select 0 - 9", so I assume that's the 10 limit. If 10 is the limit anyway, how would you change Flight Sim to allow that expansion? SimConnect does support the creation of new camera views ("CameraSetRelative6DOF"), for which FSUIPC recently added programmatic support, but I don't know how more than 10 defined views are selected. Pete

This is almost always due to a bad install of the basic joystick data in the Windows Registry. It seems to afflict Saitek users very frequently. There's nothing FSUIPC or FS can do because it makes the axis act as a digital "on/off" switch. I think the only fix might be to edit the offending part of the Registry. You could try the Saitek support forum, and there is actually a FAQ subforum thread on this, the one entitled "Fixing problems with 50% (or digital on/off) action with Saitek levers"

What is ".cs"? I don't know the coding you are using I'm afraid. Are you using Paul Henty's .NET DLL? If so you need to use the Subforum for this, above. As for "doesn't give the correct value", have you not tried to debug the code to see why? Is there no relation? Pete

What sort of connection does the quadrant use? It may need PFCFSX.DLL. Have you ever checked with PFC support at all? They tend to know more about their devices that I. I can only guess what you have and how it is connected. Pete

I was on holiday till today, as announced. Pete

If your copy of that document is that old, you must be using very old and unsupported version of FSUIPC! The Installer for FSUIPC has been installing an up to date version, related to the up to date offsets for many months, since soon after the NGX update. It was also corrected in several places and currently is up to date for the NGX SP1d. Please update you FSUIPC installation. You'll then find all the supplied documents in the FSUIPC Documents subfolder! Pete

You are under a misapprehension. There is no way any saved flight can possibly override a default flight or any other flight you explicitly load. To use Previous Flight you would need to select it. Flights are never loaded automstically EXCEPT for the one you designate as default. Previous Flight files used to always be saved automatically by Flight Simulator, not by FSUIPC. When that facility stopped working (in one or other FSX update) I responded to requests from users to get FSUIPC to provide them instead. So it does, by default, to compensate for the fault in FS. As documented in the FSUIPC Advanced User's guide, just change the INI file parameter "SavePreviousFlight" to No if you don't want this useful action. Pete

SimConnect isn't involved in WideFS. There is no difference whatsoever in WideFS between any version of FS, so you have some setting different. I would need to see the WideServer and WideClient log files, please. Paste them into a message here. Pete

I'm sure it cannot be asking for a version 3V. Are you sure that's correct? Did you uninstall an older version of P3D perhaps, but left the install entries in the Registry? When you say "it keeps asking" do you mean it loops, even if you cancel tat install stage? Each version will install separately, one after the other. I can't really help further without seeing the Install log, please. You can paste it into a message here. Pete

FSUIPC version 4.937 is no longer supported. Please update to 4.949. That error stops your "FSXOzplug" working. You'd need to correct it. The installer for FSUIPC installs for all versions of FS (though ESP support is now removed and P3Dv3 support added) Why does that worry you? As described in the WideFS documentation, WideClient (not FSUIPC) executes an "Initial.LUA" if it finds it. It logs it either way so you know. Why do you think you are missing anything? Logs are for information, not just error reports. Pete

Yes, as long as the lever is recognised as a normal Joystick input. The FSUIPC user guide will help. That's what it is for. Pete

I don't know, but I don't see any reason why the Lua libraries should stop you doing whatever you liked on the Network. Maybe the Lua reference data on their website will help? Pete

Er ... sorry. This is surely clear from the definition of the function you declare to receive the event? You quoted the words yourself earlier: Your processing function: function-name(time) YOUR processing function, i.e. the one YOU write to process the event, is declared as "function-name(time)". The function-name and the parameter name ("time" here) are up to you to choose, but it certainly means that the time is provided TO the processing function as a parameter? How else could you possibly interpret it? I'm trying to find what on Earth is wrong with the documentation here. If "time" was returned by the event.timer call itself it would be documented as time = event.timer(time, "function-name") just as it is for all the other descriptions of functions which return a value. Look through the other event function descriptions. Different parameters, as appropriate to the type of event, are provided to each. Whether you choose to use them or not is up to you. If you don't use them you don't even need to declare them -- Lua is very flexible (unlike most languages) in this regard. Pete

Yes. The thread is simply suspended for (at least) the specified time. The Sleep is actually a Windows function. It simply means that the two times are not comparable, they are not from the same source. You can use the time supplied by the event.timer function to compare with previous such times -- for instance to determine how long it really was since the last timer event. It might not be exactly the number of milliseconds requested in the call because the resuscitation of the thread might be delayed by the loading on the system -- even possibly by quite a lot with some things FS does. The actual time difference might be important for those applications wishing to do stuff in a time-related way, maybe computing speeds, distances, frequencies of things, and so on. Pete

Quite honestly I think you should be using SimConnect directly, not FSUIPC which from this perspective is really predominantly a compatibility layer between SimConnect and applications originally written for FS2004 or before, or some newer ones intended to cover both FSX and the still strong FS2004 user base.. Full documentation and many examples for SimConnect are provided within the Microsoft SDK. In any case, for commercial application, you should really be looking now at Lockheed Martin's Prepar3D, though you'd need to restrict the use to "academic and training" purposes because entertainment isn't allowed by their EULA. (God forbid that anyone might enjoy it! ;-). The Prepar3D SDK is freely downloadable from the P3D website. Pete

The data supplied to FSUIPC must be EXACTLY as documented. It sounds like somewhere you have a 64-bit pointer instead of a 32-bit one. Take care that all values are 32-bit compatible. Use the debugger to examine the byte-by-byte format of the request data being forwarded. (You probably need to write a 64-bit version of the library code -- I see you must be editing it as it is). Paul Henty has recently made his .NET DLL for FSUIPC 64-bit compatible, so you may want to check that out as a more ready-made solution, or at least talk to him. See his SubMenu above. Pete

Actually, the Log shows a normal close down. FSUIPC certainly isn't crashing there, nor taking down FSX. To help further I would need 1) the log created when the crash has actually occurred 2) the details from the Windows Event Viewer, detailing the type and place of the error. The most usual crash at that time is when the FLT + WX file is loaded, and almost always indicates a corrupted WX (weather) file. Those files are binary and are read by FS completely unchecked. The other possibility is a corrupted wxstationlist.bin file (found in the same folder as your DLL.XML). You can try deleting both files. The BIN file will be regenerated and, of course, you can recreate the weather saved in the WX files any time, or not bother anyway if you are using a weather program. The reason corruptions in these files only crash FS when FSUIPC is running is that FSUIPC reads the weather data from SimConnect regularly, as soon as it is ready. This diagnosis is bolstered by the fact that your FSUIPC is not registered, so FSUIPC is doing almost nothing else at that time, just reading data from SimConnect, weather included. Pete

Then it is PFCHID you need, not PFCFSX -- the latter is for serial port based PFC devices. You don't actually say what you installed (nor anything else of use, really), but I assume it was PFSFSX because the PFCHID driver certainly doesn't ask for a COM port! Yes, but the consoles and cockpits are more than just Windows-recognised "joystick" devices. They are HID devices, certainly, but send a lot more signals than just axes and buttons, which is what the default drivers in Windows support. Pete

By "PFCcid.dll" do you really mean "PFCHID.dll? The serial port interface program is PFCFSX.DLL When you say "the USB version of PFC Controls" do you mean the older serial port controls which use a USB-to-COM interface program in the PC? Because most of my PFC controls are like that. They are not true HID devices Or do you mean the later controls which are true HID devices? Perhaps you ought to state exactly what controls you are talking about. PFC made and make everything form yikes, throttle quadrants, and pedals, to full blown cockpits including the actual shell. The serial port ones need PFCFSX.DLL whilst the HID ones, the genuine USB ones, either use PFCHID.DLL, or simply interface directly using default Windows joystick drivers. Didn't you get any instructions or documentation with your controls? Have you tried PFC support at all? Pete