Pete Dowson

I think it would be best if you could post, as a new thread, in the User Contributions subforum. Make the application (aircraft) clear in the title. You can either include the files in the text (enclose then in code brackets -- use the <> button above), or Zip and attach. Thanks, Pete

This is almost always a result of a bad video driver or a mismatching dialogue module installed by it. FSUIPC is not actually responsible for making the dialogue -- Windows is. The answer is to download and install a proper driver for your video card (do NOT use the default one installed by Win7). An alternative if you won't do that or cannot find a driver which works correctly is to run FS in Windowed mode, or switch to Windowed made when accessing add-on dialogues. Regards Pete

I managed to reproduce the Installer bug by renaming the Prepar3D.exe before running the installer. It gets into a loop and eventually crashes trying to generate the prompt for you to locate the EXE for it. It is a result of trying to extend the Installer to work correctly with Prepar3D without thoroughly going through all the relevant code dealing with possible errors. Fixed in the latest installer being uploaded today. Regards Pete

Can you provide more details please? Is this FSUIPC3, or FSUIPC4, and which Simulator? What do you mean by "latest" -- what is the version number? I really cannot help at all with no information supplied! I've got no reports of any other such problems with the installer, except once some time ago with Prepar3D -- for which i'm still awaiting more information. Isn't a log (even partial) produced? If not, what was showing on the screen in the displayed log? [LATER] I've found one bug in the Installer by renaming the Prepar3D.exe before running the installer. It gets into a loop and eventually crashes trying to generate the prompt for you to locate the EXE for it. It is a result of trying to extend the Installer to work correctly with Prepar3D without thoroughly going through all the relevant code dealing with possible errors. Fixed in the latest installer being uploaded today. If this is NOT the problem you see, I still need details. Certainly version, which FS, log, etc. Regards Pete

Yes, of course. In fact FSUIPC4 uses SimConnect, and WideFS extends the FSUIPC interface across a network using separate network ports from SimConnect, and neither interferes with the other. WideFS and FSUIPC are used by programs written to use the FSUIPC interface, the one which has been maintained across all versions of FS since FS98 (as well as two versions of CFS), whilst SimConnect is used by programs written to use SimConnect, which applies only to FSX, ESP and Prepar3D. It's not relevant to user friendliness and stability, only on what add-ons you want to use. Regards Pete

Er, yes. By "wideclient page" what exactly do you mean? WEideclient only has a title bar. You can enlarge it's window, but that's only useful if you have a program which wants to "dock2 into FS's window -- the old EFIS98 program for FS98 used to do that, but i don't know any current one. Squawkbox 4 doesn't use FSUIPC and therefore doesn't work with wideFS. WideFS is only an extender of the FSUIPC interface to client PCs on a Network. I don't know FSMap. Does that interface via FSUIPC? If not then it's the same answer. [LATER] I googled FSMap and it says, for FSX, it uses SimConnect. I suspect if you want to use it with WideFS you'd have to fool it into thinking it was running with FS2004. Regards Pete

The autopilot altitude in FS is actually encoded in 1/65536ths of a meter. However, I don't know of any FS aircraft which can set or use any altitude in any accuracy other than 100's of feet. Here's a Lua plug-in which will increment or decrement the internal FS altitude by any amount you like in feet: alt = ipc.readSD(0x7d4) * 3.28084 / 65536 alt = alt + ipcPARAM ipc.writeSD(0x7d4, alt * 65536 / 3.28084) Save this in the FS Modules folder, as say "incalt.lua", then, after "reloading" keys or buttons to get FSUIPC to re-catalogue the plugins, simply assign keypresses or buttons to "lua incalt" with the parameter set to the increment (eg 10 or -10) and experiment with it. I think you'll find it does increment or decrement the internal value, but it doesn't affect anything until suddenly FS rounds it up or down to the next multiple of 100 feet. When you think that the accuracy of the altitude setting is only to, at best, 1 hPA of setting on the altimeter adjustment, assuming you can know the actual sea level pressure at your exact position all the time, and a difference of 1 hPA represents around 30 feet, there's little point in trying to fly an altitude to any accuracy like 10 feet in any case. Even 50 is a doubtful ambition. 100 seems eminently reasonable and normal. Regards Pete

