Pete Dowson

I see. That ecplains it. There is no "assignment" possible in "Joystick Calibration". It's only calibration of axes already assigned! That's the whole point. You can assign anywhere. FSUIPC assignments are done in the Axes tab! That is evidently why you have to assign in FS instead! I find it puzzling that you do not seem to know this yet your INI file shows that you HAVE made FSUIPC axis assignments before! Quite a lot in fact, and several very sophisticated ones: 0=CX,69,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 1=CY,1,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- 2=AX,1,F,L74:V,0,0,0 -{ TO SIM: LuaValue TDC_CursorX }- 3=AY,1,F,L75:V,0,0,0 -{ TO SIM: LuaValue TDC_CursorY }- 7=AZ,1,F,66423,0,0,0 -{ TO SIM: AXIS_THROTTLE2_SET }- 8=AR,256,F,66420,0,0,0 -{ TO SIM: AXIS_THROTTLE1_SET }- No, not true. Only when ASSIGNING in FSUIPC. It doesn't matter where you assign, but do NOT mix up FSUIPC assignment and FSUIPC assignment. If you do decide to assign in FSUIPC (as you already have for many, as shown above), be sure to disable controllers in FS/P3D Just delete the lines I showed in my previous reply, EXACTLY as I suggested there! That's why I gave you those instructions. Er .. once as a Joystick and once as a Throttle. It evidently presents itself to Windows as two devices. Or don't you have both parts? Surely you do, because you've already somehow made FSUIPC assignments to the Joystick part: 0=CX,69,F,65763,0,0,0 -{ TO SIM: AXIS_AILERONS_SET }- 1=CY,1,F,65762,0,0,0 -{ TO SIM: AXIS_ELEVATOR_SET }- and FOUR assignments to the Throttle part: 2=AX,1,F,L74:V,0,0,0 -{ TO SIM: LuaValue TDC_CursorX }- 3=AY,1,F,L75:V,0,0,0 -{ TO SIM: LuaValue TDC_CursorY }- 7=AZ,1,F,66423,0,0,0 -{ TO SIM: AXIS_THROTTLE2_SET }- 8=AR,256,F,66420,0,0,0 -{ TO SIM: AXIS_THROTTLE1_SET }- Are you saying you did all this without knowing what you were doing, or did someone else do it for you? I just can't understand how you thought you could calibrate unassigned axes. I wouldn't worry about that. The GUID is only used to differentiate between two or more devices with te same name. The GUID is always unique. You've only got one "MFG Crosswind V2". Pete

That version is not supported. The currently supported version is 4.955c. Sorry, how do you "attempt to connect"? And what is "msg#2>"? So what do you expect it to connect to? What are you running on the client PC (the one NOT running FS) apart from FSC? How do you expect it to connect with no software to do so? Why didn't you read my last reply, and in particular the part " ... WideClient.EXE which is "installed" by simply putting it somewhere convenient on the Client PC -- i.e. the Networked PC, not the FS one. " No nothing you've told me so far makes sense. Sorry. Please PLEASE do read at least some of the WideFS documentation supplied! Pete

Need more information: 1. What does the FSUIPC4.LOG show in the early section, where it logs the devices it scanned? 2. Can you describe more exactly what you mean by "unable to calibrate"? Please note that Calibration in FSUIPC is completely independent from Assignment: it doesn't matter WHERE you assign, in FSUIPC or in FS/P3D, now even how. The calibration works on the FS controls you assign to, not on the joystick inputs. From the INI file I see: B=Saitek Pro Flight Combat Rudder Pedals << MISSING JOYSTICK >> B.GUID={C478E5B0-0FDE-11E2-8004-444553540000} A missing set of rudder pedals, yet you have assignments to it: 4=BX,1,F,66387,0,0,0 5=BY,1,F,66388,0,0,0 6=BR,1,F,65764,0,0,0 Now I don't know if this will make a difference, but if I were you I'd delete all 5 of those lines. I also only see: D=MFG Crosswind V2 2=MFG Crosswind V2 2.GUID={D156B4E0-397B-11E6-8001-444553540000} which is odd as there should also be: D.GUID={D156B4E0-397B-11E6-8001-444553540000} Since you have "AutoAssignLetters=Yes" set, it should have made that line as well -- or have you edited it? I casn't think of any reaon for it not to have completed this itself as it is done part and parcel with the creation of the D=MFG Crosswind V2 line. I don't see any assignment to device D in your INI. So maybe that's the problem? No assignment at all, no calibration. Even assignment in FS would allow calibration. Pete

