Pete Dowson

Only if you write a driver to do it. FSUIPC is not a hardware driver. The only "hardware" it recognises at all is the Windows joystick API. You'll need a program to handle the data transmission and reception on your COM port and read/write FSUIPC offsets accordingly. You can write in whatever language you like, it is irrelevant to FSUIPC. You could even se the Lua plug-in facilities in FSUIPC to write it -- it has a COM library with functions for serial and USB ports. No. FSUIPC has no facilities for output data unless you write a program to do it. FSUIPC provides the interface into FS data, reading and writing, for programs which wish to do so, whether drivers for hardware or other software on the same or (via WideFS) difference Networked PCs. Sorry, but you do appear to be under a complete misapprehension of what FSUIPC actually is and does. Pete

Hmm, that's a pretty serious problem. The loader should never be needed. It's a last desperate attempt to get around some timing compatibility problems with other SimConnect loading DLLs or EXEs. Is this also true when there is nothing else loading in the DLL.XML, and no EXE.XML? Have you tried that? If not, please do and let me know. Try it without the Loader. Easiest way to do this test is rename the EXE.DLL and DLL.XML and remove the loader from the Modules folder, then re-run the FSUIPC installer. No need to reregister, that won't get lost. The different SimConnect DLLs are just interfaces with differing functions translated into calls to the real functions which are within the main code in P3D. It doesn't matter which one gets used, it just may affect the facilities available if it's an old one. FSUIPC only uses a subset in any case, and its subset are translated by the SimConnectP3D2.DLL which gets installed in your Modules folder. Looking back at the Log you posted earlier, you'll see this line: 1829 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.1.3.1 (SimConnect: 3.1.0.0) The SimConnect version shown is always the one being used -- the information in this line is that returned by the call to SimConnect to open the link. That is extremely odd. There is no way FSUIPC is involved in that. It seems something which provides data for the whole of the UK is corrupt -- maybe some of the base files being loaded via the SCENERY.CFG file? Pete

Ah, okay. I'll check that here. That's something to do with FS innards. I probably have to make more calls somewhere. Doesn't it even close if your plug-in exits (terminates) or is Killed? I won't be able to look at this properly till towards the end of the week. Sorry. But OI've made a note of it. Remind me if you don't hear back by Sunday. Pete

f there's no time expiry set, the Window closes when the Lua plug-in exits. To close it prematurely, use the ipc.display function with a null (zero length) message, i.e. "". Pete

Yes, probably. But you might also want to check what scenery files you have which encompass Europe, or at least the airports you've tried and had this problem with. FSUIPC has no idea and does not care at all where your airport is, there is nothing in FSUIPC which is dependent in any way on location. If it still happens after reinstalling 3.2 I would proceed on a series of eliminations of the assorted scenery layers you have added, starting with any which is handling an area inclding those airports, like a UTX or Orbx terrain or LandClass layer. Pete

Assuming it isn't a corrupted P3D install (which is usually the reason for hook errors), I can only think one of two things. Either your ASN is out of date, or the order of its entry in the DLL.XML file is wrong. It should come AFTER FSUIPC4's, apparently. Usually ASN warns you about that, corrects it automatically, and tells you to restart FS. Pete

Ah, if assigning in P3D instead of FSUIPC solves it, then you could do the same in FSUIPC by assigning to the AXIS brakes controls listed in the FS controls dropdown -- I assume you previous had them assigned to the "direct to calibration" Brakes entries? BTW, do you not get the autobrake sticking on after landing unless you press the toe brakes, even if you advance the throttles? Pete

Sorry, I've no idea about anything to do with Saitek. I always thought any second quadrant was a direct USB connection to the PC, that the yoke only supported one quadrant directly connected. The free-standing Saitek quadrant I had hasn't any sockets at all. Pete

Sorry. I did see it, but I think it is a question for the Prosim support folks. I have different problems. I use FSUIPC for the toe braking, and l have problems here if I forget to apply strong manual braking later is the roll out after landing -- the autobrakes stay firmly on! They should release when advancing the throttle, but they don't. But provided I use the toe brakes later in the rollout, they do release. I've tried in vain to get this sorted out with Prosim support, but haven't so far. I might try routing the brake axes through Prosim after all -- never thought of that. None of my axes have been routed that way. Wouldn't it be a good idea instead to get the first problem solved, i.e "Because of the veering to the right when taking off I disabled those functions in P3D and enabled them in Fsuipc.". Why is is veering to the right? Does the Saitek pedal set need sorting out? Pete

Good! Pete

Both locations are wrong. MakeRunways only works from the folder of the Flight Simulator itself, the folder which contains the flight simulator program. This has always been the case. The scenery.cfg file used to be there (before FS9 days -- MakeRunways has been around since FS98). This is stated in the first few lines of the documentation -- the "Read Me" included in the ZIP. It locates the currently used Scenery.CFG file itself provided the sim is installed correctly according to the Registry. The version of Windows is entirely irrelevant. Pete

Yes, I've seen all that and of course have 3,2. But I'm surprised it got release without even a message or announcement. Pete

No official announcement though? FSUIPC 4.949h is good for 3.2. Pete

Ok. Thanks for getting back with the solution. Pete

