Pete Dowson

Well, yes, it would be internal, but only the default settings. The parameters used are customisable via the documented offsets. Of course I can change the defaults if there are better ones. Can you point me to where I said what you say I said, please? I'm still a bit confused on this. It is an area I haven't worked on for years. Regards Pete

Blimey, I only just noticed. This thread started years ago! And it has the documentation included. I'll have ot print that out as i don't seem to be able to find my copy! ;-) You hit the nail on the head about the 90% limit being to low. The 727 i fly needs about 97% to maintain a good climb. Okay. Is that a default in my settings, or in the aircraft's CFG or AIR files? Can you point to where you read that, please? I'm a bit lost here. (Old age and memory -- they don't mix!) I'd be delighted to change a default built into FSUIPC4 if a new value (compared to FSUIPC3?) is better, but i need help in getting back into this particular area, please. Sorry. Regards Pete

Really? That's a surprise -- the pitch and bank controls worked well last time i looked, but I gave up on the speed control. Just couldn't stop the oscillations. There's no "INI" parameters for any of those functions. It's all via parameters in offsets. You'd either need to write an application to interface to FSUIPC tomodify the offsets, or possibly a Lua plug-in. At the very easiest it might be a matter of an FSUIPC "offset" control to change a parameter, but I've a feeling that's not on. I really don't remember much of this in any case. Do you have the documentation? It was never openly published as far as I recall, and it was a long time ago I messed with it. If you don't have the internal details I'll try to find you a copy, as a start. Regards Pete

If FSUIPC4 is not able to operate for any reason, there will be entries in the FSUIPC4.LOG file to say why -- that is assuming it actually gets loaded. It is Simconnect's job to load modules, and that is controlled by your DLL.XML file. Next time you don't see FSUIPC in the FSX Add-Ons menu, please see if there's a Log file and if so let me see it. You can paste it into a message here. Are you running those programs on a Networked PC? Are you saying that WideFS sometimes doesn't connect, or that FSUIPC doesn't run? There's a lot of difference and entirely different things to investigate depending upon what you mean. Sorry, what "add-ons entry on the task bar"? By "task bar" do you mean menu bar, the menu in FSX as called up by the ALT key? I really cannot imagine what it is you mean by "again not systematically: entries for different planes". What have planes got to do with it? You've not mentioned plane selection before. And what are these things you "click on"? words or pictures or what? Regards Pete

You did already post this and you have two answers already. Please refer to the thread you started entitled "Control conflict on FS2004". Pete

Sorry, what is the "Quick Set Minima" button? What is it supposed to do? I don't like bouncing folks back and forth between two suppliers, but I would need a lot more information to help than "it is an FSUIPC4/WideFS issue"! No one from PM has asked me about such a button -- I've never heard of it, nor any problem with anything from PM. So please do go back to them and ask them to explain, or even contact me rather than push customers off with no help whatsoever. Regards Pete

Sounds like one of the newer ones. The PFCFSX driver is only for the serial port consoles. Most of the new stuff coming out of PFC uses new controllers and USB connections. I think you need to go to PFC support about this. They should be able to provide you with drivers -- in fact they should have come with the unit. Or was it purchased to work with X-Plane or something else instead? Regards Pete

You most certainly have the assignment to the Gear in FS. You probably have not used the FS assignments dropdown to check all instances of control devices and all button assignments there. If you can't actually find it, then Andy's method should do the trick. Pete

There's no way merely installing FSUIPC will affect an add-on aircraft which doesn't use it. You have to actually register the installed FSUIPC and set options in it, such as assigning and calibrating controls -- otherwise it isn't doing anything except at the behest of programs using it. If you have registered it and used it for your aircraft controls then it is likely that the settings you have made suit the 757 but not the 747, in which case you need to use the aircraft-specific settings or try the Profiles facilities, so that FSUIPC automatically makes different settings for different aircraft. Incidentally, version 4.53 is now out of date. The currently supported version is 4.57 (with an interim update for that also available). Regards Pete

You have an FSX SimConnect problem. This specific error normally occurs when you have a copy of SimConnect.dll placed incorrectly. The only places these should be are in the appropriate Windows\WinSxS folders, or possibly in other folders not anyway accessible from FSX such as its SDK. Please check the contents of your FSX folder and FSX\Modules folders. There must not be anything to do with SimConnect is either, no files by any name such as SimConnect. You would be well advised to update your FSX installation in any case -- install the SP2 update, which fixes many SimConnect problems. Or invest in the Acceleration update which includes SimConnect SP2. Incidentally, there might be more helpful information in the FSUIPC Install log, which is also in the FSX Modules folder. Regards Pete

Right, because FS doesn't simulate transponder modes. normally the only reason to want to connect buttons or switches up for those is to drive on-line ATC functions, like your 7B91 offset access. Okay, as long as the intention was for all the keypresses to act on the one button/switch change. It was only that part I didn't understand. Seems the cockpit needs multiple keypresses to select the Transponder settings you want. Well, I think it must be getting ignored by whatever it is receiving the keypresses? Perhaps they don't like a second selection so fast after the first? Anyway, the log should show what is going on, if you select the options I mentioned. Regards Pete

I've installed IPX/SPX, and tested FSUIPC4, and I'm afraid it doesn't look as simple as a mere protocol installed. Here's part of my WideServer log: So we must look elsewhere. One other possibility I just thought of is that SimConnect might be hanging because somehow it's use of TCP/IP is conflicting with that of WideFS. Do you have a "SimConnect.xml" file in the folder where the FSX.CFG file resides (check the FSUIPC4 Install log if you are not sure where to look). You would need to make sure that the parameters provided to Simconnect do not tell it to listen on the same Ports as WideServer -- 8002 and 9002 by default. Regards Pete

If your Windows system is on your C drive, then that is where the FSX.CFG file is located. The one you might find in FSX's own folder is just a dummy, a template, not the one generated by FSX from your option selections, and used each time you run FSX. Provided you installed FSX correctly and didn't mess with its location thereafter, you don't need to worry so mucvh where these files are. FSUIPC's installer locates them via the Registry. Regards Pete

Please double check that, as WideServer was certainly able to initialise an IPX/SPX listening service, and without the protocol installed that would fail. here's a typical example of such a failure: I really think it is impossible for the IPX/SPX service to be successfully initialised without the IPX/SPX protocol installed. Nevertheless, now I know you are using XP Pro I will try installing IPX/SPX on my XP Pro PC here and see if that causes problems for WideServer. Regards Pete

Sorry, I don't understand. The above Button assignments would make all 5 or 4 actions occur each time the button or rotary signalled "off" to "on". Is that what you intended, 4 or 5 keypresses each time? Are you forced to use Keypresses with your chosen aircraft panel? Generally it is far better (more reliable, more efficient) to use the FS controls instead. Most FS keypresses are translated into controls in any case. If you enable FSUIPC's Event logging and check the log you will see which keypresses generate which controls, and then you can assign them directly. Sorry, I don't know the add-on aircraft you are dealing with, and you've not shown any examples of what you are programming. Are these pump switches operated by keyboard? Do they work as you wish FROM the keyboard? I'm npot sure what you mean by "only on the first action". Can you explain that? I can't see how anything can be wrong with the GF modules. They normally either work or don't. But you haven't really given me enough information to understand your problem, let alone help solve it. Have you thought of using the Logging facilities in FSUIPC to help you see what is going on? You can log Buttons and Keys as well as FS Events. If you are using FSX you can even display the log in real time, with the "console log" option enabled, and FSX running in Windowed mode. Regards Pete

As stated in the documentation, this can also happen if you have an FSUIPC.DLL file in the main FS9 folder. Check there too. Also you must never just rename FSUIPC and leave copies in either place. They will still load as FSUIPC is they look like DLLs to FS's loader. The only other possibility is that your previous FS session did not actually terminate fully. The window and all other signs might have disappeared, but some threads in some parts of FS or your add-ons are still running, and FSUIPC.DLL is being kept alive in memory because of that. To check for such things look in the Process list in Windows Task Manager (Ctrl-Alt-Del). If there's still an FS9 process then, terminate it forcefully. Removing FSUIPC.DLL from the Modules folder merely stops FSUIPC.DLL from loading. It cannot cripple or stop FS. It sounds like you may have deleted some vital part of FS instead. For example, the module called FSUI.DLL is the Flight sim User Interface. It certainly won't run without that! 3.916 is very much out of date. The current version is 3.96 and is now the only one supported. Before that 3.93 was current for six months. Please do check the Announcements in this Forum before posting requests for help on old versions. Regards Pete

Thank YOU. It is nice to get a thank you now and then without a new problem! ;-) Regards Pete

