Pete Dowson

Please, please do read the documentation a little more thoroughly. It isn't that obscure! Offset 0020, which you are reading, clearly says that it is the GROUND altitude, in metres x 256. The ground beneath you is NOT going to be going up with you when you climb, nor down when you descend!!! The ground altitude depends on the mesh underlying your scenery! 33474/256 = 131.73 metres or 432 feet. That's the ground altitude above sea level at the spot beneath the aircraft. Pete

Without more details I'm afraid I can't help. Pete

With nVidia and Matrox, at least (not ATI I think) you can configure the two screens as one larger screen. If you do that you can have a much larger FS screen which is all hardware accelerated. I think, since DirectX8, and on WinXP, more than one 3D window can be accelerated at once, but it doesn't matter how you configure it, FS runs really slow with more than one 3D window open. Yes, it is okay for panel parts undocked though. Regards, Pete

Yes. But it wouldn't suit all planes. There are various parts to PM. You can purchase a complete Boeing or an Airbus set, including an excellent FMC, or stuff for a Regional Jet, but I don't think you'll find anything completely suitable to props and light aircraft in general. But it isn't me you should be asking. Go look at their website. For light aircraft like the Cessna, or even the Baron, the better route is the hardware one. The Real Cockpit do nice gauges (under their SimKits banner) and even supply complete cockpit sets. For VFR flying I use a nice hardware panel (for a Piper Arrow III) made by Aerosoft Australia -- but the don't make them any more. Regards, Pete

FS panels, no, Project Magenta, yes. In fact PM was designed for use on several PCs. I actually use 6 PCs for it in my cockpit, though two or three are quite adequate. There's a freeware set of panel programs too, FreeFDs I think it is called -- check the links on http://www.schiratti.com/dowson. Regards, Pete

Gauges are small library routines, just DLLs, than have to be run inside FS as part of a panel. They do not run through the FSUIPC interface to connect to FS so they cannot use WideFS, which is only a Network extension of the FSUIPC interface. If parts of FS were dependent upon FSUIPC for interfacing to FS I think Microsoft would have written it in the first place, don't you? ;-) Any programs (not modules or graphics or aircraft or panels or scenery) which interface to FS via FSUIPC. That's all. Nothing else. Why weird when FSUIPC was written explicitly to link things NOT part of FS to FS? FSUIPC would not be needed to link parts of FS to FS, now would it? THat would indeed be weird. I think you are thinking things backwards? ;-) Interfacing any program which connects to FS via FSUIPC from another PC on a Network. That's all. Go look at ActiveSky, FSMeteo, Radar Contact, Project Magenta, FreeFS, FS Real Time, FlightTracker, Flight Keeper, FDC, TrafficBoard, FSMetar, AFCAD, etc. There's a list of some on the download page at the Schiratti site. If you have no need of any programs other than FS and add-ins like scenery and aircraft then you don't need WideFS and don't really need FSUIPC unless you ant to make use of some of its additional user facilities. (Although of course some panels also use FSUIPC for some things too). Regards, Pete

Please try different aircraft, and always say which aircraft you are using. Don't you have FS2004? I think all FSUIPC does is pass this on to FS, which may not care what value it is when it isn't applicable but may force a change else, hence the needfor checks on appropriate aircraft. Try switching it in FS and seeing what values you get back. I didn't obtain that list, it was provided by someone else who did such tests. Pete

That DLL is an essential part of Windows. It contains nearly al the Windows interface along with USER32.DLL and GDI32.DLL. There may be others, but between them they cover most of what is known as Windows as far as application programs are concerned. You don't really need to "know" about the DLL to use standard Windows interfaces, they should all be documented in your VB package and you should be able to use them without any explicit links. The ones used for serial ports and other devices are also the standard file access facilities. Pete

