Pete Dowson

Okay. Thanks. Found a 3.0 version SDK (thank goodness I do regular backups) and rebuilt my DLL with that. It should be forward compatible with 3.1 as well as 3.2 (just tested okay with 3.2). Please download SimConnectP3D30.zip, and place the enclosed DLL into the Modules folder. When you run P3D I need to know only that it says this in the FSUIPC4.LOG file (near the beginning): Trying E:\Prepar3D v3\Modules\SimConnectP3D3.dll Found it: trying to connect and this, a little later: SimConnect_Open succeeded: waiting to check version okay Trying to use SimConnect Prepar3D Then we'll know it is working ok. Incidentally, the version number information (right-click properties) I include in the DLL is the version number of the SDK used to build it. Thanks, Pete

SimConnectP3D3, which was developed for P3D3.2, is only a "stub" as far as I am concerned, but it does embody the library from the SDK related to P3D version 3.2. It must be that Lockheed Martin have made that library incompatible with 3.1. That's a bit worrying. Since you also have FSX installed all you need to do is remove the SimConnectP3D3.DLL from the P3D Modules folder. FSUIPC will use the FSX SimConnect quite happily. Any reason you aren't updating to 3.2? It is said to be much better. I'll see if I can find a version 3.0 of the SimConnect.lib file and re-compile my interface DLL with that. Do you think you could test it for me when I have? I cannot install 3.0 or 3.1 now. Pete

