Pete Dowson

Well, i don't know VB, but aren't their Strings fundamentally different in storage to standard ASCIIZ? For example, don't they start with a length byte instead of ending with zero? And I seem to recall that by default it uses either Unicode or wide character format, not ASCII. You may need to declare that field as an array of 15 BYTES instead, to be safe, then convert it to a VB string afterwards. After that, provided Integer is definitely 16-bit ("WORD" is a Windows type defined as "unsigned short"), and provided VB doesn't pack any extra bytes between any of the fields, it should be okay. I suspect VB doesn't support "unsigned" types -- if not, take care with the heading as you'll get that in the range -32768 to +32767 (representing -180 to +179.9999), so you'll need to correct for that to get the proper unsigned range, 0-359.9999. If you can declare an array of 96 of those structures, and read the complete 96 x 40 bytes in, you have all the data to hand. read it at, say, 1 second intervals (normal TCAS scan rate) and you should be fine. Regards Pete

I'm afraid it is looking rather like a hardware problem, possibly something on your motherboard as it appears to be affecting both COM and USB ports. Before rushing to replace that, however, there's a chance that some installed driver, maybe for the DSL connection you had changed, may be clobbering things (e.g. trying to share the IRQ and failing), so you could try a process of uninstalling the Network / DSL connection altogether to see if that brings things back to life. However, this isn't something to be taken lightly and if you are not totally confident of being able to reinstall everything and get back on-line I wouldn't start. I assume you've tried alternative USB sockets? Do you have any USB devices which are working at all (oher than simple LED lights, which only use the power line, of course). Maybe you can plug your mouse into one and see if that still works? You might try to find a hardware help forum, but in the end you may need to take it to a commercial company to get them to diagnose the problem and fix it. I cannot see how us software types can help a lot, at least not without access to your machine. On the specific observations: Unfortunately many folks find that uninstalling and reinstalling FSX clobbers the Simconnect system, essential for FSUIPC and many other FSX add-ons. The problem is that uninstall doesn't properly uninstall SimConnect, as it is then part of the Windows SxS (Side by Side) library system. Then it doesn't get instaled correctly. Help for this is given in the FSX Help announcement above. Really none of your symptoms were at all related to FS or the PFC or GoFlight drivers in any case: Yes, this is what it looks like when there's no connection. Something en route is broken. Regards Pete

Doesn't look like it helps there with structures, does it? I just Googled for "structures in VB" and found these two which may help. http://msdn.microsoft.com/en-us/library/78kf2xd4(VS.80).aspx http://weblogs.asp.net/pleloup/archive/20138.aspx The first most certainly seems to indicate that VB supports structures and arrays of structures. I don't know VB at all. Don't you have any reference material you can read? Erplease re-read my last message, in which I declared the data area for reading, the offset and the size. You seem to be skipping things! Please read what I write otherwise we will get nowhere. We? I am not confusing them, and you must not either. Your program will never work if you don't take care to use the correct types and not mix them up. Bits are not bytes! Pete

What do you want to achieve with limited sensitivity? That is an ambiguous term. Does a more sensitive axis give finer control (one interpretation), or does it make things change faster (so, coarser control)? Do you want to be able to access the full possible range of movement of the aircraft's control capability, or put upper and lower stops on what it can get to? FSUIPC's calibration is designed to ALWAYS achieve full control, from minimum to maximum FS capability. So if you aim to prevent, say, full throttle, or full elevator up/down, etc, then I'm afraid FSUIPC will defeat that objective every time UNLESS you use RAW input in FSUIPC's axis assignments, then, after calibration, alter the calibrated values in the INI file so that the min and max values it uses are outside the axis's RAW range. That makes the FS extremes unattainable, as the RAW values can never get there. (You could achieve the same without using RAW mode if the normal non-raw axis inputs are substantially less than 16380 -- that depends on their drivers and what happens in Windows calibration, which would normall scale them). This cheat is, however, thoroughly NOT recommended. In my opinion you must ALWAYS be able to get to all possible settings FS allows. So, it comes down to whether you want finer control in the central areas, or courser control. For that it has to be adjustment of the slope. The extremes are "tethered" to achieve the full range, but the spread is placed to give you the "sensitivity" (in whichever possible interpretation you meant it) where you want it. Incidentally, as far as I can tell, FS's own "sensitivity" is basically a divisor -- it divides the value it receives from Windows calibration by a different amount depending where it is. Effectively the lower you set the slider there, the cheaper and more granular you are making your joystick -- so you can buy a really expensive joystick with maybe 256-512 step resolution on each axis and make it operate worse than one with the usual 32-64 steps (or even less) you can pick up in a toyshop. This is why I always advise setting that at maximum. Regards Pete

