Pete Dowson

There's nothing wrong with asking, and if you can find useful information on it, good luck to you. It is just that I cannot allow publication here and keep good relations with PMDG. I don't really agree with their policy on this, as I think they'd actually do better opening their super aircraft up to cockpit builders and hobbyists. But they seem to fear that hardware vendors will "cash in" on their hard work. They actually sell the interface facilities to those hardware firms who are supporting their aircraft. Of course this policy rather leaves home-builders out in the cold. Regards Pete

FSUIPC knows nothing about displays at all, but I did write a little freeware FSUIPC client application called "gfdisplay" which you can use for GoFlight LED indicators and for GF digital displays, like radio and MCP values, too. It's available in the usual download place. Regards Pete

I'm not really clear what a "double action rotary switch" is doing, then. The ones I have operate one contact repeatedly when turned one way, and another when turned the other way, so it is easy enough to assign one Keypress to one direction and another Keypress to the other. Then you use the radio frequency INC and DEC controls, as named (not by numbers!) to do the job. Are your rotaries of the graycode sequenced types, with three or more different contacts indicated, so you have to decode the direction based on the sequence? I've never actually seen one of those, though examples of them programmed as Button inputs are provided in my documents courtesy of users. Regards Pete

No, sorry, there are no similar facilities for keys. In fact I don't understand why you'd need them. Perhaps you could explain what you are trying to do and why? I may be able to see another way? If you really need to use button-oriented facilities, you can program the keys to toggle or set or clear one or more of FSUIPC's "virtual buttons". 288 of these are available starting at offset 3340, with 8 in each byte from 3340 to 3363 inclusive. There are added FSUIPC controls in the Keys assignment dropdown for manipulating these: Offset byte setbit Offset byte clearbit Offset byte togglebit The offset would be, say, 3340, and the parameter 1 for joystick 64 button 0, 2 for joystick 64 button 1 and so on. Having assigned the keys in such a way you'd need to edit the INI file according to the button programming syntax you mention. You wouldn't be able to program them in the Buttons tab of FSUIPC because it isn't scanning and interpreting keys whilst in the Options dialogue. Keys then belong to Windows. Note that, in FSUIPC4, and upcoming for FSUIPC3 (I'm testing at present), there are new Lua programming facilities available, giving much more power for additions via programmed plug-ins to FSUIPC. Currently documentation and examples for these are provided only in the "FSX Downloads" Announcement above, but I'll release it in the "Other Downloads" too as soon as I've finished testing it on FS9. Regards Pete

PMDG's use of FSUIPC's offsets in FS9 are proprietary to them and are not published by them as they have a policy of charging for development data for third parties. I think some folks did hack into these once, but I also heard that, as a result, PMDG scrambled (encoded) their data, though this may have been just another rumour. I don't really think anyone here is likely to be able to help you, at least publically, and in my position, with good relationships to PMDG, I couldn't allow open publication of confidential proprietary information here in any case, no matter how much I sympathise with the needs. Sorry. Regards Pete

Please update to a supported version of FSUIPC -- 3.75 is now very old. There have been many versions since then and currently the oldest supported version is 3.82. There's a version 3.832 available in the Announcements aove, too. It sounds like the FS sensitivity slider is set at zero (far left). For all axes assigned in FS make sure the sensitivity slider is max (full right) and the null zone slider is min (full left). Do this before trying to calibrate in FSUIPC. Regards Pete

No, use the "Keys" tab, then. But why are you talking about FS control numbers? What is wrong with simply assigning the keypresses to the named controls in the Keys tab drop-down? I don't understand why you are playing with numbers and asking for syntax. Regards Pete

Erwhy are you messing with keyboard keys and FS control numbers? Can you not simply assign the effective button presses your switch produces in FSUIPC's "button and switches" tab to the relevant Fs controls, using their name? How are keyboard C and D keys involved in any case? You need to explain yourself a little more, I think. Regards Pete

Good. I'll upload them to the Announcements tomorrow -- busy tonight. Thanks! Pete

Okay. 3.831 is history. Download http://fsuipc.simflight.com/beta/FSUIPC3832.zip As before, for the Traffic Zapper control these lines can be used in rhe FSUIPC.INI [general] section: ZapAirRange=n (cylinder radius in nm, eg. 2.5) ZapCylinderAltDiff=n (half cylinder height in feet, eg 500) It's the latter parameter being non-zero which changes the mode to your vertical cylinder system -- if it is omitted or zero the normal system is used. This only applies when your aircraft is airborne. On the ground the normal system is used. In this version you can repeat the control as fast as you like -- machine-gun style, the aircraft will be deleted closest first, in order. There's now also a new control: Traffic Zapall (number 1085). This uses a fixed cylinder 500 feet above and below, radius according to ZapAirRange or ZapGroundRange (yes, it operates on the ground too), and simply deletes all AI aircraft in that cylinder. These facilities will also be in FSUIPC 4.319. I'll upload both to the Announcements above after you've had a play and tell me they are all okay. i've tested them here and can't see anything wrong. Regards Pete

I just noticed an error here: The Range is not the diameter of the cylinder, of course, but the radius! So those example parameters, 2.5 and 500, give a cylinder 5 miles diameter, 1000 feet tall (if the aircraft is at least 500 AGL of course, else it's cut off by the ground). Yes, but you need to allow a second or so each time for the internal table to refresh and reflect the loss of the first one Zapped. Else the second press Zaps the same one againMaybe i can do something about that, though -- delete it from the table anyway rather than wait for confirmation. I'll take a look at that. i'll look at that too. Regards Pete

If you mean the touch-down vertical speed value in offset 030C, FSUIPC stops changing that value when the "on ground" flag in offset 0366 is set, so all you need do if wait for 0366 to be non-zero, then read 030C. Don't forget that if the aircraft bounces it will look like a touch-and-go to FSUIPC, so then the value won't stabilise until the final touchdown -- by which time you'll have lost the value you want. One answer to that is to keep reading both 0366 and 030C together, and take the first value of 030C when 0366 becomes non-zero. Regards Pete

I've implemented it, even though i don't like it much -- but it was easy to do (a lot easier than the main system). Download http://fsuipc.simflight.com/beta/FSUIPC3831.zip Add these lines to the FSUIPC.INI [general] section: ZapAirRange=n (cylinder diameter in nm, eg. 2.5) ZapCylinderAltDiff=n (half cylinder height in feet, eg 500) It's the latter parameter being non-zero which changes the mode to your vertical cylinder system -- if it is omitted or zero the normal system is used. This only applies when your aircraft is airborne. On the ground the normal system is used. Incidentally, it only deletes one aircraft at a time, still -- the nearest. You didn't really mean to clear the whole cylinder or aircraft, did you? I could do that too, and in fact it would make a little more sense to me as you'd not need specific TCAS confirmation either, just knowing that your space is clear. However, if I added that I think I'd prefer it to be a different control. "Traffic ZapAll" or something. And it would assume a cylinder with a fixed altitude difference, say 500 feet. Regards Pete

Yes. Microsoft have always called this "Kohlsman inc" and "Kohlsman dec" -- after the German company which invented the little pressure window in early-days altimeters. In fact they spelled it incorrectly to, as the company was named "Kollsman". There's an easy way to find out the FS names for any controls. Simply enable Event logging (axis or non-axis) in FSUIPC's logging page, then operate the control using the regular FS keypress or mouse clicks. Look in the FSUIPC log and you will see the control named. FSUIPC gets all the internal FS names from a table in Controls.DLL, part of FS itself. Regards Pete

I assume a Delphi "Longint" is 32-bits, then? In most current languages I think an Int or integer is 32-bits in any case. In C/C++ you can have a "short int" too (16-bits). Some versions support "long long" for 64bits but Microsoft C/C++ seems to have special types like _int64. One of the problems in C/C++ is that types like "int" are actually of undefined length -- they are the length of a 'normal' number on the hardware being used. Hence compiler-system-defined types like _int8, _int16, _int32 and _int64. Regards Pete

The mechanism isn't based on whether the gauge code is in C/C++/XML or whatever, but whether the way the mouse rectangles are defined is based on the structures in the gauge toolkit. It relies on being able to find the mouse rectangle table and locating the appropriate entry by its offset in that table. To do that they have to be pre-defined, not generated on-the-fly, and in the correct format. It is the offset which is recorded, plus a couple of check bytes for safety. Incidentally I thought CAB files were simply a collection of compressed GAU files -- surely they aren't themselves another unique type? Regards Pete

Well, I don't think TCAS is that accurate that you can know this, and a lot of folks' planes don't have working TCAS in any case. I still think you should be able to see what you are zapping. Sorry to disagree. 66% but with MyTrafficX, which is actually a lot more than 100% default AI. I also use Radar Contact 4 for ATC, and that does deal with dire conflicts quite well. Not 100%, but enough for it not to be a huge problem, ever. That's both with FS9 and FSX. RC5 promises to be even better, but for other reasons in the main. Isn't that one of the reasons you fly to busy airports with 100% AI? If you don't have any conflict avoidance to do, any go-arounds to do, ever, just a plain old landing like all the others, why do it? Live and deal with the extra excitement! ;-) Regards Pete

I'm surprised it does anything in FS9 -- that's a bonus over what is documented, I think. It is part of the 3-element SimConnect variable "STRUCT BODY ROTATION ACCELERATION", which provides these read-only values in the X Y and Z axes. Unfortunately no other rotation acceleration values are provided nor accessible. Can you do it by writing values to the ROTATION VELOCITY BODY X,Y,Z values, offsets 30A8-B8, as they are certainly writeable? Meanwhile, to ensure this is fixed in the next version of FS, please write your needs to tell_fs@microsoft.com Regards, Pete

Vertical? Obviously I did completely misunderstand you, then. You want to be able to zap aircraft above you and below you, not specifically in front of you, the only limitation being the range or altitude difference? I really don't see the point of that at all. If you cannot see what you are zapping, I'm essentially against it. I was almost willing to concede the horizontal cylinder idea, with the proviso of a max 45 degree bearing (to avoid zapping something beside you). I'd do it by the range-from-extended-centreline method, taking the nearest AI within the right distance with a bearing less than 45 degrees off our heading. I would only apply this to airborne user aircraft. Otherwise the current ground zapping applies. Regards Pete

And this has changed recently, or has it not been tested before? FSUIPC merely calls the routine inside FS which is the same one used by Ctrl+; and the menu facilities. Are you leaving enough time between the calls? i.e. is the flight fully loaded before you try again? No idea. FSUIPC can't do anything differently. You need to always tell me the Version number of FSUIPC -- if not the latest, try that, just in case (the latest is 3.829, available in the Announcements above). Also, it would be useful to see the IPC write logging -- I take it you have used the Logging to check what you are doing? [LATER] I have just tested it using FSInterrogate, with three FLT+WX combinations renamed x y and z (to make it quicker to edit the pathname in FSInterrogate). All three were loaded correctly. I continued and did the same three again, with no problems. So, it sounds like you have some problem in your program (which you should be able to diagnose with the help of Logging), or possibly some problem with FS or your Flights. But try the very latest FSUIPC first -- I was using 3.829. Regards Pete

Sorry, I do really know nothing at all about Elite. All my PFC support has been for their equipment operating with PFC's proprietary protocol, not the Elite protocol, which I've never seen. Only Elite support can help you I'm afraid. Regards Pete

No, you'd decrease the range to give a wider angle. The reason for the normally narrow angle is because during testing (and Beta testing) it was far too easy to zap the wrong aircraft, especially when trying to clear a space on the tarmac to park your vehicle. The wider angle with less range makes sense when you look at it like that. Well, 2 to 3 miles is a heck of a long way for this facility when you consider you don't even get AI aircraft drawn over 10 miles away. Surely you can leave it a lot lot later than that? at 2 to 3 miles without having a very narrow beam the ambiguity about what you may zap would be huge. Sorry, I obviously misunderstand. If there's no angles involved and the nose is irrelevant, how is this "cylinder" computed? Are you talking about using aircraft track not heading? And are you saying everything in that cylinder? Or just the nearest, like the aircraft to your left innocently on approach to a parallel runway? The geometry / trigonometry of what you ask would need figuring out. What I implemented already was straight-forward range and bearing computation. I'd have to go revise trig from my old school books to work out range from an extended centreline. I suspect I'd still want to use heading not track, though, as the former is visually discernible more readily, so the nose is still important. And is this cylinder horizontal, or tipped for a climbing or descending aircraft? The trig for anything but horizontal would be even more horrendous, but if it isn't tilted, the diameter would need to be that much greater for your approach situation. Do you have any formulae? don't forget, all I have it Lat/Lon/Alt/Heading for your aircraft and Lat/Lon/Alt for the potential targets. Consider these as X Y Z coordinates in 3D space. Now I need a formula. BTW surely only in front, though, not behind? You wouldn't know what you were zapping if you aren't looking. If it starts to look feasible I'll put it on my list, though it actually sounds more like a good application for a little add-on utility rather than something built into FSUIPC. In the current FSX version there's a facility for Lua plug-ins to FSUIPC, and this facility could most probably be programmed that way. But I've not yet considered porting it to FSUIPC3, though, because so far no one has expressed interest in the FSX version. :-( Regards Pete

It's really meant for zapping during taxiing. The zapping on final approach was a bit of an after-thought, though it works well if you leave it till the last moments. There might be a problem in a crosswind landing, with you crabbing, till you kick rudder to straighten up of course. Aren't the user-adjustable parameters already provided sufficient? Have you tried changing them? You can only alter the range, the angle alters in inverse proportion. Regards Pete

I don't know Delphi, but this looks wrong: Considering the value you are reading is a 32-bit integer (occupying 4 bytes), don't you think one byte (8 bits) is a bit small? You do seem to know it's 4 bytes long because you have that in the Read: Regards Pete

Disabling only UNC doesn't really leave it at risk provided you think twice before executing or opening any files you don't know. I think all UAC really does is ask you to confirm that you really want to do what you say you want to do -- those annoying messages asking for confirmation. It may also stop some things being done without elevated administration rights. I'm sure that if you still have Windows firewall and defender running, and a good anti-virus (like AVG free) then you'll be just as well protected against everything, except of course yourself. ;-) Regards Pete