"Lua KillAll" would look for a Lua plug-in called KillAll.lua and run it. I've no idea what that Lua contains as I've never seen one named that way, but if you really need to Kill all running plug-ins then you'd either need to invoke a macro which executes the LuaKillAll control. or, yes, usa a plug-in to send that control in the KillAll plug-in, i.e. using: ipc.control(1084) (The 1084 is from the list of FSUIPC additional control numbers in the Advanced Users guide). Mind you, I've not tried it and I'm not quite sure what would happen if a Lua plug-in tried to murder itself in such a fashion. However, all profile-specific Lua plug-ins are automatically closed when you change profiles, so this action is only really acting on plug-ins loaded by the generic [Auto] section. This line is interesting: I'd like to see the LuaFiles list, to see what entry 22 is -- I assume it is KillAll as well, but then I don't understand why there's no space in the FSUIPC-added annotation between "Lua" and "KillAll". It's definitely a Lua "Run" assignment as shown by the 'R'. Here's my entry for the keypress I use to kill all plug-ins: 2=49,24,1084,0 -{tab+1: Press=LuaKillAll }- Pete

If the virtual joystick buttons are those provided by FSUIPC, then, yes, to assign them he'd need FSUIPC registered. However, he also says: So where are those already assigned? Pete

I really don't know. With FSUIPC you can assign to buttons and switches if those buttons and switches are recognised as normal joystick type buttons and switches (up to 32 on each device, with up to 16 devices). I don't know if the Saitek Panel is a Windows-recognised joystick. If it is you should be able to see this in FS assignments itself. Do you? Is it shown in Windows Game Controllers, and if so does it detect the buttons and switches? I don't know SPAD either. You might want to ask in whatever forum SPAD is supported. Pete

Oh dear. It's an assignable control, called LuaKillAll, and, just like Lua, LuaKill, LuaSet,, LuaClear, LuaToggle and LuaValue, it is clearly listed in the assignable controls drop down for Keys and Buttons. As stated in the Installation and Registration document, found in the FSUIPC download ZIP, the FSUIPC Lua documentation is in your FSUIPC Documents folder (inside the FS Modules folder). Have you never looked there? The information about the added controls is provided on the very first page, the introductory part entitled "What is provided in FSUIPC for Lua programming". Pete

I just checked, and, in fact, if you try to read an L:var which doesn't exist you actually get zero, not "nil" -- there's an error in my code there, which I will correct in the next FSUIPC update. Currently you can only check whether it exists or not by using n = ipc.getLvarId("name") which will return nil if it doesn't exist. But from what you say, the "nil" error you are getting is because it thinks the function you are calling doesn't exist. There's no library called "pic", so that could be one reason -- or is that another autocorrection gone wrong? Also is isn't "readLVar" but "readLvar" -- another autocorrection? Surely not? Lua is case sensitive -- every character must be correctly upper or lower case. If you really are using ipc.readLvar then I think you need LINDA support. I don't know what it is doing to get that screwed up, I don't know it at all I'm afraid. BTW use the built-in FSUIPC assignable control "List local panel variables" to get a list of all the valid L:vars for the current aircraft, and their current values. Pete

Please ALWAYS post questions or support requests to the Support Forum, unless very specifically concerned with mentions in the SunForum, in which case they should be appended to the relevant tab. BTW I assume you mean "ipc.readLvar" not "ipc.readvar", which doesn't exist. ;-) This sentence seems to finish rather abruptly. Did you trace with LINDA? Why? Where does LINDA come into it? Did you try tracing using the facilities in FSUIPC? No, there is no "stripping out" of anything at all. And names with spaces in a certainly okay -- one of the default FSX ones is "L:EFIS Mode", and the default FSX 738 actually features as many as 31 different ones with embedded spaces -- and they all work fine. Pete

