Pete Dowson

Try removing or uninstalling thst CH control manager. This result can be nothing to do with FSUIPC. I suspect the control manager just gets in the way. You should certainly be able to move the rudder without also pressing the toe brakes. Put you feet lower down / further towards you, not near the back. In the axis assignment tab you can tell it to ignore an axis temporarily if it in always being seen first. It sounds like, when you get to calibrate the toe brakes, you'll need to set quite a large dead zone, with no brake operation, in order to avoid braking unintentionally! What does it show on the axis assignment? Are you selecting "RAW" for some odd reason? If the axis is properly calibrated in Windows before using FSUIPC it should have the usual non-raw range of something below -16000 to something above +16000. But thr raw axis value from amnay devices is, indeed, 0 to 255. Pete

It doesn't write to the INI till you press OK. Don't press OK till you've done them all! It is easy! Pete

That isn't related to the common one which was also the most common in FSX-MS. Sorry, I can't help with that specific one. It's more likely related to a corrupted file someplace. Pete

Calibrate throttles properly first, with the correct minimum and maximum. Then you just move both levers to each intermediate position you want to sync, clicking the Sync Pos button for each. Then OK out. There's never going to be an overwrite question for that. I don't really know what you are doing. Pete

Oh dear. I said ONLY the throttle calibration lines, these: Looks like you only set one sync posiition! I've just set 4 on mine, with this result: SyncSlopeThrottle2=5/5,33/34,54/56,85/87,100/102 You can have up to 63 sync points, which pretty much only skips one or two possibile positions, so giving extreme accuracy, if you have the patience. But half a dozen should be enough for even the wonkiest axis mismatch. With only one such position set you are simply not taking much advantage of the facility! Pete

Well if it worked there'd be a series of calibration points, other than the usual minimum, centre, maximum points, recorded in your FSUIPC4.INI. All the facility does is calibrate linearly between each point so that the points match up and interpolation between them is very close. It is a well established facility used and working for years. Seems you are making an error somewhere? Or maybe you are defeating it all by choosing a non-linear slope? Best show me the throttle calibration entries you ended up with in your FSUIPC4.INI file. Just paste them into a message. Pete

That could be your main problem. I don't know it, but many folks have said that it isn't compatible with any sort of direct assignment in FSUIPC. Try without it. That's just a case of simple axis reversal. Please see the options you have in calibration. All axes are available in FSUIPC for assignment, you are simply not recognising which are which. Use FSUIPC's logging facilities to see which ones you need to assign to for your specific aircraft. I can't help you with that aircraft. I don't have all aircraft and there are too many variations. Certainly there's a steering axis assignable in FSX controls (new to FSX, it didn't exist in FS9). The FSUIPC direct tiller axis uses the rudder axis internally. I'm not trying to persuade you to use FSUIPC for assignments. It sounds like you really don't want to, in which case please don't. Pete

How many synchronisation points did you use? Did you choose them in reasonable places for where you see the biggest discrepancies? No two axes are the same hardware-wise. It isn't possible with the sorts of components they use. If your device is really so bad then perhaps you should return it and get a replacement, or have it fixed. But you should also realise that in real aircraft the throttle positions rarely line up exactly for the exact same thrust values. They also are real hardware devices, like yours, often with even more variable components like cables and gears and other parts which waer and strectch differently, as well as being subject to normal physical environmental variations. If you want fictional perfection maybe you need to stick to the graphic ones on screen? ;-) Pete

No, it isn't doing any harm. At most, just delete the registry entries for Prepar3D v1, i.e. HKEY_LOCAL_MACHINE\SOFTWARE\LockheedMartin\Prepar3D Pete

All this sounds like the usual problem of an axis being configured in the Registry or in Windows game controllers as a digital not an analog axis. You need to sort that out first. Go to game controllers, or whatever CH control program you might otherwise be using, and get it working properly there first. Assuming there's no cross-talk in the device the most usual reason for such behaviour is that you have assignments in FS still whilst trying to assign in FSUIPC. You MUST disable controllers completely in FS if you want to assign in FSUIPC. No, best always to disable controllers completely, else FS will automatically reassign. You cannot possibly have any assignments in FS if you want to assign in FSUIPC. There is not way FSUIPC can disable FS control just because you load a different aircraft. It can only control assignments made in its own system. But you don't need to create profiles for all the rest. If mostly you want the same assignments make them for one of the other aircraft without selecting Profile Specific. They will then be the general assignments, applicable to all non-profiled aircraft. Pete

