Pete Dowson

I have something similar set up. But I'm not sure I have the same settings. I can check tomorrow -- by cockpit system and associated client PCs are off for the night -- I'm going to bed very soon. I suggest first, though, that you enable Button logging in the FSUIPC options and operate the PTT button, remembering of course it has to be held down. Show me the Log. On the WideClient side, I'm not sure that P2A needs "UseSendInput". Do the P2A instructions say so. I'll check my settings tomorrow. Does the WideClient log show anything? Pete

Who is this addressed to? Which 'code'? Pete

The installation guide does tell you that the documentation is all installed for you in your own Documents folder, like most other documents in your PC. And to make them even easier to find they are all in a folder entitled "FSUIPC7", the name of the program. Pete

PLEASE PLEASE DO NOT POST SUPPORT QUESTIONS INTO REFERENCE SUB_FORUMS CLEARLY MARKED "Not for support requests" Why are you using L:Vars when PMDG generously provides all the controls you need as additional assignable controls? These are all listed in the .h file installed in your PMDG 737's SDK folder. Look to the end. The number representing the controls can be used to make assignments in FSUIPC as <custom> Controls. You can also use mouse macros with PMDG aircraft, but using the controls PMDG provide is far more straightforward. Pete

It's just a reference or address to a piece of data provided by FSUIPC. Is it motorized? If so surely it must come with a driver and instructions? If not then it won't turn under PC control, it is just a manual trim. Pete

Hmm. Error c0000417 is something to do with security. Searching for information on Microsofot websites doesn't help a lot except suggesting that it could be a device driver problem. The FSUIPC4.LOG also indicates this. It terminates at the point that FSUIPC tries to acquire access to your joystick-type devices, found in the Reistry as: 375 Product= Trust Gamepad 375 Manufacturer= ShanWan 375 Vendor=145F, Product=01BB (Version 2.0) 375 Product= T.Flight Hotas X 375 Manufacturer= Thrustmaster 375 Vendor=044F, Product=B108 (Version 1.0) 375 ------------------------------------------------------------------- The next log lines would normally be showing FSUIPC acquiring these so that you can make assignments to them. So, could you try, as a test, unplugging these two devices before starting FSX. If you get that warning allow FSX loading to continue. If FSX then loads, try plugging the devices in one at a time. If FSX doesn't then crash, check in the FSUIPC options assignments tabs that FSUIPC is indeed seeing them correctly. If the crash still occurs with neither device connected, I'll need tro think further. Otherwise: If it crashes on reconnecting the first, retry but with the other connected. We're trying to determine which may be the problem. If it does show that it is one of the devices, try going into Windows Device Manager and uninstalling them in there -- also uninstalling drivers if the option is available. Then power off, reconnect them, and power up again. Pete

Yes, towards the back of the READ ME document supplied with MakeRwys. No. Why would you want that? It won't save any time, if that's what you are thinking. All those thousands of BGLs have to be processed for any one of the files. The data is collected in memory during this process, only output to the files at the end -- a part that only takes a couple of seconds. Are you really short of disk space? Pete

