Pete Dowson

I don't use CTS/RTS to enable or throttle data, but I've always raised the control signals so that devices which do check for them will accept the data. Ah, good. Pete

Hmmm. Strange. I've received several such reports recently, and yet there's been no change in any of that part of FSUIPC's installation or registration checks. I suspect that some recent Windows updates have changed something in the default security settings which is defeating part of my own checks. When you say you "performed the installation in admin-mode" how did you select this? Did you right-click on the installer EXE and select "run as administrator" from the menu? If not, could you try that and let me know, please. I'm looking at revising some of the checks in both the Installer and in FSUIPC, and will try to overcome this new problem automatically, but so far I've not tracked down exactly why it is happening to just a few new users. Let me know how you get on and I'll let you know what I can do. [LATER] Can you try 3.991, from the Download Links subforum, and let me know, please? Regards Pete

That is no good. I need to see only the Log for a case where it says you are not registered! Pete

Okay, i found a silly error I made. I put the processing of that new parameter into part of the INI file processing which deals with unregistered users only. It's now moved into a part which covers all users. Apologies for that. Please download 4.702 and retry. Here's the link: [uPDATE: it is now 4.703 due to other changes!] FSUIPC 4.703 Regards Pete

See what happens in FSX if you run it without a controller plugged in, and then plug it in. Or move it from one USB socket to another. Or possibly even making any major updates to Windows. I think there are a number of things which could cause FSX to assume a newly connected controller and therefore to redo its automatic connections. This use to happen much more in FS9 and before. Perhaps it isn't so bad in FSX. I don't know. I use all PFC equipment connected via COM ports and driven by my own drivers. Regards Pete

Yes, I understand that part, but in which way are you detecting or deciding it is "not registered anymore"? That's the question I need you to answer. And I also need to see the FSUIPC log file for such an occasion. So it stays "registered" (by whatever method you determine this, as yet to be revealed) for 2-3 days? Then loses it, somehow, ... and gets it back ... how? Regards Pete

I didn't say you did. I said that there is no way possible for FSUIPC to lose your registration UNLESS you reinstall. Just turning off the system and turning it back on again cannot possibly cause the relevant information to change unless there's something seriously wrong with your hardware corrupting the Registry on the hard disk each time. You still have not explained what you meant by Now you contradict yourself by saying the license file still contains your information???? I suspect you are misinterpreting something. How exactly are you determining that What does "losing the key" look like? Because it is not possible and, as you just confirmed, it does not happen. How are you assuming this fact? Why not paste in the FSUIPC log file for one of the occasions you ran FSUIPC and it supposedly "lost your key"? Pete

It may need the control lines connecting too -- DTR probably (pin 4 on a DB9) and maybe RTS too (pin 7 on a DB9). normally the lack of DTR means "disconnected". Regards Pete

Button assigning is surely easy enough. You press the button, see it recognised, and choose an action for it from the drop-down. Axis assignment can be left to FS if the options seem too complex for you in FSUIPC. The axis assignments were really only added to FSUIPC for more advanced users like cockpit builders or those with different setups, eg,. helicopter controls vs. Prop controls vs. Jets. FSUIPC offers the facility to automatically switch axis assignments for different aircraft, which can't be done in FS. The original and main use of FSUIPC is for better calibration and defined responses, which can be done for FS assignments in any case. Reworded? Do you mean re-named it so it didn't load? If so, then, yes, all that means is that the file was for some reason corrupted in such a way that the Installer was unable to correct it. The way you pasted it it seems to have lost all of its new line codes, so to check it I reformatted it and it then looks okay. So I've really no idea what was wrong with it. But I wouldn't worry about it now. Well, yes, a lot of folks get better (more efficient, more effective) results that way, but I think if a "How To" tells you to do that it should also help you to do it. Doesn't it? How did you go so wrong if you followed instructions? Basically I'm of the opinion that you should ever only do things you understand, and if you want to be ambitious and do more, learn about it first. The documentation is complete, it doesn't omit anything, but if you want to do something and don't for some reason understand the wording, ask. It's through questions and answers that the documentation has grown to what it is like today. It can only get bigger, which might be unfortunate, but if that's what it takes, that's what it takes. Regards Pete