What message about installing FSUIPC? Why do you restart? I don't know. You don't provide any information. What version of FSUIPC? Where's the Install Log file? Please paste it here so i can see. It will be in the FSX Modules folder. Please also read the Installation document. Regards Pete

Intentionally? Any answers to the other questions? What windows? Why IPX/SPX? Maybe logs with DebugAll set? An FSUIPC4.LOG file? I must admit to being a little concerned as to whether IPX/SPX works properly in WinXP or later. Microsoft have not paid attention to that protocol for a long time. If you are not actually using it I'd try uninstalling it. Conversely, if you are using it for something, or at least once you confirm which version of windows you are using, I could try installing it here. Pete

Sorry, it was the FSUIPC4.LOG I asked for which was missing. I was going by your titles, one of which is incorrect. Okay. Yes, the 192.168 part are okay, it was the 220 in the third part which looked odd. It is interesting that you have the IPX/SPX protocol installed, as shown by this: I've not seen anyone with that installed since Windows 98 days. Are you using that prootocl for anything? What version of Windows are you using? I'm wondering, as that is the only difference, if it is that installed protocol which is causing the lock up, somehow? Both the Client and server log show nothing ever connects, so if something is hanging it is down in the windows networking someplace. There certainly something wrong. The networking code in wideFS is basic stuff lifted straight from Microsoft examples and has worked fine now for 12 years. Since the problem is occurring before any connection to my part of the code occurs I don't think I can help much more. You need someone who knows about networks -- in fact it sounds like you know more about them than I. And the symptom you are getting has never occurred to my knowledge in the 11 or more years of WideFS so I'm completely mystified. You might be able you get more information from either end by changing or setting the Log parameter in the WideClient.INI file and the WideServer section of the FSUIPC4.INI file to "Log=DebugAll". Normally this would produce a horrendously large log, but since there's no connection, and the attempt looks like it lasts less than a couple of seconds, I expect it will be quite short. You never explained why you added the Protocol and ServerName parameters to the WideClient.INI file. Regards Pete

