Pete Dowson

Hmm. That's unusual. Mine don't. But it may depend whether you swap between one pair of USB sockets and another pair (USB sockets always seem to be paired). Maybe also it needs a ssytem re-boot without them connected in order to clear the assignment tables, possibly made in the BIOS at boot time. Sorry, I don't understand. What windows? And why would the order matter to you? Only by trying what I say above. But I am puzzled as to what the actual number of a device matters if you aren't using it. Regards Pete

That simply means that CHCM is the installed "Game Controller" for that device. You will get default Windows Game Controllers for devices for which you've not installed a specific driver. Not enough information there. Where are you looking, Axis assignment or joystick calibration? Where is the throttle then assigned? Are you perhaps looking at the 4-throttles page when you only have a single generic throttle assigned, whether in FS or FSUIPC? There are too many possibilities to even guess what you are doing and what you are seeing. If you look through the thread so far, you can see it's really just been going in circles, getting no where. If you want to resolve anything you need to stop and provide information, real solid black-and-white information. Why would you need to do that for REX anyway? Is it in their instructions? If you are using it to control the weather it should be able to clear the weather on its own. Otherwise it would be a rather poor weather control program, don't you think? Regards Pete

The only way I know is by using a database of runways, like those produced by my freeware "MakeRunways" program, and use the Latitude and Longitude of the aircraft to work it out from the latitudes and longitudes of the runway centres, with their lengths and widths to define the rectangle. Alternatively I suppose it could be done by finding the correct AFD (Airport Facilities Data) BGL at the time, and analysing the runway data in that. But I would have thought that would take too long unless they've found where it might be in FS memory -- the latter would be neat. ;-) If FSPassengers does it without a database or reading the AFD data "on the fly", then the author(s) must have found a different way. If they have I doubt they'd release the information. There are several interesting programs which do clever things like that -- FollowMe, for instance, is able to get the taxi routing which FSX ATC would direct traffic along and use it to route the FollowMe car. Regards Pete

Sorry, I don't know what the incompatibility was. But a good place to ask is on the RC forum at http://forums1.avsim.net/index.php?showforum=135 Quite honestly, I don't actually know that RC uses the facilities I mentioned, only that they were originally added to FSUIPC for RC after discussions with the RC authors. Even if RC does use the facilities, it might be that it also still depends on the TCAS mode setting for other parts of its interaction. Regards Pete

Yes, it is automatically installed into your FS Modules folder when you install. You do not need to purchase a Registration in order to install it and read the dox. Later, when you want to Register just re-run the Installer. Note that there are usually (as now) updated versions available in the "Updates and other Goodies" Announcement here in the Forum, so after installing the current main user release, please do avail yourself of the improved update versions. [LATER] I've also now provided the documentation package separately as a download from the Updates and other Goodies Announcement. Regards Pete

Hmm. I'm surprised FSUIPC didn't refuse to run in the second instance, complaining that a copy was already running. That's usually the result of such an attempt. Good. Possibly the previous INI hadn't been saved because of the non-termination. No problem, don't worry about it. Glad you are sorted! Regards Pete

Sorry, no. The limitation is nothing to do with generation of tables or transmission to WideClients. It is the compression of all the possible information about AI aircraft into the limited table space allocated in the offsets. The whole system of offering traffic data was intended to be sufficient for TCAS implementations, and it certainly is. Most of the other applications it is now used for are naturally more demanding, but to redesign it now would mean a pretty thorough revision of both versions of FSUIPC and all of the applications which depend on the formats already provided. FSUIPC does (and has for a long time) provided a way for applications to read any or all of the full AI traffic descriptive strings (not just the very abbreviated ones in the TCAS tables). This is by individual AI requests (one request per string) via the 16 byte offset D000, also the palce for detecting runways in use. The strings available, up to 48 characters each, include: Tail number Airline name + Flight number ATC aircraft type + model (as tweo zero-terminated strings) Aircraft title ATC aircraft type + last 3 digits of tail number Of course, this mechanism was intended to be used by ATC programs needing specific information about an aircraft they are about to talk to, so they could formulate their requests correctly no matter what mode the TCAS table was set to. I believe it is used in this way by Radar Contact. Because of the amount of FSUIPC interaction required for each AI aircraft, it isn't really so suitable for the construction of tabular traffic displays such as those provided by TrafficBoard (or my own TrafficLook), though it isn't beyond the bounds of feasibility. Really, if there was any reason for me to seriously revise the TCAS tables in FSUIPC, I would prefer to expand the current limits of 96 ground and 96 airborne aircraft. Both are now getting to be quite a serious limitation, with products like UT2 and MyTrafficX easily able to populate "mega airports" like Heathrow with 200+ aircraft. However, even if I found a way to expand this without inducing incompatibilities for existing programs, the extra "slots" still wouldn't be useful without those programs being revised to access them. Of course for FSX it would be more appropriate for new or thoroughly revised programs to use SimConnect directly, as always intended. The extended life of FS9, probably still around 50% of the market, has really spoiled that type of renewal, but things are going that way, nevertheless. Regards Pete

