Pete Dowson

VAFS support needs to help you. I am not so sure that your problem is the same as the previous one reported in this thread, which I think may well be down to an illegal registration of FSUIPC (the submitter never came back, after all). You have not registered FSUIPC, and the log shows everything is fine as far as FSUIPC is concerned. The VAFS folks will need to debug their program from their end. One point. It looks like your FS2004 installation takes a full 3 minutes to load upor was that merely you leaving it that long on the initial menu? Then another minute to load your selected flight. And then, when FS was ready to fly, you only left it for 6 seconds before closing it. surely you didn't manage to load VAFS and see it fail in that short interval? Or else, it may be that you are starting this "VAFS" too early, before FSUIPC is ready. You should probably wait until you are fully ready to fly. Regards Pete

Hmmm. i'll have to check that. My algorithm should still be able to match it. [LATER] Found it! It's a very very (very) long-standing bug. All versions of FSUIPC4, in fact. I'll fix it in FSUIPC4 in the next increment uploads. Good catchthanks! (Just shows, not many folks share by drive instead of path). It doesn't apply to FSUIPC3 -- in that it simply uses the first PATH it can find which fits. So if the Drive is listed first, it uses that and doesn't search for a folder match at all. But I improved it for FSUIPC4 by making it search them all and choosing the one which made the UNC path the shortest (and hopefully thereby the neatest). Unfortunately, in the process, I messed up the drive-only matching case. Regards Pete

The only time i've seen that is when the path isn't shared at all. FSUIPC looks up the shared paths lists in the registry and runs a comparison against the path it needs to find the longest match, then uses that. So, for instance, if you shared the FSX path itself with the share name "FSX", then the UNC path would be \\\FSX. The registry entries containing the share paths are found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares For each shared path or drive, the shared name will be a parameter key, and the data will contain a part called "Path=..." which is the one I will be attempting to match. Check this with Regedit. If you think it looks right, and FSUIPC4 is getting it wrong, I would need to see the whole section. Either export it and ZIP the exported file, or take a screenshot (provided all the shares and all the Path= parts are showing). The exported file might be best. If its too big to past as text here, ZIP and send to me at petedowson@btconnect.com. Alternatively, try sharing the folder as, say, FSX. You'll find using short specific share names far more convenient. Same for the My Documents FSX files folder. I always share-name that "FSPLANS" in any case, as Project Magenta needs it so. Regards Pete

There are examples, and the T8 and P8 LEDs are the easiest -- just one line for each LED stating what lights them. You'd need the FSUIPC Offsets list (in the FSUIPC SDK) to find the values the LEDs are supposed to be indicating. Regards Pete

Sorry, can you expand more on how you are doing this? Is it by program, over the IPC interface, using some offsets? Do you have a log of this? Have you tested using FSInterrogate? Regards Pete

Hmmm. you might be able to do it by assigning keys to virtual buttons, then processing those with conditionals, but I think it would turn out less than satisfactory -- everything will be going through too many steps and Windows messaging, slowing it down. You need to be able to turn in fast enough to adjust frequencies in a reasonable time, and I think with keypresses you'll probably have to hesitate between each click. not nice. I assume that type of rotary must be cheaper, or easier to obtain? Those I have are definitely easier to program. Regards Pete

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