That IP address doesn't look right for a Local Network -- that's an Internet address. Something is configured incorrectly on your Network. Instead of using: in your WideClient INI file try using the actual IP address of your FSX PC instead. Incidentally, why did you add the Protocol and serverName parameters to the INI in the first place? Are you running the two PCs in different workgroups? I understood that. but WideClient isn't actually connecting, as they log shows. Something in Windows is causing the problem -- and that IP address Windows appears to be supplying for your FSX PC looks like a symptom. I suspect it is something to do with protection being applied, probably in your router? Are the two connected via your router? Unfortunately you didn't provide probably the most important Log file, the wideServer log file from the FSX Modules folder. Maybe there's a further clue there? I didn't ask for the INI files. Regards Pete

I've never heard of that happening before. It sounds like the network software on the FSX PC is not responding for some reason. Or else it is something to do with an application. Does it happen immediately you run WideClient or after you run some WideClient applications? OR do you have something else running on the Client PC first, before you run WideClient? It is possible for applications to hang or crash FS when they have access. I really need information, as always. Version numbers first please: version of WideClient, version of FSUIPC, update state of FSX, and Windows versions on both PCs. Not "latest" please, but numbers. There will be a WideClient log file in the WideClient folder on the client PC and WideServer.log and FSUIPC4.log files in the Modules folder of the FSX installation. Please show me all three. Can I also assume you have not changed anything in any INI file? Regards Pete

Version 3.75 is very old and has not been supported now for over two YEARS! As clearly Announced in the Announcements in this Forum, the only supported release is the current one, which, for FS9, is 3.96. Please update. The certificate bound into FSUIPC 3.75 expired early last year in any case. Your registration is for FSUIPC 3, not "3.75" and you should keep up to date if you want continued use and support. Regards Pete

The timeout is only executed when in the axis or buttons assignments or the calibration section of the options, so they won't be logged unless you go into those sections. Do you have anything assigned in FSUIPC for the Saitek joystick? What actions of yours does the log extract purport to show? Sorry if I'm confused now -- I thought you were having problem assigning or calibrating? If you have already done that, in FS perhaps, then something else must be wrong. Does FS see the joystick? Did you try increasing the JoystickTimeout from 15 to 20 anyway? The value 20 seems to be working fine for other Saitek user's, so far anyway. How do you know that the above is the registry path to GFConfig.exe if you could not find the registry key to see it? Sorry, I don't understand. I presumed that, to check the registry entry, you looked in the Registry, with RegEdit for example. If so then the "key" is the stuff on the left which points to the path you just listed. If you have the entry selected the full key is shown in the status bar at the bottom of Regedit's window. On my system, for instance, the full key is: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\GFConfig.exe The "Wow6432Node" is only applicable to 64bit operating systems I think, and is automatically inserted by windows. My program merely looks for SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\GFConfig.exe within the HKEY_LOCAL_MACHINE registry section. The key contains two parameters: "(default)" and "Path". I use the Path one. You can easily get the Key name into the clipboard, for pasting into a message, by using Regedit's Edit menu, "Copy Key Name" facility. Regards Pete

FSUIPC4 uses DirectInput for the axis polling and that part isn't subject to my timeout in any case. Only the button assignments would be affected in FSUIPC4 if there were a timeout problem, as that part still uses the standard Windows interface, not DirectInput. I think the DirectInput code in DirectX has its own error checking and prevents the sorts of hangs which a bad driver or failing joystick can produce. By adding such a check to my code for the Windows API I am really merely bringing it up to that better standard. Or at least I will have when I've got the timeout correct! ;-) Thanks for the feedback. Very useful. Regards Pete