Ugh. What a horrible language it must be! Two points then: 1. It doesn't matter how many bytes you write, provided no more that the 32 (from offset 2FE0), and the last one is zero. It is the zero with terminates the title string, not the end of the area provided for it. 2. If you must write the parameter byte(s) and string separately, it would be safer to write the string first, then the "slot" byte (0), because it is writing the slot byte which triggers the action. Of course, as I said, for submenus the "response byte" can be part of your title string. Just use distinct letters or number characters so you can distinguish the response when you receive it. Regards Pete

FSUIPC cannot "lose" allocations. Please show me your INI file, and a Log with Button events enabled and you pressing the ones you say are lost. Please make sure you tell me which allocations you think have been lost. Regards Pete

That isn't right in two ways. First the slot number goes in Byte 0. The title starts in byte 1. Second, you should write the whole lot in one write, because FSUIPC will be taking the action of adding the string to the menu system as soon as it sees you writing to 2FE0. If it appears to be working for you you are just lucky. It will be very time critical. The correct way to do it is as shown in the documentation. Declare your title string as, say "XMy title string", i.e. with the extra character at the front, then, before writing that string, alter the first character to the binary number of the slot. Maybe in VB.NET you would have to do this by having the string declared as a BYTE array, so you can address byte [0] specifically./ Same errors here. The 128 + slot number goes in byte 0 not 1 or you overwrite the response. You should write all in one write again. Your title will have two preceding characters "XYMy Submenu title" and you replace X and Y before writing. Bytes [0] and [1]. In fact, because your response number is arbitrary -- your choice of any value from 1 to 255 -- you might as well make it an ASCII character, like 'A'. in which case you only have the Byte[0] to overwrite, in "XAMy Submenu Title" If you are getting away with the code as you are stating it you are very lucky. It isn't designed to work that way. did you look at the Lua example I provided? Lua is quite Basic-like in many ways -- more restrictive in some, more flexible in others. Regards Pete

All these assignments are being made in FSUIPC4's "Axes" tab? You have disabled controllers in FSX itself? What version of FSUIPC4, please? The actual version number is needed. Please also show me your FSUIPC4.INI and FSUIPC4.LOG files from the FSX Modules folder (you can paste them into a message), and tell me the Joystick Numbers and Axis letters of the two axes you think are interfering with each other. Regards Pete

If it still happens with 3.965 please let me know. I'd need some more details then, please: your FSUIPC.INI and .LOG files, and I'd need to know the version of Windows, please. Regards Pete

Okay. Thanks. Pete

OK, I leave that at your desgression I would be a bit worried about messing up folks' assignments (those like yours, in fact) if I just removed it like that, so I will probably make it an option, defaulted in but with an INI file entry which can be changed to tell me not to poll its buttons.

So you do assign in FS, not in FSUIPC? The assignments in FSX change? As far as I know that can only happen if you are disconnecting and reconnecting your controls. Are you doing so? The other thing to check is that you don't have USB power management enabled. If you do then Windows will switch off your controls if they aren't used for a while. That could mean they are not detected when FSX first boots up. To switch off power management go into Device Manager and find the Properties for each USB device/hub listed. If you've assigned an axis in FSX and it doesn't respond in FSUIPC, then it can only be that the sensitivity slider in FSX is too low. The sensitivity slider should be at max (full right) and the null zone slider at min (full left). These don't matter if you aren't assigning in FS, but are crucial if you are! Have you tried the obvious? Press the Start button (bottom left), and in the little edit box you see (where it says "search programs and files") enter "Game controllers" and hit Enterit comes right up. Alternatively, in "Control Panel" you will find "Devices and Printers" and among the Devices listed there you should see individual "Game Controller" entries for each recognised joystick type device installed. Many folks do disable game controllers entirely in FSX and assign everything in FSUIPC, and, of course, it works with any aircraft. In fact with FSUIPC you can have different assignments for different aircraft, automatically changing when you change aircraft (e.g yoke for Boeing, joystick for Airbus, G-stick for Helo, etc). However, if you want to keep things simple, get things working in FS. You should get things working in FS first in any case, because problems like the power management one will defeat any software. Take a look at some of the helpful documents available. The one from SimSamurai is quite good, even though it is talking about FS9 it nearly all applies to FSX too. Also there's a guide for CH users in the "stickie" threads near the top of the forum. Regards Pete

Okay, but it is now out of date and not supported. The current main release is 3.96 with an improved version 3.965 already available in the Updates and other Goodies announcement above. Regards Pete

That's good! Ah. I know absolutely nothing about WidevieW these days. Last time I used that was with FS98 I believe. It was all rather different back then. You do realise it isn't anything to do with my programs, I assume? The free program "SuperATC" can be use to recognise ATC commands/response to Radar Contact. It uses Microsoft's speech Recognition. Regards Pete

Sorry, I really don't know. Why not try it? There's no fee! Regards Pete

Sorry, I cannot support old versions. 3.96 is supported, and there are further fixes and improvements in the update already available in the Updates and other Goodies announcement above. If you do not update I cannot really help you with anything. Regards Pete