This is why I always ask those who say they don't understand to be much more specific, so that the wording in the documentation can be improved. And it has been. The stuff on calibrations was improved a great deal in that way in its first few months, but that was about five years ago, and considerng the number of users the number of folks still not understanding it are very very small and those are the ones who are never explicit. It is no good people asking me to explain things any better than I have done because I have done my best there given the feedback I've received. What would be the point of repeating here what is in the documentation? The only sensible process is to get to the real reason someone misunderstands and then trying to word that differently. Quite honestly, users who are computer literate and aircraft literate enough to understand how to use MSFS and fly aircraft with it must be pretty intelligent to start with, so I assume 99% of misunderstandings are simply because my documentation is in English. Why are you looking in FS9.CFG and Devices.cfg? Are you so computer literate you now want to mess in FS's technical files? Why? Anyway, the answer to your first part is that I haven't a clue and I don't think it is at all relevant, and to the second is that FSUIPC doesn't know and doesn't care anything about any devices, joysticks or CFG files. It is only dealing with FS controls, NOT joystick axes themselves. It is FS's job to deal with its CFG files. It is in FS where you make assignments, set sensitivities, and so on. FSUIPC only sees the controls resulting from all that, it doesn't know or care how they get that way. I've really no idea. It was simple enough before FS2002. Since then (when FS changed to DirectX for its joystick inputs) everything changed in that area. I never delved into it because it isn't relevant to anything I do. If you wanted to find out you'd need to experiment. I think the SCALE value is set by the Sensitivity slider and the NULL by the null zone slider. I assume they are axis numbers on that device. But which is which I have no idea. I used to know before DirectX came on the scene. To find out more you really need a programming book on DirectInput. But I cannot imagine what it is you are needing to know this for, unless you are trying to program something? No idea, sorry. Please see if you can look this stuff up in a book on DirectX. Programmers count from 0, it is the first number. Are you programming then? What's all the earlier stuff about computer literacy? What does "offsets" have to do with any of the rest of your questions? If you mean "FSUIPC offsets", then the answer to "what they are" is really simple. They are "hexadecimal numbers relating to the positions of values in FS98's GLOBAL.DLL data area -- they are the number of bytes offset from the beginning of that area, offset 0000", The answer to "what they do" is "nothing, they are just numbers". Applications use them just as addresses in reading and writing this "memory" via FSUIPC. Since FS98 I have maintained the same offsets for values for compatibility in application programs. Before FS2000 they were different for each FS version and so applications had to be modified for each FS version before they would work. In order to maintain the same offsets and add more as things grew more complex, FSUIPC has to work a bit of magic -- there's really very little such data in FS's GLOBALS.DLL these days. So the memory area implied by these offsets does not exist, it is all smoke and mirrors. Regards, Pete

That's the device name you need then. It isn't a function of C but of Windows so it is language independent. All of the routines you need to call arre in KERNEL32.DLL, part of Windows. Surely you have some documentation on reading and writing files in VB? You want the CreateFile(), ReadFile(), WriteFile(), CloseHandle() routines. Other calls applicable to serial ("Comm") devices include SetCommState(), ClearCommError(), EscapeCommFunction(), SetCommTimeouts() and PurgeComm(). Regards, Pete

Sorry, I've no idea how to handle USB ports, let alone one with a PDA on the end. If it is merely a named device I would assume you open it as a file ("CreateFile") then WriteFile to it, and CloseHandle at the end. As for any device or file. Regards, Pete

What is the "FSUIPC-Joysticks-Slew Axes-Slew Heading"? I don't have such a thing. If you are talking about the slew calibrations on page 10 of 11, none of those are operative if the top left button in each reads "Set". If it reads "Reset" then calibrate, or press it to switch FSUIPC calibration off -- it then turns back to "Set". Pete

Sounds like you've not calibrated your controls in Windows at all well! Just calibrating them in FSUIPC isn't ideal, as FSUIPC is only manipulating the end results. With bad Windows calibration you are likely to get less resolution and even asymmetric sensitivities on either side of centre. Best to go back to Windows, calibrate everythnig as best you can there, then load FS, check that it all works reasonable well, and also ensure (in Options-Settings-Controls-Sensitivities) that you have max sensitivity, min null zone, and then go into FSUIPC for its refinements. The slew mode calibrations in FSUIPC do work but they are only a recent addition -- really you should be able to use slew in FS without FSUIPC, indeed, as most of course do and have had to for years. Which joystick screen? Slew controls are only on Page 10 of 11. When you say "Set" mode, do you mean you've pressed the 'Set' button so that it reads "Reset"? That's when you can calibrate. In Slew mode you cannot calibrate the normal controls, only the slew controls -- which have their own page. I don't provide calibration for all of them, only the main four. The normal controls don't get through FS when in slew mode, nor vice versa. You should bear in mind that the FSUIPC facilities are not calibrating joysticks but FS controls -- the things that FS is using internally. FSUIPC has no idea what actual axes are being used at all. Regards Pete