Sorry, what exactly IS "the next airplane? The table contains details of up to 96 aircraft. Each slot can contain details of an aircraft, or it can be free. As aircraft come and go slots get freed then re-used. You can tell when slots are used or not and when they change from the ID. There is no such thing as a "next airplane". What sort of idea is that? And what do you mean by "not fair" in this context? Of course there is. Where are you learning your programming? Structures can be of any length. Just define the structure as documented for you. That's most of the programming already done! And why are you referring to 32 bytes? Neither of the tables have 32-byte slots. One is 40 bytes per slot, and the other is 20 bytes per slot, as clearly documented. Assuming you only want the data in the main Airborne table, the 40-byte per slot one, all you'd need to do is declare your array: TCAS_DATA tcasAirBorne[96]; then read into it (i.e. to (BYTE *) &tcasAirBorne[0] ) 96 x 40 (i.e. 3840) bytes from offset 0xF080. When that completes you have all the data in your own array of 96 entries and you can scan reading the id's, for example: for (i= 0; i < 96; i++) { if (tcasAirBorne[i].id != 0) // deal with airborne aircraft } I shouldn't really have to teach programming here. Regards Pete

I don't think that's FSUIPC4 -- it will be FSX. In order to make sure it doesn't intercept any axes not actually being used, since a few versions ago it doesn't intercept (nor therefore calibrate) any axis until it sees an input for one. It can't stop that first one going through as it isn't intercepting at that time. So, until you move the axis, FSUIPC4 isn't actually interfering with it at all. That was the only way I found to deal with some of the peculiarities of SimConnect and how they affected some of the sophisticated add-ons, like the Level D aircraft.. The interception is reset whenever you load a new aircraft in case you use different axes with it. The one way to stop this to is bypass both FSX and SimConnect and only use FSUIPC4 axis assignment, with axes directed straight ot FSUIPC4's calibrations. Then SimConnect isn't used, and there's no interception of axes needed at all (because none are seen by nor transmitted from FSX). Hmmm. If that's the case, then the explanation I've just given cannot really be the reason -- unless the USB driver for that controller does feed values for all operating axes on that controller when you move just the one. FSUIPC's own axis assignments doesn't take any notice of unchanging input values, it only acts on them when they change. This makes it much more efficient than the regular 6 per second readings FS performs, and it means it can operate faster when needed. However, it too may be contributing to what you observe. It puzzles me as to why you'd get a zero input. There's never anything in FSUIPC which creates an input value. It either intercepts (or reads) and calibrates or it doesn't. So I don't really understand where your zeroes are coming from. It might have helped a little to understand if you'd described how you are dealing with the axes. There are several combinations, different paths through FSX and FSUIPC4. Regards Pete

Does FS9 do that, or is it supposed to be a function of the Level D 767? Parking brake key? "Ctrl+." you mean? That would toggle the Parking Brake on, so tapping is the same as holding it down -- or do you mean just the Brakes (.)? The latter sounds more likely to me. Maybe something is watching for the BRAKES control and not the AXIS LEFT and RIGHT BRAKES controls, which would be used by the pedals. I don't see how calibration would change anything, that's for sure. Of course, if you assign them via FSUIPC you can also assign a Control to be sent when a particular range is entered on the axes, so you could get it to send a BRAKES control (if that is what is needed). Better to send a Left Brake for LEft and Right Brake for right, if they work -- you could test those by "tapping" F11 or F12. What about the defaults? I really don't know if this is an add-on function or not. If it is built into FS (which I don't really think it is), then it sounds like there's something about the way the LEvel D is intercepting things which is stopping that happening. More likely, though, it isn't an FS9 function and the implementation on the Level D is only taking note of the Button/Keypress Brakes control(s) and not the axis ones. Regards Pete

As you will see from the data definitions 9the structures in the documentation, yes, the one field which needs to be an ASCII string is an ASCII string, but its only the one. Well, writing is the same as reading except you supply the data and use a different command. But there's certainly no writing involved whatsoever in READING traffic data! Where do you get that idea? Sorry, what is this about? Please be more specific. The structures are most certain of a specific length, each variable in them is defined by the language they are shown in. And the size of each slot is defined. What are you reading? You seem to be reading something completely different! I've never had so much trouble with such simple things! Have you done much programming before? Which is fully defined in the documentation if you'd only read about it! :-( Please, if you are going to misread documentation, at least be specific so I can see what you are reading. It evidently isn't the parts in which I describe this facility. Regards Pete