Okay. All done and dusted. Download 4.578 from the Updates announcement. Here's the documentation: Have fun! Regards Pete

The flags are only set if SimConnect sends me a new value, and it won't send a new value if it was exactly (and I mean EXACTLY) the same as the previous one! Sorry, I thought that was implied. All i was saying was that if they are all changing the changed values all get provided at once, not one after the other. If they don't change you get nothing. You can see this in slew mode. No change initially. Raise the aircraft -- only the Altitude flag is set. And so on. When you don't see a "new" value the old one is still current. The "timer" is a timestamp. It records the time of the last CHANGE to one of those 6 values. If they don't change, why on Earth would the time in 0588 be changed? You seem to miss the point of it. I'm sorry, but you seem to be misunderstanding something here! :-( The FLAGS show which values CHANGED at the TIME shown in 0588. If none change subsequently, those flags and timestamp are still correct. Obviously, surely!!! 25 or 6 to 4. I think only because you seem to have missed the point of the changes. It is recording the time FS changes the values, so if you have a steady frame rate then of course it should be spaced reasonably regularly! Sorry, all this seems obvious -- are you and I on the same wavelength anymore? Ideally each packet of information from SimConnect should be timestamped, so you know the exact time the information provided was accurate. They didn't implement that. I explained it to you if I remember correctly. What I've done is the next best thing -- provided a timestamp on the arrival in FSUIPC of the packet. This will be more accurate than you reading any timer anywhere when you are polling, because your poll will hardly ever coincide with the actual arrival of data from SimConnect. It cannot, don't you see? It isn't complicated. If it helps understand, please think "timestamp" not "timer". It is the value of a timer when a particular event occurred -- the updating of those data items. Pete

Actually probably the most common option is a third one -- just having a reverse button which effectively does the same as pressing F2 (i.e. simply repeats the "THROTTLE_DECR" control). Right. Ripe candidates, then for using THROTTLE_DECR repeating on that button. Before you go on, you'll need to clarify that a bit for me. If you are going to use the other two axis levers for reverse, why are you using buttons as well? surely the use of the reverser levers replaces any need to use buttons for reverse? Sounds like the TQ6 is being seen by Windows as a standard joystick (number 2) with buttons, and is also being scanned by FSUIPC because you have GFDev.DLL installed. If you don't have any other GoFlight modules you want to program in FSUIPC you would probably be better off renaming GFDev.DLL so FSUIPC doesn't try to use it. You'll find it in the same folder as your GFConfig program. Actually I didn't know the buttons came through as normal joystick buttons. Maybe I should remove the TQ6 from my button scanning in any case. No one ever mentioned it before! So you are NOT going to be using the other two axes as reversers? This is getting confusing I'm afraid. Yes. now I am beginning to understand that when, above, you said "I only use 2 of the 4 axis for the throttle and ofcourse also two reverse axis" you didn't mean you were using any reverser axes at all. You are simply not using the other two axes at all? (But what was all that about "not real axes"? Buttons aren't anything to do with axes, let alone being real or non-real). It seems to me to be completely realistic to calibrate a proper idle zone, and to push the throttle away from reverse. You can certainly program something like that as a Lua plug-in. It isn't a pre-programmed FSUIPC facility. Take a look at the recently included "TripleUse" lua example -- that provides three separate button uses, but based on quick press, double press, and longer press. You could use a timeout after last release to send another command (just one set set the normal Throttle axes to zero). Only because the button is arriving in FSUIPC from two sources. 4.577 is available now. Regards Pete

Not for the submenu. I need to use the second byte to determine the Response value. Please study it again. No, because the maximum slot number is 56 (there are only 56 slots). The top bit (0x80 added is the flag which tells FSUIPC that this is for a submenu to be added to an already created menu entry. You have to refer to an already set menu slot. Please study the proposal again and think about it. It is so easy to do I've almost finished and will be testing it later! Regards Pete

Actually i just had a quick look and it may not be hard to do. What about a design like this: Having already setup the main menu, write this to 0x2FE0: Byte 0 = 0x80 + slot number of main entry, as before Byte 1 = Response value (any non-zero value 1 - 255) Bytes 2-31 = The zero-terminated string for the submenu entry SimConnect limits you to a max of 16 submenus. There are no further sub-levels. When the user selects the submenu FSUIPC will fill in byte 3 of the slot with the "Response value" provided. Naturally you don't get notified when the main menu entry is selected when there are submenus. What do you think? I reckon I could add that this week (FSUIPC4 only, I'm not adding it to FSUIPC3). Regards Pete

FSUIPC doesn't support that at present, though SimConnect does, so it would be a possible extension I suppose. Really the FSUIPC option is a carry-over from the previous FSUIPC3 versions, and only provides that level of compatibility so that earlier apps could work with FSX without change. If it is a serious need I could probably work out a way of building it onto the current FSUIPC3 facility, but it isn't an instant thing. I'd need to do a bit of research before I decided. Regards Pete