Pete Dowson

You should be able to balance the toe brakes without needing to also adjust with the tiller. It's quite often that to pedals don't equate exactly, but rather than use the tiller just apply more or less pressure on the relevant toe brake. You can also apply a "slope" to make them less sensitive initially, progressively more severe. Pete

If it is only a matter of writing values to defined offsets, then it is easiest just to assign buttons or keypresses to "Offset byte set", or "Offset word set" (etc) controls, specifying the offset (x....) and parameter to be written. I assume Eric's documentation suggests this. Regards Pete

Ah, thanks for the clarification Ian. So for the OP the answer is "no, you can use SimConnect instead". Pete

The most likely cause is some sort of corruption. If it were FS2004 or FSX I'd say it points to a corrupted weather (.WX) file, but i don't recall whether FS2002 ever had these. I did ask to see the LOG file, which will show where things were at at the time it crashed. That might help. Can I ask why you are trying to use FS2002, which after all was one of the poorest versions of FS (along with FS2000)? Even FS98 was better than those two stinkers. And with it being so old, I'm not even in a position to help much really. Let's look at the log anyway. Regards Pete

I have no idea what most of your post is all about. I assume it relates to some odd interchange you've had on another forum. However: If Plan-G (a program I do not know and do not use) uses FSUIPC to interface to FS, then, you would most certainly need a licensed copy of WideFS in order to use it on a compueter separate to FS. But you would not need to use WideFS on the same PC as FS. That's it. There's really no more to say. Regards Pete

The complete list of control names and their numbers for FS is provided in a document (*List of XXX controls") in your FSUIPC Documents folder. If add-on aircraft add to this, then their documentation needs to provide the list. There's no way FSUIPC can guess them. Regards Pete

If you are calibrating in FSUIPC, set FS sensitivity to maximum and dead zone to minimum. If you are assigning in FSUIPC, the FSX sliders have no effect in any case. If you are still assigning in FS then the sliders should stay where you set them, for sure. More so that the FS method, certainly. The FS "sensitivity" slider simply reduces the effect of the axis -- so instead of it operating from full down to full up (for instance) it only operates for part of that range. This makes it MORE sensitive in the range it allows control over, but doesn't allow you to reach the extremes when you need them. The "slopes" facility in FSUIPC calibration allows more sensitivity in centre and less on the extremes, or, more usefully, vice versa (the flattened central area i mentioned). Just choose a slope and try it. For general use with most aircraft a slightly flattened central area seems best to me. You can't do that with FS alone. Regards Pete

Whether there is a "dead zone" or not is completely up to you in your calibration. The main use of a dead zone is simply to ensure that when you take your hands off the controls the position the controls go to is always neutral ("zero"). If your controls always return to exactly the same place when you release them, then you are very fortunate, and you really need no dead zone. What you might be confusing it with is sensitivity. To get a graduated sensitivity, with movements near the centre being worth less in terms of control surface movements, then you should be using a slope with a flattened central zone, maybe instead of a "dead zone" altogether. When you say This must be something to do with the way you are interpreting things, because there is never any change in the calibration or dead zone imposed unless you actively change it. Maybe you are approaching at too high a speed, which would certainly make the effect of control movements more severe. Also, on approach you are using more flaps than during takeoff, and with more flaps (= more wing surface) everything becomes more exaggerated. Regards Pete

There's really no way I can help with such an old version. Please update to the current version and try again. The CFG file only stores your settings. When you try with a supported version it will be the FSUIPC LOG which is relevant, not your settings. And also please then explain what "the screen shifts load and fails" actually means, because it doesn't make any sense to me I'm afraid. Is this at all related to fSUIPC in any case, and, if so, how do you know? Regards Pete

A rotary control usually sends a "button press" and a "button release" alternately, so just assign the same control to both press and release. Pete

There aren't "tutorials" as such, but if you are using a .NET programming language I'd recommend you refer to the subforum FSUIPC Client DLL for .NET. Otherwise you will need the FSUIPC SDK which is available in the same places as FSUIPC (here and over in Schiratti.com), or maybe you want something simpler and more immediate, in which case check the Lua plug-in facilities for FSUIPC which are documented in your FSUIPC Documents folder (within the Modules folder). Regards Pete

If HIDmacros can read the buttons, then the device is properly defined as a HID (Human Input Device), but just not completely as a Joystick. FSUIPC does support generic HID devices, but only through the Lua plug-in system. You need a small Lua program to decode the USB inputs, using the com library HID functions. They will do most of the work for you. Check the HidDemo.lua example plug-in provided in the Lua plugins ZIP in your FSUIPC Documents folder within the Modules folder). Regards Pete

Sorry, but there's nothing there which points to anything related to my software. In fact it doesn't even identify the module of FSX which is involved, so I can only think it's something outside, like a driver crash. You'll need to try to idebntify what it is that has changed, or go through a process of elimination, trying FSX without anything added and gradually add things. Regards Pete

Working a bit in the dark here, without being able to reproduce it, but I suspected it might be related to the thread execution terminating naturally at the same time as it is being killed for the next try. I think there's a small chance of an overlap there where some things are already closed. I've added more critical sections to try to lock those out from each other. It's a bit of a trial and error process with your system being my only way of testing. Sorry, but could you see if you can make FSUIPC4909b crash, using the same Luas? Thanks! Pete

