Pete Dowson

Well, i wouldn't really lose any view area in that case -- the excess would spread over my ceiling and, worse, over the shiny top of the cockpit, causing unwanted reflections and distractions all over the place! I think I did say somewhere I was projecting at 1080P, which is 1920 x 1080 resolution. Things would be really distorted if Isqueezed that down to 4:3! ;-) Pete

Since all Mytraffic does is install traffic BGLs, which are executed by FS like normal scenery and traffic files, I can't see how that is possible. It sounds like your FSUIPC key file is reing deleted or FSUIPC itself is not even running. Have you checked? Is there an FSUIPC entry in add-ons menu? If so does it show you registered or what? There's no difference in either of those, except that the second one was taken when FS was still running so it is not completed. Evidently WideServer IS running in both instances, so the title bar announcement "... with WideServer" must still be there. Surely if you have problems on the Network, the Wideclient log is more important. The FSUIPC log will also be relevant I should think -- doesn't the RemoteFlight server run on the FSX PC, not on a client in any case? Pete

If you are already using version 3.999z2 or 4.90, you are okay. Else you should update. As I've now said for the third time, and as the Notice you referred to clearly states. Please just go and do it and stop asking the same question. Pete

If you bought keys in 2004, they would have been for FSUIPC3, which is the version for FS9 and before. FSUIPC4 is a new version which didn't appear till 2006 and only works with FSX and later. If you upgraded from FS9 to FSX or P3D, then you also need to upgrade to FSUIPC4. You need to purchase new keys, or go back to fS9 and FSUIPC3 where you old keys will certainly still work! Same for WideFS. Pete

My previous answer still applies. You should be using 4.90 or 3.999z2. Why do you ask in any case? The notice is clear isn't it? Pete

Not if it is still on the same PC you already registered on. But make sure you download and install the latest version -- 3.999z2 for FS9 or 4.90 for FSX/P3D. Is this in Windowed mode? If not, try switching to Windowed mode (ALT+ENTER) to see if they are okay then. If so, then it is a video driver problem. Try updating your video driver. Regards Pete

I'm reaching the point on my cockpit PC where I might have to bite the bullet and reinstall everything. After over two years with a perfectly working setup I'm now suffering from blurries (blurred ground textures) which occur within 5 to10 minutes of normal flying. I really have no idea what's changed to do this. I've tried backtracking my FSX CFG, and my video driver, and terminating as many other processes and services as I dare, yet it still occurs. I've followed all the hints I found everywhere. It's exasperating! Regards Pete

With what? Sorry, you give no context! Depending on which FS you use you should be using version 4.90 or 3.999z2. No earlier ones are supported, and in any case may not work at some stage becase of the signature revocation. Pete

If the Windows driver/game controller offers calibration facilities, yes, because that determines the maximum range whuch can be read by appications. These days most devices either do not have calibration for their axes, or are pretty much defaulted to a good full range in any case. Regards Pete

The SCREEN is 4:3, the PROJECTION is 16:9, so there's lots of room to shift the whole picture up and down to get the horizon in the right place! That's what i actually said if you read it again. ;-) If I tried projecting 4:3 onto a 16:9 screen I'd have lots of horizontal adjustabilty but no vertical adjustability! Regards Pete

If FSUIPC is not registered, and there are no programs using its application interface, then it doesn't do anything. Sorry, but you simply must look elsewhere. If it only happens when FSUIPC is installed then you have something else installed which is using FSUIPC and therefore only does whatever it does when FSUIPC is installed. If you don't know what you have installed I think you will simply have to resort to uninstalling FS and starting again. There's no way I can see your system from here and work out what you've done. BTW since it isn't doing anything, why on Earth are you installing it in any case? You presumsbly MUST have something using it! Pete

Normally it is best to plug everything in, and use FSUIPC to assign only those devices you want in each profile. If you unplug and re-plugin devices into the same USB port, then they will get assigned the same Windows ID, so it gets confusing. If the devices have different GUIDs (strange long number/letter mixes) then what might work is the use of FSUIPC's Joy Letters facility. You tell FSUIPC to assign letters to the devices instead of using Windows numerical IDs. Please see the Joy Letter chapter in the FSUIPC User Guide (see the contents list, about 2nd page). If the devices are always connected then you could swap aircraft and device use "on the fly", without reloading FS, but I suspect you will need to restart FS each time you want to change over if your devices use the same USB socket. This is because ultimately FSUIPC does have to use the ID number. Surely you have another USB socket you can use, rather than sharing one? Regards Pete

They can run together if the "ClassInstance" parameter is used in the WideClient.INI file to change the name of the Window Class being used. Then all you need to do is change all the programs which want to use it to use the new Window Class. Yes, and this is quite correct -- The only possible ways around it are to run a batch file to switch between one and the other, as Torsten suggested, or revise the Apps you are using to link to both, with the Window class in Wideclient changed as I mentioned above. Think of it logically. If two programs are offering exactly the same service, joined in exactly the same way, how can it be decided? The Applications you are using would have to be changed. there's no other possibility whatsoever. If you wrote them then you should have no problem. Pete

