Pete Dowson

Are, so P3D3.3.5 and Win10 were not a change before this happened? Sorry, it got very confusing in the messages above. So not even the Win10 updates of 3 days ago were a "change"? You see why I'm a bit dubious over this "nothing changed" claim? (If nothing changes then neither will behaviour). Pete

I don't think the keypress option will work once focus is in those Menus. I think you may need to use the controls accepted by SimConnect. Try assigning to the FS controls called Atc menu 5 and Atc menu 1. I can't guarantee those will work either, but worth a try. If you are editing the INI file then instead of the "Kn,8" assignments use "C66176,0" for the 5 and "C66172,0" for the 1. I know they are labelled as "ATC" responses, but the ATC menu is using the same mechanism as the GSX one, so there's a chance at least. Pete

Pretty major changes, and maybe something else you had installed is now behaving differently on Win10. Have you checked the Processes and Services running, yet? BTW in the last two messages you've been talking about "KeySend", which is the term used in FSUIPC/WideFS for special messages sent from FSUIPC to a WideClient on a network and programmed, often to a keypress, in the WideClient.INI file.. Did you really mean keypress assignments in FSUIPC, as when we started all this? Pete

No, no difference for sending it keystrokes. That's all Windows stuff. I have tested with P3D 3.3.5 on my main PC (win7). Well, something obviously changed somewhere. But you just said nothing was changed!? I'm confused. But have you checked that all the updates have installed? I notice there was yest another batch only 3 days ago. Anyway, for something to come between the definitely-accepted Windows API calls FSUIPC is making to get the KEYDOWN and KEYUP actions simulated (see below *) and the receipt of those messages in FSX or P3D, something is intercepting them first -- not not the real keyboard messages, which would be identical. So it must be something at a pretty low level which is interferng with the actual API calls somehow. This is why I'd suspect some service, running in the background. Pete * It uses a sort of recorded-keypress playback option which has been in Windows over many versions. The idea of using this is that the end results seen in the receiving program look identical to those it would receive from the real keyboard. The only ways it can be defeated is if the target program used a hardware-access polling method insted, which neither FSX nor P3D do. Hardly anything does, in fact.

Wow! I got FSX-SE installed on the Surface Pro really quickly! Good fast SSD in it! I've tested button assignments to keypresses, and it works fine. So either it is NOT a Win10 problem, or your Win10 is out of date or corrupt. I think you must have something else going on there. Check what processes you have running at the time apart from FS. Here's the relevant part of the Log from the Win10 machine: 887766 Button changed: bRef=0, Joy=0 (A), Btn=0, Pressed 887766 [Buttons] 35=PA,0,K81,8 887766 SendKeyToFS(00000051=[Q], KEYDOWN) ctr=0 887781 Sending WM_KEYDOWN, Key=81 (Scan code 16), Ctr=1 887797 KEYDOWN: VK=81, Waiting=0, Repeat=N, Shifts=0 887797 .. Key not programmed -- passed on to FS 887797 *** EVENT: Cntrl= 65552 (0x00010010), Param= 0 (0x00000000) SOUND_TOGGLE 887891 SendKeyToFS(00000051=[Q], KEYUP) ctr=0 887906 Sending WM_KEYUP, Key=81 (Scan code 16), Ctr=1 887906 KEYUP: VK=81, Waiting=0 887984 Button changed: bRef=0, Joy=0 (A), Btn=0, Released 888000 [Buttons] 35=PA,0,K81,8 So, I'm sorry, but I don't know what is interfering with this on your PC, but I'd try stopping all other processes and possible some non-Microsoft services too, till you find the culprit. Pete