Yes, thank you for your testing. I've found it! As you saw, It works properly for uncalibrated axes, but only for calibrated axes if certain other controls are also calibrated -- it is using the wrong index to access the calibration table! :-( The reason it worked in tests here is that i had all the possibly affected axes either calibrated or uncalibrated, because of the amount of testing needed. I should have checked each separately with all the others uncalibrated, but of course there are so many possibly interactions when the wrong index is used that it is difficult to spot that. I've just done such a test and found the bug. It'll be fixed in FSUIPC 4.745 and 3.998g very soon, in the Download Links subforum. I'll making new Installer builds too. Regards Pete

They are documented as providing calibrated values -- so, for instance, a forward only throttle input of -16k to +16k should calibrate to a range of 0-16k, as required in the throttle offsets, but there were not. The idea for those offsets is that you could disconnect the throttles using other offsets and copy the values directly from those into the throttle offsets, but you could not do that without making correctins because the range was wrong. Ah, really? I don't think I saw that here! If what you are saying is true then that is wrong. [LATER] Ah ... found it! It works properly for UNCALIBRATED axes, but only for calibrated axes if certain other controls are also calibrated -- it is using the wrong index to access the calibration table! :-( The reason it worked in tests is that i had all the possibly affected axes either calibrated or uncalibrated, because of the amount of testing needed. I should have checked each separately with all the others uncalibrated, but of course there are so many possibly interactions when the wrong index is used that it is difficult to spot that. I've just done such a test and found the bug. It'll be fixed in FSUIPC 4.745 and 3.998g later today, in the Download Links subforum. Regards Pete

Why did you post this in the FAQ subforum? Please use the support forum. I've moved it for you. No. There are enough such usable contributions already in the User Contributions subforum. The macro supplied with FSUIPC3 is only there as an example. I shall probably remove it and put it only in the User Contributions subforum on the next release. Regards Pete

And look at how you defined the r: Don't you see how this is different to the others? It tells FSUIPC to call that place, X48590, twice! Why not simply define it in the same way as all the others? i.e. 57=r=RX48590*X8bcc Pete

No! Calibration and assignment are two separate things. You do NOT have to do any axis assignments in FSUIPC. You can assign everything in FS or everything in FSUIPC, just not both. Irrespective of where you assign axes you can, if you wish, still do calibrations in FSUIPC! In general you shouldn't have multiple different controls assigned to the same function. However, conflicts will only arise if the one not currently in use is moved or is sending unwanted changes (i.e. jitter). Usually you can safely park unused controls at a position where this never happens -- generally at minimum or maximum. If you do assign in FSUIPC and use "direct to calibration", then FSUIPC will actually arbitrate between controls, only using the one with the maximum value or deflection. Regards Pete

Offsets 3328 and so on were always wrong before (no one cared to report it till very recently), but now they are fixed to work correctly. If you want to use the old broken values you need to change a parameter in the INI. Please see the list of changes included with the 4.743 update. Regards Pete

There's no difference for Prepar3D and FSX or ESP. It's the same code. Are you running the installer "as administrator"? There's no "fsuipc.txt" file. Do you mean the FSUIPC4.LOG file? You need to ( a ) run the installer by right-clicking on the EXE and selecting "run as administrator". and ( b ) make sure you are running as the same user who installed Prepar3D If still no joy I need to see the Installer log and the FSUIPC4 log. I cannot help without information. BTW do you have an FSX or ESP installation with registered FSUIPC4 and WideFS7? If so you can copy over the KEY file from that. Regards Pete

I've not heard of that one. Is there an FSUIPC4 log file produced? If so paste it here. Have you followed all of the hints in the FAQ subforum thread about this SimConnect problem? That's generally a bad idea as it can result in SimConnect corruption. Timing can be changed in other ways. most notably there's an FSUIPC4.INI file parameter now which can be used to delay the SimConnect opening. But this only helps when FSUIPC is actually loaded -- most of the trust bug crashes occur before FSUIPC is even started. If that's happening then there won't be a LOG or an INI file produced. The delay parameter is described in item 40 of the recent changes list, here: 40. The order of initialisation actions in FSUIPC4 has been changed substantially in an attempt to try to avert the possibility of causing a loading problem with SimConnect, whether or not this is caused by Trust checking timing bugs. Furthermore, in order to allow changes to the timing to be tried, to avoid clashes with other competing simConnect clients being loaded at the same time, a new parameter is added to the FSUIPC4.INI [General] section: InitDelay=0 This can be set to a value from 0 to 120 to delay the actual linking to SimConnect by that number of seconds. Whether this may help or not is unknown at this time. If you can paste your DLL.XML and EXE.XML (if the latter exists) here then maybe I can suggest ways of temporarily rearranging the way things are loaded. You find those in the same folder as your FSX.CFG file. If you don't know where that is, check through the FSUIPC Install log and it wil tell you. Regards Pete