Er, do you have the FSUIPC SDK? If not download it. Inside you will find a "Programmers Guide" document. There's sections near the front describing the structures I mentioned. Structure definitions include variable types, of course. The offsets are listed -- there's a large table of all the offsets and you'll find the ones you want in there. I really thought you would have looked first. It makes sense now that your earlier questions were so, basic and confused. You should really use the tools provided, including the SDK. Get it from www.schiratti.com/dowson. Of course not. Why encode stuff like Lat/Lon/Alt/Hdr etc in string format? There's not enough space as it is! That would be very inefficient! Pete

Yes, as you already said I think. All that is available for AI traffic (though not necessarily tail number -- it's a user option. Mostly for commercial flights it would be airline and flight number. Whether on-line MP traffic injectors provide all that or not I don't know. What took a long time to load? The traffic, TrafficLook, or the data in the display? It appears as it is available -- the traffic build up in FS is not instantaneous in any case. I'm not at all understanding what you mean. Nothing takes very long on any system I've ever used it on. Really? Why on Earth longer than one second? Most TCAS displays using FSUIPC work very well much faster than that. What is the problem? Yes, of course, as I've said (several times already?). FS can only read AI traffic details from FS. Eryou read the tables in FSUIPC, if you want to use FSUIPC. I am really bewildered by your questions. You ask about reading traffic data from FSUIPC, I point you in the right direction, then you ask me if you have to read it to get the information you want? Sorry, this is nonsense questioning. Please, can you try to be more specific? No. Why do you think that? Where would you supply a "slot number"? What are you reading which even suggests such a thing? All the traffic data is laid out in 4 tables in FSUIPC's offsets -- 2 for ground traffic, 2 for airborne traffic. There are only so many slots. When a slot is freed (because the aircraft leaves the area or transfers from air to ground or vice versa, that slot may be reused. You can tell which slots are used by the non-zero ID. The two tables for ground (and also those for airborne) have the same slot allocations -- it should be one table but as more data was added the space ran out, so one table is just an extension of the other. Why? There's lots of information provided in the Programmer's Guide, including the structures to use to define the data format for each slot. All you need is an equivalent set of arrays of structures in your program to read the offset data into, maybe all in just the 4 reads, then deal with the contents as you like. This is effectively what TrafficLook does. Pete

Nice. For multiplayer on FS9 or before you have to be sure the on-line link program injects the data into FSUIPC's TCAS tables. I think Squawkbox 3 does. Not sure about the IVAO programs. There was a program called AIBridge which did it for previous programs (that's by Jose Oliveira). For FSX I think the on-line flying programs create AI traffic instead of using the MP interface -- if they do they should be already sorted. Well TrafficLook will allow to corroborate what you are reading with what it sees. Of course you can also use FSInterrogate to show the TCAS tables areas in FSUIPC offsets. I can answer specific questions if you stumble over anything. Regards Pete

Yes, I don't think one specific unit can be "shared" as all the LEDs are controlled by the same command. Regards Pete

Copy and paste from someone else's bad code you mean? Regards Pete

Download and check through the FSUIPC SDK then. Maybe one of the languages supported by contributing enthusiasts may appeal to you? You'll need full information on programming the displays you have too, though. Regards Pete

If there's nothing else driving these LEDs, and it takes several minutes to change, then it seems to indicate that the trigger is changing -- i.e. the bits in offset 5678. Use the FSUIPC Monitor facility (on the logging tab) to see what is happening to those. Are you sure they're correct? Pete

I don't know VB, but don't "" normally enclose a string? If so, then all these are wrong: A string "0" is NOT the same as an integer which is zero, nor (for 32FA or 1274 a 2-byte (16 bit) value which is 0! "0" is certainly not 0! Why are you writing to 1274? That is an FS menu option. I'd delete that part if I were you, in any case. It isn't part of this facility. And here: it is very inefficient to write 128 bytes when the string is a lot shorter than that, and may cause your program to crash if the undeclared bytes are not in accessible memory. Do you have any VB programming books you can learn a little more about it from? Regards Pete

Sorry, but you've wasted your money buying FSUIPC, then, as it doesn't drive displays. It never has been a hardware driver. If it is the FSUIPC application programming interface you were interested in, that's free in any case for personal use or for freeware applications. You can't. There are no facilities to drive displays. FSUIPC is not and never has been such a program. You have to be a programmer and write your own program. You'll need to get yourself some books on pogramming, then refer to your hardware manual for your display and the FSUIPC SDK for the interface. The user facilities you pay for when you buy FSUIPC are all described in the user manual. If what you want to do is not described there, it doesn't do it. Regards Pete

You should have mentioned this to SimMarket. They should still be able to sort it out for you if you raise a problem ticket with them. Otherwise you can send me all the details -- full details of both FSUIPC and WideFS registrations, and I will update the FSUIPC one for you. Send to petedowson@btconnect.com. Regards Pete

Sorry, I'm not sure i understand you. If you mean to have separate bits for up to 4 pumps, then how do you expect to accomplish this? FSX only provides one switch! Maybe FSXI or ESP2? Regards Pete

How are you doing that, please? Which version of FSUIPC is that with, please? It is either an old one which had such a bug, or, possibly, you have the throttles assigned in more than one place? First please make sure you are using the latest FSUIPC release -- 3.82 or 4.30, or the interim update availalbe in the Downloads announcement here. It's 2 am here now. I just saw this befor switching off, so sorry for any delay whilst I sleep. Regards Pete

Hmm. Thank you for the compliment. Have a nice day yourself. I reply for the benefit of other readers. That's why I operate a Forum and not, as I used to, support by private email. The right direction to do what? I corrected the mistake you made in stating the mappings in case it confused other readers, and I pointed to the correct checkbox for mapping one to 4 throttles which is what you appeared to ask for ("multiple engines on one throttle", remember?). I said it a way that showed I couldn't see a way to make it easier for dummies, which is what you asked for, right? Regards Pete

It just occurred to me that I operate the PM TO/GA option in the PFC driver for their 737NG cockpit, so i looked it up to see what I did (this is several years old, so I couldn't remember off-hand). It uses this other offset, just grabbed from the PM documentation: This definitely works because, as I say, I use it. To operate that from an FSUIPC assignment you'd use "Offset Word Togglebits" (because, as you'll see above, it says these are bit toggles -- i.e. it looks for a change, it doesn't care what the state is, only that it changed). The offset is x050A and the parameter, for bit 0, is 1 (2 to the power of 0, the value of the lowest bit in the word). Regards Pete

Reading the PM documentation (on the PM website), the 04F2 offset needs a VALUE written to it, not bits set as such. It looks to be a Word offset (2 bytes) and you need to write the value 121 to it. So the Offset control to be used would be "Offset Word Set", with the offset x04F2 and the parameter 121. If that doesn't work you should file a bug report to PM support. Really you should be getting this help from PM support rather than me. I expect you paid them a lot more than you paid me! ;-) No, it is evidently new. I cannot keep copying PM's documentation into mine, which is why I advised you to look to the PM website. FSUIPC interfaces to FS. The majority of defined offsets for FSUIPC are those relating to FS, not to PM. The PM offsets are their "private allocation", which is why they document them. If you want to use a default FS aircraft, the TO/GA offset in FSUIPC will control the default FS TO/GA facility -- though I think there's no need to use offsets as FS provide a control for it -- "Auto throttle to GA" (that does for TO and GA it seems). Most sophisticated add-on aircraft do their own thing, however, especially in the A/T and A/P areas, so FS controls for those aren't so applicable. You have to refer to the third party documentation (and support, of course). PM is no different, it is like a very sophisticated add-on aircraft panel. Regards Pete

Yes. You can use the Offset controls to toggle a bit in the Virtual Buttons offsets, 3340 and following. Thre are 36 bytes in which 8 bits each represent a button on a "virtual joystick" -- numbers 64-73. There are 32 buttons on each of the 9 joysticks, giving 288 possibles. So, for example, for the first 8 joystick, number 64, you'd assign Offset Dword ToggleBits as the control, with x3340 as the offset, and then 1 for button 0, 2 for button 1, 4 for button 2, 8 for button 3 and so on. The next joystick, number 65, would be at offset 3344 (there being 4 bytes in 32 bits or one Dword). Unfortunately, because the keyboard reception isn't working when the button scanning is used whilst INSIDE the FSUIPC options, it isn't possible to program these buttons from the FS PC's keyboard within the FSUIPC options. They were more intended to be used from an application program or vis the button facilities in WideClient. So, you'd need to assign the keypress controls in the Options dialogue, carefully noting which joystick number and button number it is so you can use that when editing your INI file. Using "togglebits" you'd change the status of the button on each press -- press for on, press again for off, and so on. To emulate a normal press / release button you'd program the keypress to send the "setbits" control on the press and "clearbits" control on the release, so the button only looks pressed whilst the key is held down. Best also to check the "No repeats" option (added in the new versions of FSUIPC). You can't access button and flag states directly through offsets -- only the virtual buttons as just described. Regards Pete

Display it on the Google Earth display, you mean? That'd be clever? In 3D, or do you just mean mark their positions? What are you reading? Have you downloaded the FSUIPC SDK and checked the documentation? You won't get any multiplayer data unless some program is providing it directly to FSUIPC. FSUIPC only gets AI Traffic data direct from FS -- try using the supplied TrafficLook program to see. As documented. Have you any more specific question? I really cannot teach programming from scratch, you have to tell me what you don't understand, after you have referred to the documentation supplied. Regards Pete