Pete Dowson

I don't use the PMDG aircraft myself, but I think this is because the NGX coding only takes note of the regular FSX "axis throttleN set" controls. This is unfortunate because those controls offer no possibility of a reverse zone, unlike the "ThrottelN set" controls used by FSUIPC's reverse-idle-forward calibration. One answer I've read from others is to use the "no reverse zone" option in FSUIPC calibration and set the "UseAxisControlsForNRZ" option to "Yes" in the relevant [JoystickCalibration] section in the INI file. This would mean finding another way of engaging reverse, such as either a reverser lever or a button programmed to send Throttle decr controls, as is common for the buttons on full-back positions on the Saitek Throttle Quadrants. Another possibility is to use the FSUIPC-added assignable controls for "throttles off/on/toggle" to disconnect the throttles when the A/T is engaged. You should be able to program that to operate with the A/T switch, either via dual assignment or macro, or even using a Lua plug-in to read the relavant NGX offset. Regards Pete

The buttons on the EFIS panel must operate toggle functions. In the real cockpit, they are simply press/release for on and off, alternately, so they should work exactly the same if you program the VRi switches to send the same thing for both press and release. If whatever interface you are using (ProSim?) hasn't implemented it this way then they've made a mistake. Check in their support.forum. Regards Pete

Hmm. Not sure why that is. Possibly it occurs with the Console On contorl -- I can probably detect that and change focus back -- but the logging option changes simply set or clear bits in a flag word. I don't see how any focus change can possibly be triggered by that. But that was changed long long ago! How long ago was your previous update? Pete

There's no change in the registration system. Either you are making a mistake, or your system date is incorrect. The very latest interim update is 4.859q, BTW. 4.853 should will work also provided your registration was purchased before Jan 1st 2013. Regards Pete

I've been looking at this, and it is really a complex bag of worms. To do anything with the Window I need to track down the Window handle associated with the reference FS gives me, but I've searched and searched for that and it is simply not anywhere easily reachable. I have no idea how they've implemented these Windows. I do wish it were easy, because then maybe I could get into the ATC and other Menus and divert them to Client PCs. So I'll pursue it for that reason. But there's no solution in sight for a long time, if ever. Regards Pete

Sounds more likely that someplace deep in SIM1.DLL a different black-box virtual object is chosen for different 'aircraft types'. The whole business in FSX's Sim Engine is about as obscure as you can get. I *hate* object oriented programming with a vengeance! I really gve up when they re-wrote everything that way. This is why 99.9% of everything FSUIPC does is using SimConnect. Pete

But a "full cycle" means changing it from 0 to 1 and then back to 0 (or vice versa), so effectively nothing changes. Why would you want that? There's no point. Surely you either want to set something or clear something? With VRi devices you cannot detect the button being held down, if that's what you are thinking! One button press/release == one event, setting 'pressed' or setting 'released'. So you program it accordingly. Think of the buttons as toggle switches, like light switches. A full cycle for a light is off-on-off or on-off-on, and alwways needs two presses. If there's only one press for the full cycle, how would you ever be able to choose to have the light on or off? Sorry if I'm misunderstanding. Maybe you can explain better what you mean? Pete

But you can see them in XML okay? Surely that's all you need. what "control response from FSX" would you expect f the aircraft loaded is not Concorde? Hmm. I think I understand. You actually want these controls to DO something inside FSX. Is that something you can't program in XML, then? Regards Pete

The registration system and codes have never changed. I am therefore sure you are making a mistake somewhere. Please Zip up yout FSUIPC4 Install log, the last FSUIP4 log (with FS closed down), and your FSUIPC4.KEY file, all of which you'll find in the FSX Modules folder, and send as an email attachment to me at petedowson@btconnect.com. i will then be able to tell you what is wrong, if anything. Regards Pete

You say they "do not work", but they are simply numbers sent to FS's engine. They will work with aircraft which FS recognises as supporting what they are intended to do. If you have add-on aircraft which use the same controls for other purposes, the problem is with the add-on. So I don't undesratnd your interest in them! Unless FSLabs made use of the same control number codes, I don't see why they should work in their Concorde. Since they simulate almost every aspect of the aircraft they will need a great deal many more functional controls than those offered internally by FS. There seems to be some confusion in this thread. Perhaps you need to explain yourself a little more? I thought you wanted to receive these controls, and you can do. No need to "trap them". Regards Pete

That is very much out of date and unsupported. You need to be using at least 4.853, the earliest supported version. Regards Pete

Well, the visor controls are still assignable in FSUIPC4, so if you have a ported aircraft which makes different use of them, they should still be okay. Here they are from the FSX controls list: DECREASE_CONCORDE_NOSE_VISOR 66295 DECREASE_CONCORDE_NOSE_VISOR_FULLY 66384 INCREASE_CONCORDE_NOSE_VISOR 66294 INCREASE_CONCORDE_NOSE_VISOR_FULLY 66383 Pete

Was it possibly FSUIPC3, for FS9 and before, you purchased a key, not FSUIPC4 for FSX and later? If so I'm afraid you'll need to purchase new keys, as they are two separate products. Otherwise, I think you must either be making an error when entering your details, ort you have the PC's date set incorrectly. Regards Pete

