Pete Dowson

FSUIPC's process is a single process. Each Windows process is allowed only ONE console window, and when it is opened every part of the FS process which wants to log anything gets its output in the same log.. There is no fix. You just get the logging which is enabled in whatever DLLs are running -- ASN has one as well as FSUIPC. SimConnect also has a console logging facility which would share it too. That's not my recommended way at all. You can Monitor it to the title bar or to a normal FS dockable and sizable message window, or use one of the neat little Lua plug-ins around to log it in a more readable fashion in a window or on a client PC. Pete

When you run FS is a runtime log file produced in the Modules folder? ("FSUIPC4.LOG"). If so, please show it to me. If there isn't one then it sounds like you have a corrupt DLL.XML file which is preventing SimConnect even loading FSUIPC4 in the first place. Find that in the same folder as your FSX.CFG file. You could try renaming it, then re-run the FSUIPC4 Installer, which will make it create a fresh one. If FSUIPC4 then loads okay, the renamed one is corrupt in some way. If you post that here I can possibly check it for you. There are many third party add-on installers which make a mess of it, with just sill slips. XML is very very fussy about format, every single chracter appears to be critical! Pete

You probably need someone from SPAD to help. Is there a support forum for it at all? FSUIPC itself is only the interface. Pete

The FSUIPC facility to map throttles from 1 or 2 lever devices in order to operate 3 or 4 engine aircraft are identical in both FSUIPC3 (for FS9) and FSUIPC4 (for FSX-SE). Just do exactly the same thing. Pete

For the older PFC serial devices you need PFCFSX.DLL, and for the more recent full USB HID devices you need PFCHID.DLL. both can be installed together if needed (my cockpit has both types of PFC device). The installation is manual -- just place the contents of the downloadable ZIPs into the Modules folder. FSUIPC will load them and initialise them if it finds them there. Pete

Just installing FSUIPC cannot change anything. All your settings are in the FSUIPC4.INI file, in the Modules folder. That does NOT get changed or replaced when you "reinstall". If you want to reset everything you've done in FSUIPC4 simply delete the INI file before loading FS. FSUIPC will revert to default settings which involve absolutely no interference with any controls at all. Pete

You really need Saittek support for this. I don't use any Saitek gear. The only stuff I know of which might help was that supplied by a helpful user (Al,) -- please see the FAQ subforum thread which I've just revised to paste in the Saitek help, which was originally on their Forum but seems to have been removed. Pete

