Pete Dowson

Check that your assignments work with default aircraft. If so then you need help from FSL. They might not be using the default FS controls. Or maybe there are some other settings or switches you need to operate. Pete

Thanks for the clarification. That's probably a wise move in any case. I don't think it has ever really been guaranteed to be the sim's folder. I suppose if this has been assumed by lots of plug-ins I could automatically set it as the current folder before loading them, but I'd be a little worried about possibly then mucking something else up. Pete

Sorry, I don't understand. are you saying that the location I'm given by SimConnect, i.e. c:\users\documents\prepar3d v4 add-ons\FSLabs\simobjects\airplanes\FSLabs A320 IAE\A320.air is wrong, that in fact the aircraft files are not there? How is this the "absolute address" c:\p3dv4\modules\linda\aircrafts Surely new aircraft aren't stored there! Confused! Ah! You are saying that the current folder, the one you assume by using .\modules\linda\aircrafts\ is not necessarily (and possibly never is?) P3D's root folder? FSUIPC determines P3D's absolute location during inititialisation (from its own path), and uses that in all its needs rather than any relative folder locations. Of course, the lua lfs library will simply assume that the current folder is the one to base relative addressing on. I thought it was always dangerous to make such an assumption. Other add-ons running in the same process can easily change it. Anyway, if you've arrived at a good solution, then fine. I'm not sure how that relates back to what you thought were timing problems with 3C00 and 3D00 offsets being populated. Pete

You should be able to tell from the size and description. 1 byte is 8 bits, so can either be unsigned, 0-255, or signed -128 to +127. The size and description are definitive. "Booleans" are simply numbers too, non-zero for true, zero for false. There is a convention tha says true is 1, but in fact any non-zero number would do. And the size is still relevant. PMDG for example often use 1 byte for "booleans", but C/C++ usually uses an int (32 bits or 4 bytes). Whether you are using FSUIPC or XPUIPC, if you are programming to an interface which uses the offsets, surely you have some sort of reference to the language you are using to program them!? In FSX and P3D all of the PMDG values are in separate offsets, documented in separate documents. They have to be enabled in their configuration files, as described in their SDK. I've no idea about PMDG on X-Plane. Pete

Try using search facilities in your viewer! Stall and Oversped warnings are certainly there (036C and 063D). Others are locally derived in the gauge module from values you can read, like RPM and manifold pressure. Whether you would get warnings or not depends on the aircraft model, so it is part of its instrumentation. But you can read the values yourself and compare them with limits. There's a FAQ about Bits, Numbers and Hexadecimal in the FAQ subforum, but mostly the abbreviations are standard programming terms. Float is a 32-bit floating point value whilst a 64-bit one is a double. But different names areused in different languages. I don't know anything but ASM and C/C++. For nomenclature like U32, etc, U just means unsigned, S signed and the appended number 8, 16, 32 is the number of bits. A fairly basic nomenclature and surely easy to understand? And more definitive. For example, in Windows whether an "int" is 16-, 32- or 64-bits depends on the system it's running in. Usually terms like INT32, INT64, WORD (16-bits), DWORD (double word 32-bits) and QWORD (quadword or 64 bits) are used for precision is descriptions. Array is a programming term which you must surely know about if you've learned any programming, in any language? If you aren't programming why do you need this information? Pete

In that case it will be the calibration. Maybe you have half of the range dedicated as a reverse range, and shoould be setting the "No Reverse Renge" option? The post reference you gave actually refers to something which was obviously nothing to do with me, and you need to read it again. The "patch" to which you refer was evidently a replacement to your HTR ptrogram to make it process an offset correctly. If you read it all properly you will see that there was apparently an error in an early version of FSUIPC which, instead of being pointed out to me at the time it was discovered, was used in the faulty condition by the HTR programmer. So when I actually fixed FSUIPC his software was wrong. I've no other information and no way of knowing what the original bug was now. I think you really should obtain the correct working version of HTR. Nevertheless, using the History document (which you also have for reference in your FSUIPC Documents folder), I looked through the "fixes" list for version 4.80, the first major version after the 4.745 to which that post refers, and found this (number 3 in the "Bugs Fixed" list on page 24): 3. Fixed offsets 332E–3336, and 3412, 3416, 3418 to provide the axis values is the correct range, calibrated if so subjected. For clarification, for throttles the correct range is 0-16k for forward thrust, with negative values providing reverse. These values are then suitable for application directly to the FS control offsets, as documented. These offsets have been wrong for a long time, often providing the incorrect range (-16k to +16k). Therefore, in case this bug fix messes up any programs which have assumed the offsets were behaving correctly, and made their own "fix" already, a parameter in the [General] section of the FSUIPC.INI file is available to force these back to their old (wrong) behaviour: just set "AxesWrongRange=Yes". Note that this was mostly fixed by version 4.743, but a further correction was applied in 4.745 Take note of the red parts. Could that be your answer? Pete