That's a strange Windows error message. It doesn't identify the module which failed, nor the error code, nor the offset in the module. Are you sure you got the right entry? That one certainly is of no use at all as it contains no information. I can see nothing wrong with the FSUIPC4.INI file either. I'm afraid it is getting near the point where an FSX reapir might be called for, or even a reinstall. (Ugh). One last attempt. Use this parameter: InitDelay=0 to delay FSUIPC's attempt to use SmConnect. Try 30 (30 seconds), for instance. see if it lasts longer. Regards Pete

It will do unless you remove its entry in the DLL.XML file. And what does the Windows error log show? I did ask before. The FSUIPC4 log shows it is simply waiting for SimConnect. It can't do anything until Simconnect sends it the normal opening sequences. The Simconnect log finishes where it should be recording the Open request from FSUIPC, at least, possibly also CPF_DLL_FSX.dll. It's a bit strange that the SimConnect log shows a last entry at 25 seconds after FSX is started: 25.85651 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.9.0.2" but you see it closed down within 5-6 seconds? That's a lot of difference. In a normal case the Simconnect log proceeds thus: 0.00000 SimConnect version 10.0.61259.0 0.00914 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.04521 Server: Scope=local, Protocol=IPv6, Address=::1, Port=7858, MaxClients=64 0.04935 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=7859, MaxClients=64 1.20673 Panels data export found and set to 20B319D8 5.67281 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.9.0.2" > 12.93797 [ 0, 1]Open: Version=0x00000004 Name="FSUIPC4" I'm suspecting now a corrupted FSX installation in the SimConnect area, but the Windows evidence will help prove this one way or the other. After FSUIPC has made the Open call, it does nothing except await the response, which arrives aynchronously -- over 7 seconds later in my example above. I really don't think FSUIPC can do anything in between. Just in case it gives me any ideas, could you paste your FSUIPC4.INI file into a message please? Regards Pete

Have you tested with a default aircraft. That's always the first thing to do. And where are seeing these values? If you mean that is what shows in the Axis Assignments tab in FSUIPC then thee is something wrong with your device, or more likely its driver. The input value shown in the assignments tab is just wheat is arriving into FSUIPC from Windows. If you mean in the "IN" value on the calibration tab, and you are assigning in FS instead of in FSUIPC, then the most lilely problem is that your sensitivity slider in FS is not at max and/or the null zone slider is not at min. If you mean in the "OUT" value in the 4 throttles page, then you should realise that the normal values for a throttle with reverse zone are -4096 for full reverse, through 0 for idle, to a maximum of 16383 for full thrust. So an output value like that is correct for a throttle calibrated without selecting the "NRZ" (No reverse zone) option. For a normal generic throttle with no reverse range the range can be -16384 to +16383, with -16384 being idle. 0 would then be half thrust. To get the correct values for OUT in whatever mode you are selecting, you need to calibrate correctly. You will see what you see if, for examply, you calibrated the max thrust position with the lever half way up. Regards Pete

Ah, at least a crash is better than a hang, because the Windows error log will show us something. Can you check please? Also, it is now shown that it isn't FSUIPC with the problem -- when you say 'No' to that question fSUIPC isn't even loaded let alone started! If it only crashed on the "Yes" answer it would looks very much like the usual SimConnect timing bug -- please review the FAQ thread entitled "FSX fails to run after FSUIPC4 first installed". Was a new FSUIPC4.LOG file produced when you answered "Yes"? If so you should show it. But something is obviously different. Why "obviously" had to respond "Yes"? If SimConnect is run at all (as it always will be) then it will produce a log when requested! The log you show proves that FSUIPC wasn't even loaded let alone run. The only SimConnect client loaded was PMDG\DLLs\PMDG_HUD_interface.dll. Try without that -- it is more the suspect now. Well the entry in your DLL.XML doesn't say that -- in there it is stated to be in a CPFlight folder within the FSX folder. Seems you've not installed that correctly? I think you've got a lot else going on there than you previously thought! Regards Pete

Hmm. This looks similar to another recent report. Did remove of the axis card enable FSX to load okay? In case it is the problem of an incomplete Registry entry for the device, can you please first download version 4.902 from the Download Links subforum, and see if that helps. If not, please get some more logging for me. In the [General] section of the FSUIPC4.INI file, add: Debug=Please LogExtras=x200000 Then run FSX again and show me the FSUIPC4.LOG. Thanks, Pete

The thread title says you want an "offset". There is an offset for rudder trim position, to which of course you can write 0 to centre it. But then your text talks about assigning a button instead of writing a program to write to an offset. Buttons can be assigned to controls, and the control to set the rudder trim postion is,called "RUDDER TRIM SET". did you miss that completely? Just use it to set 0 as the parameter. Pete