You are calibrating the steering tiller for all aircraft (as seen in the [JoystickCalibration] section. You are quite correctly only assigning the axes you want in the different profiles, but you are calibrating all of them generically. It is the calibration which determines the actions, not the assignments. Usually folks want separate calibrations for different aircraft types (as they all behave differently), but if you are happy with them all responding identically, just separate out the Steering Tiller (ie first RESET its calibration), and then re-calibrate it specifically for only those aircraft profiles needing it. Pete .

I am pretty sure that the Toggle Aircraft Exit controls can take the "select" number (1-4) as the parameter, which saves having to issue separate controls. Alternatively, use the FSUIPC offset provided to open/close doors. Pete

Not quite out yet. FSUIPC was updated for 12946 some time ago, in 4.939u to be precise, on 24th June (seven weeks ago)!! The currently supported version of FSUIPC is 4.943! That is the version on the proper downlad sites at present -- please always see the Download Links subforum here for latest information! Pete

The tiller should have nothing to do with anything else but the nose wheel. FSUIPC's own tiller implementation is different in that it uses the rudder -- there was no choice before FSX, and the facility precedes FSX by a long way. I think you need to ask on the MJQ400 support forum. Pete

The first problem is generally one of axis definition in the Registry. It sounds like it is defined as "digital" (i.e. on or off, rather that having a range). The other one, operating from 0 to 16384 is probably to do with the Control Manager (in fact both of them might be). However, FSUIPC can calibrate a full FS range no matter what the input range, so it isn't really so much of a problem. I suspect you shouldn't be using the CH control manager at all if you want to do things more flexibly in FSUIPC, but as i have no CH devices I couldn't be certain. It is only what others have said. It will pay you I think to visit the CH hangar website, http://www.ch-hangar.com/, or even Bob's Stickworks (http://stickworks.com/), but I think the latter is now pretty old and not updated for years. Pete

The simplest answer was already given to you by mgh. It is also the one which will last and reward you in the future as well, is to change the stupid Explorer folder option which insists on HIDING filename types from you when it thinks it knows what they are! Well, naturally that is the case, because the LOG from FSUIPC4 is, surprisingly "FSUIPC4.LOG" not "FSUIPC.LOG"! Also, whilst I don't read German, looking at your original picture it seems pretty obvious that the German for "configuration settings" is referring to the FSUIPC4.INI file, whilst that saying it is a simple TEXT file is referring to the LOG. Why not actually see what it is telling you if you refuse to change its silly option settings? The advice provided in the documents for FSUIPC does actually tell you these things, but why read any documentation? :-( Pete

I'm afraid I cannot now go back to P3D build 12945 to test this. Can you update to 12946 please? However, I don't think it will necessarily make much difference. I did try your Lua program here and though of course it won't work properly (I do not have the aircraft it deals with), I "fiddled" it to get some of the "display" calls to operate and they all closed fine -- when the program exits. However, this is a tidying up activity which FSUIPC attempts to do, and is quite precarious. I think the differences you found between versions are simply ones of timing. It is definitely not good practice for a plug-in to create a display window then simply terminate, without caring what happens to it. You should either use the second parameter in the display calls ("delay"), to specify how long the display should last, or explicitly clear it with a null string before exit. Please see the documentation. Note also that the documentation for the display function doesn't actually say what happens to the display when you exit, and you should also note that the one you are using is a generic one for all plug-ins and is not specific to your program, unlike "setowndisplay". Pete

Good. I'll make that version the official current release then. The logs at both ends will show the reconnection occurring, of course, but otherwise it should be pretty smooth. Pete

No, it cannot be FSUIPC. There is no such message or pop-up. Pete

FSUIPC's interface extends from FS98 (where it started) through CFS1, FS2000, CFS2, FS2002, FS2004, FSX, ESP (now defunct) and P3D. Through all that it has been extended and developed whilst all the time maintaining compatibility, thus allowing applications written to its interface to be continually carried forward without needing revision. That was its raison d'etre. When FSX was being conceived and developed I was invited by Microsoft to help them design it so that an extra interface like FSUIPC wasn't so necessary. The result was SimConnect. The idea with SimConnect was that it would be continually developed, just as FSUIPC had been, to carry on extending its capabilities. It was in fact still rather deficient n some areas, compared with FSUIPC, but did have extra new features which FSUIPC did not. Before onward development of SimConnect could continue, sadly the MS FSX team was abolished and development stopped. The SimConnect in ESP, Microsoft's last involvement, was no better than that in FSX. Lockheed-Martin have extended the SimConnect interface in some new areas peculiar to their wishes and needs, but sadly not fully making up for the areas missing as far as FSUIPC's needs went. Discussions about this are on-going, however, and I am hopeful. FSUIPC4 itself makes use of SimConnect for 95+% of its needs, with much less "hacking" direct into the code than FSUIPC3 and earlier (which was almost entirely hacked directly into FS code). So, in that sense, FSUIPC is only presenting you with a different way of doing things. If you aren't interested in supporting anything before FSX with your software then SimConnect should be fine. But you may prefer the style of the FSUIPC interface. Some folks do. But the choice is entirely yours. Both FSUIPC and Prepar3D use DirectInput methods to read joystick buttons and analogue inputs ONLY The devices have to be recognised in Windows as joystick varieties of HID (Human Input Devices). Neither FSUIPC nor P3D handle displays or indicators directly. If you have devices which are HIDs but not classed as joysticks, then FSUIPC does allow programming them via plug-ins written in Lua and using it's COM HID library. It could similarly cope with non-HID serial or USB (COM) devices. However the plug-in facility is only available to purchased and registered installs of FSUIPC, and if you are a C/C++ programmer already you'd probably be better off programming them using an external EXE, which could then also be networked if needed. Regards Pete

Hang on. Is this PMDG 737 profile you created different to the last one you said you created? You can't create two with the same name. Please explain. How are you "creating" these profiles? You shouldn't be doing so in the INI file, but in FSUIPC itself. If the actual FS "aircraft.cfg" file name of the aircraft you load contains anywhere in its name either "PMDG 737" or "Boeing 737" (ignoring differences in upper/lower case) then it will automatically be associated with your PMDG 737 Profile. That's the whole point, which you seem, somehow, to have missed! How? What is making you so confused? This facility has been availble and well used for a long time time, many years in fact, without anyone expressing such confusion? Please explain what is confusing you so much. Pete

If those are the names of those aircraft in their CFG files, then those will select Profile PMDG 737. You are not actualy making any use at all of the "ShortAircraftNameOK=Substring" facility. The whole idea of that facility was to save adding all the different liveries, but YOU have to select the correct "substring" and enter it yourself. Perhaps like this: [Profile.PMDG 737] 1=PMDG 737 2=Boeing 737 However, I'd be suspicious of those last two aircraft names you list -- PMDG aircraft always seem to have PMDG in the name.. Were those added automatically by you loading the aircraft and selecting the PMDG 737 profile for them? If so, then what you say later makes no sense, i.e. So the names were NOT set automatically by you selecting the profile for them after loading them into FS? That really is the only safe way unless you want to go through the AIRCRAFT.CFG files for each aircraft to get its name. And since there is no "substring" or abbreviated name provided, even though you selected the option, that is nothing to do with it. The "PMDG 737" you chose for the Profile name is just that, a title. You could have called it "My planes" without it making the slightest difference. Pete

I've tested here and I cannot find anything wrong. How are you testing? Instead of looking at the actual rudder from outside the aircraft, just enable axis logging in the FSUIPC Logging tab. Also enable the Console Log and put FS into Windowed mode, temporarily, so you can see what goes on in real time. As you move the controls, if FSUIPC is allowing them through you will see the values being logged. On aircraft without the tiller assigned or calibrated you should see that it does nothing, and the rudder ALWAYS sends the full range of axis values. On the aircraft with both tiller and rudder assigned, when you are parked on the ground you will see that the tiller sends the rudder controls, full range of values, whilst the rudder control does nothing. If you are not seeing exactly this I think there's something wrong with the assignments. In that case please paste your FSUIPC4 INI file here. Pete

Hmm. That shouldn't be so, but maybe there's a bug. Possibly I've never had such a mixed case -- even aircraft without steerable nose wheels are steerable with the FSUIPC-assigned tiller because it uses the rudder control in any case. Perhaps it's an original bug and no one ever found it because of this. I'll test here and get back to you. Pete

Please try this updated WideClient.exe when you can: WideClient6999x.zip Before running it, set this parameter in the [Config] section: ReconnectMinutes=240 That would be for an automatic reconnection every 4 hours (4 x 60 minutes). Adjust to taste. (0 disables). The re-connection will just be a little hiccough, but it is going through exactly the same process as it would after a timeout triggered by a stoppage at the Server end. I think this should work fine for you, but if not do let me know and I'll implement some not-so-nice solution at the Server end. I'm away all next week, so if we miss this weekend I'm afraid there will be a week's delay. Pete

You've not read the FSUIPC documentation? If you assign both rudder and steering tiller in FSUIPC, they are managed whilst the aircraft is on the ground. The steering till is 100% active at 0 knots, and winds down to 0% at (by default) 60 knots -- that value is a settable parameter. The rudder effectiveness is the reverse -- 0 at 0 knots, 100% at 60 knots. For taxi you use the tiller, on a takeoff roll you use tiller and rudder with rudder being dominant after 30 knots (or half the set value). This is a long-standing feature of FSUIPC, for added realism, and is well appreciated. Both controls, assigned "direct to calibration" in FSUIPC, actually use the rudder, not the new steering control added in FSX (though that is also assignable in FSUIPC, just not calibratable). If you do not want this action you should not assign the FSUIPC steering tiller -- assign to the FS control instead. You can of course use Profiles to have different assignments for different aircraft types. Pete

No. The Server doesn't have a single "stream" each time something conects it's a new one. How else can it cope with multiple separate clients coming and going? You can test this by having another copy of Wideclient running on your one and only client PC, with perhaps one of the display Lua plug-ins showing frame rater, VAS or similar. You can run multiple WideClien's by setting the "ClassInstance" number to a non-zero value. I use three clients on one of my PCs, two running parallel ButtonScreens. These additional clients must use TCP protocol, not UDP because UDP isn't specific(i.e. it isn't addressable on the one PC). As I said it is much easier for me to put a reconnection timer into WideClient, with a parameter to set the elapsed time, and would also be smoother for you because there's be no need for the Client to delay before reconnecting. Okay, if that doesn't work as I believe it will, I'll look at the Server end. Pete

Found the problem, and fixed it here. It'll be okay in the next release, probably on Friday (version 4.943). Thanks for your report and data! Pete