For my 737 cockpit I have a 210 degree FOV curved screen, using just two 4k projectors (I used to use 3 x 2K projectors but 3 x 4K reduces the performance too much, preventing the level of AUI and scenery density I can use. The screen and software to overcome the curve screen and the edge distortion (fish eye) is from Natvis. From inside the cockpit I can see direct left and direct right, so no need to pan or have 'mouse look' type operation which would be unrealistic through the cockpit shell's windows anyway. This cockpit uses P3D5.1. However, on my VFR PC, the one where I've installed MSFS as well as P3D, I only have one 55" 4K screen (actually a Samsung TV). For VFR flying I need to be able to change the view -- e.g looking left or right rear when on a circuit. The VFR cockpit is a hardware one with analogue gauges. I've made a program to get it working pretty much 100% with MSFS except views. There's a lever on the hardware cockpit which moves left or right, centre sprung. That was easy to program for panning left and right with P3D5, but for MSFS I'll have to use the simple 'look left' and ;look right' keypress assignments for now as none of the view controls work through SimConnect! Rather annoying. This omission has been lodged with Asobo. With your screens and VFR I suppose you've tried using nVidia surround mode (or the AMD equivalent) and stretching the MSFS window across? Theoretically it should look like one screen to MSFS. But maybe Asobo drive the screens in some way which stops that? I've not been able to try it. Pete

Oh, I'm a bit confused then. You are okay using the mouse but want to use a joystick axis instead. Right? If you just want to avoid the toggle you could try the FSUIPC Mouse look option (see Miscellaneous tab page). The Lua plug-in facilities are described in separate documents in the FSUIPC documents folder. Pete

You need to supplied the last FSUIPC4.LOG, your FSUIPC4.INI file, and the FSUIPC4 Install.Log -- you will find them all in the FSX\Modules folder. Please ZIP and attach. AND please got to Windows' Event Viewer. In Application Logs please find the event reporting the FSX.exe crash. Copy the details and paste into your reply here. Pete

I think FSX/P3D (you don't say which) only operates that by mouse. I can only think of trying either 1. using Pan View instead. This suits a POV , like, I think, one of those on your yoke handles, or 2. make a Lua plug-in script to operate the mouse in response to yoke movements. There are functions in the mouse library to move the mouse pointer around, and operate the wheel, and click the buttons. It would take a bit of working out to get it working to your satisfaction. I'm note sure whether Pan View operates suffiiciently like Mouse Look for your purposes. I've always used it for looking around, outside, in the cockpit, whatever. I very seldom use the mouse with flight simulation. Pete

That is pretty much the case in Prepar3D and FSX, but, because FSUIPC interfaces exclusively to MSFS via the facilities of "SimConnect", we are dependent upon Asobo exposing all the switches, dials, etc, via that interface, as mostly happened with those previous sims. Unfortunately, functions programmed internally to particular aircraft gauges have mostly never been exposed via assignable controls or keypresses. We managed to use other facilities which unfortunately are not (yet?) implemented in MSFS -- access to local panel variables ("L:Vars") and "Mouse Macros" (a way of activating switches otherwise only accessible by mouse). Fpr SimConnect controls, more coverage is happening slowly but is nowhere near complete, and many of those they have provided do not work yet. MSFS is an evolving product, it just is nowhere near complete yet, and especially not in its support of external programs. There is a list of the state as we know it in your FSUIPC Documents folder. We put in requests to Asobo for more, and hope. Pete

The proper way to get consistent key cobminations in most programs is holding the 'shift' key (whether Shift, Control, or Alt) whilst then pressing the action key. The shifts are indicated to the program concerned by flags set in the action key's notification. At least that is the case for the key input methods used in FSUIPC (via WM_KEYDOWN and WM_KEYUP messages). I did read somewhere that MSFS uses a different method, and if so that might explain the difference in result. Either way, a "split second" doesn't seem to be sufficient to ensure consistency. Pete

I thought you wanted to assign to a button, and were using FSUIPC for your controls. If not, just use MSFS assignments, of course. But then why post in this forum? No, not at all. Leo Badnar cards should be usable directly in MSFS. What are you using FSUIPC for? I don't know Pokeys, sorry. Maybe post a new thread asking about that with Pokeys in the title. Then others who know my help. for that, probably best to post in the main forum where it will be seen by many other FSUIPC users, not just those on MSFS. Pete

A rotary encoder provides two button indication, one for clockwise, the other anti-clockwise. Thos are usually assigned to Increment and Decrement fuctions, either via controls or keypresses. But going back to your main question: Is it currently possible using keypresses, or keypress assignment in MSFS? If so, that's they way to go in FSUIPC -- assign the encoder buttons to the keypresses. (Re-assign the keypresses in MSFS if you find that not acceptable). Otherwise, please read on. In all previous versions of FS (and P3D for that matter) the control of the range (and other options) on the MFD/PFD has been a facility local to the gauge software doing the display. The only provision made by MS and L-M was for mouse click type control. In FSX we got around that by hacking into the code and accessing functions specific to the cockpit panel concerned so we could provide facilities which we call "mouse macros" -- basically a way of doing mouse actions using joystick buttons. With P3D4 and P3D5 we had persuaded L-M to implement functions to allow this in a more tidily and legal way. With MSFS such facilities are on the list of needs provided to MS/Asobo. They could, alternatively, look at providing the controls needed through their SimConnect interface, But there's still no many more basic things missing from that it might be a long time coming. So, sorry, it doesn't look likely that this will be feasible for a while yet. Pete

Yes, but changing the response in the sim doesn't really simulate that. Maybe having to move the controls further for the same effect will give you that illusion (I don't think it would for me), but really I can't see anything other than force feedback which can do the job. The "smoothing" is by the interpolation being made by FSUIPC between the points on the matrix represented in the graph. If you make single point changes in the slope number the change should be okay. I think it would be the best John could offer. Pete

Checking through the list of keyboard shortcuts you can use, I see "Display ATC" is assigned to "scroll lock" by default. If that can't be assigned in FSUIPC (not sure if SimConnect supports it), you could change the key assignment in MSFS that assign your button in FSUIPC to that keypress. Pete

Interesting idea for GA aircraft (airliners etc either have hydraulic or electronic links between controls and surfaces), but I don''t see why you'd need floating point values. The whole range for the value sent to the sim is -16384 to +16383 and increments below about 128, or even 256, are pretty unnoticeable. Also FSUIPC interpolates between the points in those slope graphs which are basically a simple matrix of y values by x points (sorry, can't remember the dimensions -- John would be able to tell you). Without supplying a complete replacement matrix I'm not sure how you would do it to result in something smooth enough. Maybe you are thinking that the curves are derived by some sort of mathematical formula like Fourier Transforms, which they are not. Perhaps the best way, and probably easiest, is just to use the -15 to +15 values available to you when adjusting manually -- i.e. a dynamic adjustment but operating like the actual calibration 'slopes' option. I can see that something like that might be implemented. And it would only need a single byte for each control surface axis (aileron, elevator, rudder, tiller). I know, though, that John is very busy, so it would be a matter of adding the idea/request to the list of things to do when much of the really serious stuff is properly resolved (hopefully with Asobo fixes to the interfaces). Just keeping track of the MSFS updates is a full time job. Pete