Actually, the PMDG 737NGX and 777X implementations support their own full range of additional FS controls. The start levers are defined in the list ("PMDG_NGX_SDK.h! in the NGX SDK folder) as #define EVT_CONTROL_STAND_ENG1_START_LEVER (THIRD_PARTY_EVENT_ID_MIN + 688) #define EVT_CONTROL_STAND_ENG2_START_LEVER (THIRD_PARTY_EVENT_ID_MIN + 689) In other words, add 688 or 689 to the value defined as the ID_MIN earlier in the list. You assign custom controls like this in FSUIPC as <custom control> and enter the number in the space then available. I don't know if those controls toggle, or whether you have to have a parameter (1 or 0 maybe) to set them one way or the other. (I don't use PMDG aircraft). I don't know. Those two errors refer to C sharp and Visual Basic, and FSUIPC uses neither, but I suppose there might be something incompatible about programming keystroke inputs to programs. I've recently purchased a Surface Pro 4, and that comes with Win10 installed, so I try that -- need to install FSX on it first. I'll get back to you with results when I can, maybe next week. BTW, you have the same button sending Q twice (or rather, attempting to), so even if it did result in a "sound toggle" you'd not accomplish that: 14=PQ,2,K81,8 -{Key press: Q}-15=PQ,2,K81,8 -{Key press: Q}- Pete

I'm sorry, but I really don't know. As you say, Centre frequencies ARE Type 10 records within the AFD BGLs, but I don't know if that includes them all. However, the BGL documentation I hsve does include documentation of a "Boundary" type, which seems to allow definition of Centre, Class areas, Tower< Clearance, Ground, etc ... even Prohibited, National Park, Training. These records are not in the Airport BGLs I'm used to examining (type 3) but a separate type called "Boundary" (type 32). Link to documentation: http://www.fsdeveloper.com/wiki/index.php?title=BGL_File_Format Pete

Please post general and FSUIPC/WideFS support questions here, in the Support Forum proper, not in a Subforum not relevant to your question. Windows 10 makes no difference to FSUIPC or WideFS. But perhaps you are under some misunderstanding? What are you "installing", exactly? And is this for FSX, P3D or some old version of FS? It is very relevant! For FSX and P3D there is only one component of WideFS you need -- that is WideClient.EXE which is "installed" by simply putting it somewhere convenient on the Client PC -- i.e. the Networked PC, not the FS one. It will make a default INI file the first time it is run, along with a Log file. Pete

Ah, thank you very much for this report. Good news then! ;-) Pete

You can use renamed EXEs with FSUIPC, but you have to rename its files too -- including the Registration file, and the INI file with your settings. You should have noticed that the LOG and INI files it made were not "FSUIPC4.LOG" and "FSUIPC4.INI". That would have pointed immediately to the problem. This is all part of a facility to allow the use of different settings for different purposes and is explained in the section Multiple INI files on page 49 of the FSUIPC4 Advanced Users guide. That section talks only about FSX, but most of it applies to P3D too, though perhaps not the part about renamed P3D CFG files. L-M may not have implemented that facility, I haven't checked. Pete

Er ... that would certain mess FSUIPC's installer up! But if that was the case how come Checking version of the Prepar3D v3 EXE:... Version 3.2.3.16769 (Need at least 1.0.677.0) was logged by the installer? It can't do that if you change the EXE name. In fact that would mess the run-time actions as well! For now EXACTLY as I asked in my last message here! Did you not read to the end? Pete

Oh, sorry, I didn't realise they were links -- folks never seem to do that here. They either paste them in or attach them. I thought they were just underlined and coloured for emphasis. BTW both logs are of course identical. The installer places the same log in its own folder and in each installed copy of FS it encounters. It performs all of the installer actions in one session and produces just one log. Note: in the last install log, the one you pasted just above, it says: Registration dialog exit: selected FSUIPC DELETEDeleted previous registration ... What were you doing there? It is not the same as the log you linked to originally. Also it contains this strange error Failed to install "FSUIPC4_Loader.dll" Error 32 reported ("El proceso no tiene acceso al archivo porque está siendo utilizado por otro proceso. ") in the FSX install section, which the linked one did not. The error is " The process can not access the file because it is being used by another process. " -- what was using a DLL installed in the FSUIPC Documents subfolder? What other processes were you running at the time? I see you are still using P3D3.2. Any reason for sticking with that? I think 3.3 offers more stability and of course other improvements. Anyway, the installer log shows nothing else wrong, only those two oddities. The same registration would have been automatically placed in both sims. So it must be a run-time thing. For that I need to see the FSUIPC4.LOG file, from the P3D Modules folder, please. Don't enable any looging options or click "New Log", just run P3D, get to a "ready to fly" point, see that FSUIPC says unregistered, then close P3D down. When completely closed, get that Log file. Pete

