Pete Dowson

Yes, you need to look elsewhere as FSUIPC only does what you or an application asks it to do. And just having it installed does nothing really. Check your trim settings - rudder and aileron trim. One is probably non-centred. Pete

What's "altimeter increase" and "down"? Do you mean the Kollsman -- setting the QNH? Pete

It works fine here. for example, with pretty much default FSX scenery with the default setting (1500 ft) I get 54431 runways listed on the final screen and the r4 file is about 3.5 Mb (r5 a bit larger). With />5000 as the command line parameter only 13691 runways are shown and the r4 file is down to 1.1 Mb. The other files listing runways are similarly smaler. So you are doing something wrong. All I do is drag a shortcut only the desktop (i.e hold the ALT key down whilst dragging MakeRwys.exe), then in Properties-Shortcut, add the parameter to the end so it reads E:\FSX\MakeRwys.exe />5000 What are you doing differently? What version are you using? Regards Pete

There shouldn't be any problem. Both copies are yours. I think you can buy as many as you like. Pete

FSUIPC only provides an interface to FS, and most complex add-on aircraft implement lots of extra things in their own way. In some cases you can access these through "mouse macros", in others through "L:Vars" ("Local panel variables")., both facilities being documented in the FSUIPC documents. But also in the case of iFly implementations, at least on FSX, there is a 3rd party program called iFly2FSUIPC, which maps iFly capabilities into FSUIPC offsets so they can be manipulated. I don't know much about that utility, and it may not even apply to FS9 versions. See for example http://library.flight1.net/?p=3681 iFly might have their own Forum where you might find more information. Regards Pete

Thanks! Hmm. Very odd. I assume there is still only one of those? Evidently the same device now has two entries in the Registry -- and with two different GUIDs! Which does FSUIPC respond to, 11 or 14? Also odd no #12, when you said "I changed it's id to #12"! The original, according to the earlier INI you posted, was 1=Saitek Pro Flight X-55 Rhino Stick 1.GUID={7DA742F0-A6B2-11E3-8001-444553540000} which would equate it to #14 in your new configuration. Pete

I think that seems to prove a Registry problem, because it is the registry entries for a device which determine that joystick ID. The actual IDs were seen be FSUIPC before (hence the Joy stick identities in the INI file), but then they didn't respond using the associated data. Good. Let's hope so. Could you give me a link to that JoyIDs program, please? I'd be interested in seeing exactly what Registry changes that makes. It may also be worth me putting it as a link in a new FAQ subforum thread on the subject. Pete

I'm pretty sure i must be a Windows problem somewhere -- registry or drivers. FSUIPC uses pretty much the same facilities in Windows as FSX, but probably a different version level - DX8 instead of DX9 I think. But all updates to DX are backwards compatible (else when DX10, DX11 etc came out and got installed FSX etc wouldn't work). With this in mind, I would have advised trying to repair Windows -- maybe update or reinstall the current DirectX package. But one thing which contradicts all this is that some devices are detected, which in turn points away from DirectX problems and straight back at the way the devices are defined to Windows -- i.e. registry. I don't know how you'd sort that out. Is there no help on the Saitek forum at all? FSUIPC can't really do anything unless it sees the devices, and it evidently doesn't see all of them. Pete

Calibration does not "detect" or work with axes but on the resulting FS controls. So, please tell me exactly how you've assigned the trim wheel. The calibration section will always detect changes in whichever control it is designed to calibrate, so you need to be very explicit. Maybe show me your INI file so I can see for myself. That sounds like a faulty wire or bad USB port. Try another, or get the device checked -- the USB unplugged/connected sound certainly means an apparent disconnection. You should also make sure that Windows power management is turned off on all USSB devices in the Windows device management. But power management will not make it look like a disconnection/reconnection. That is either the infamous Windows 8 problem everyone suffers from, or it is to do with Windows power management, as just mentioned. That is surely due to bad connections or USB ports. It cannot be Windows 8 or power management. Pete

The requests from WideClient are being blocked, so it is timing out. That is all. you have some sort of firewall problem I think. The WideServer log might have helped too, but my guess is that it shows no sign of anything attempting to connect. Apart from firewall type problems, the only other thing which could block it is if some other application is already using Port 8002. But that seems very unlikely. Pete

Actually it's the Windows crash report, and as Luke says, it shows the culprit is WEATHER.DLL, not FSUIPC4.DLL. Look again: The other log you supplied is NOT the "FSX.LOG" but an FSUIP4.LOG, and it actually shows a completely successful session and a normal close as you can surely see: The crash is because SimConnect is not resilient to corrupted weather data, and this makes itself felt when FSUIPC is running because it is reading the weather data from Simconnect at regular intervals so it can feed it to client applications. I see you aren't actually using FSUIPC4 for anything yourself -- it isn't registered! So either remove it so it doesn't read weather, or change the WeatherReadFactor in its INI file to zero so it doesn't read weather, or try fixing your weather system. I suspect you have a corrupt file -- maybe wxstationlist.bin in the same folder as your FSX.CFG, or more likely one of the .WX files in your documents\Flight Simulator X files folder. Try deleting them all. Pete

