Pete Dowson

Then you didn't find offset 03C0! Note that, as it says, you need to actually have the relevant joysticks actually scanned by FSUIPC, which means at least something assigned. But then the same applies in the Lua library facilities. BTW the FSUIPC you are using is out of date. You should update. Pete

There's the problem. the version information is not being supplied by Windows! I assume that was a typo for 4.4.16.27077? I'm afraid this will need further investigation with added logging. i'll see if that can be dealt with tomorrow and let you know. Pete

Very strange. This implies that the standard Windows function "GetFileVersionInfo" failed, or at least returned wrong information. It examines the version information in Prepar3D.exe in your main P3D folder. Perhaps you could find that, right-click on it, select Properties and ensure that it too shows 4.4.16.27077. That P3D version shown later (time 75141) is supplied by SimConnect after connecting, too late though for correct FSUIPC initialisation. Can you also try running P3D by right-clicking on it and selecting "run as ... administrator". This gives it extra privileges. Maybe Windows is preventing the version info being read!? (Which would be very bad). One other check you could do, please. In FSUIPC's Options, go to Logging. In the Monitor facility, right hand side, enter 3124 for the Offset and U8 for the Type. Then check Normal log below, and see what FSUIPC logs for the value in 3124. Failing help provided by these actions, I will probably have to provide a test version of FSUIPC with extra logging around the code concerned. Pete

Well, many users are certainly using Win10 1809 without such a problem. Could you paste the entire (new) log please? Did you try the Client re-install as suggested? Pete

Well, one of the modules in your 4.4 installation is corrupt. The message you showed refers to the list of FS controls FSUIPC obtains automatically. Try re-installing the P3D client (only). that doesn't take log (uoi need to uninstall first via the Windows "Programs" app -- you can do this and retain your registration). If you still need to come back here, please paste the entire LOG file after closing P3D. You can use the <> button above the edit area in order to enclose it tidily. Why aren't they posting here, then? This aspect of FSUIPC hasn't changed since P3D4.1 times and the versions of FSUIPC since then. Before that FSUIPC provided a fixed list of FS controls which didn't change with P3D additions. Pete

You posted in the FAQ subforum! Please always post support questions to the SUPPORT forum -- i.e. here. I've moved it for you. Something is wrong with your P3D installation! The message only appears with versions of FSUIPC later than 5.1 if it detects too early a version of P3D. FSUIPC uses facilities only added since P3D4.1. Please look in the P3D Modules folder for the FSUIPC5.LOG file. It will show what version it detects. Paste it here if you cannot figure it out. Also check the version number stated by P3D in its menu. Pete

That sounds like you haven't disabled controllers in P3D, so it will be operating according to its default assignments for your device. You either need to assign everything in P3D, or everything in FSUIPC. (Axes assigned in P3D can still be calibrated in FSUIPC is desired). Pete

If you check through the SimConnect variables available to read, and do find something else other than the ones already supported in FSUIPC, hen by all means it can be added. But I'm afraid we are not hacking into the internal code of the Sim these days. The list of available SimConnect variables can be found here, under the heading "Simulation Variables" in the SimConnect API section.http://www.prepar3d.com/SDKv4/LearningCenter.php Good luck. I think you'll find that FSUIPC already reads all those concerned with air pressure. Both John and I are of the opinion that it isn't re-calculated "in real time" but only based on QNH or altitude changes of a metre or close. Maybe your only recourse is to interpolate for lesser changes. Pete