What are you trying ot "program"? There's no programming needed unless you are into something pretty complex, and for that there's plenty of examples here, in the User Contributions subforum and elsewhere. And you can always ask questions. For simple accurate calibration you only need to assign in FS as usual and calibrate in FSUIPC following the numbered steps. There's absolutely no programming involved whatsoever. I don't know how you manage to get settings in such a twist, but since everything you changed is stored simply in the text file called FSUIPC4.INI, all you needed to do to start again is delete that file before reloading FSX. Okay. In that case FSUIPc is simply not being loaded. so it sounds like it might be a corrupted DLL.XML file. Find that in this folder: C:\Users\Todd\AppData\Roaming\Microsoft\FSX Despite the name it is a text file, so just paste it here and I'll take a look. Alternatively, rename it (eg to DLL old.XML), and re-run the FSUIPC4 installer -- no need to reregister, just cancel there -- it will make a new DLL.XML file with only FSUIPC4 being loaded. Note that in order to access that folder and file you might need to run Windows Explorer "as administrator" (a right-click option). Regards Pete

Actually you are. I've not heard of anyone ever having "tons of problems". If you thought lots of folks were having "tons of problems" why on Earth did you buy it? Oh dear. Uninstalling and reinstalling FSX is one of the worst things you can do. The uninstaller doesn't deal with some of the components properly -- especially SimConnect, which ends up wrecked quite often. It sounds exactly like a SimConnect problem, but check the Modules folder for an FSUIPC4. LOG file. If there's one there, show it to me (paste into a message). If it isn't there then FSUIPC isn't being loaded. In that case please show me the Install log instead. But first make sure you are using the version 4.70 installer. I cannot support anything earlier than that. SimConnect problems will affect very many add-ons, not just FSUIPC. Having uninstalled and treinstalled FSX you've let yourself into a potential Windows reinstall problem -- eexactly what I found I had to do to fix things in the end. It isn't anything to do with FSUIPC. Regards Pete

No, it's there okay: The Cirrus: Vendor=0689, Product=C200 (Version 2.0) Manufacturer= Precision Flight Controls, Inc. Product= PFC Cirrus II Pro The avionics: Vendor=0689, Product=C201 (Version 2.0) Manufacturer= Precision Flight Controls, Inc. Product= PFC Avionics Adaptor It's the GoFlight stuff that isn't seen here! So, since the code in my PFCHid driver does the same thing as this HidScanner program in order to determine what's connected, it sohuld see both Cirrus and Avionics stack, but the GF driver shouldn't see its device. Curiouser and curiouser ... Pete

Hmm. Strange. Something else is going on then, apart from what we saw in the Logs. Can you repeat the test but with SimConnect logging enabled, please? See the FAQ subforum for details. ZIP the resulting log and send to petedowson@btconnect.com. Regards Pete

You posted the exact same message THREE times. I'm not going to answer three times, so I've deleted the other two. Strange. Maybe the Vendor / Product codes clash? Does it work if you remove the GFDev2k4 module so it doesn't run? If so it might just be software, but otherwise it's to do with the USB interfaces. Try running my little hidScanner program HidScanner, and show me the log file it produces. I think this is probably a question for PFC. Let's see. Regards Pete

Well the only options related to trim or elevator position are still in FSUIPC3 and also in FSUIPC4. Maybe experimentation will find the right option for you? But I still can't understand how the trim is so far out from A/P use - the FS A/P uses trim to do its job, so it just MUST be correct. Are you sure it isn't an add-on aircraft doing its own thing, without using trim? If so, your FS trim might be left however it was last time you used it. What happens if you use your rocker to get a load of nose up trim BEFORE releasing A/P? Pete

I've not tested it yet -- haven't got SB4 installed at present. So before I put 4.701 up in the Download Links subforum can you test it for me and let me know, please? Download FSUIPC 4.701, copy the DLL into your FSX Modules folder, then add this line to the [General] section in the FSUIPC4.INI file: NoActionOn7B91=Yes Note that this won't stop the FSUIPC-supplied controls for SB4 working, only causes FSUIPC to ignore changes to 7B91 from external programs. Let me know if this does the job. It isn't an obvious facility internally -- the ClientData access to the SB4 settings via SimConnect are asynchronous, so it definitely needs testing. Regards Pete