Do you mean you have to move your tiller to the left? If so then obviously it is not properly calibrated with the centre at 0. If you mean that any movement of the tiller fixes it, then either the tiller itself is faulty or dirty, or, more likely, the default flight you are starting off with has is deflected. If this is the case just get it set straight and re-save the flight. That seems exactly as if the setting in your flight is -4320, because unless the tiller axis is jittering (i.e. changing values on its own), FSUIPC won't see any input whatsover from it until you move it. The same applies to all axes. They are not polled, they just send values when they change. Pete

What's HTR 1.5? If HTR perhaps a Saitek product? Because their installer has a notable flaw in that it often seems to install data in the Windows Registry which causes this. You should really post on the Saitek support forum, because it is high time it was fixed and users advised. Meanwhile just see the very first thread in the FAQ subforum. Pete

So if the radar.bin is created for ProSim to read, FSUIPC + ASN have done their jobs. The rest is up to ProSim. Reading the ProSim forums regularly I have seen posts saying that certai versions did mess this up. Find a version that works. There are about 90 Betas uploaded now! BTW, FSUIPC is also capable of producing its own graphic, in BMP format. You need to have another line to the FSUIPC5.INI file. I implemented that and presented both to marty, and he preferred the raw data and to make his own bitmap. Details are in the document in your FSUIPC Documents folder. Pete

Ah, so they are sequences, not combinations. In that case it's a lot easier to do in Lua, as you can make the plug-in act on successive keypresses thus: When X is pressed, make it run a Lua program which simply tests if global vatiable "A" is set, and if so send the control for X then A and clear global A. If not simply set global variable X. Same for when A is pressed, but the other way around. Of course for you to be able to use A or X on their own you'd have to actually make it event driven, so pre-loaded, and timeout the arrival of the complementary keypress then clear the relevant global(s). Actually it would be better being event driven as then it wouldn't be so time critical about how fast you pressed the two keys. However it's an awful lot of trouble to go to when you have about 1600 other easy straight assignable key combinations (over 100 normal keys with all possible combinations of the 4 allowed shift keys, excluding ALT). Even if you remove the 100 or 200FS pre-assigned ones, there's still a lot to choose. Why would anyone resort to two successive key presses? Pete

I just did a search on "CH MFP", and see this subject came up 9 years ago and was defnitively answered by Bob Church "Stickworks" who is the known expert of CH devices: Pete

So it's a specialised HID device, like the Goflight button/switch es like GF-P8 and GF-T8. Even for FSUIPC to see them a Goflight-supplied DLL is needed,though you can program them directly using Lua plug-ins. Even your device can probably be programmed that way, you just need to do a bit of detective work to decode the data you receive. It is very unusual for a simply button device to have its own unique protocol so it has to have its maker's software. Pete

Hmm. Never seen that or tried it before! how many characters does it accept all pressed together? Pete

The underlining is not very useful if you can't sent the character to use it -- which could be done using Lua as shown in the example in the ZIP in the FSUIPC Documents folder "Payload737.lua". You can't invent new controls to do new things unless there's a way provided to do them in the underlying software (i.e. P3D), so, yes, it would involve L-M adding controls. For defined Cameras you can use the "VIEW CAMERA SELECT" 0 - 9 controls, but I think the cameras have to have an ID (0-9) specified, and probably all they do is put that view into your currently selected window. Pete

