Pete Dowson

No, never -- FS gauge DLLs (.GAU files) are only part of the code, or often these days only XML scripts. They are parts of FS and rely on the graphics code and main driving code in FS. You'd need to look at external gauge programs. There are a few around, I think -- FreeFD (if that's still around), FsXpand for instance, as well as the complete systems like Project Magenta, SimAvionics, ProSim737 and FlightDeckSoftware. Regards Pete

The calibration is incorrect, then, or else your Aircraft.CFG file is corrupted. Try another aircraft to distinguish between the two possibilities. Pete

Right, because, as it says in the WideFS technical document, Teamspeak does not obey the RW/SB PTT command messages. You have to use keystrokes and "UseSendInput=Yes". No. there are no keypresses involved, only registered Windows messages. No, a keypress assigned to your joystick will send the keypress to FS, not to a Client PC. You must still use KeySend. Not that, either. You need separate KeySend numbers, then multiple assignments to your button at the FS end of things. You can have any number of assignments to the same button, but to do this you have to edit them in the FSUIPC INI file. just find the KeySend 1 and 2 assignments in the [buttons] section and ass two others for, say, KeySends 3 and 4. Regards Pete

2.307 is not actually the very latest one, only the last one to have a documentation overhaul sufficient to put it up on the main release site. The latest is 2.313, in the Download Links subforum, and, if you browse through the list of changes in it, down the page aways, you'll find these relevant items: 1. An additional INI file option "FlapPosLights=Yes" is added. This option should be changed to "No" if you are using older firmware and get flashing Gear lights on occasion. 2. Some other codes sent to the PFC control board which might cause gear LED flashing with older firmware are no longer sent unless one of the Motors or 737NG cockpit options is selected. The problem arose because additional features in later PFC hardware needed specific codes sending which older firmware mistake and do incorrect things. Regards Pete

None of that shows anything useful. As I said, FSUIPC would only be able to reset things to default when it didn't manage to read assumed existing ones. Maybe you had some sort of crash in the middle of an FS session whilst the file was being used. I don't know how it happened, but nevertheless it happened. Files can get corrupted by crashes, power failures and so on, as well as by hardware faults. FSUIPC's INI and MCRO are examples of "configuration settings" files, just like FS's CFG files (FS9.CFG, AIRCRAFT.CFG, PANEL.CFG, SOUND.CFG etc etc), and are maintained through an interface in Windows called "Private Profiles". FSUIPC itself does not perform direct input / output on the files, it relies on Windows. Each line "xxxx=..." and section [xxxx...] are addressed by parameters in calls to functions in the PrivateProfile API in Windows, and it is those which find them and read them or write them, in the appropriate places. I'm sorry such a thing happened to you, and I wish I could help, but like most things you use on a computer it is wise to keep backups. Never trust a single copy on a single computer with any data which takes work to reconstruct. Regards Pete

When you unplug and re-plug in a controller, FS assumes it is a new connection and does its automatic assignments. That can only ever happen if you actually delete the file. FSUIPC never does this on its own. It will only create a default INI file if it cannot find one already there. Somehow you deleted the FSUIPC4.INI file, or else your hard disk is playing up. Regards Pete

But COM3 is actually the REAL serial port, isn't it? The one where your VRI device is located? It looks like SerialFP2 has already claimed it? If SerialFP2 is already running when you start FS, then naturally FSUIPC won't get a look-in! Regards Pete