Sorry. It isn't like that. The ground friction thing was a table which once a few clues were established was easy to find. The is no easy way to hack into FSX code. It is all a series of black boxes (C++ objects) with the most convoluted assembly code imaginable. I just haven't the time nor patience any more. If I were 20 again I'd take up the challenge. but at nearly 70, life is becoming too precious to waste so much time -- and I know it would be a waste. I've tested this on several occasions recently. Why not invest in the FSLabs Concorde? By all accounts it is a splendid re-creation! Pete

Have you opened your account? That's where all your SimMarket purchases are recorded along with registration keys. Pete

4.859q is now available. The logging controls are these: Regards Pete

Google seems to translate this to: "Hello, like buying FSX licence do not FSUIPC4 Seven 64"? Is this a question? Sorry, I do not understand. Regards Pete

Please, rather than post PICTURES of TEXT files, just paste in the contents of the text files. I cannot quote parts back from pictures to show you what is wrong! Your ipcReady.lua program is toggling the virtual BUTTON identified by the value written to offset 66C0. So, if your "HidMacros" implementation seds values to 66C0, you will get buttons programmable in the Buttons & Switches tab. But then you edit the KEYS section of your INI, which handles normal keyboard imputs -- nothing to do with Buttons! You are ignoring the button number 0-287 altogether! Your KEYS entries are all wrong. What is the 'N' for at the beginning of each line? There is no format "H66C0=1,M4:22,0". I don't know where you are getting this from. In any case you cannot program conditions into the KEYS section, and in this line you omitted the Key and Shift codes altogether -- it is completely wrng in every way. Why are you trying to test 66C0, when your ipcReady is already converting it to button toggling? With that ipcReady.lua loaded, you do not need to do any editing of the INI file at all. Please DELETE the stuff you've added altogether. Just use the Buttons & Switches tab to program the virtual buttons you operate from HidMacros. Note that, if HidMacros can toggle bits in offsets, then it would be FAR FAR EASIER to avoid using 66C0 altogether, and simply program HidMacros to set or toggle bits in in the virtual button offsets, 3340-3363 directly. For some reason you seem to be wanting it as complicated as possible, rather than very simply. Regards Pete

This looks like an add-on aircraft specific action. I suggest to pose the question on this in the Carenado support forum. It really shouldn't do what you say. That is EXACTLY what AP_ALT_HOLD_ON/OFF FS controls are -- not FSUIPC but FS controls. In FS itself there is no distiction between those and the Toggle with the appropriate previous condition. So, it must be that coding in the Carenado add-on it intercepting these controls and acting incorrectly when it sees them. There is nothing FSUIPC can do itself about that. It is an error in the add-on. You can, of course, program your toggle switch to send the same toggling command both then switched on and off. All you'd need to do is ensure it was synchronised to start with. A more complex and reliable solution would be to program both to depend on the state of the FSUIPC offset which indicates whether the ALT hold is on or not. With an offset condition you could make the "on" position do nothing if it was already on, and the reverse for the "off" position. This involves editing the FSUIPC INI file. Regards Pete

Yes, there's such an option in FS9 and FSX too. But surely you only set it once, not every time you load P3D? Okay. Evidently yet another bug in Windows 8. There's nothing in FSUIPC which is in any way related to that option. It cares not a whit about the time values. I suspect, as I said originally, it is some problem in Win8 affecting SimConnect. Regards Pete

Tell me about it! Blame Microsoft. All the FS control names are obtained from their CONTROLS.DLL module at run-time, not built into FSUIPC, and they are the same ones FS itself uses in its configuration files which record its assignments too. I think many of the names are historical, and some probably do nothing now in any case but have simply not been removed. Some are actually named incorrectly! The only way I find out which does what is usually trying them, or using the logging as you've fond. Incidentally, when doing such an investigation you'll find it much easier if you temporarily switch FS to Windowed mode (ALT + ENTER), make the window a little smaller, and enable the "console log" in FSUIPC's logging. Then you can see the controls being logged as you use them. Regards Pete

It's easy enough, and loads of spare FSUIPC control numbers (I use the range below the FS controls which start at 65536). I might include it in 4.859q over the weekend. You don't want it in FSUIPC3 I hope? I don't want to add anything new into that, only bug fixes, if needed. Pete

Er, sorry, but what do you mean "change system time to GMT"? Where and how are you dong that in FS? If you want to adjust your PC's time (and why would you?), why not do it BEFORE FS is running, not whilst it is running? That probably instigates all sorts of reloads in P3D. I really doubt that it is anything directly to do with FSUIPC as such. More likely it is related to the continuous and timed updates FSUIPC receives from SimConnect. Changing the system time whilst all that is going on doesn't seem a healthy thing to do at all. Regards Pete

Oh, a keyboard shortcut and just for those three? Hmmm. A bit specialised. If I were to implement that it would be by adding assignable FSUIPC controls, one for each logging option. Then you could make a little macro with three lines to toggle those three entries, and assign that to a keypress or button. Would that do? It would be much more flexible. Pete

Evidently you have flying tips turned on, and FSX doesn't know you have rudder assigned in FSUIPC -- how can it? Pete