Pete Dowson

Weird that they didn't before! I wonder what was doing that? Oh, so the 2080 upgrade was worthwhile then? I'm reserving judgement. My 1080Ti's are never getting over 40% usage -- my limit is the 100% core 0 (or whichever I allow first) usage. I need a 6GHz processor! Pete

Strange. That option doesn't normally also hide extensions (you said you said "8 FSUIPC listins" -- though what they all are I don't know. There should be FSUIPC itself, the DLL, then an INI, a LOG, and a KEY file. 4 files looking like "FSUIPC" if the filetype is hidden). Easiest just to delete the lines dealing with the button/switch in question -- the numbers after the P (for Press, R (for Repeat) or U (for Up or Release) are the joystick ID (number or letter) then a comma and the button number. What "calibration problem" are you having? The normal FSUIPC Options calibration should do all you want, unless you want some sort of restriction or scaling for the axis values. I use PFC axes throttle quadrand, yoke, pedals) with no trouble using normal calibration. Pete

You register with the FSUIPC installer, as it was with FSUIPC4. If you've already installed FSUIPC5 that's okay, just run the installer again and this time register both. Pete

Very strange. that can normally arise only from editing the INI file to make it so, as a different assignment in the Options replaces the previous one. You have Windows Explorer still hiding known filetypes from you! There are instructions in the User Guide to turn that annoying option off. (See the section entitled "Finding and Editing files relating to FSUIPC and WideFS" quite near the beginning). The INI file is the one with description something like "configuration settings", whilst the "text file" is the LOG file. Best to turn the explorer folder option to stop hiding such things from you. Pete

The latter. WideFS7 is still WideFS7. Pete

Testing without Prosim running (i'm on my development PC -- won't be able to test in the cockpit till Monday), but using the Prosim 738, when lowering the gear, whilst the gear handle position goes from 0 to 16383 instantly, the three separate position readouts change,as the gear drops, to 16383 also. I therefore do tend to think that the 16381 values you get indicate that the gear is not fully down and locked. Checking the log and seeing the actual SimConnect values would confirm that. The log entries should end up showing something like this (for the three values): 3015640 Monitor IPC:0BF0 (S32) = 16383 3015640 SimRead: 0BF0="GEAR RIGHT POSITION" FLT64: 100.000015922 The fractional .000015922 should be ignored I think -- a quirk of whatever computations take place in P3D. This is with P3D4, but on Win7, not Win10 (though I don't see how it's anything to do with anything in Windows). Pete

Try re-running the FSUIPC Installer. No need to re-register, and it won't change anything EXCEPT to clear a flag in the Registry which was set by a previous P3D crash. There will also be details of the crash somewhere in the Windows Event Viewer. So next time, please check there and supply those details. Finally, please always post the contents of the FSUIPC4.LOG file (from the Modules folder). Pete

What am I supposed to look at here? Your message is rather curt to say the least. From your subject title, the only clue you give, SerialFP2 is not my program. For that you need VSI support. Pete

Was that an FSUIPC5.INI file (i.e. were you using P3D version 4 before as well? It is likely that the IDs of your devices have changed. Check the [JoyNames] section in your cvonfig file, see if they IDs there correspond to what you see for Joy# when you use the Button or Axis assignment tab. By "using admin rights" do you mean "...as adminitstrator" in the right-click menu? Did you let P3D install in Program Files, rather than choose a separate folder, like C:\Prepar3D? Win10 is much more strict on permissions, and sometimes there's a setting that prevents the Installer setting the Modules folder permissions sufficiently. Is there an FSUIPC5.LOG in the P3D modules folder? Is the INI file there the one you tried to copy there? Perhaps you could show me the FSUIPC5 Install log? Pete

FSUIPC5 is NOT FSUIPC4. You need to purchase a key. Pete

Yes, they are designed to be used with click spots on aircraft panels. They are NOT emulating a mouse. Pete

I don't think so. Do they read 16381 or 16383 with default aircraft? Can you show me the FSUIPC log showing the monitored values, please? The original SimConnect value will also be logged, which would show whether FSUIPC was acting correctly. FSUIPC converts a "percant" value as supplied by SimConnect (actually a fractional value between 0 and 1) to the range 0 to 16383, to make it common with FS9 and before, which always used a 0-16383 system for percentages. Does Humberto say that the reason for the 3 reds is that the values are not 16383? I'll check here to see what I get, but there's been no such problem with ProSim for me (though at present I'm still on 2.08). Pete

Sorry, I don't understand -- "interruption"? How do you mean? That certainly is strange as FSUIPC is using standard DirectInput methods. Without resorting to raw serial USB port treatment (which you can program via the com library in Lua) there's nothing more it can do. Pete