Oh, i don't need to see a video. I've just not heard of it -- I don't know much about Airbuses I'm afraid! You can use a bit in the free user area, 0x66C0 - 0x66FF Have you looked at Lua at all, any of the provided examples, for instance, or the many offerings in the User Contributions subforum? I'd rather help YOU solve it rather than simply do it for you, because then you (and others reading this) will understand it and be able to develop other things as and when. In particular, you need to find the A/P Master offset. This is easy enough for the default A/P -- it is 0x07BC which will change from being non-zero to zero when you switch it off. But if you are using an add-on aircraft with its own A/P it might not be easy to determine the A?P going off. If it is the default A/P you'd use the "event.offset" function to detect when it changed. This would call a function where you'd test the result (the "value" provided) for zero (e.g. "if val == 0 then ..."), and if so set the bit in your chosen LED offset so it lights, then sleep a while, using ipc.sleep(number of milliseconds), then clear the bit, sleep a while, set the bit, sleep a while, clear the bit, sleep a while, ... for the number of flashes you want. Adjust the sleep times for the flash length and gap length you want. You'd set and clear the bit using the ipc.setbits and ipc.clearbits functions. Finally, you'd save the resulting Lua file into the FS Modules folder as "ipcReady.lua"so it starts running when FS is ready to fly. Or if it's only for a particular aircraft you'd name it something else and put its name into the FSUIPC INI file in an [Auto ...] section bearing the aircraft's name or a Profile name, if you are using profiles. I'll answer questions and help you make it work, but I won't write it for you (though i see I nearly did! ;-) ). Regards Pete

No. FS aircraft panels are part of FS. There's no separate program for each panel or gauge, they use the graphics and logic in FS's code. Without FS underlying them they couldn't exist. Regards Pete

Was there? That's news to me. Why would it need to? The AP uses trim to trim the aircraft, so when it is disconnected the trim should be set as needed for that situation. Maybe you are getting mixed up with these facilities, neither of which does what you mention, mainly because there's no way to "maintain elevator trim" without leaving it where it is -- in other words it maintains itself in its own position. DisconnTrimForAP: When this option is enabled, FSUIPC disconnects the analogue elevator trim axis input to FS whenever either the FS autopilot is engaged in a vertical mode (altitude hold or glideslope acquired), or a program, gauge or module has disconnected the elevator axis via FSUIPC (offset 310A). Note that the setting can be overridden for specific aircraft which have specific FSUIPC joystick calibrations by setting this parameter differently in that [JoystickCalibration …] section. ZeroElevForAPAlt: controls the option for FSUIPC to automatically centre the elevator input each time the Autopilot altitude hold mode is changed (switched on or off, including AP engaged changes too). This option can be operated inside FS on FS2004, but if needed on earlier versions must be enabled in the INI file by setting this parameter to “Yes”. Note that the setting can be overridden for specific aircraft which have specific FSUIPC joystick calibrations by setting this parameter differently in that [JoystickCalibration …] section. I never withdraw facilities unless they are impossible or unreliable. I really think you are thinking of something else, especially as what you ask is simply not needed -- FS doesn't change the trim when you disconnect the A/P. Are you using an analogue trim axis? If so you'd need to make sure its position agrees reasonably closely to the A/P set trim position. In my cockpit that's done by the A/P motor controlling the trim wheel, but without motorised trim you'd need to try to do it manually. Really, if the trim axis is stable it shouldn't change the trim position set in FS. However, since you will not doubt need to make some trim adjustments subsequently you'd still need to keep it in a reasonably close place to the A/P's setting. Regards Pete

If, despite it "not being a good idea", you want to experiment with axes on a Networked PC, it can certainly be done with a Lua plug-in placed in the WideClient folder. If you are interested I can make an example Lua program, which you would then need to modify to suit your specific device. It would be reading the joystick like a driver, accessing the raw HID (Human Interface Device) values. Regards Pete

Should it? What aircraft is this with? Where is this LED? Since I don't know what device you are using which has an LED I can't say whether it is easily drivable from Lua or not. Regards Pete

Ah, nasty! Glad you got it sorted. Pete

You don't need to. All versions of the FSUIPC Installer for the last 15 months accept a different email address for WideFS compared to FSUIPC. Please read the Installation and Registration document included with the Installer in the FSUIPC Zip. Note that you should be using FSUIPC version 3.99 or 4.70 by now. No earlier versions are supported. Regards Pete

Good. Thanks for letting us know. Regards Pete

Without knowing what you are actually doing I can't really advise. Just installing and registering FSUIPC does nothing to any controls. You can calibrate in FSUIPC whilst still assigning in FS, and this is the easiest and most usual way. If you assign in FSUIPC there are two different ways of doing so and both then need also calibrating in FSUIPC, and always disabling in FS -- you must never have the same axes or buttons assigned in both. Whichever of the three ways you assign, when calibrating in FSUIPC you must follow the numbered steps in doing so. You can achieve very accurate results to suit your wishes and the aircraft you fly, but FSUIPC is a tool. The results depend wholly on how you wield it. Pete