Pete Dowson

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

The controls are actually called Fuel selector left, Fuel selector right, Fuel selector all and Fuel selector off. However, the default 172 has no off position. These controls operate the switch on the main panel, bottom right, and they work fine here. Use FSUIPC's logging to see what you are doing wrong. Enable non-axis Event logging, operate your switch and check the FSUIPC4 log file in the FS Modules folder. If you temporarily run FS in Windowed mode you can enable FSUIPC's console Log and see what happens as it happens. Here's the log I get and can see the switch turning when I use the controls from assigned buttons (I an logging buttons as well so you can see this). 636578 Button changed: bRef=0, Joy=101, Btn=0, Pressed 636578 [Buttons] 22=P101,0,C65957,0 636578 FS Control Sent: Ctrl=65957, Param=0 636578 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000001} 636593 *** EVENT: Cntrl= 65957 (0x000101a5), Param= 0 (0x00000000) FUEL_SELECTOR_LEFT 636702 Button changed: bRef=0, Joy=101, Btn=0, Released 636702 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} 637373 Button changed: bRef=0, Joy=101, Btn=1, Pressed 637373 [Buttons] 25=P101,1,C65956,0 637373 FS Control Sent: Ctrl=65956, Param=0 637373 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000002} 637373 *** EVENT: Cntrl= 65956 (0x000101a4), Param= 0 (0x00000000) FUEL_SELECTOR_ALL 637482 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} 637482 Button changed: bRef=0, Joy=101, Btn=1, Released 638138 Button changed: bRef=0, Joy=101, Btn=2, Pressed 638138 [Buttons] 26=P101,2,C65958,0 638138 FS Control Sent: Ctrl=65958, Param=0 638138 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000004} 638138 *** EVENT: Cntrl= 65958 (0x000101a6), Param= 0 (0x00000000) FUEL_SELECTOR_RIGHT 638216 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} 638216 Button changed: bRef=0, Joy=101, Btn=2, Released 638918 Button changed: bRef=0, Joy=101, Btn=1, Pressed 638918 [Buttons] 25=P101,1,C65956,0 638918 FS Control Sent: Ctrl=65956, Param=0 638918 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000002} 638918 *** EVENT: Cntrl= 65956 (0x000101a4), Param= 0 (0x00000000) FUEL_SELECTOR_ALL 638996 Button changed: bRef=0, Joy=101, Btn=1, Released 638996 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} 639698 Button changed: bRef=0, Joy=101, Btn=0, Pressed 639698 [Buttons] 22=P101,0,C65957,0 639698 FS Control Sent: Ctrl=65957, Param=0 639698 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000001} 639698 *** EVENT: Cntrl= 65957 (0x000101a5), Param= 0 (0x00000000) FUEL_SELECTOR_LEFT 639807 Button changed: bRef=0, Joy=101, Btn=0, Released Of course add-on aircraft might do things their own way, but I would have thought it unlikely for such a simple operation. Pete

Sounds like you are writing values of the wrong type. Both hour and minute values are single 8-bit bytes. If you write values as normal integers you are writing 32-bits, or 4 bytes, so when writing to 023B you will also write 023C, 023D and 023E. Changing the time correctly in FS is not so easy in any case. You really need to build the changed values in a structure and write it all in one go. Note that if you change the time by a minute or more it will cause a reload of scenery. Pete

The difference in ProSim performance, when it is run on the same PC as FSX or FSX-SE (with the same version of FSUIPC) is very significant. Prosim was never really smooth even with FSX, but with FSX-SE it was awful -- 1 second pauses every 3 seconds on all displays. Ugh. But when Prosim is on a WideFS client PC is is gorgeously smooth. I don't know why I didn't try it before. Really nice now. There's nothing FSUIPC can do to make that happen. It sounds like they aren't properly calibrated in Windows. That's the starting point. Also if you are assigning in FSUIPC (you don't say if you assign in P3D or in FSUIPC) you must disable controllers altogether in P3D. I just tested 1.42b3 this afternoon, and I'm afraid it is no better. I've already told Marty. Looks like I'm keeping it on the WideFS client PC. As I said, I should have done that long ago! Pete

Sounds like either you've not calibrated it, or the axis is classified as a digital one not an analogue one in the registry. However, you supply virtually no useful information. What do you see in Widows games controller? Are you assigning in FSUIPC or in FSX? Are you calibrating in FSUIPC or not? Is it different if you change where you assign? Ah, does this mean you are assigning in FSUIPC? Are you seeing a gradual increase from 0 to 255, or jumping from one to the other? If it is gradual there, but jumping between those three values as seen in the Axis assignments tab, then it is the Windows calibration or digital /analogue setting which is all wrong. You need to sort that out in game controllers in Windows. Ha ha! You misunderstand it then. There's absolutely no connection between an FSUIPC installed in FSX and one installed in P3D. FSUIPC is contained along with all of its settings in the Modules folder of the program you installed it into. There's no cross-talk, no interaction. What you are saying only proves conclusively that the matter is in Windows settings for that device. Pete

It certainly isn't FSUIPC.and it seems to be more a question for the Prosim team. However, I am using Prosim too. Not tried with P3D yet (I don't like it at present, though it is getting better). I found that Prosim with the new FSX-SE gave dreadful 1-2 second pauses in ProsimDisplays, at regular intervals, on the separate PCs. The only solution for me was to run the main Prosim737.EXE program on one of the other PCs, NOT the FS PC. Smooth as silk then! Marty, author of Prosim, released last night version 1.42b3, in which he says he has recoded the parts which he thinks might be responsible for this. I have it here for a re-test this afternoon. Maybe you'd like to try that, too, if moving the EXE to a different PC doesn't help? BTW, what's the "Jan 15th" version of P3D? Which year? They do have version numbers! Do you mean version 2.4 or are you Beta testing 2.5? Pete

Well, let's see: 2328877 Monitor IPC:0366 (U16) = 0 2641269 Monitor IPC:0E98 (U16) = 64 2641316 LUA.0: Starting turbulence sound So, the sound was started within 50 milliseconds (1/20th of a second) of turbulence being indicated. That's pretty good! 3745148 Monitor IPC:0366 (U16) = 1 4534232 Monitor IPC:0E98 (U16) = 64 4893783 Monitor IPC:0E98 (U16) = 0 4893783 LUA.0: stopping turbulence sound However, it only stopped when the turbulence stopped, not when you were on the ground. So, let's look at the code yet again: Aha: if (value == 0) and (sndflg == 1) and (ground == 1) then The "if" line says do the following if there is no turbulence, and the sound is playing, and you are on the ground! So, it is doing what it is told. Looks like the sound would never stop once it started if you stayed flying, even if turbulence stopped! The way you have it you have to have all three conditions You obviously need to say "stop if the sound is playing AND the turbulence has stopped OR you are on the ground. So: if (sndflg == 1) and ((value == 0) or (ground == 1)) then Just basic logic! Pete