There's been no change in how key presses are sent for many years, and as far as I can tell it works no differently in P3D 3.3.5 than in any previous version or FSX. If you enable Event logging too you'd see that the Sound toggle event will be sent by FS as a result of the keypress. Well, there's no difference. Both logging is correct. The "Key not programmed" bit is not present with the button assignment simply because FSUIPC is not intercepting Key Presses that it sends. If it did, and you'd programmed that keypress in FSUIPC, it could easily end in infinite loops being created. I have the Q keypress assigned in P3D 3.3.5 to its default, the sound toggle. I assign a button to send a Q keypress. Here is what it looks like pressing Q on the keyboard: 582320 KEYDOWN: VK=81, Waiting=0, Repeat=N, Shifts=0 582320 .. Key not programmed -- passed on to FS 582320 *** EVENT: Cntrl= 65552 (0x00010010), Param= 0 (0x00000000) SOUND_TOGGLE 582476 KEYUP: VK=81, Waiting=0 And here is me using the button I assigned to press Q: 195360 Button changed: bRef=0, Joy=101, Btn=0, Pressed 195360 [Buttons] 126=P101,0,K81,8 195360 SendKeyToFS(00000051=[Q], KEYDOWN) ctr=0 195360 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000001} 195360 Sending WM_KEYDOWN, Key=81 (Scan code 16), Ctr=1 195469 SendKeyToFS(00000051=[Q], KEYUP) ctr=0 195469 KEYDOWN: VK=81, Waiting=0, Repeat=N, Shifts=0 195469 .. Key not programmed -- passed on to FS 195469 Sending WM_KEYUP, Key=81 (Scan code 16), Ctr=1 195469 *** EVENT: Cntrl= 65552 (0x00010010), Param= 0 (0x00000000) SOUND_TOGGLE 195469 KEYUP: VK=81, Waiting=0 195563 Button changed: bRef=0, Joy=101, Btn=0, Released 195563 [Buttons] 126=P101,0,K81,8 195563 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} Now if you compare this to your log extract you'll see that the ".. Key not programmed -- passed on to FS" bit is missing in yours. I don't know why that might be, except for the possibility of something else having the Focus at the time maybe, or intercepting the keypress before FSUIPC sees it. I don't *think* there are any FSUIPC options which alter this behaviour, but if you show me your FSUIPC4.INI file I will check it out. BTW, just as a matter of interest, if I program keypress Q to "sound toggle" in FSUIPC instead of relying onthe P3D assignment, I get the same end result but it is FSUIPC sending the event instead. Here: 1290612 Button changed: bRef=0, Joy=101, Btn=0, Pressed 1290612 [Buttons] 126=P101,0,K81,8 1290627 SendKeyToFS(00000051=[Q], KEYDOWN) ctr=0 1290627 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000001} 1290627 Sending WM_KEYDOWN, Key=81 (Scan code 16), Ctr=1 1290627 KEYDOWN: VK=81, Waiting=0, Repeat=N, Shifts=0 1290627 FS Control Sent: Ctrl=65552, Param=0 1290627 .. This key is programmed in FSUIPC4 'Keys' options 1290627 *** EVENT: Cntrl= 65552 (0x00010010), Param= 0 (0x00000000) SOUND_TOGGLE 1290768 Button changed: bRef=0, Joy=101, Btn=0, Released 1290768 [Buttons] 126=P101,0,K81,8 1290783 SendKeyToFS(00000051=[Q], KEYUP) ctr=0 1290783 JoystickValues PCnum=0, dwCount=1, data[2]={00000065 00000000} 1290783 Sending WM_KEYUP, Key=81 (Scan code 16), Ctr=1 1290846 KEYUP: VK=81, Waiting=0 The order of the logging ("Control Sent" before "This key is programmed") is only odd here because there are several things happening all at once and all competing for the log addition. Naturally the key programming in FSUIPC is detected before the control is sent, but the logging is just after. Pete

You should register in the Installer. It will apply to both FSX and P3D. The FSUIPC4 Install log file is produced for a purpose. It will show me what you are doing and what happened. That is what it is for. Why not paste its contents here so I can see it? Pete

Yes, but this is for a window created by FSUIPC on request of that program. FSUIPC uses direct calls into parts of FS to get them created for it, and it can remember and re-establish positions and sizes. GSX and ProATC/X don't use FSUIPC for those menus, they use SimConnect. Maybe some SimConnect windows do have positions and sizes saved in the Flight files -- did you check? -- but if not I think they are simply sized and positioned by SimConnect automatically. The functions supported by SimConnect for this do not allow for these things to be specified by the programs. Pete

Yes. The EXE wouldn't launch because the ClassInstance=0 parameter makes it pretend to be FSX/P3D, and you can't have two copies of either running at the same time on the same PC. That's why you changed the ClassInstance parameter! However, the Log you attached doesn't show a connection -- it doesn't see a Server named "DISCOVERY_80_SERVER". Are you sure that's a correct name? I think the name is limited to something less, like 11 or 12 characters! Pete