Hmm. Interesting. I've heard of DX video modules in the FS folder messing things up on the graphics front. but this is a first for me with DirectInput. Thanks for letting me know! I'll bear this one in mind! Pete

Yes, I'll be uploading an interim update to stop those repeating unnecessarily. Did you see the other report, above, about a similar (but different) problem, and my reply? Your case is certainly different. Windows DirectInput is returning an error, so that FSUIPC cannot read any of the devices: I don't see the point of doing that -- FSX was released before Windows 7 was thought of, so if you are going to run it in Compatibility Mode at all I would have thought XP more appropriate. The error returned by Windows is: DirectInput8Create failed, return = 80040154 for all three connected devices! I checked the number, it means "Class not registered", which is either a Regstry corruption, or a missing DLL, or an unregistered DLL. I'm afraid I don't know how to fix that other than bytrying to uninstall and reinstall the devices from scratch. Maybe there's help available in the Saitek forum? I notice it is only Saitek devices which seem to have these sorts of problems. Regards Pete

The log is rather overfull with useless repeats of errors on unconnected devices, so I'm making a little interim FSUIPC update which doesn't repeat those. However, the log does certainly show that FSUIPC is successfully reading all three devices fine: 59531 Read joy 0, Buttons=x80000000, POV=-1 59531 Axes: X=65535,Y=65535,Z=33800,R=33284,U=37670,V=24252 59531 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 59531 Read joy 1, Buttons=x00000000, POV=-1 59531 Axes: X=0,Y=0,Z=0,R=0,U=0,V=0 59531 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 59531 Read joy 2, Buttons=x00000000, POV=-1 59531 Axes: X=0,Y=0,Z=0,R=0,U=0,V=32639 59531 S=0,T=0,P=-1,Q=-1,M=-1,N=-1 #0 is your throttle and has values on all 6 axes as you can see the 65535 values for X and Y are a standard indication for a missing axis). #1 seems to only be returning values 0 -- which are specifically returned values, not like 65535 for missing axes. #2, your rudder, has a value for axis V, which seems and dd axis for a rudder, but may be correct? You say you have the throttle and rudder working, but there are no assignments in your INI file, so I'm not sure what you mean by that. Can you clarify? You apear to have no button assignments either, and you haven't answered the question about whether your buttons are seen in FSUIPC or not. Did you actually move any of te axes during the time of the log? You only seemed to have it running for 19 seconds. Do you have some Saitek software installed? The log definitely shows that FSUIPC sees the device and is reading the values using the standard Windows interface without any problems. It's just that the values are stuck at zero. I'm thinking this is an incompatiblity between the Saitek drivers and Windows 8 -- possibly just a more extreme example of the problems n Windows 8 affecting all joystick users. I can only suggest trying to uninstall the devices including any drivers and rebooting so that they are re-discovered as ordinary USB devices without any special drivers. You might also check wth the Saitek support forum to see if there's any help there or others seeking the same. Regards Pete

Replacing a DLL with an identical DLL rarely achieves anything! Well, it certainly shows that the devices are identified from the Registry: I see there's no [Axes] section at all, which is indeed most odd. I've never seen anyone have a result like this. It's as if the USB side of things is completely unresponsive. I know some folks have problems with USB devices on Windows 8, but this is a bit extreme! I notice that there are no buttons assigned either. Have you tried assigning buttons at all? You don't say. You didn't show me the Log file. Have you looked in there to see if any errors are shown? Maybe we can find out what is happening with more logging. Could you please edit the INI file, adding these lines to the [General] section: Debug=Please LogAxes=Yes LogButtonsKeys=Yes LogExtras=xA00008 Make sure controllers are disabled in FSX Then run FSX and go to FSUIPC options and move each axes a couple of times. Also go to the Buttons tab and see if it responds to button presses. Show me the resulting FSUIPC4.LOG file. Regards Pete

Not really, because you contradicted yourself completely earlier -- you said no log is produced because "when I start fsx up, I have about 5 seconds before a fatal error occurs". Obviously you cannot have FS loaded and choose an aircraft in that time So, I repeat. If FS is running with FSUIPC installed then there will be a run-time log file. It is that I need to see. I cannot help you otherwise. It is impossible to help anyone with zero information, surely you can see that? You also need to find the data about this fatal error from the Windows event viewer. That tells me where the error occurs and what sort of error it is. I did ask for this information 4 days ago! Pete

I assume you are using Profiles. The profile-specific settings are all stored in that INI file and so are the names of each aircraft associated with each profile. The aircraft names are kept in its own Aircraft.CFG file which is part of the aircraft file system, so things will simply tie together by name. There's nothing for you to do except make sure you keep a copy of the files concerned. Pete

Easiest thing to do is make a backup copy of your FSX Modules folder. All of FSUIPC's settings are in its FSUIPC4.INI file, but you may also have macro files and Lua plug-ins to consider. If you have multiple controllers (joysticks etc) it would be a good idea first to set FSUIPC up to use joystick lettering instead of numbering, assuming you've not already done that. It's just a matter of changing one line in the FSUIPC4.INI file and running FSX again to get it changed. There's a chapter in the User Guide which explains it -- see the contents list. If you aren't using letters instead of numbers there's a good chance that all your assignments will get mixed up when Windows reassigns joystick numbers. Pete