The queuing of the requests. Unless you limit the number of values from the axes to the sim (by imposing a sufficient delta (minimum change), then the messages pile up in WideFS's memory and in the Windows message queue at the server end. I think that's the reason for the symptoms you observe. That's okay for variables you are reading. For writing each write is a record in memory. The allocation is dynamically increased to match needs, I think it isn't suitable for the purpose you are putting it to. It was not designed for such use. The design and protocol was fixed in FS98 days and was specifically to enable cockpits to be built with indicators and switches located in the cockpit using lesser and smaller computers to reduce the connections to the server. Very early on it was discovered that this did not suit analog inputs used for real time control of flight. Since SimConnect was introduced in FSX, back in 2006, there has been no point in changing WideFS's main protocvols and ways of working because SimConnect offers a more direct route into the Sim and with Networking facilities built in. Compared to that, WideFS's route is very cumbersome. FSUIPC uses SimConnect for almost all of its actions. Pete

It is really a very bad idea to have flight controls such as yoke connected to your flight simulator via a Network. You need to connect all axes direct to the main PC. This is why WideClient only provides support for buttons and switches. I've no idea what is causing your need to have WideClient reconnect. Each time it does so there's a big setup delay in any case whilst it re-requests all of the variables it was monitoring for you. And the excessive loading by WideClient on your PC will be caused by Client program request process, nothing else. The need to forcibly close WideClient at the end indicates some sort of Network software problem. Pete

If your question is "can FSUIPC handle these makes of devices", then my answer is: I don't know. You would need to ask those makers if THEY support FSUIPC offsets for their switches etc, and conversely can read them for their indicators. I suspect they would all have drivers which interface more to SimConnect, readng the Flight Sim values more directly. But I have no way of knowing. You need to ask them. In Mark's reply "your software" means either software YOU write yourself to suit YOUR hardware, or the software written for the purpose by the hardware maker. In other words, "it is all possible, and this is how". Pete

Sorry, I still don't understand why you need the 4 repeated? And where are you saying you want it repeated? On the About screen, in the Documentation? Why have you got all these versions anyway? Only one installer version of FSUIPC4 is supported, (4.974) and there's currently one update for it (4.974b) which is also supported The download area here clearly states the full version numbers, so (I've highlighted them in red so you can find them next time!): FROM THE UPDATED MODULES area of DOWNLOAD LINKS subforum: Install complete FSUIPC version 4.974 Install FSUIPC4.974 for FSX, FSX-SE and Prepar3D versions 2.5, 3.0 - 3.4 (32-bit only: all versions to date of release) Changes since 4.96 are now included in the History document in the FSUIPC Documents folder supplemented by the Changes document in the ZIP. FSUIPC 4.974b DLL only, for current 4.974 users FSUIPC4974b.zip -- This interim update provides an improved Lua ext library. Those included functions operating on external application windows now more reliably find and act on the top level window, as generally necessary to have effective keyboard and state changes (min/max etc) recognised and acted upon. Pete

That looks like the result of a couple of overlong or improperly terminated Taxiway names. The Runways.txt file is oanly a log of the processing being performed. Are the end results okay? check the T5.csv file in the CYYJ entries. If you send me the BGL (only) responsible (as logged in the header to the section your showed) I can see if it an error in the BGL or some condition that MakeRwys should deal with. Send ZIPPed up to petedowson@btconnect.com. Pete

WideClient can handle buttons and switches over the Network fine, no problems at all. but for the control axes mentioned by John you need to connect them directly to the main simulator PC. WideClient does not offer facilities for those because of the response time you'd get -- maybe only milliseconds, but enough to make flying a rather haphazard business. Pete

Where? Why? FSUIPC4_4.974 makes no sense really. It is FSUIPC version 4 subversion .974 or FSUIPC version 4.974, which seems the clearest to me. Duplicating the 4 makes it 44974. Pete

Sorry, but that facility is still WideClient only. The event.textmenu() in FSUIPC5 only deals with text messages and menus from SimConnect. I expect the file display option could be implemented,in FSUIPC5, but it is a separate lump of code. Maybe it could be fitted into a future release. Pete

and Are all these WideClients running on the same PCs, or separate PCs for separate simulators? I think you need to show me the WideClient and WideServer LOG files for the occasion where yo need to restart, and maybe after you restart, so I can see the difference. Because wideClient won't know if it's the first, second, or nth startup. Pete

From the Log I see that there are two devices in the Registry with the same ID: 218 Device acquired for use: 218 Joystick ID = 6 (Registry okay) 218 6=Generic USB Joystick 218 6.GUID={F8E14780-0113-11E8-8001-444553540000} 218 Device acquired for use: 218 Joystick ID = 6 (Registry fixed) 218 6=Logitech Extreme 3D 218 6.GUID={212E2D20-8E24-11E6-8001-444553540000} Note that in the second one there's a note "Registry Fixed". This wil be because your FSUIPC5.INI imposes that ID nnumber (presumably for a joystick you already had, and with assignments too. You can change the ID for the first Device 6 in one of two ways: 1) Edit the INI file and give it an unused number there (8 seems to be the first such). This generally succeeds (it has to correct the Registry, and will result in "Registry fixed" for the item changed). OR 2) Use the JoyIDs program to change it. See the FAQ subforum thread entitled I can't tell from the Log (only the INBI), but I do hope you are using Joy Letters, because withe 8 different devices almost any change can mess up you assignments -- more noticeably Windows updates or new device additions. Once you have them all safely assigned letters, when you add or remove a device, just delete all of the Numeric entries in the [JotNames] section of the INI, leaving only the letter ones, so that the scanned IDs can take precedence over any old ones you have. Fixing joystick connections not seen by FSUIPC If this doesn't work I need to see other files which contain salient data, from the Modules folder: FSUIPC5.INI FSUIPC5.Joyscan.csv Pete

I assume you are looking at the PMDG 737NGX offset document installed in FSUIPC documents subfolder? I don't use PMDG aircraft, but are you sure they don't use the standard FS/P3D facilities for radios? I would think they'd have to because other things (like ATC, ILS, VOR), operated by the Sim, use them too. For FS/P3D offsets you need the Offsets Status document, in the same folder. Pete

In the latest version of FSUIPC5 you can use the event.textmenu() function in an FSUIPC plug-in. Is that sufficient for your needs? The transmission to WideFS is by private offsets, so I expect offset access would be possible if you wanted to monitor these yourself rather than use a plug-in. I'd have to check the code first, though. Pete

Must have been some sort of corruption somewhere in the previous install. Glad you got it fixed. Pete

You probably posted to the wrong place. This is the support forum, here. The SubForums above all all specialised or reference forums only. ALWAYS post support questions in the support forum please. (John moved ths post here so I'd notice and deal with it). Are those devices COM port serial devices, using PFCFSX.DLL, or more modern USB ones using PFCHid.dll? If the former, how are you connecting the devices to the PC? If through one of those USB adapters, then that is likely the problem. When I tried those (and I went through several makes) they never worked reliably enough for the sort of traffic the devices impose. I now always use a PCI or PCI-E card providing an RS-232 socket on the back of the PC. The best make is Brainboxes, but there are cheaper ones which are probably just as good. If they are HID devices then I'm sorry, I've no idea. You might want to try different USB sockets, or a better powered hub. Pete

It actually arrives as a double float (FLOAT64), which is just a number in Lua's terms. There's only one "number" type in Lua, so it is something you don't need to worry about. Well, that depends on what sort of values you expect or want to deal with. Lua numbers are all floating point and therefore also signed, but many applications of L:Vars are neither -- eg plain 0 and 1 for OFF/ON. but 0 and 1 will stil be okay whether signed or unsigned and whether fixed point orfloating point. In other words it is your choice what you want to see in your offset. If you elect for fixed point and there are fractions, FSUIPC will round it to the nearest whole number. But a negative number stored as unsigned will look to you are a very large positiive number). Hope this is clear? Pete

There's something wrong there, then. Enable Button/Key logging in FSUIPC's Logging tab, then operate the buttons. See what gets logged. Switching "up"? What sort of buttons on screen are you talking about? Most CDUs don't have up/down toggle switches. Of course, I don't know the Airbus. I'm just concerned that FSUIPC is doing the right things. How they then work on yor add-on aircraft is a seperate problem which i cannot really solve -- it may be a matter of experimentation. Don't FSL provide keyboard short-cuts? Or are there L:Vars which work. Mouse macros sometimes need you to experiment with the code. If you are using P3D4, the standard code is 3. That means "single left click". There's a list of the codes in the Advanced User's manual, Just search for the Mouse macro section. Pete

If you mean Shift + E + 2, you pressed Shift + 2, no P.. Shift + 2 invokes PANEL_2 660593 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1660593 .. Key not programmed -- passed on to FS660796 KEYDOWN: VK=50, Waiting=0, Repeat=N, Shifts=1660796 .. Key not programmed -- passed on to FS 660812 *** EVENT: Cntrl= 65907 (0x00010173), Param= 0 (0x00000000) PANEL_2660937 KEYUP: VK=50, Waiting=0660937 KEYUP: VK=16, Waiting=0 BTW, what is sending all those "SMOKE_OFF" controls? Whatever it is might be the cause of your problems. I've been re-checking exactly what happens with Shift+E followed by a select 1-4, and if there are intervening controls, like all those SMOKE OFF ones, you probably do need TimeToSelect=4 left alone. That works fine here, on two separate systems, and with my Prosim 738 (version 1 with the older door system) I can most definitely and consistently choose which doors open -- SELECT 1 works both passenger doors, SELECT 2 works both service doors, SELECT 3 the aft cargo door, and SELECT 4 the forward one. (The latest Prosim 738 has separate controls for each AND the emergency overwing 'doors', but that does it by using L:Vars instead, so needs a Lua plugin or L:Var macros. The plug-in is better as you can then also adjust the rate of opening/closing). Pete