I did have a quick look at the PMDG SDK data (the PMDG_NGX_SDK.h file) and found this: #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_MIDDLESINGLE 0x40000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 #define MOUSE_FLAG_RIGHTDOUBLE 0x10000000 #define MOUSE_FLAG_MIDDLEDOUBLE 0x08000000 #define MOUSE_FLAG_LEFTDOUBLE 0x04000000 #define MOUSE_FLAG_RIGHTDRAG 0x02000000 #define MOUSE_FLAG_MIDDLEDRAG 0x01000000 #define MOUSE_FLAG_LEFTDRAG 0x00800000 #define MOUSE_FLAG_MOVE 0x00400000 #define MOUSE_FLAG_DOWN_REPEAT 0x00200000 #define MOUSE_FLAG_RIGHTRELEASE 0x00080000 #define MOUSE_FLAG_MIDDLERELEASE 0x00040000 #define MOUSE_FLAG_LEFTRELEASE 0x00020000 #define MOUSE_FLAG_WHEEL_FLIP 0x00010000 // invert direction of mouse wheel #define MOUSE_FLAG_WHEEL_SKIP 0x00008000 // look at next 2 rect for mouse wheel commands #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 I know that a lot of dials in the cockpit are adjusted by left or right mouse button use. Maybe the parameters need to be the values above for RIGHTSINGLE to increase and LEFTSINGLE for decrease? Worth a try? Those values are presented in that file for a reason. Regards Pete

I saw that you sad you had FSXX as well, but you chose FSUIPC3 which is only for FS9 and before. As I said, there are TWO latest versions -- 3.999z2 for FS9 and 4.90 for FSX. Choose the correct version! Regards Pete

If FSUIPC is written the log is by its side. If FSUIPC couldn't be written then neither can the log. For FS9 and before you must install 3.999z2 (or later), the current one. All earlier versions will become unusable when the GlobalSign signature revocation is instigated. It seems you've moved FS9 sincce installing it, or merely copied it instead of installing, as you should. Therefore your Registry does not have any information about FS nor where it can be found. It also looks like you don't even know where you put FS9, because the folder ""J:\FSX\Div fsx filer\FSUIPC" is extremely unlikely to be where FS9.EXE is to be found! Whywould you install FS9 into a folder called "FSX\Div fsx file\FSUIPC"? The dialogue you were presented with asked you to locate the FS9.EXE which you run FS9 from. This is further confirmed by this: If you also want to install FSUIPC4 for FSX you need at least version 4.90. Regards Pete

Repeating the same thing rarely makes things any different. Is that the well-known (?) Win8 bug? Don't you think the same thing might happen in FSUIPC too -- after all it is using the same DirectInput interface into Win8? Rather than "clear the FSX axis", did you not try actually disabling controllers in FSX? They do have a habit of getting automatically re-assigned, especially if they "come and go" as appears to be the case in Win8. And if they are still assigned, because of this, when they are "gone" their last fixed read value will stick and interfere with inputs from FSUIPC. That most certainly sounds like interference from another source -- i.e. FSX. But did you ever test them in the air? (See below for reason). Seems so. How are you getting the wrong one? [Anserewed later I think ...] By disabling controllers or by unassigning axes etc? Oh, I see further messages ... I'll add answers to those here too ... ======================================================== Is this with default aircraft? How are you observing the rudder operation -- by the actual graphic? You do know that the rudder movement on real airliners is limited on the ground? For instance on a 737 it is limited to 7% The more sophisticated add-on models might simulate this (as in fact FSUIPC does if you also use the steering tiller). Oh dear. Please check the FSUIPC Installation or User Guide which tells you, early on, how to stop Windows from hiding file extentions from you for common filetypes. That is always going to confuse the issue! NONE of the files will be without a filetype extension. The ".INI" file you saw with that type will probably be a TEXT file, one you saved sometime -- it's real filename is probably FSUIPC.INI.TXT because that's how you saved it. It won't be FSUIPC's doing. According to the INI file you have a Steering Tiller calibrated: SteeringTiller=-16380,-512,512,16380 As you don't appear to have one assigned, what is that for? Try deleting that line or going to the steering tiller tab and pressing the Reset button. If FSUIPC thinks you are using a steering tiller then it limits the rudder action to zero when stationary, increasing to 100% at the threshold speed (default 60 knots). It doesn't limit it when flying -- did you ever check the rudder when NOT on the ground? Couple of points on your FSUIPC axis assignments: You have two different axes both assigned to the generic throttle: 0=0X,256,D,4,0,0,0 10=2V,256,D,4,0,0,0 and you also have two further axes assigned to Throttle 1 and Throttle 2. 2=0U,256,D,9,0,0,0 3=0V,256,D,10,0,0,0 Don't you find the throttle controls a bit, er wonky? I would expect all those to interact with each other! Assuming you fix all this, if you still get problems then logging is the only way to find out what is going on. Regards Pete

:-) Pete