All that means is that your default flight, loaded when FS starts, or, by now, probably all other flights you have created, has the magnetos set thus. All you need to do is set everything the way yyou want, THEN save a flight and say it is to be your default flight. I've always started off completely cold and dark, with all switches off 9except parking brake). Where did you get such a format from? Have you not seen the examples in the Advanced User's guide, in the section "Macro Controls"? To start with there's a K for Keypress or a C for control missing -- in your case a C in fromt of the control numbers to show it is a Control you want, not a Keypress. Second, there are no examples of adding a parameter by "=0". ALL the examples, ALL of the button and key assignments in your INI file, have parameters set by ",0" -- i.e. a 'comma', not an 'equals'. So, try: [Macros] 1=Cold_and_dark 1.1=C66023,0 1.2=C65794,0 BTW you do know Control 65794 is "Pause On" don't you? Not related to a cold and dark cockpit start. Regards Pete

Drat. I thought I might have nailed it. I wish I could reproduce it here. I'll have another look in the next few days. Pete

You'd need to have a small Lua plug-in in the Wideclient folder which read the log file as it was written and display it locally. There's a "wnd" library in the WideClient Lua implementation which can display scrolling texts. You'd need to share the FSX Modules folder so it vould be read, of course. If that's all then just have a very small Lua program which reads the offset containing that memory value and displays it using the "display" library, which does formatting etc for you. Pete

Now I am confused. You said "When I was running Wind XP COM 9 was the suggested port.", but now you say you did not use a COM port name but \\.\WCEUSBSH001? How is this? Nor do I, I'm afraid. All I'm aware of is what was supplied by another user, i.e. this: Maybe this is where the "COM9" confusion comes in - the port at the device end? All I can suggest is to try the sccessive numbers, 002, 003 etc as suggested. In fact, if the "Port_#0001.Hub_#0002" relates to the name to be used, the Hnnn part might well be H002 after the Hub number. Worth a try? [LATER] After a bit of Googling, it transpires that the device naming "WCEUSBSHnnn" derives from the use of a Windows USB driver "WCEUSBSH.SYS",, which is not included in Vista or later. Apparently these now use WinUSB.sys. Now I've no idea how to determine the device names it needs. Maybe \\.\WINEUSB001, etc? I'm afraid I have no suitable devces to try this out on. Reading further, it looks like the device name might be found in the Registry, but it's in a section according to its GUID and I've no idea how you'd find that. Maybe search for "Port_#0001.Hub_#0002" in the Registry? Or maybe even that is the name already, i.e. \\.\Port_#0001.Hub_#0002 ? Regards Pete

But it does work. The fault is in your system. Even though you are not and don't want to be at all friendly, I would try to help you isolate it and fix it, but since you appear to simply refuse to supply any helpful information whatsoever I'm afraid you cannot be helped. Pete

The list of FSX controls which FSUIPC has installed in your FSUIPC Documents folder lists them all, and those are the same names listed in FSUIPC's drop-down assignments lists (though the latter also includes FSUIPC's own added controls and those for Lua and Macro files). The example in post #5 was "View forward right" which you will see in both places. The list document provides the numerical equivalent which is what you'd use in a Lua plug-in, and is how the FSUIPC INI file records your assignments. FSX uses the name strings instead in its XML file recording assignments. I'm afraid I'm a bit out of my depth with FSX's panel display handling, but I would have thought the Panel ID open and Panel ID close controls would work without loading multiple copies. There's also a Panel ID toggle control. Pete

Ask again? Not seen a previous one similar. "Oxford English Dictionary: discrete: adjective: Separate, detached from others, individually distinct. Opposed to continuous." The affect is to have less separate positions which do anything. For instance if the range of input is -16383 to +16383 and the "Delta" is 8192 then you'd only get 4 or 5 distinct values through the whole range. Okay for a 4-slot flaps axis but not so good for fine aileron or elevator control. Throttles are okay with less resolution than the main three surface controls. Pete

I don't know anyone not at your PC could suggest' a port blindly. The association of port numbers to USB or RS232 sockets is specific to the hardware arrangement, the number of other devices also connected, and, as you've found, the version of Windows. To find out where it is connected go the the Windows' Device Manager (in the Control Panel) and open up the entry "Ports (COM & LPT). If there's only one entry, that's probably it, but one way to be sure is to unplug it, refresh that display (Actions menu, scan for hardware change) and see which one has disappeared, the reconnect and rescan to be sure. Pete

Not as far as FSUIPC and GPSout is concerned. All it needs is the port name so it can open it through Windows. If Win7 isn't seeing it as a COM or USB device, then it most certainly can't be connected to. If it is a COM device, then use the port number you find. USB devices acting like COM devices usually have the sort of name I mention as an example in the documentation -- but the name in Win7 may well be different to that in XP. 4.88 is no longer supported. You should be using 4.90 or later now. You don't purchase a specific FSUIPC4, and only current versions are supported. "Suggested com port"? That's rarely the same from one PC to another let alone different versions of Windows. Haven't you checked to see what it might now be? Yes. The COM port might be different. But no, no difference as far as GPSout itself is concerned. Pete

Thanks ... I am actually a frustrated real world flier, having done the training to the point of needing a medical certaificate to go solo only to discover I have Retinitis Pigmentosa, causing deteriorating tunnel vision and preventing that ambition going any further. Hence the simulation instead. But I've been a programmer since leaving uni in 1963. Regards Pete

If the device isn't seen by Windows and assigned either a COM port or a name, then there is no way GPSout can send anything to it. Maybe the name or port is different? Or maybe Windows is autoloading some other driver software which takes over the device, as an interface sepcific to that sort of device (may to that "wescomm" program you mention?). In the latter case you'd need to find it and terminate it too in order to free up the port. I remember I used to have to do that with a Garmin device I had once. Sorry, I can't be much more help. There will be a way, but I can't find it from here. BTW running anything other than installers "as administrator" is rarely necessary and often a bad idea. Regards Pete