No you shouldn't have to. did you already have FSX installed when you installed FSX-SE, because that's how it looks. If you didn't, and installed FSX AFTER FSX-SE, that might explain the mess. If you have already run FSX-SE (you didn't actually answer that part), then you need to find out where the CFG file it is usding is stored. If it is FSX.CFG then that's actually wrong and an indication perhaps that FSX-SE didn't realise that FSX was installed when you installed it. If you can find the CFG file it is using, and it is "FSX-CFG" then you could make a copy of it called "FSX_SE.CFG" to fool the FSUIPC4 installer to generating the correct DLL.XML. Look in C:\Users\Chris Hayes\AppData\Roaming\Microsoft\FSX-SE and C:\Users\Chris Hayes\AppData\Roaming\DoveTail Games\FSX or C:\Users\Chris Hayes\AppData\Roaming\DoveTail Games\FSX-SE I'm guessing a little here with those names. However, even then, I'd be concerned also about other ramifications -- in particular where FSX-SE is storing its flights and plans. normally with a dual FSX + FSX-SE installation FSX-SE would use a folder in Your Documents called "Flight Simulator FSX-SE Files" (or similar), to keep them separate from FSX Files, but when it is installed as the only FSX it uses the same name as FSX -- Flight Simulator X Files. This difference will affect some of the things FSUIPC can do (as well as other applications, I'm sure). The first thing to do is try to explain and understand what you did to have both FSX and FSX-SE installed if you only intended to have FSX-SE. Can you do that? Did you think you had uninstalled FSX? Pete

You have a good FSX installation, and FSUIPC4 installed fine there, as shown: INSTALLATION FOR FSX: SetupPath="D:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\" Checking version of the FSX EXE: ... Version 10.0.61637.0 (Need at least 10.0.60905.0) with the DLL.XML file being found and updated too: Found FSX.CFG in "C:\Users\Chris Hayes\AppData\Roaming\Microsoft\FSX\FSX.CFG" Now checking DLL.XML ... ... There is a previous DLL.XML, checking for FSUIPC4 section. ... FSUIPC4 section already exists but will be replaced. (for FSUIPC4, without Loader) ... FSUIPC4 section of DLL.XML written okay So, your FSX is fine. However, your FSX-SE installation needs an FSX_SE.CFG file (if it was a standalone installation, with no FSX also installed, it would be named FSX.CFG, but that is not the case here). FSUIPC4 has been installed okay into FSX-SE: INSTALLATION FOR FSX-SE: SetupPath="C:\Program Files (x86)\Steam\steamapps\common\FSX\" Checking version of the FSX-SE EXE: ... Version 10.0.62615.0 (Need at least 10.0.62607.0) But because you have no correct FSX_SE.CFG file, the FSUIPC4 Installer does not know where to place your DLL.XML. Without a DLL.XML file telling FSX-SE to load FSUIPC4.DLL, it cannot operate. Maybe you have not yet run FSX-SE? The CFG file is not made until you do. Pete

It sounds like you are using an old version of the FSUIPC installer, and also still have entries in your Registry saying FSX is installed. Please try again with the current version, FSUIPC 4.949p. This not only puts a copy of its log into the created Modules folder, but also one in the same folder as the Install EXE you are running (or on the desktop, if that's where you run it).. It is ALWAYS available! This change (adding a copy in situ) has been in for several releases, so you must be a fair bit out of date. Without the install log there is no way I can help you. No, it checks both. No. The location is irrelevant. The registry should show the locations of all installed FS's. Pete

I have a test version, 4.949q, which has support for the 737NGX CDU data. Please try it and let me know. I have it apparently working here, but I've not processed the raw data from the CDU myself. It's in the exact format PMDG supply. Download FSUIPC4949q_TEST.zip and read the included READ.ME. Please let me know when you've tested it. Pete

I think this may be a symptom of one of the commonly reported problems with Saitek devices -- the installation appears to create the incorrect Registry entries. I think the Saitek support forum may have solutions posted, probably involving editing the Registry. Please see the FAQ subfurm, the thread "Some Saitek axes only provide partial movement" may be partially applicable too. I cannot help directly, as it is not an FSUIPC problem (it can only work with whatever the device provides), and I don't use any Saitek devices. Pete

The log shows you pressing several buttons. Is this right? 167750 *** Entered Buttons option page *** 192282 FirstButtonChange res=00000003 (0.0, 3) Button 3 231110 FirstButtonChange res=00000002 (0.0, 2) Button 2 231125 FirstButtonChange res=00000011 (0.0, 17) Button 17 232157 FirstButtonChange res=00000002 (0.0, 2) Button 2 again 232172 FirstButtonChange res=00000012 (0.0, 18) Button 18 233078 FirstButtonChange res=00000002 (0.0, 2) Button 2 again 233094 FirstButtonChange res=00000010 (0.0, 16) Button 16 247063 *** Exiting Buttons option page *** It looks like button 3 was pressed first, as it is 39 seconds then before any other button is pressed But then the others are in pairs -- button 2 + 17, 18 and 16 respectively, each pair with a second between. If all that is the result of pressing just the one button then there's something very strange going on with that joystick. Are you sure there's no other software doing this? Did you install a driver for it? If so it might be that is the porblem. I see that you have programmed button 16 successfully: 251328 Button changed: bRef=0, Joy=0, Btn=16, Pressed 251328 [buttons.C182_N6182G] 0=P0,16,C65561,0 251328 FS Control Sent: Ctrl=65561, Param=0 251500 Button changed: bRef=0, Joy=0, Btn=16, Released 253938 Button changed: bRef=0, Joy=0, Btn=16, Pressed 253938 [buttons.C182_N6182G] 0=P0,16,C65561,0 253938 FS Control Sent: Ctrl=65561, Param=0 254047 Button changed: bRef=0, Joy=0, Btn=16, Released and it is working okay. If you want to program 17 and 18 to do the same, just make copies of that assignment in your FSUIPC4.INI file -- the part in Red above, with new line numbers (the value before the =) and 17 and 18 replacing the 16. If the one button is representing 16, 17, and 18 I don't see why you'd want to program them to do different things. But you seem to be implying that this 3-buttons-in-one operation is an intentional part of the device's design? Looking earlier you said something which I now realise is contradictory: If button 16 is obtained on the first press, why do you say you have to press it twice to get the assignment obeyed? The log clearly shows that it successfully sent the assigned control (65561 = Pause Toggle). So it worked on one press. The log actually showed the order to be 17, 18, then 16, implying you need to press three times to get the button 16 assignment actioned. Pete

Well, I would have needed to see the results in the INI file of what you "tried". That simply deletes the assignments for the currently detected axis. So that's exactly what I suggested, deleting the duplicate assignment. What was it you thought I suggested? Having two axes assigned to the same control will always produce conflicts unless you ensure one of the assigned levers is kept parked in a place with no jitter. Pete

No, not at all. WideFS merely extends the FSUIPC application interface to other computers, for running those applications separately. What you are mixing it up with is WidevieW, by Luciano Napolitano. Pete

Stranger and stranger, because in that case all WideFS is doing is opening a port. With "AdvertiseService=No" also set it isn't actually doing anything except that. That's an access violation, meaning usually that the module concerned is using a bad memory address, or one not within its process. I've never heard of USP10, but checking on my system I see I have many copies installed, and many different. There are 8 different versions installed in the WinSxS folder -- 4 for 64-bit, 4 for 32-bit. Then Office 10, 11, 12 all have different versions, and also Visual Studio 10 and 12. All seem to be different, judging by the sizes. I wonder if trying a different one might help? Not sure how you'd do that -- maybe putting one in the FSX folder would get it loaded instead of the one in whichever Windows folder it is loading from. Not really. if the process is terminated by a crash it won't be continuing then to generate another one. That DLL doesn't appear to be part of those, at least not only part of those. I just used Dependency Waker on FSX.EXE, and the dependency on USP10.DLL is nested like this: [ ] FSX.EXE [ ] MFC80.DLL [ ] GDI32.DLL [ ] LPK.DLL [ ] USP10.DLL Not that this helps much, I'm afraid. Not sure what else can be done. I myself am a very heavy user of WideFS (I wrote it for my own use originally, with the first editions of Project Magenta). My cockpit system uses 8 PCs, 6 clients linked by WideFS, 2 of which also have SimConnect linkages.and 1 by a separate linkage (Aivlasoft's EFB). If I could reproduce the problem I might be able to get to the bottom of it, but I've no idea how. I'm sure it must be something in your system. If experimentation with alternative USP10's, or a repair/replacement of it, doesn't work or seem viable, I would suggest uninstalling your Network hardware in Device Manager (drivers too), then re-booting so the system finds it again and replaces the drivers. Pete

No idea at all. How is your button doing different things each time? Is it meant to? Is it in the user guide for the device? All I could help with is to tell you what is happening. For this you need to enable Button logging in FSUIPC's logging tab. Then test and show me the log. Pete

It is perfectly correct behaviour. Button and Key assignments can be both Generic and Profile-specific. All that happens is that the Profile-specific assignment overrides any generic assignments for the same button or keypress. This allows the majority of common controls (Gear, Lights, etc etc) to be made just once and apply to all aircraft whilst those switches and options specific to the aircraft can vary. Axes and Joystick Calibrations are either generic or profile specific. They cannot be mixed, because axes are effectivey active all the time, whereas buttons and eyes only do something when you press them. This is written up in the documentation somewhere. I think if you log buttons/switches (an option in FSUIPC's Logging tab) it will show in the log. But of course you can simply click the button and see. Pete

Ah, thanks. Always useful to have a reference. I believe those two turned out to be Network errors, related to a thread trying ot access Network options already closed. I think SimConnect was also in use across the Network. You say: What about if you don't even start WideClient, so that the Network never really got used? I tried the hotkey and allowshutdown options prior to seeking your help The problem I have here is lack of information. Are there no more details of the crash available, eg. from the Windows Event Viewer? Another thing you could do is to stop WideServer broadcasting, just in case it is only related to that channel. AdvertiseService=No You'll need then to be sure that your WideClient.INI file includes the ServerName or ServerIPAddr, and the Protocol. Pete

Well spotted Thomas! Maybe the problem is related to one of those? Pete

This is a support request, moved from User Contributions subforum. Please always post support questions here, not in the specialised subforums which are for the purpose implied in their titles. You have a Regstry problem with your installed FS. To help resolve that I need to see the Install log. That's why one is made. That will contain all the details. You'll find it saved in the FSX modules folder, and also in the folder where you ran the Installer. It is a text file -- you can paste it in its entirety in a reply here. Pete

Would that matter, for this test? It isn't logging every two seconds. The pair of vales are logged together within a fraction of a second, with the -2471 being prevalent and then sticking for a variable number of seconds, sometimes less than a second. The difference between the two numbers is very small -- 260, just enough to be registered by FSUIPC. You could actually make a small change in the INI file for it to be diregarded. I'm surprised it's enough to see movement on screen. Yes, small jitter is a frequent problem, usually occurring when the point of contact in the lever mechanism is just between the two values. It can be exacerbated by wear and tear, by dirt, humidity, and slight variations in the voltage supplied. Best to disable controllers, not to worry about assignments. So, you did not actually test with Mixture 2 assignments removed in FSUIPC? Looking at your Assignments in FSUIPC I see, in the Generic axis assignments.two axes on the same controller both assigned to "Axis mixture2 set": [Axes] 4=0V,256,F,66425,0,0,0 9=1V,256,F,66425,0,0,0 For the Q400 you have no Mixture2 assignments, and for the Piper PA23 you have just the one:You only have 4=0V,256,F,66425,0,0,0 So, I suspect you have an assignment you forgot about (one of those two generic assignments) and it is that which is setting the mixture without your intention. BTW, after you've corrected this, if you still have that jitter and can't fix the device, you can mask it by ncreasing that '256' value in the assignment to, say, 300. I'd also advise you to enable joystick lettering. With 5 different devices you wouldn't want them to get mixed up just because you unplugged one, or updated Windows, or similar. Pete

I've never had any other reprots of such a problem, and WideFS hasn't changed at all in many years. I'd need you to narrow it down. Is WideServer connected to a Client when you exit? If so, what is it running? What if you close the client Application before closing FSX? What if you also close WideClient first? What if you close down using the WideServer hotkey option ("ShutdownHotKey"(? BTW, it's "Dowson" not "Dawson", and version 4.949h has been superseded by 4.949p. Pete

You have lots of changes going on, earlier for mixture 1 too. And lots of other commands being issued! Without knowing exactly what you did here, I can't make any sense of the log. You ran the session for 6 or 7 minutes, with the first 3 or so spent in doing other things with VOR1 and many other controls. Does it take all that to induce your problem? You say but the earlier part of the log shows both Mixtures being operated in concert, The Mixture 2 alone changes start here, i.e. after nearly 5 minutes into the session. 283063 Sim stopped: average frame rate for last 124 secs = 28.3 fps 283063 Max AI traffic was 59 aircraft 293999 *** AXIS: Cntrl= 66425 (0x00010379), Param= -2731 (0xfffff555) AXIS_MIXTURE2_SET And even then it isn't "nudging every few seconds", is is simply jittering around two values, -2731 and -2471. Jitter is quite common with some joysticks.. There maybe a nearby more stable spot to park the lever. Buttons really don't come into it. It's axes or levers. There's most certainly an input, a jittery one, which is assigned somewhere to Mixture 2. If it isn't assigned in any way in FSUIPC then it is either in P3D or some other software you have running. If you want me to check your FSUIPC assignments you need to post your FSUIPC4.INI filer. Pete

It still isn't making sense. How do you assign keys AFTER closing P3D? Aren't you using the FSUIPC options? FSUIPC doesn't run outside of the Sim. There is no control for "GSX window", so how are you assigning it? If you want F12 to go direct to GSX then you must delete its assignment in FSUIPC! And FSUIPC won't be changing anything back. You have F10, F11 and F12 assigned, but not C X or V. That is what you said you wanted. I still don't see where FS2Crew comes into all this. Pete

Er, sorry, I still don't understand. You assigned keys to WHAT functions? What was the assignment to? Where does "FS2Crew" come in and why is it relevant? FSUIPC doesn't care why you assign things, but it needs to know what you want it to do when you press the keys. You say you "changed the assigned keys to another keys". How? Did you delete the previous assignments first? You can assign all your keys to different functions as you wish. They are all separate. You just can't assign keys to keys as you are implying, at least not directly. You say you assigned keys then closed down and rebooted and changed them. Why? Why not just assign them as you want in the first place? Looking at your INI file, I see you have no keys at all assigned by default, you only have them for the 737NGX. So when you load something else they won't be operative. The assignments are: [Keys.737NGX] 14=223,8,66278,0 .........The `¬¦ key (left of the 1 key) assigned to Rudder trim left 15=49,8,66279,0 ...........The 1 key assigned to Rudder trim right 16=81,8,66695,0 ...........The Q key assigned to Toggle jetway 17=123,8,66317,0 .........The F12 key assigned to Toggle alternate static 28=121,8,66297,0 .........The F10 key assigned to Toggle autofeather arm 29=122,8,66317,0 .........The F11 key ALSO assigned to Toggle alternate static So F10, F11 and F12 are assigned, though F11 and F12 are assigned to the same function. There are no assignments to the Z X or C keys, so whatever they do will be up to P3D or any other program which may be intercepting them. Pete

I don't understand. You are assigning keys to keys? How? FSUIPC has no easy way to save a "conversion" of one keypress into another -- you'd have to assign to an FSUIPC control which in turn sent a keypress. Show me your FSUIPC4.INI file please. Your settings are saved there when you "OK" out of the options. There's no way FSUIPC will lose them, so I suspect you have assignments you are not aware of.. Pete

Version 4.949h is out of date and not supported. The current version is 4.949p. There must be something doing this. What add-ons do you use? If there is nothing assigned to mixture 2 either in P3D or FSUIPC, then it must be either something else sending the mixture set control, or a bug in the add-on aircraft. If it happens with default aircraft it must be the former. Try enabling event and axis logging in the FSUIPC logging tab. Keep the session short, just enough to see the problem, then close down and show me the log. But please update your FSUIPC first. Pete

The details you provide show it isn't FSUIPC causing a crash: Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentException at System.TimeSpan.Interval(Double, Int32) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr) FSUIPC doesn't use any part of Framework. Something you have running which uses FSUIPC is probably the culprit. The Log shows you using LINDA. Maybe there's some incompatible element in that? Does it use .NET Framework? I'm afraid I know nothing about LINDA. So, first see if you still get crashes without it, and then see if LINDA support can help. If it isn't LINDA then, as you say, There's something odd about those add-ons, maybe only in relation to LINDA. FSUIPC does care or know what aircraft you are using. Changing buttons or axes goes through the same code for all. Pete

It sounds like something else is grabbing the mouse inputs first. Did it work with the middle mouse button before you disabled it in FSUIPC's INI file? Are you assigning the space bar to the FSUIPC "mouselook toggle" control, or using the on/off facilities in FSUIPC, or leaving it to the default FS control? Either way, try the other. Maybe the FS keypress is being taken by something else. Perhaps you should show me your FSUIPC4.INI file so I can check your assignments. You could also enable some logging so I can see what's happening. You can enable key/button logging, and also event logging in FSUIPC's logging tab. Pete