Yes of course. As listed on the first page of the Lua Plug-ins document, there's an assignable FSUIPC control called "LuaKill" exactly for this purpose. There#s even one called LuaKillAll to kill all running plugins. You can start then with the Lua control as well of course. The Auto loading facility is really just making use of this. Pete

Sorry, what has WideFS got to do with it? Evidently you did not uninstall v3 properly. And why on Earth did you install v3 into a folder called Prepar3D v2? Yes, I gave you exactly the solution in my previous message. did you not read it? Pete

It is n't relevant -- the point is they must be run in the same way. Not really as I asked. I said to close P3D first. Good. Saves you going to their support forums. Pete

And a good job too, because you appear to be using P3D version 2.5 but the Registry says it is version 3. see this part of the Log: You have registry entries for both versions 2 and 3 pointing to the same place, and version 3 being the more recent naturally FSUIPC installs for that! This part shows that in fact the Prepar3D.EXE file is version 2.5. How did this mess get made? What did you do? The only solution to the mess is to use the Registry Editor (RegEdit) to delete the key: HKEY_LOCAL_MACHINE\SOFTWARE\Lockheed Martin\Prepar3D v3 Such a mix up will be certain to get other add-on installers doing odd things too! Pete

Leave it to its default setting normally. It's only to stop a loop developing when the add-on aircraft itself uses those controls, which very few do these days. How are you detecting this? In the calibration tab? What throttle assignments do you have? Where and what to? Perhaps you need to show me more of the INI file, not just two lines. Note that some of the PMDG aircraft do not like FSUIPC calibration at all. Pete

I've checked here to see what I do in my cockpit programming. I do send keypresses to select GSX and ProATC/X menu items, and they work fine, with the numbers 0-9. I just have a separate button to invoke the menu then the normal choice 0-9 on other buttons (these are actually on a touch screen using the Button Screen facilities in WideFS). If the original sequence you programmed didn't work then either you have something wrong there, or it needs some delay between the key presses. (I wouldn't be surprised if that isn't the case at least after the Ctrl+F12 to allow the menu to be created -- SimConnect probably misses the choices thereafter). To check the former possibility, please show me the [Buttons] section of the FSUIPC4.INI file which you edited. To handle the latter isn't possible with only assignments I'm afraid -- although it might be worth sending the "Ctrl+F12" on the press and the 5, 1 on the Release. If that doesn't work then the only way would be to use a Lua plug-in to send the keypresses, and instigate that by your button. Pete

There is no difference to the interface FSUIPC presents to applications whether it is running in FSX, FSX-SE or P3D (or even FS98, FS2000, FS20002, CFS1 or CFS2)! Maybe those programs check whethe rit is FSX or P3D and make their own decision, but this is unusual, and all the programs I know which use FSUIPC run fine independently on whether it is with FSX or P3D. There are NOT two versions, "free" and otherwise. It is identical. The only things purchasing it gives you are the User Facilities. Registration enables those which are otherwise locked. I think you need to contact Support for those two programs. Oh, and make sure you are not running P3D "as administrator" and those programs not, or vice versa, because programs of different privilege levels can't talk to each other. If you want me to check FSUIPC is running okay you need to find the FSUIPC4.log file in the P3D Modules folder, and paste its contents here. Please close P3D first. Pete

This is an install problem normally caused by the inability to find the Prepar3D.CFG file. Full details of what happened are in the FSUIPC4 Install.log file, which you can find either in the P3D Modules folder, or in the same place as you ran the Installer. That cannot be anything to do with FSUIPC, because if it couldn't add itself to the DLL.XML file, it wouldn't even be loaded. FSUIPC touches nothing else but the DLL.XML and the files it places in the Modules folder which it creates itself. What do you mean by "any more"? Are you saying you had installed it and had it working before? You just said this was all fresh "yesterday"? Of course, if FSUIPC is not being loaded then it cannot add itself to the menu system. Find the Install log and paste its contents into a message here. I'm out all day but I'll get to it when I return later this evening. Pete

I'm still confused, but never mind. I can't help anyway. But you also said, just before: So you already knew it couldn't be Win10 itself!? No need to reply. The repeated contradictions confused me, but it doesn't change my conclusions. Pete

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