It sounds like you are assigning a button to send the INCR or DECR both on press and release? Either that or your button is misbehaving and sending two signals. Oh, one other possibility is that you've got it assigned twice, once in FSUIPC and again in FS. Pete

I don't think there are any controls or facilities outside of the overhead gauge itself for much of the overhead local functioning. If you are sticking to default aircraft in trying to implement full hardware cockpit controls I think you'll be continuously frustrated. They are not designed for it, and most of what you see is purely cosmetic. If you want decent 737 systems implemented you either need to use add-on aircraft such as the PMDG or iFly 737s, or use external systems simulations such as pmSystems from Project Magenta. Pete

That is a useful utility to experiment and see the values, but your sole reference should be the Offsets document. I suspect that is where you are going wrong! What interface are you using? Is it Paul Henty's DLL? If so you probably need help using it -- he supports it in the SubForum here so entitled. In C# is <int> an 8-bit unsigned BYTE value? Because if not there's the start of a lot of problems in the first place. Apart from 024A all those offsets are 8-bit unsigned values. And 024A is a 16-bit unsigned value (occupying 2 bytes). An "int" is usually a 32-bit signed value! (occupying 4 bytes). Where does the value 16777217 come from? What's the point of that? Byte values can't be larger than 255 in any case! Pete

Aha! I now see your problem: If you rename the main FS program then the files associated with FSUIPC must be renamed too -- the INI file and the LOG file and the KEY file. It is a VERY bad practice to rename the main FS file -- the Process name is then different, and many add-ons will be confused. Take a look in your P3D Modules folder, see how the FSUIPC4 log and INI files are named. The Key file must be similarly named. I'm afraid I cannot support installations with main process name changes. I hope simply renaming the Key file similarly will work for you, but I cannot do more. Pete

All FSUIP4 needs to be "registered" is the correct detail in the FSUIPC4.KEY file (which is a simple text file) placed in the Modules folder. Nothing else at all. You say you copied yours over from the FSX Modules folder, but evidently that's not true because the details would then appear in the log in the places highlit in the log here: Something else odd about this log. Look: That's the same date and time as the original log you posted BEFORE you say you copied FSUIPC4.KEY across. Please go and check the P3D modules folder. And please don't supply old logs dating before you changed anything! Pete

I'm afraid I've no idea what interface you are using into FS. I don't see anything there referring to any actual FSUIPC offsets. I can help you interpret offsets, but I've no idea what you are reading nor how, nor what that odd value "16777217" has to do with anything. The sim date and time offsets I would always use are the simple ones -- those from 0238 to 024A. If you need to see offsets correctly iterpreted, so that you can choose the right ones, please use FSInterrogate2, as supplied in the FSUIPC SDK. Pete

Please update to a supported version (4.929). You use it to provide parameters to those controls which use parameters, like all of those ending in "Set" which do set a value. If you don'ty understand the control you are assigning to, then either experiment with it to see what it does, or don't use it. They shouldn't be increasing by 10 when pressed singly. Are you perhaps assigning the same to both press and release? FS applies control acceleration when it sees them being used quickly. If it isn't that, maybe it's a bug in the add-on aircraft you are testing it with? and the same answers apply, though you shouldn't expect the altitude to be incrementing by 1 foot! Er, the controls listed for these things ARE the FS controls, same as assigned in FS. The CRS window is also known as the OBS or OBI. Check those controls. Same as in FS -- you start pushback and then press the 1 or 2 key. In FS the 1, 2, 3, 4 keys are assigned to "SELECT 1, 2, 3, 4.", so those are the controls you assign to. You might also get away with using 1 or 2 as the parameter for the Pushback control. I don't remember now if that works or not. For these sorts of questions, which are really about FS not FSUIPC, you can find out what things do by trying them, and you can find out what the true FS names are for controls you can already use, by mouse click or by key press, by using FSUIPC logging. Just enable Event logging n the Logging tab, then 'events' (controls being sent to FS's sim engine) are logged by both number and name. If you (temporarily) run FS in Windowed mode and enable the console log in FSUIPC's logging tab you can see the results in real time. Either it is a faulty lever or you have totally messed up the calibration. Did you actually calibrate BEFORE trying to use detentes? Why are you using detentes in any case -- does your lever have marked positions or real detentes? If not there's really no point, because you still need to guess the position to place it into. Just calibrate it like a throttle lever, etc. You oeration will be exactly the same. The detentes feature are for folks with custom made flaps levers with proper detentes. It's called the "User Guide", and the chapter on calibration has easy to follow numbered steps to good calibration. Most of your questions are really about FS not specifically FSUIPC. The controls you are concerned about are all FS controls and all FSUIPC does is expose them, using the names defined by FS in its CONTROLS.DLL module. The list is generated from FS, not predefined by me, and in fact i don't even know what they all do -- I suspect some do nothing and are just remnants from MS's earlier mistakes. Regards Pete