Actually it doesn't say to read the result in the same process. I don't think that can work with Wideclient. The L:Var is obtained by a request to PANELS.DLL in the Sim. The way to do these things (and there are others, for instance when reading weather stuff), and especially in WideClient, is to write something impossible to your offset, and the offset address, and the L:Var name, which can all be one process. Then, separately, wait for your impossible value to change in your offset. That would obviously require some sort of process loop. If the application needs much more immediate access to such values there's really no way other than running only on the same PC. Even then I'm not sure it can be guaranteed in the same process. Pete

Well, it would probably have been quicker to refer to the documentation supplied than posting here. But, still, here goes: Offsets are listed in the Offsets Status document installed in your FSUIPC Documents folder. Searching that quickly finds the following (after a few other references to other "gear"): 0BE8 4 Gear control: 0=Up, 16383=Down 0BEC 4 Gear position (nose): 0=full up, 1 6383=full down 0BF0 4 Gear position (right): 0=full up, 1 6383=full down 0BF4 4 Gear position (left): 0=full up, 16383=full down where the '4' is the number of bytes. So they are 32-bit (4 x 8 ) integers, or type "U32" (unsigned 32-bit). In the Logging tab in FSUIPC options, right-hand side, you can see monitoring values by offset. You will use all 4 entries, with the above offsets and all of type U32. (This Logging facility IS described in the FSUIPC User Guide which you can also find in the FSUIPC Documents folder). Below the table of 4 there are options. I would recommend both normal logging and FS Window options checked. Then you have a record of the offsets changing in the LOG file, as well as being able to watch them on screen. Pete

No, you are okay. FSUIPC5 does have a different interface for 64-bit programs (which isn't supported in FSUIPC4 and earlier), but existing 32-bit ones are okay with the older interface. And there's nothing extra fror 64 bit programs. Ah, you found out! 😉 Pete

Isn't that what it does in any case? It's a Windows thing. That runs a program, You originally seemed to be asking to switch to a running program, which is all ALT TAB can do. You can do this with h = ext.gethandle("name") --name is program name incl .exe, or program title (as listed in Task Manager) ext.focus(h) Oh, and, sorry, i misled you about needing WideClient. You can use the ext library in FSUIPC too -- I forgot I added that library to both! 😞 Just same the above short two-lines program as, say, "usexxx.lua" where xxx suggests the program you are switching to, then, in FSUIPC, assign your button or key to Lua usexxx. Pete

The joystick number 1004 is the joystick with ID 4 on the PC running WideClient, the first in WideServer's list. (The button number is 16 in both cases). Looking at the Logs, I see that you are running WideClient on the same PC as the sim (using ClassInstance=0). So, since you still have Wideclient scanning buttons (as it is supposed to do), it sees the button and sends the press to FSUIPC, as it is supposed to do. You can stop WideClient scanning buttons by setting "ButtonScanInterval" to 0 in its INI file. It means what it says -- the button scanning thread has been started. You changed the Log option to "Yes" which makes Wideclient log a lot more information. It defaults to "Errors+". Pete

Google translation: Good, So just the wrong parameter. (By the way, 536870912 = x20000000). Pete

Google tells me this means: Keyboards do repeats automtically. Are you pressing the key for too long? If not, please enable Button/key ;gging and Event (non Axis) logging in the Logging tab of FSUIPC, then repeat the attempt, and show me the log file (in the Modules folder). Also please show me the INI file (FSUIPC configuration settings) so I can check your assignments. Pete

Okay. Thanks for letting me know. Pete

Wasn't that the display shown in the picture you posted earlier? If so, as I computed for you, it has the vertical speed correct. Unless Smartcars is using FSUIPC to get its data, then it cannot be using that offset. The offsets are part of FSUIPC now -- only in FS98 were they in the Sim. The work involved in developing successive versions of FSUIPC was in tracking down the locations of the values needed in each new FS version. That changed in FSX when SimConnect was invented, with my involvement, to make it all easier and hopefully version independent. Pete

The reason for the apparently odd units in many FSUIPC offsets is that those were the units actually found in the locations equivalent to the offsets but in the FS98 module called "GLOBALS.DLL". Since the prime purpose of FSUIPC through all the versions of FS from and including FS98 (released late 1997) has been compatibility, the units in those equivalent offsets are the same as the older original units. Newer added offsets can use later appropriate units, but forcing older programs to be revised has always been avoided as a main FSUIPC policy. To convert the 256*m/s units into fpm, simply multiply by ((60*3.28084)/256). If you are not writing a program to interface to FSUIPC to do this, then use a Lua plug-in, which can of course then display the results in real time. Pete

Thank you. But after looking again at your previous posting, I think you are just confused about the units. (as, I hope, I clarified in my post previous to this). Pete

Going back to this. You are talking about feet per minute,. -879 is 256 x 3.4336 metres per second. 3.4336 mentres = 11.265 feet, 11.265 feet per second = 675.9 feet per minute., which agrees with the display in the picture you showed. So, there is no difference! Please do be aware of the units being used. Goshob himself did recognise that the offset values were 256 x mps. Pete