Er, there is no separate "error" saying you need to run Prepar3D at least once. There is just the one error message when it cannot locate the CFG file so it can place or edit the DLL.XML. The two separate complaints you appear to have are surely just one? If not please tell me the COMPLETE text of the message, not just a part. Now look at the log. See this part: Looking in registry for Prepar3D install path: HKEY_LOCAL_MACHINE\SOFTWARE\LockheedMartin\Prepar3D Parameter"SetupPath" ... >>> OK! FOUND Prepar3D! <<< ... SetupPath=F:\Program Files\Lockheed Martin\Prepar 3D v2 Looking in registry for Prepar3D v2 install path: HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v2 Parameter"SetupPath" ... >>> OK! FOUND Prepar3D v2! <<< ... SetupPath=F:\Program Files\Lockheed Martin\Prepar 3D v2\ So, you evidently have a mess in the Registry. It says you have Preapr3D (version 1) and Prepar3D v2, both installed, but both in the same folder!!! Later you see this: INSTALLATION FOR Prepar3D: SetupPath="F:\Program Files\Lockheed Martin\Prepar 3D v2" and later ... No Prepar3D.CFG there Cannot edit the DLL.XML file to activate FSUIPC. which is your ONE error. The problem simply is that you don't really have Prepar3D (version 1) installed despite the Registry saying so. So, FSUIPC4 Install is installing everything TWICE, in the same folder, once for Prepar3D (which it cannot activate) and then again for Prepar3D v2. Everything is going to work despite this mess. In the next installer I will append "v1" to the Prepar3D messages so this is clearer. When the Installer was first done for Prepar3D it wasn't apparent that when v2 came out you'd be able to have both v1 and v2 installed side by side. Pete

Sorry I do not have or know much about the PMDG aircraft. If its own controls do not accept negative values then you will need to find another way. But looking at the descriptions of the controls you are using: #define EVT_MCP_COURSE_SELECTOR_L (THIRD_PARTY_EVENT_ID_MIN + 376) //this is the first one What do you think this actually does? Most things in the list seem to operate by using the mouse system, so the parameter is probably a set of mouse flags. I expect you need left mouse click or right there. You are proably lucky that a +1 parameter looks enough like the correct mouse click for an increment. The second one looks more useful: #define EVT_MCP_CRS_L_SET (THIRD_PARTY_EVENT_ID_MIN + 14500) // Sets MCP course specified by the event parameter This seems to say it sets the course value directly, by parameter. Pete

Are you assigning in FSUIPC or in FS? If in FSUIPC, to which controls? Have you calibrated them properly, following the numbered steps in the FSUIPC User Guide? If so then they should match pretty well. you can use the "sync pos" option on the 4 throttles page to line them up more precisely. See the FSUIPC User Guide (it is covered on page 50). If you are not talking about the calibration to get the same thrust at the same positions, but only about some sort of time delay, then I'm afraid that's down to the response of the model you are using to the controls being sent to it. Try it with a default aircraft and see the difference. Pete

Okay, I've now been able to look at this one. That is, in fact, the same common G3D crash which FSUIPC patched in FSX SP2 and Acceleration. So I'll patch it in FSX-SE too -- but only the current version (62608). The fix will be in the next FSUIPC release, 4.939, probably next week. I've still got Prepar3D 2.5 to deal with. Regards Pete