There no one way to "set up" any controller. It all depends what contorls they are (I don't have any of the regular ones myself), and what sort of aircraft you fly, and how you like to fly it, and which specific add-on aircraft it might be. FSUIPC calibration is no more complex than any other method, simple move lever, click, etc. But is is a general tool with lots of facilities and more than one way of doing things because some ways work better with some aircraft and another way with others. If a video on YouTube doesn't help then I don't think it will be usable to you, as I can't think of a better way. And that will be by a user, not myself -- I am the worst possible teacher you could imagine. Try installing FSUIPC and reading the User Guide. If it really does look beyond you, don't buy it. Pete

The output from the GPSout facility in FSUIPC, which is configurable in any case, is standard GPS output -- either a selection of NMEA sentences, or "Aviation" format. And the output is always to a serial port (COMn). You link to your GPS using a serial cable, possible with an USB adapter and appropriate driver. In other words the GPout facility just emulates a real GPS. So any device which can accept such input should work fine with it. But then you say your device "uses your Wi-Fi to connect to X-Plane on port number 49002", then I'm sorry, but there's no such Ethernet transmission facilities in FSUIPC. You could write your own as a Lua plug-in, but there's not a ready-made one. Pete

It's stopping at the exact place where it will be scanning for Joystick devices. Since it applies to 3 different installs/versions of FS, I think you have a rogue joystick driver which is causing DirectInput to hang -- maybe one not compatible with Win10? Pete

What happened to the first lines? They are important too. Please don't remove things and make the Logging less useful. Logs would being something like this: ********* FSUIPC4, Version 4.949f by Pete Dowson ********* Prepar3D.exe version = .... Reading options from "E:\Prepar3D v3\Modules\FSUIPC4.ini" Running inside Prepar3D v3 on Windows 7 Module base=12EA0000 User Name=... User Addr=... FSUIPC4 Key is provided WideFS7 Key is provided Anyway, there's no sign of any SimConnect problems there at all, and as far as FSUIPC knew the menu entry added here: 149500 FSUIPC Menu entry added stayed there. If FSUIPC became disconnected from SimConnect so that the menu entry disappeared, it would perform a complete reconnection, which is what I assumed was happening regularly from your description. So, something else was going on. I can only suggest that you go though a process of elimination to see which add-on may be responsible -- assuming of course that it isn't a P3Dv3 bug. There do seem to be quite a few still, so it might be worth reporting on the L-M forum too. Pete

Check the FSUIPC log. It sounds like your system is overloaded and SimConnect is stalling. Those aircraft have nothing at all in common with FSUIPC and are not related. They are also probably suffering from the overload where SimConnect is simply not responding quickly enough and eventually stalls. I cannot support other add-ons which have nothing to do with FSUIPC. Pete

Nothing of mine works with X-Plane. I don't know if someone else has done a similar feature -- maybe check with the XPUIPC author? Pete

No, there USER license is a license t use the USER facilities. The applications interface into FS via FSUIPC, for those programs which use it (certainly not the ones you mention) is free to users and always has been. Look at the FSUIPC user guide. It tells you what you pay for. No programs "contain" FSUIPC. They may install an old copy, but they shouldn't overwrite a later one. Not so many programs use FSUIPC nowadays in any case, as it is supposed to be replaced by SimConnect. Those that do so in FSX/P3D either do so because they were originally written for FS9 or before, or because the author thinks FSUIPC is easier or more convenient. Pete

With effect from FSUIPC4, WideServer, the FS end of WideFS, was re-written and built into FSUIPC for much more efficiency on the heavier system which FSX became compared to FS9 and before. Therefore the WideFS for FSX and P3D is a new product and needs a new licence purchased. Wideclient remains the same so it works with a FS versions from FS98 through to P3Dv3. Thus the pointers you found to the same main WideFS ZIP which contains valid documentation for both 6 and 7 and the WideClient.EXE you use on the clients. You simply don't use the WideServer.DLL. This is all made clear in the documentation. Please note I had to move your support request from the FAQ subforum to the main Support Forum for attention. Please post support questions here in future, not to the FAQ subforum. Pete

Is the a support forum for that aircraft or its publishers? Perhaps ask there? All FSUIPC will be doing is sending the control, same as if it was sent by FS assignment. Not much else to it, unlike the actual toe brake axes which are more complex and have more things going on. The fact that it works okay in other aircraft does point to something wrong in just that one. No, there's no "brake release" control it can send. The brakes controls are simply one-offs, which when repeated build up brake pressure and when to sent let it dissipate. The brakes shouldn't come of from a high pressure to zero instantaneously, though, but come off as the pneumatic system lets them. Maybe that model has the rate of decrease set very slow. I don't know if that's a settable parameter, but it might be worth a look in its AIRCRAFT.CFG file to see. Pete

How would you operate its brakes without FSUIPC assignment? Pete

Unlike the throttle and prop axes, the mixture axes have no negative output to FS -- there's no "reverse mixture". Instead there's a point which FS sets at 8192 which is the normal "idle" level for turboprops -- 0 is "cutoff". It is where you'd calibrate your Idle detrente on the mixture if you have one. This is clearly documented in the FSUIPC user guide -- see the 4th bullet in "NOTES and EXCEPTIONS" on page 50 (though it doesn't actually state what the "idle" value is, i.e. 8192). And the Mixture calibration has always been like this in FSUIPC! It isn't a change. It was the same back in FS2000 days. Regards Pete