Pete Dowson

Okay. The documentation is wrong. I'll revise it. Strange it has never been pointed out before. Here's what the code accepts: 1 Shift 2 Control 4 Tab 8 -- (not used) 16 Alt 32 Left Win Key 64 Apps Key But I'll be testing this as i'm not sure about a couple of things. Pete

Perhaps you were trying to ask (unsucceessfully obviously. asking "how possible" instead of "which bit"), WHICH of the bits labelled ALT you should use? That's actually quite interesting. I hadn't noticed there were two entries for ALT. It looks like a documentation error -- a mish mash from FSUIPC key lists. If this was your original question, why not just point out the ambiguity? It would have been much quicker! Pete

BTW if TAB is requested is has to be sent separately in any case, as there's no "shift" in Windows for TAB. So it sends "KEYDOWN for TAB then KEYDOWN for the main key + shift bits, then the KEY UPs. Unless the destination program is one that can process multiple key presses like that, then the TAB would probably be ignored. FSUIPC processes them, but that's the only double press it accepts. Pete

11 is used in FSUIPC itslef, where "8" meant "key by itself". Rather a waste of a bit -- the flags derived from original Windows message codes, though that one's an oddity. I think it dates back to something in an early version of FS and therefore FSUIPC. Not sure why TAB wasn't generated. I'll take a look. Oh dear. 😞 You didn't read your own quote? "The shifts value is a combination (add them) " Shift and Control = 1 + 2 -> 3 (you added the old 8 in from FSUIPC practice). Surely it is logical then that 2 + 4 = 6 means Ctrl + Alt? they are BITS -- individual bits for each shift! Always have been, in FSUIPC, WideFS and Lua! Your second "quote" is from the key code list, not the shift list! Pete

In ext.sendKeys, 11 is Shift+Ctrl+Tab, not just Shift+Control. As documented one 19 in the Lua library PDF, along with the keycodes! It also lists the value to add for ALT. What is the 4 in the 4th parameter position for? It isn't a listed keycode. In the list of Windows Key Codes it says: VK_MBUTTON 0x04 Middle mouse button (three-button mouse) but I doubt that works with the basic SendMessage WM_KEYDOWN, WM_KEYUP method used in sendkeys. Interesting to try perhaps, though. The Windows documented list is extended since I last looked at it. Pete

A way around that is to use it to toggle one of the "virtual buttons". FSUIPC has 288 of them, every bit of offsets 3340-3363. You can either toggle them directly, or perhaps easier use the 4 byte offset 29F0 to specify which button, and whether to press, release or toggle. Then you have assignable buttons! 3110 and 3114 are not "free offsets" as you stated, but assigned and documented FSUIPC functions, as you are indeed using. 67145 is an FS Control. There's no FS control for a keypress, except for the "SELECT 1' to 'SELECT 4' controls as used to select Engines or actions for several other controls. There is an FSUIPC added control to send keypresses. Look up numbers 1070-1072 in the list in the FSUIPC Advanced User's manual, about half way through, in a section called Additional “FS” Controls added by FSUIPC5 and certainly listed in the Contents at the front. Pete

Well, I'm not going all through your Profiles to see what you have assigned there, and in some cases maybe one or more of these is overridden by a profile assignment*(when you use an aircraft with such a profile, but you have all these in the main default button assignments (NOT the Profile you have confusingly called "DEFAULT", but the true default): 6=R1,10,Cx42000BC0,xC0010078 -{offset sword decrement, offset 0BC0 (Decr=120, Limit=-16383)}- 9=R1,3,Cx42000BC0,xC0010078 -{offset sword decrement, offset 0BC0 (Decr=120, Limit=-16383)}- 21=R1,2,Cx32000BC0,x3FFF0078 -{offset sword increment, offset 0BC0 (Incr=120, Limit=16383)}- (0BC0 is the elevator trim) 30=R0,12,C65615,0 -{ELEV_TRIM_UP}- 31=R0,10,C65607,0 -{ELEV_TRIM_DN}- 36=R2,12,C65615,0 -{ELEV_TRIM_UP}- 37=R2,10,C65607,0 -{ELEV_TRIM_DN}- 36=R2,12,Cx32000BC0,x3FFF0078 -{offset sword increment, offset 0BC0 (Incr=120, Limit=16383)}- 37=R2,10,Cx42000BC0,xC0010078 -{offset sword decrement, offset 0BC0 (Decr=120, Limit=-16383)}- See the problem? Multiple assignments to the same functions is never a good idea, and in two cases (R2,12 and R2,10) you have two assignments to do the same thing in different ways. I've not checked the axis assignments, but if you have axis assignments to elevator trim too that makes it even worse. Note all those button assignments are "R" ("Repeat" whilst held). Might any of those actually be latching switches, or held down for any reason? Ebable button logging in FSUIPC to double check. If you enabled button logging AND even logging then you'd see exactly what was going on. Pete * Saying that, though, at a quick glance i can see you have some duplicates in the profiles too).

