Pete Dowson

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

Posted twice? See reply to other post.

The names are those used internally (and in the saved assignments file) and obtained automatically from FS at run time. I don't know them all by heart, I have to look them up -- there's a lit provided in your FSUIPC Documents folder. You can also find out what they are called by enabling Event logging in FSUIPC and using the controls (by keypress or mouse) and seeing what is logged. However, for the ones you ask they are pretty easy to remember. I think "cycle view" might be "Next view". But try it. There's also a "Next sub view". You could find these in the published List document by searching on "view". Doors are called Exits in FS, so just search for Exit. I think it is "Toggle aircraft exit" and you can give the exit number as the parameter -- 1, 2, 3, or 4. I think it defaults to 1. FS has never provided separate controls for Gear Up and Gear Down. The only way you can do that is to assign to the FSUIPC Offset word set control with the correct offset for the Gear state and the appropriate value as parameter. All the offsets are listed in the Offsets list ("FSUIPC4 Offsets Status"), again in your FSUIPC Documents subfolder. Pete

I moved your post in "User Contributions" to this, the Support Forum, because 1) it is obviously NOT a "user contribution", but a Support request 2) It would have not been answered otherwise. Answering your questions, I think you are confused because you followed a wrong path, going to a Support location for files instead of the ones designed for you. If you purchased a WideFS key from SimMarket, then to download it you would have followed a link to the correct download area. There you would have seen that the active part of "WideFS7" is actually included in FSUIPC4. Your registration key unlocks it -- in FSUIPC4. The Network-connected client PCs run a component of WideFS called WideClient, and that same website you would have gone to tells you to download he WideFS package (whatever version) to get that client. WideClient.EXE is compatible with all versions of the WideFS server ("WideServer") from #1 to #7. You can download he package here, in Download Links, where you will see The complete package (the first one above) includes WideServer.DLL, which for FSX and later you discard. The main reason you need that package is for the documentation. Sunbsequently you only ever need updates for FSUIPC and WideClient, because it is very very unlikely that the main WideFS documentation will ever change. Hope this clears up your confusion? Pete

First of all you do always really need to state the version number of FSUIPC. Regarding your point 1, you need to be clearer. There are 4 set buttons. Please describe what you are doing. There is no way FSUIPC "ignores" a value if you are doing the correct sequence -- follow the numbered steps in the User Guide for correct calibration. Point 2 is also meaningless. Of course all boxes have default initial values. The top left SET button is the one which enables calibration, after which it changes to RESET enabling you to cancel calibration. Only the SET buttons above each calibration value transfer the current IN value to the box(es) beneath. That's part of the process of calibration. A slope of +15 gives the flattest initial response (virtually no change at all for initial movement) but extreme response the other end -- it has to to cover the range needed. It is -15 which will give you a "hair trigger". What does that mean? Pete

First see the FAQ subforum thread entitled "Fixing joystick connections not seen by FSUIPC". If that doesn't help, perhaps more information would (as you don't really supply any). -- for example * Which flight simulator program? Maybe FS2004, FSX or P3D? P3D1,2 or 3? * Which version of FSUIPC? If not a currently supported version, please update first. Current is 3.999z9 or 4.949 * LOG and INI files from the FS Modules folder are relevant. You can paste their contents into a message here. Pete

Hmm. I don't anything about "symbolic links", but if they are supposed to be handled invisibly by the operating system they shouldn't make MakeRunways fail. I'll need to have a look at that -- but first I'll have to find out how to make such links. Pete

I need to see the lines preceding this error to get the context -- from the place which identifies the file being processed at the time, Also, I need you to b using the current version, 4.694, so it relates to my code as it stands now and I can use the details being logged. I might also need the specific BGL file which causes it. I would strongly suspect a corruption in the file, but whether it is or not I need to safeguard against it. If you wouldn't mind ZIPping that and sending it to me, do it as an attachment to an email to petedowson@btconnect.com. Meanwhile, see if it works okay with that particular BGL file renamed or removed (you can just rename it as say .BGX in stead of .BGL). Pete