The second parameter actually documented for the key on its own is 8, so really the KeySend line should be KeySend101=123,8 though you can also use 0, as it says. However, I *think* it should default to 0 if omitted (but i've never tried it -- I tend to follow my own documentation! ;-) ). The other thing is that without direction to your specific program, the keypress will just go to the application on the client PC with the current keyboard focus. Are you sure that was your program? The easiest way to make sure it's directed to your program is to have WideClient actually start your program, using a Run or RunReady parameter, then add a third parameter to the KeySend line to tell it to go to that program, by reference to the parameter name you used to load it. You could use your program's window class name, if that's likely to be unique, plus it's title bar text if that helps. There's also a difference between using UseSendInput=No (default) and Yes. This changes the way the key is sent. Normally your program would only get WM_KEYDOWN and WM_KEYUP messages, but with UseSendInput=Yes WideClient simulates the keyboard more closely and as a result you get messages such as WM_CHAR where appropriate, and all the Windows message flags are set properly. Different programs look for keypresses in different ways. BTW you can log the KEYSEND reception in WideClient by setting Log=KeySend in the INI file [user] section. Pete

Ha! Typical. Always blame FSUIPC! :-( There is nothing in FSUIPC which either touches lights or stops others touching lights. FSUIPC is just a tool for use by client applications and users, and I'm not aware of any aircraft designed for FSX which uses FSUIPC these days. Lights are a matter of proper aircraft modelling and most certainly don't need any assistance from FSUIPC. Pete

Sorry, I can't help with SIOC at all. Don't know anything about it. If you want the equivalent of the tiller offset 3BC4 but for throttles, why not use of of i's neighbours (offsets range from 3BA8 to 3BC6)? There's a whole list of assignable axes there -- the 6 labelled "quadrant axis N" are the 6 axes left to right on a PFC quadrant eg spoiler,throttles 1-4 and flaps. Is there a SIOC support forum anywhere? We don't seem to have many SIOC users visit this forum at all so it may be a long time before you get any help here. Maybe try the MyCockpits forums? Pete

"FSUI.DLL? That's a standard part of FSX. It is nothing to do with FSUIPC. You are in the wrong forum. Regards Pete

Sorry, but I don't understand why this "Elite" software needs to "find the FSX program". Doesn't it just need to see FSUIPC? What does it want to do? Perhpas it interfaces via Simconnect? If so you probably merely need to install the FSX SimConnects -- these are provided in the FSX-SE SDK folder: FSX\SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces There are all three FSX installers there. I'm afraid I've no idea. What does this Elite software do? FSUIPC is not a hardware driver. It merely allows assignments to standard Windows-recognised joystick type buttons and axes. It does understand a bit about GoFlight, but that needs the GFDev.DLL driver from GoFlight too. If your panel is a USB connecting device, or maybe a serial port device, then you could probably write a driver using Lua, as a plug-in, but you'd need to know exactly what you are doing, how to drive the device. Pete

You should really update to 4.938f. Version 4.938c is no longer supported. You can install all versions of Simconnect without one affecting the other or any installed add-ons. You'll find the three FSX versions in the Steam installation of FSX, in the SDK folder (look for Core Utilities Kit\Simconnect SDK\LegacyInterfaces). For full compatibility with add-ons I would advise installing all three -- RTM, SP1 and SP2. No, FSUIPC hooks into inner code within a number of FSX modules, so it has to be changed for every new version of FS. However, it can use any version of SimConnect -- it isn't tied to one. If there's a choice it chooses the latest one it recognises. Pete

Well, the uninstall action failed to remove the Registry entries for FSX. Your registry is now in a bit of a mess as it includes entries for both FSX and FSX-SE, but both pointing to FSX-SE.. I think that either you have not shown me the whole installer log, or you aborted the install when you got the error for FSX! You should have let it carry on. It is only failing on the FSX part, not on the FSX-SE part! Your registry still contains the entry for FSX, which now points to FSX-SE, thus: Looking in registry for FSX install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX! <<< ... SetupPath=C:\Program Files (x86)\Steam\steamapps\common\FSX and it also contains the pointer for FSX-SE: Looking in registry for FSX-SE install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition\10.0 Parameter"SetupPath" Not there, so looking in: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition\10.0 Parameter"AppPath" ... >>> OK! FOUND FSX-SE! <<< ... AppPath=C:\Program Files (x86)\Steam\steamapps\common\FSX\ If you had let the Installer continue it would have worked fine. You are aborting after it says it can't edit the DLL.XML for FSX, NOT for FSX-SE! Why do you care about FSX if you have deleted it? Pete

Yes, the current FSUIPC4 installer does cope with that. Yes, but then the registered path to the FSX.EXE would be as for a parallel FSX-SE, and the Installer would class it as FSX-SE, but in this user's case the path is in the usual FSX registry entry. Puzzling. Until the user finds the CFG file I won't know what is happening here. Pete

Can you find the FSX.CFG file, please? It should be in C:\Users\Lauri\AppData\Roaming\Microsoft\FSX or, just possibly C:\Users\All Users\AppData\Roaming\Microsoft\FSX However, the installer found it in neither place. It is just possible that DoveTail have changed the installation method since build 632608 was released, but it worked fine here with the same paths as FSX. In fact I thought that was the main idea -- to make it look like FSX so most installers would work fine. As you see from FSUIPC's install log, it is treating it just like FSX. Maybe they are now using "DoveTailGames" or "Steam" instead of "Microsoft"? Let me know, please. If they have changed it I can deal with it with a new installer version, but it would be rather annoying for them to have done this. Regards Pete

If this knob really driving an axis, and not providing button presses? Where are you assigning "speed increas"? What actual control? If it's an axis you assign to an axis control, not aan increase or decrease, and then calibrate to get the right range. If it sends button presses then turning the other way should give you a different button number, so you assign that to decrease. All the rotary encoders I've ever used give a different result turned one way compared to the other, so you can make two different assignments. If you are seeing the raw phased changes of two different buttons, then your rotary encoder is one of the more basic ones and is usually connected via a decoding board such as the Bodnar ones which decode the phase differences for you. Otherwise you'd need to do this yourself by programming thepair of button inputs appropriately. There's details of how to do this in the FSUIPC4 Advanced User's guide, about page 24. Look for "two-phase type rotary switches". Pete

It is quite possible that the way the gauge is designed, the switch does not reflect the actual internal setting of the selectors, but those controls are still having the correct effect -- otherwise the mouse click wouldn't send them. If you go the FSUIPC's Logging tab and on the right-hand side enter 0AF8 for the offset, type U16, and check "normal log" below, it will log the internal setting. I suspect to change the visual switch might need the use of local panel variables (L:Vars). You can get a list of those by assigning a key or button to the FSUIPC control for that purpose, or, better, there's a logging facility in a Lua plug-in provided in your Example Lua plug-ins package in FSUIPC Documents. Pete