Why via a "free offset"? How does the offset relate to a keypress? Why not assign the keypress to the button directly? And what key compbination have you programmed ProATC/X to respond to? Pete

Not to me, no. It says no more that the previous post, except that the chap who wrote your App is probably using Paul Henty's .NET dLL. Best to send it to your ACARS perople, as I suggested. Pete

I've had a look as promised and it is easy enough. So it will be in the next release of FSUIPC5. Pete

There's more to the DLL.XML than that. Just use the <> button above this edit area to paste in a copy of the complete file. Or, better, attach it as most folks do. Did you update to 5.14? Did you check for the FSUIPC5.LOG and FSUIPC.INI file and didn't see them? What did you see? Pete

That's a report from your SIM ACCARS program. I've no idea what it is checking. Perhaps it is looking for a different version of FSUIPC, not version 5. You'll need to check with the supplier or author of that program. BTW entitling a thread "ERROR" doesn't help attact anyone else who might otherwise be able to help you. it rather spoils the point of posting in an open forum. Pete

First of all, you are NOT installing version 5.14, but 5.121b. See the Log you supplied: "Installer for FSUIPC5.DLL version 5.121b" Please download and install the current version, 5.14. Then, after running P3D4, check the Modules folder. Is there an FSUIPC5.LOG and FSUIPC5.INI file there (make sure first that you are not hiding filenames in Explorer -- see instructions for fixing that at the end of the Installation gide. If those files are there, then show me the FSUIPC5.LOG file. If not, tFSUIPC5 is not being loaded. The DLL.XML file may be corrupt, so show me that. Pete

Not without more information. You obviously have a duplicate assignment, Show the INI file here. Pete

Seems like a question for the PMDG support forum, then, as there are obviously some odd things about those aircraft. PMDG will tell you not to use FSUIPC for their throttles. I say you can but it is best just to assign to the standard Axis throttle controls and NOT calibrate. Their code reads the throttle axis inputs at a higher priority level than fSUIPC feeds them back after calibration. Pete

So you want an unrealistic control response. not ther realism carefully built into the aircraft model for you? You said your friends yoke gives you corespondend with the one screen yoke. That's find and dandy, but it also achieves 90 degrees you said. Does he never move his yoke axis further than the 45 degrees you see to want? If it is justy a lack or central sensitivity which concerns you, as result of the same full range being compressed on your yoke to half the movement, then the best an easist was it to use a slop with a flater centre, as I sugested. I don't really see any need to worry about your yoke position matching that one the screen -- I don't see why that bothers you so much. If you genuinely want to limit the real range of your aircraft's airlen movement, then you can fiddle that, aftern normal FSUIPC calibration, in the calibration line in the FSUIPC settings file (the INI file). Yo'd have to increase the limits -- make the miinmum value of the axis a lot lett (or more negative if it is negative already, and the maximum a lot higher. For instance of values like -16380, xx, yy, 16380 change them to -32760, xx, yy, 32760 (where xx and yy are oyur centra neutrol zone). But, to be honest, I think you are after the wrong thing. You should always be able to reach all possible settings of your controls even if normally you wouldn't. I think you just want more control in the normal region. Pete

It's the Lua interpreter itself which reads the files. FSUIPC just passes it the filepath. The Visual Studio compiler options for character sets being used are Unicode, or Mult-byte character set. Now Unicode is a 16-bit charcter code system and I can't compile with that without losing cimpatibility with pretty much all the files used or accessed by FSUIPC. And it would mean a lot of code changes too as the two really are not compatible for most character or string based operations. But I thought "UTF-8 was an 8bit character system with extensions by multiple bytes. Isn't that the same as "multi-byte character set"? I it needs Unicode then, sorry, there's no way without quite a major amount of error prone changes. And do you know if the Lua interpreter is compatible in any case? Are these 'unexpected symbols" actually withing code? Does the Lua compiler accept the input? Pete

What you are saying dosn't make much sense. If you hold any sort f aileron deflection long enough the aircraft will keep tilting in that direction, well past 90% and maybe upside down and beyond. If you mean the graphic on-screen yoke, then that is merely a representation. what matters if where the control surfaces on the wings move to. You need to be able to reach both extremes, and limiting the input to prevent that is wrong. If the surface is to have a limited amount of movement then that is determined by the modelling, probably the .air or cfg file. Check the outside view when on the ground and see whether the ailerons keep moving even to the "90 degree" points on the screen representation of the yoke. If so then that is what you need. Maybe you are simply finding the control too sensitive? If so just choose a slope in FSUIPC Calibration with a flatter central area, to give you more delicate control with normal deflections without preventing you reaching the extremes. Pete

This is the same problem as folks using the Aerosoft airbus Pro have. Please see my answer to a query about that, as the answer will be pretty much the same: see this thread not far below yours: Airbus Pro Throttles Pete

Not this Peter! I've never created any gauges and wouldn't know where to start! sorry! Pete

I think most sim pop-up screens appear centralised. How do you keep them from going back next time? I don't think so, at least not at the moment. I can make a note to look into it though. If I did it it would be for FSUIPC5 (in P3D4) only, as that's the only This is the first time in the 20 years of FSUIPC that anyone has asked such a question! Pete

As it implies, if you set it to No you can't use profiles becase you've told FSUIPC not to support them! That reverts its operation to the older, now really defunct, "aircraft specicitc" settings, which were aircraft name based rather than having groupings of aircraft with single profile name. Some folks still use the old method, probably from hacan convert to Profiles simply by setting this to Yes (its current default). Pete.

Are these USB hubs powered? If not I think that will be the problem. Never rely on PC power for hubs. If they are powered then I suspect that you have a hub or PC USB port problem, as things when staying powered should not be simply lost. I assume you've made sure Windows USB power management is turned off for its more direct connections? Though this should not affect powered hubs. Now this makes no sense. If you are adding a new connection, how can any assignments be "as they were before"? If they get "swapped" then both GUIDs must have been changed -- so Windows identified them the other way around. This seems extremely unlikely as GUIDs are random numbers which are guaranteed not to reproduce within an immense number of iterations. So, they must have looked EXACTLY as if they had swapped over You trell me how that can happen, as I have no idea. And there's absolutely nothing FSUIPC can do about it, obviously. In any case you don't need to reassign everything. Just swap thters as I said. I assume you don't keep adding and removing devices? Is this all just whilst you are building? Pete

They've probably implemented their own autopilot. The controls directly assignable in FSUIPC are the built-in P3D ones. If you enable FSUIPC's event logging (in the Logging Tab), then use the on-screen autopilot button, and check what is logged afterwards, it may (or may not) tell you what control was used. If it does then you can use that. if not then check the Aerosoft documentation to see if they provide a keyboard shortcut, or the possibility to assign one. Then you can assign your button to that. Otherwise it will either be a matter for a Mouse Macro, or maybe an ordinary macro to write to a local panel variable (L:Var). But we can discuss that more after you check out the easier options. Pete

Some of the more sophisticated add-on aircraft read throttles differently, bypassing the usual FltSim methods. PMDG Boeings are examples -- though they respond to calibrated inputs they also read more directly so bypassing that. The result is that they can get two different inputs and so act jerkily. The advanced versions of the Airbus system do something special with throttles too, I assume emulating the thrust modes rather than using the throttle input directly. I suspect that if you use FSUIPC for assignment you must assign to the standard FS controls - "Axis throttleN set". Try that first WITHOUT calibrating (press the RESET button in the calibration section if you've already set calibration). If that works, only then try Calibrating. You will probably have to set the "NRZ" (no reverse zone) option. If that still doesn't work, there's one other trick: add (or change to Yes) "UseAxisControlsForNRZ=Yes" into the relevant [JoystickCalibration] section of the FSUIPC5.INI file. That's the last hope for normal calibration. If that doesn't work I can only think that it must be done by writing a Lua plug-in to process the axis. Pete