Have you tried just using ProSim's WXR display facilities? I've seen reports on the Prosim forum that this works. (https://prosim-ar.com/forum/viewtopic.php?f=13&t=12738) Is your CPflight WX RDR program using the file generated by ActiveSky and placed in your ProSim panel, or is it making up its own image? If the latter then FSUIPC is not involved, except you should probably remove the radar file path line in the INI, as ActiveSky might not like trying to serve two clients. Pete

Ah, so I understood it the wrong way around. i thought you wanted X and 1 to go to the Sim. Sorry, but X is not a "shift" character. FSUIPC can only have its list of "shifts" simultaneously recognised. These are extended and should be ample: Shift, Ctrl, Win and Tab. (Alt could be used, but is precarious as it invokes FS's menu bar). Sorry, that sounds unlikely! Are you saying FS does really accept multiple text key presses for the one assignment? I'd like to see how it manages to record those. And recognising multiple text characters pressed at the same time is relatively complex. Each text character sends a WM_CHAR message and it is that which is normally used. To detect them being presse and released means monitoring WM_KEYDOWN and WM_KEYUP messages which only give keycodes, not the ASCII character derivation, though that can be derived by yet more Windows calls. FSUIPC does this sort of thing for the Lua plug-in keypress and detection programming, but it isn't a normal process. Really? That's rather a bad omision on MS/DTG\LMs part! If you are using P3D I think you should point out that omission to LM. (Too late for FSX/FSX-SE). Meanwhile, I think you would be best choosing a more normal keypress combination. Pete

What is "X+1"? Do you mean a sequence, "X", "+", "1"? What exactly is each keypress supposed to do? Are these default FS beacon lights? Key 8841? That's a very strange number. How do you arrive at that? It certainly isn't a valid keycode. Anyway, the correct format would be 0=keycode, shiftcode, 66239, 0 If you needed a parameter like '1' replace the 0 by 1. But i don't think the parameter does anything for a "Toggle" control, which that is. And instead of trying to edit the [KEYS] section in the INI, just assign the keypress in the normal way, in the Keys tab in FSUIPC Options. The INI parameters are generated, correctly, for you! Pete

Does Windows see it as a "game controller"? Does FS? FSUIPC only scans and uses joystick type devices (plua GoFlight buttons and switches, through their DLL). If it is a joystick type device it will appear in FSUIPC's joystick scan -- look at its Log file. Maybe it is a joystick type device but you still have its own CH driver running and that prevents its buttons being seen? Pete

Sorry, I don't know "WX RDR". The FSUIPC facilities for ASP4 are aimed only at ProSim. Other applications do their own thing, FSUIPC is not involved. Pete

Surely you don't want ALT V and ALT W? Shouldn't the release be before the W? One problem you'll be encountering, which is impossible to get around this way, is that as soon as a menu is opened, the main thread in FSUIPC can no longer get keypresses read by FS -- the focus changes to the menu, and any keypresses still in the main FS buffer are seen after you exit the menu. You really do need a Lua plug-in which operates separately, in its own thread. More below. You really need a delay holding the ALT down. You can't really do that with simple keypress assignments, you'd need to use a Lua plug-in. And for successful use of keypresses from a Lua plug-in for doing quite complex see the example "Payload737.lua" in the Examples ZIP in your FSUIPC documents folder. (At least it used to be 100% successful -- I've never tried int in P3D4). Exactly. Rather than "VIEW00-VIEW09 (underlining)" in menus, surely you want working controls you can send, not menus? If you know where the views are positioned you could use a Lua plug-in to move then click the mouse on them to move focus. Pete

3124 was "electric always available". But it has been re-used since FSX for the specific version of the main FS version given in 3308, as documented in the FSUIPC4 Offsets Status document installed in your FSUIPC documents folder. You are certainly making an error somewhere. I've just loaded P3D3.4 and checked offset 3124 and it reads "34" which is correct. I used the FSUIPC Logging tab monitor facility. Check it yourself. BTW why wait from July 15th till now to ask again? Pete

Exactly. It does this "behind the scenes". Just check the main Sim folder, where MakeRwys is run, and see that the "makerwys_scenery.cfg" file has been generated and left there for you in case there are questions afterwards about what MakeRwys extracted. No changes are made to the main Scenery.cfg file itself because that risks double scenery layers when they occur in the Addon.xml files as well. Pete

I don't think moving it to another PC will necessarily help with that. It is more likely to be a function of the way they menu is being generated. After all, the same sort of windows can be generated by my Lua plug-ins (I use them quite a lot when testing and developing), and they don't cause any delays. It isn't the displaying which is the problem. L-M have recognised this as a bug and did actually confirm this in a reply to a thread you started in their SimConnect subforum, here: https://www.prepar3d.com/forum/viewtopic.php?f=6310&t=127155 Pete

You mean on-screen SimConnect messages and menus, I presume. Whilst this was possible via WideFS in FSX and P3D1-3, and documented, it isn't currently implemented for P3D4, but awaiting some facilities from L-M. From what they have told me this should not be too far down the road, but there's no sign yet. I have been chasing this from time to time, as I have for the other facilities still outstanding. This is one facility which I, too, am desparate for, because I find it totally annoying to have the realism i'm achieving with a full cockpit, with shell, and a 210 degree FOV curved screen for the outside view, to have these messages and the menus (especially) put in the sky in front of me. The facility, when implemented, would apply equally to ProATC and GSX menus, though of course the GSX ones are less of an urgent need as they are only used on the ground, for taxiing and other ground activities. Pete

1400 to 1520 inclusive covers 7 stations: 1400, 1430, 1460, 1490, 14C0, 14F0, and 1520. How do you count only 5? BTW FSUIPC simply handles these with SimConnect using payload station numbers, 1 - n, where n si the number of paystations supported by the currently loaded aircraft, as supplied in offset 13FC. FSUIPC does not process this data at all. What you get/set is just what FS and SimConnect provide and allow. Pete