Er, really? If you don't use WideClient.exe, then nothing will ever talk to WideServer, so it will always say "Waiting for clients"!!! The WideCliennt.INI goes in the same folder as WideClient.exe, and that is where the LOG is generated when you run that WideClient.exe. If you don't run WideClient there's no point enabling WideFS in FSUIPC on the Server! I think you don't understand anything about WideFS! It takes one SERVER, and one or more CLIENTS. With no clients where is no point! There has to be something taslkning to WideServer, and that can only be WideClient! Please read more about what WideFS s all about in the documentation included in the ZIP package. Pete

You have axes assigned in FSUIPC, so what are you doing enabling controllers in FS? You MUST choose one or the other! Furthermore you even have duplicate assignments in FSUIPC. You could have seen this yourself: 0=0X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=0R,256,D,2,0,0,0 -{ DIRECT: Elevator }- 3=0U,256,D,3,0,0,0 -{ DIRECT: Rudder }- 4=0S,256,D,36,0,0,0 -{ DIRECT: SteeringTiller }- 5=0T,256,D,2,0,0,0 -{ DIRECT: Elevator }- 6=1X,256,D,1,0,0,0 -{ DIRECT: Aileron }- Devices are: 1=BU0836 Interface 0=Plasma-MM2 2=Plasma-MM2 I've no idea what a "Plasma MM2" is, and I assume you have your own stuff connected via the Bodnar board, but as you can see you have two assignments to Aileron, one on the Bodnar, one on the first MM2, ands 3 (THREE!) assignments to the elevator -- two on the Bodnar, and one on the first MM2. Now this can work -- FSUIPC arbitrates between multiple assignments and uses the one with the most deflection -- but is that what you intended? I can understand 2, for a dual cockpit, but 3 seems excessive. You don't have anything assigned to the second MM2 in FSUIPC. You DO have assignments to both rudder and tiller, in FSUIPC, ad so the Bodnar board. Not only are these things assigned, but they are also calibrated, so you've evidently got them working already: SteeringTiller=-16380,-512,512,16383 Rudder=-675,-675,-675,-675 SlopeSteeringTiller=9 Aileron=0,1264,16383,16383/8 Elevator=13723,13723,13723,16380 However, the Rudder calibration is completely wrong -- I'm not surprised is remains locked over in one position. Also the Aileron is calibated with only one side working, and the elevator calibrated with only the other side working. You obviously have not bothered to follow the documented steps to proper calibration as laid down in the User Guide! The tiller calibration is defaulted, though you've set quite an extreme sensitiivity slope. There's no point in providing the FS assignments file. I assume, as you are assigning in FSUIPC, that you've switched controllers off in FS. The file doesn't tell me either way. Pete

The Installation document provided in the downloaded ZIP file actually lists everything installed and where it goes. Pete

Did you not read the part I mentioned just? Seems a long long time without reference to provided documentation. If it isn't assigned it isn't scanning it. If you want me to check your settings, just cut and paste your FSUIPC4.INI file into a message here. You'll find it, as with all things to do with FSUIPC, in the Modules folder. Note also that there is often no point assigning things in FSUIPC if you have all you need in FS. Themain point of FSUIPC assignmetn, apart from supporting some functions not listed by FS, is to enable different assignmetns for different aircraft types -- yokes vs sticks, for example. Also, you do NOT have to assign in FSUIPC to use FSUIPC calibration -- the calibration works on exis commands not on joysticks, so works no matter where you assign. Pete

This is the Support Forum. All of the links in my programs, documentation, on the download sites, everywhere, point here. The latest are at the top, and they are in order thereafter. You can always find links to all the posts you made, as in most Forums of this nature -- just click on your log-in name, top right, choose Profile. When you say "programming" I assume here you mean simple assignment? Are you saying it remains blank when you move your elevator axis? Or simply that X appears again? If the latter it is merely because your X axis is more sensitive or is jittering a little when you move the elevator. Just use the Ignore to temporarily ignore that axis (it only lasts this visit), then rescan, as documented in the User Guide. Pete

I think the size is determined automatically to best fit the content. All this is part of the FS functionality. It isn't really a user option. Pete

Multiple actions of any type can be configured in the FSUIPC4.INI file itself. The format of the parameters is defined in the Advanced User's guide. You just have a list of assignments to the same button, and they are executed in sequences according to parameter number. Pete

Can you clarify what add-on menus you are talking about? The built-in FS menus are like any Windows app, brought down from the fixed position menu bars, and the don't go ti "random sizes and positions", and the ProATC/X and GSX menus are like the built-in ATC menu (made the same way by SimConnect-controlled FS functions) and always appear central and of standard size unless you've moved them yourself. Pete

Unless whatever it is you have using offset 66C0 etc can be changed to use the offsets which read and write L:Vars. Pete