I moved this out of the "FAQ" subforum into this support forum, because you are asking for support, not looking up a Frequently Asked Question! (You are quite lucky i spotted it so soon -- it could have gone unnoticed for a week or several ;-) ) The message you are seeing occurs when FSUIPC is started and finds FSUIPC already running. That can occur because there are incorrect additional copies of FSUIPC in the main FS folder (whether by the name FSUIPC.DLL or not), or renamed copies in the Modules folder, or, and more usually, because the previous session of FS has actually not yet closed down, and is probably hung. [ Ah, in that case, it is evidently the third reason: your FS9 is not correctly terminating and leaving FSUIPC still running when you try to run it again. Of the three things you are doing, it is actually only item (2), restarting the PC, which is clearing it. After closing FS, use the Windows Task Manager to check running processes. Scroll down to find FS9.exe. End that process forcibly, and next time it will load okay. Something you are using is causing FS9 to hang on termination. That is the cause of the problem. It isn't an uncommon thing, There are a lot of addons which run multiple threads and I think some of them don't get tidied correctly. FSUIPC won't close itself down until everything else has. Anyway, if you can't isolate the cause, the work-around is to terminate the FS9 process via the Task Manager. Regards Pete

There is no difference here with any of that in any version for years. The ServerIPAddr and ServerName are both available as alternatives, but if you specify either you must also specify the Protocol. That has never changed. When you omit the server identify, WideClient gets it from the Server broadcasts, and gets the Protocol that way too, but when you specify the server then it ignores the broadcasts so does not know the Protocol. No, absolutely not. There is no way WideFS or FSUIPC can interfere with ASE's SimConnect connection to FSX unless you are specifying the same ports for both SimConnect and WideFS -- but in that case it would be WideClient which could never connect because SimConnect's ports are open long before the WideServer component of FSUIPC4 is running. It sounds to me as if your Server's IP address has changed. That could explain both of your problems. Nothing of mine can do that! Regards Pete

Are you using the Installer for version 3.98? If not, do so! And do NOT try to register inside FS. Registration is done in the Installer. Please do read the Installing and Registering guide included next to the Installer in the ZIP file. No. and unless you use the current installer I cannot help you. If you still get a problem with the current installer, show me the FSUIPC Install log. That is what it is for. I cannot help with the zero information you are supplying! Regards Pete

There's something seriously wrong with your hardware if nothing happens when you move the lever to the right and left -- obviously both ways should produce input values. are you sure it wouldn't have been the same moving it to the left first instead? The first few values received are normally discarded to remove spurious rubbish when things are first connected or re-connected. You just need to waggle things a little, that's all. "I then moved it to the left and joy 0, X acis#, delta 256, in=-16384, out= -16384" Er ... your joystick is sending NEGATIVE values for left-hand movement? That is unusual. If that is true you'll need to reverse them for use in FSX as it uses negative for right. "I then selected Send directly to FSUIPC calibration." Is this just for efficiency, or do you have a specific reason for using the direct option instead of the default? "I checked the top box below it and selected Aileron from the drop down menu. I then selected the joystick calibration menu 1 of 11, Aileron(direct), items populated were: min= -16383, centre = -16383, max= -16383, in=-16384, out= -16383. I then pushed Reset and then set = -16380, centre=-512, max =16380, in =-16384, out=-16383." All this time you were holding the aileron hard left, to keep the value at -16384? Why? BTW there are two 'centre' values, not one, to give a dead range around the spring-loaded central position.. Now here it goes wrong. If you pressed "Reset" just before, that left-hand button would have changed to "Set", because now the axis is not being calibrated. Er, sorry, that makes no sense. You had the yoke held full left, and then you turned it left *(?) and the OUT changed from -16384 to +16384? That makes no sense. And then, although it was still held left, you turned it left again? On this: When you released it, it stayed stuck full left? If it re-centred you should certainly not then press "min set"!!! Here again, you release it and THEN press a button? Sorry, you seem to have this completely wrong. You are supposed to be calibrating the positions on your yoke. Pulling it one way then the other and releasing it back to centre does nothing useful except test the spring and the centre position. Additionally, if your aileron control appears to be reversed you need to select "REV" BEFORE starting to calibrate, else it will be all wrong. The sounds correct for a normal aileron input, because left SHOULD give a large POSITIVE number, like 16383, NOT -16383, and FSUIPC does not allow you to set the minimum larger than all the other values! That also sounds correct, because you have it all the wrong way around. Are you sure you haven't got the screen so small you cannot see the - signs correctly, or you think you see them where they are not? That's the only way I can think of explaining it. What you appear to be trying to do is calibrate the ailerons the wrong way round. Left and Right mixed up! I'm not surprised. You set -16384 as maximum, so NONE of the other values can ever be higher than that! If I were you I'd delete the INI file entries, as they seem to be confusing you, and start again. This time remember that the NUMBERS must increase from left to right. Also remember that the left and right of the aileron are nothing to do with the left and right on screen, because Microsoft in their wisdom decreed that negative means right. Pete

Very few FS controls use the parameter -- mainly only the "SET" controls, including all the Axis ones assignable in the Axes tab. The "Toggle" controls simply do as they say, toggle the value -- turn it off if it is on, or on if is off. They are really designed for buttons (as on a joystick) rather than latching switches. When using toggle switches instead of buttons with toggle controls the only way really is to ensure all of your switches are set correctly when you close down FS or before you start up again. Alternatively you can "synchronize" them using the mouse on screen to start with. Personally I prefer always to close down the sim in a "cold and dark" state, with everything off, and start up with the default flight also with everything off. There is an alternative method, and that is to use the FSUIPC offsets to switch these things on and off, and assign the switches to "Offset" controls appropriate to the variable or bit being changed. You'd need to download the FSUIPC SDK in order to get the full list of offsets, and work it out from those. In your examples, for instance: Fuel pumps:: offset 3104, 1 byte, 1=on, 0=off, so Assign "press" to "Offset byte set" with offset x3104 and parameter 1 Assign "release" to "Offset byte set" with offset x3104 and parameter 0 Master Battery switch is similar but offset x3102. Alternator switch is similar but offset x3101. Those are easy ones. Some (like lights) are by single bits in an offset, in which case you'd work out the bit value and use "Offset word setbits" and "Offset word clearbits", et cetera. Regards Pete

It depends on how those programs work, what they do and whether they use SimConnect or FSUIPC or neither. You'd certainly need the PCs linked together in a Network. else they can't talk to each other! WideFS is just a way of extending the FSUIPC interface into FS to other PCs on a Network. It is useful for running programs on other PCs, but this will only work with WideFS if those programs use FSUIPC. Of the programs you mention, I don't know FSBuild or TopCAt, so I can't advise on those, but with IVAO the interface is via different programs, depending on which you use (Squawkbox or FSInn? -- no idea what "the eye" is). For FSX neither of them uses FSUIPC in any case, but I think they can be run on a client (networked) computer. You'd need to refer to their documentation for instructions. Every program has a different solution, different requirements. Regards Pete

If you are using standard joystick drivers then they are seen in Windows as joysticks and assigned in FS or FSUIPC. Nothing to do with offsets. Pete

Er ... the way FS is set up, the Minimum value, -16384, refers to full ailerons RIGHT, not LEFT! The full left value is +16384. It sounds like you've set the maximum value as the minimum, so cannot get any other result! Before pressing buttons you need to observe what you are doing. "Minimum" does NOT mean "LEFT", just because following western conventions we read left-to-right. "Minimum" for a number means "lowest", and negative values are considered lower than positive ones. If this is not the problem you have (though it seems the most likely), then some extra information is needed: What version of FSUIPC? What have you done before "the calibration part"? If you assigned in FS there's nothing before calibration to do in FSUIPC. If instead you assigned in FSUIPC, what method did you use, what control to you assign to (by name)? Where in the calibration part are you seeing -16384 and nothing changing? You imply that some other value is showing before you "turn it to the left", but what, and where is the aileron lever then. If it is stuck on the left how do you see it moving to the left? It has to be right-of-left first in order to go left. Is that with FSUIPC calibration enabled or disabled, with FS assignment or FSUIPC assignment? Remember, I cannot see your system from here and I've no idea what you've done nor what you are seeing. I don't even know if you are talking about FS9, FSX (or even FS98, come to that). Regards Pete

Not generally. It uses FSX controls when you assign your own axes. However, yes, it is true that if you write directly to the FSUIPC-defined throttle value axes, it sends these values to SimConnect using the GENERAL ENG THROTTLE LEVER POSITION:n (n= Engine number) variable. That's the whole point of providing the direct offset method -- to avoid the use of FS controls and therefore further manipulation. What CH driver is that, which writes to offsets? Most joystick drivers just allow you to assign the axes as you like. If they are using SimConnect directly, not going through FSUIPC, then I'm not sure what they mean by "offsets". There is no place you can write to make FSUIPC send the AXIS THROTTLEn SET control EXCEPT the location for sending FS controls -- offset 0x3110. You write the throttle value to 0x3114 (4 bytes) and the FS control number (see the list of FSX controls document) to 0x3110 (4 bytes). You can do this with any control. Regards Pete

In the first problem, then, you most certainly have not set the command line correctly in the shortcut you've put into the Windows "startup" folder. Perhaps you should show me exactly what you have there, and what and where you've saved your configuration file. I expect it is something simple like an incorrect folder path. In the second problem, where you don't see the devices in Device Manager, I wouldn't worry about that. Device Manager doesn't see these virtual ports, only the real ones. I have three pairs set in my VSPE: COM14-COM2, COM6-COM10 and COM8-COM9. Device manager lists the REAL com ports for my VRI devices -- COM3, COM4 and COM5. The main thing to check is, when you right click on the VSPE icon in the system tray, so that it brings up the VSPE window, does it show your virtual pair at the top with "Pair" and "Ready", and "initialiszation ... OK" in the bottom part? Assuming your device is on COM3 and one of the virtual pair is COM5, this is okay: [VRInsight] 1=COM3, COM5 and your log does not show any "VRI port n "COMx" failed to open" messages, which it surely would if those ports couldn't be opened. So, provided SerialFP2 is set to find the other port in the virtual pair, you are good to go. The first time you use FSUIPC for the VRI device you probably need to tell SerialFP2 to re-search for the correct port -- it might want to use COM3 at present. If it does, but FSUIPC doesn't see the buttons, then SerialFP2 is using the device's real port, COM3. Check. Look at the little SerialFP2 window. For more assistance try enabling the VRI logging. Add Debug=Please LogExtras=x4 in the INI [General] section. Regards Pete

Actually you do not need a Lua script if all you want to do is program some of the switches and knobs and buttons to do something different. If you assign them in FSUIPC they are not passed through to SerialFP2. Regards Pete

Yes, confirmed. Sorry, there's no other way in that case. Regards Pete

If it is that important to you you can run WideClient on the FS PC as well -- just set the ClassInstance in the INI file to a non-zero value. Then WideClient can run your programs and minimize them. [LATER] I've had another look at the FSUIPC4 code. If the "HIDE" option in [Programs] works for the program(s) you are wanting this facility for, then try downloading FSUIPC 4.665 using this link: FSUIPC 4.665 then using "MIN" or "MAX" instead of "HIDE". Unfortunately, as with 'HIDE' this technique relies on the program initialising according to the settings it gets from Windows when it starts, so it probably doesn't help in your case. To do a fuller job, as with WideClient, involves porting quite a lot of the code which WideClient uses over to FSUIPC, which I am really reluctant to do. The WideClient solution I suggest above does work, however, and having WideClient running as well, on the FS PC, shouldn't be any noticeable overhead on a multi-cored PC. Regards Pete

What is this "mod"? What is giving you an error message? If cannot be VSPE because you said "it loads fine", so I cannot imagine what is is you are then doing. So you are saying you can get VSPE running but it isn't creating the virtual ports? What does it display when you open it? I mean the status of the pair? And if the FSUIPC log shows nothing about the ports, it sounds as if you've not added the VRInsight section into the FSUIPC INI, because if you had, and the ports were not created, it would log that as an error. If SerialFP2 sees it and works it, then it doesn't matter. But I don't know anything about X-Plane. Does that support VRInsight directly? The information put into the INI file is direct from the Windows Registry. The only reason FSUIPC lists the devices with names and GUIDs is so it can track them if you opt to use the device letters for joysticks instead of the Windows ID numbers, which are subject to change. There is no other use for the information, and no point in trying to erase it. Regards Pete

I'm sorry, but I cannot help you at all unless you use a supported version of FSUIPC. The ealriest supported version is 3.98 and that will be a year old soon! Incidentally, even the installer found the FSUIPC.DLL in the Modules folder, so evidently you are looking in the wrong place: Please update before coming back. Regards Pete

What's the difference? As far as I am aware all commercially made popular throttle axes are just simple Windows' joystick axes. Why are you writing to offsets? why not simply use the controls available? What is a "register set" for an FS control? Regards Pete

I find that quite hard to believe, and you provide no information whatsoever. The system of registration with your keys has not changed in all the time it has existed, so you are most certainly not entering all of the details correctly. And there is no way it cannot install everything correctly -- either by finding your FS via the Registry, as it should be able to if FS is correctly installed, or simply by you pointing to where it is when asked. Additionally, if your existing install of FSUIPC is correctly registered there is no reason to re-enter any registration details at all. Unless of course you've reinstalled Windows or deleted your KEY file. Please show me the Installer Log and perhaps I can tell you where you are going wrong? Regards Pete

The calibration facilities only operate on assigned axes. You have to assign the axis to use calibrations -- FSUIPC has no idea what axis you want to use for which control. Just assign in FS (or in FSUIPC if you wish), but don't try calibrations for axes which aren't even assigned! There's no menu "axis control assignments". Look on the left hand side of the Axis Assignment tab. Once you move your axis and it is seen, you need to select one of the three types of assignment methods. Then one of the 4 assignment slots, then you can get the drop down. facilities to select an action for that axis. Sorry, I don't understand that question. As far as FSUIPC is concerned there is absolutely no difference between XP and Win7. None at all. If you don't understand the documentation on how to assign axes in FSUIPC, why are you using it? Is there something you need to do which you cannot do with FS assignments? Please always state FSUIPC version numbers, by the way. If you are not using at least version 3.98 please update first. Regards Pete