Those are very explicit instructions so you don't need to know anything else. Just follow them. Pete

I'm afraid, then, that there is probably no way to do what you want. It is known that FS has some problems with multiple monitors, but I really don't know what your problem might be. Have you considered using one or two Matrox Triple-head adapters? You could make 6 monitors look like just two very wide ones using those. Pete

Assign 1 to engine 1 and the other to engine 3 then edit the INI file to add similar assignments for the other engines. You cannot program multiple actions on one button press in the Options screen only, you have to edit the INI. Alternatively, if your microswitch sends a "press" and a "release" and not just a press, like a button, you could program one engine on the press and the other on the release -- that certainly can be done in the options screen. The 4 reversers tab in the joystick calibration has options for doing exactly that. The check boxes to enable such mapping are clearly labelled. Regards Pete

Well, I'd certainly worry about them getting worse as hardware doesn't change unless it's developing a fault, or getting dirty or being affected by heat or humidity. But i wouldn't worry very much about them being unsynchronised because that's quite realistic. Real throttles aren't either. Engines don't all perform exactly the same and the cable connections etc do not all stretch or contract at the same rates. The values aren't relevant. You should be calibrating with some leeway left at both extremes in any case. Please do follow the steps in the calibration section of the FSUIPC user guide, otherwise you are really not using FSUIPC to any advantage. Regards Pete

Yes, and I've found it. It is reading the "read" area before it is copied over, instead of the "write" area as it should. It must have always been that way. Evidently no one has used this facility before! I'll upload 4.744 tomorrow, or maybe even later tonight. [LATER] I've got some other things to do before making a new release, so please get 4.744 using this link: FSUIPC 4.744 Pete

Okay, thanks. I'll check it out -- but it will be tomorrow now. Can you just tell me which version of FSUIPC4 it is you are using, or, better, make sure it is the same in version 4.743 as that's where I'm at. Pete

I'm wondering if there's some computation done in FS which is overflowing or something when the screen coordinates get too big. Have you tried telling Windows (i.e. drag them around in its settings) that half the monitors are to the left and half to the right of the "home" screen, so that you get smaller X coordinates, but some negative? (Or simply choose the centre one as the home screen). Pete

The quickest way to find out what they are called and how numbered is to enable Event logging in FSUIPC's options, operate the control using one of the usual methods, i.e. via the panels, then look in the Log file -- found in the FSX modules folder. If you (temporarily maybe) run FSX in windowed mode you can enable FSUIPC4's console log and see events logged in real time. I think CRS is known as OBS in FS. The baro setting on the altimeter is known as "Kohlsman" in FS, after the originator of the Kollsman window in altimeters -- MS misspelled the name too! As I said, the quickest way to find out what they are called and how numbered is to enable Event logging in FSUIPC's options, operate the control using one of the usual methods, i.e. via the panels, then look in the Log file -- found in the FSX modules folder. That looks like a copy of mine. If you've installed FSUIPC that list is installed for you along with FSUIPC documentation in the Modules\FSUIPC Documents folder. Regards Pete

Show me the string, not part of it. I can't tell what is happening with partial information. Regards Pete

There's no way, as you've found. The structure in the NWI was devised for the facilities in FS9, where you could control both heights and top styles. In FSX the height is not even readable either, really annoying when trying to detect whether you are in cloud or not. I think FSX uses some sort of algorithm based on cloud type and base altitude to determine the heights and tops. FSUIPC reads the weather all the time in order to populate the weather offsets. How else could it do it? It reads all sorts of things from FSX all the time. That's it's prime function, to be an information supplier for applications. Pete