Well, I've not done this in a program, but you could easily check for yourself using FSInterrogate (you can WRITE to FSUIPC in FSInterrogate as well as read and observe, you know). Anyway, for just a simple percentage increase/decrease you don't need the actual capacities -- you'd only ever need capacities if you wanted a fixed number of gallons or litres or pounds of kilograms of change. You just need the fact that 100% level is known to be 128 * 65536, or 8388608. In "pseudo-code" (i.e. no known language): Read the levels for all tanks (in one Process call) For each tank, assuming its level readout is now in 32-bit integer 'L' For 1% increase: L = L + 83886 (which is (128 * 65536) / 100, thus 1%) Check L <= 8388608 (this is 128 * 65536, representing 100%) -- if not set L = 8388608 (100%) For 1% decrease: L = L - 83886 (which is (128 * 65536) / 100, thus 1%) Check L >= 0 -- if not set L = 0 (0%) Write L back to level offset for this tank Loop for next tank Do the Process call for all the tanks written Pete

Strange. I don't insert the checksum, that goes through a routine to generate it. Maybe I didn't re-initialise it for the second sentence of the same type, though in that can 2.581 should have been wrong too. [Later] Yes, there was a statement missing. The sum provided was including the complete preceding GSV too. The same applied to the previous one I sent -- most odd that it didn't fail. Try 2.583 attached. Sorry, I've not had time to test any of these myself. Pete GPSout2583test.zip

"Groan". :wink: Attached 2.581. Pete GPSout2582test.zip

C. I don't know or use C++. My only computer languages are ASM and C (previously BCPL before C was invented). UIPCHello is in C in any case. If you copile it as a C program, not C++, it should be fine. Check you have the name of the LIB correct as well. It has an _ character in it I think, and case is possibly important too. Pete

Okay, easy enough. Actually, there's a GSV option already in there -- has been for a long time. Just seems to have missed mention in the docs. Sorry. Here is what it would have provided: $GPGSV,1,1,04,01,45,000,50,02,45,090,50,03,45,180,50,04,45,270,50 Anyway, I attach test version 2.581 which includes the above values. See if that meets your needs. Regards, Pete GPSout2581test.zip

The P8, T8 and RP48 displays merely consist of 8 LEDs numbered L0 to L7. In the GFdisplay documentation I give full examples for the other modules, which provide more complex cases -- but most of those also have LEDs. It is surely easy enough for you to apply what you can learn from the documentation and many examples to the simpler modules. If there's something you don't understand about the examples, please go ahead and ask specific questions. Then I'll know what improvements to make to the documentation. But I didn't want to try to program everything for everyone. That isn't the purpose. It is a toolkit for folks to do exactly what they want. Regards, Pete

I evidently don't understand VB at all. What is actually setting or changing value in the variable you are writing to 0B7C? What is "8372890"? Where are you reading and using the tank capacity, or are you assuming it is fixed (i.e. doing this for a specific aircraft)? You seem to be updating something AFTER writing something else. It always worries me when I see arithmetic like Val(100) + argNum / 8372890 * (128 * 63556) What is done in what order? Do you know? I always use parentheses to force the order I know I want. In particular, if "argNum" is the +1 or -1 passed as a parameter, then dividing it by 8372890 will surely give zero!? After all, it is declared as a "long" so it isn't capable of storing fractional values is it? Pete

I found the problem. Typo in the code! Thanks for finding and reporting it. I've replaced it by version 3.499a now, see the Announcement. Thanks again! Pete

But filled with what, and why? Well, I can't tell if it is worthy. If you can explain the point of such fixed fictitious data then, yes, of course I will consider it -- if you provide the exact data it will be easy enough. I don't actually need checksums, they are calculated dynamically. Regards, Pete

That sounds like a good idea. But if it also actually Reads the data from FSUIPC (which probably it doesn't, from your description), it would need something like an "FSUIPC_Process" call to actually do the read. We shouldn't encourage the use of lots of separate "Read-Process" pairs, which are grossly inefficient. Maybe a library with calls for popular specific variables, a generic call for others, then a separate "Process" entry which actually does the business, including the conversions of the known (named?) variables. The unknown unnamed ones would still be provided "as is". Thanks for the suggestion, and the potential offer! I look forward to seeing what transpires! :wink: Regards, Pete

An lever, any axis, assigned to spoilers will have a position, somewhere very near fully retracted, which will arm the spoilers. It's a positon on the movement of the spoiler arm -- play with the FS graphic and you'll see what I mean. However, do NOT test this on the ground -- FS will let to arm the spoiler okay but it will then immediately deploy them fully because of the ground situation. Take the aircraft into the sky then find the "arm" position and mark it. No more so than any other calibration. I have considered having a sort-of centre area which could be calibrated for this, but it is a lot of work and on the whole I really don't think it is necessary. The simple axis position method does work -- provided you have some feedback so you can see when it is armed. Regards, Pete