I wonder if this report might be relevant? That was part of this thread: https://forum.simflight.com/topic/91275-is-it-just-me/?tab=comments#comment-552215 Pete

I'm afraid FSUIPC3 is no longer supported. And when unregistered it really does nothing. Even the data is presents in its offsets is nearly all obtained directly from sections of FS9 memory, just as with FS98, FS2000, CFS and FS2002 and the first versions of FSUIPC. With FSUIPC4 and FSX, judging from your report it looks like any stutters which appear to be due to FSUIPC will be down to SimConnect, because an unregistered FSUIPC (one of your tests) does absolutely nothing after initialisation except receive the data it requested from SimConnect during its initialisation. Perhaps you need to consiider re-installing FSX, or at least starting it without the FSX.CFG file so that it reverts to defaults. The only known cause of stutters in FSUIPC is the use of the AutoSave, because it is then asking SimConnect to save a flight at set intervals. But even then they aren't noticeable unless you are using advanced add-on aircraft which also save data, or, less likely, your disk system is slow or fragmented and there's not enough cache space in memory, or disk caching is turned off. You should check the FSUIPC log file to see if any errors are reported. Maybe if the Sim is running "unleashed" (i.e. no frame rate limit or Vsync set) there's not enough time for even the actions of filling the offsets to be carried out. Timeouts would result in re-initialisations which would certainly cause a stutter. The lg would show this. With FSUIPC4 there's a parameter you can increase which sets the time out for SimConnect data updates. It's normally 1 (1 second). You could increase that. (This wouldn't apply to FSUIPC3). Otherwise, I'm sorry but, because there's nothing to look for as a cause of stutters within FSUIPC I cannot even start "looking at" it. Incidentally, FSUIPC3 dates to 2003 whilst FSUIPC4 to 2005. Perhaps it's time for a move to a more modern system? Pete

I don't know why you say "as you know" in you request for help. Having never heard of this product I searched for it with Google. The description on-line makes no mention whatsoever of needing FSUIPC, so where are you seeing this requirement? I'm always interested in knowing about commercial products using FSUIPC. Really the makers should ask us for permission or even agree to pay a fee from their consequent profits. It was through such funding that FSUIPC sustained continual development when it was free for users (1998 to 2004). [LATER] I looked this up on the App Store on my iPhone, and it says nothing there about needing FSUIPC either. It needs the Remote Server from the website. I see there's also a free app called RemoteFlight LITE, which is says is good for checking your connection. Again, no mention of FSUIPC. But perhaps you should try that to verify that the Remote Server is installed correctly? [LATER STILL] Aha! When you go to download the Remote Server, only then does it say you need FSUIPC, thus: SERVER REQUIREMENTS Microsoft Windows XP or later Microsoft .NET Framework 4 ( Available here or via Windows Update ) Compatible with various simulators (look below for details) FSUIPC library from Pete Dowson ( Available here )Unregistered version of FSUIPC is sufficient for RemoteFlight Server. Make sure you install FSUIPC for all versions of FS2020/FSX/P3D you wish to use. X-Plane users must use XPUIPC ( Available here ) instead of FSUIPC So, I downloaded the server and installed the free Remoteflight LITE on my iPhone, and it connects easily, though I have to press "Refresh Data" when MSFS is ready to fly. Note that you have to enter the IP address and the Port number displayed on the Server screen. The errors you are getting seem like you've not installed things properly. You also don't say whether those errors are shown when you try to start FSUIPC or when you try to start the RemoteFlight Server. Pete

The "type" in offset B004 is in fact decoded to the documented Lua types in WideClient for use in event.textmenu when it receives the offset data. The original data is actually the SimConnect type with additions. So, apologies, the offset documentation is currently wrong. The types and their Lua classification are: 0x000-0x007 SimConnect scrolling text line in one of 8 colours (Lua type 1) 0x100-0x107 SimConnect non-scrolling text line in one of 8 colours (also Lua type 1) 0x200 SimConnect menu (Lua type 2) 0x300 SimConnect message window (Lua type 4) 0x400 File display facility (Lua type 16) 0xFFF Active Sky weather summary for planned route (Lua type 8) The Lua types are bit flags which can be combined in the event.textmenu to trap more than one of these, hence the coding conversion. [LATER] Oops. I see John has also replied in the same vein! Pete

That sounds correct. Why mess up a working sync by trying to make Throttle 2 behave differently? Maybe I'm misunderstanding you? There's really no need to post all those pictures. Your words would have been sufficient. The pictures really tell me nothing extra. Incidentally, whilst I originally added the Sync Pos feature because of requests, I've never used it myself. It is quite realistic for the throttles not to be quite aligned to get the same thrust indications on the EICAS, especially as the aircraft ages. The controls may be set up synchronised ex-works, but then things change, especially anything involving mechanics and hydraulics. Pete

Yes, but you'd need an old version of WideClient on the XP machine as the later versions only work with Win7 and later. Nothing to do with 32- or 64-bit. Why not install the 32-bit version of Win7? You should always use the latest version of FSUIPC for your specific Flight Simulator. They all support WideFS. Pete

On my copy, Page 35 of the Advanced Users guide has a section entitled Automatic running of Macros and Lua plugins with instructions and examples. Do you have some sort of corrupted install? Also there are explicit instructions in this thread! Did you not read it first before adding to it? Look about 6 posts above your first post. Pete