Pete Dowson

GPSout is not FSUIPC dependent except on FS2002, and that wasa not intended. See my previous message. There is nowhere on the 'net that I know. You could try writing a Gauge. Regards, Pete

Sorry, I really have no idea why you are having such a problem. It really does sound like GPSout is not actually installed in your FS Modules folder. Either that or you have a corrupted version. GPSout has been working quietly in the background on many users systems now for years, with almost no changes needed except for occasional addition of new sentence types. This is right through FS98, FS2000, FS2002 and now (with version 2.51) on FS2004. There is really nothing in it to go wrong, it is so simple! Maybe you should download it again, make sure you have a good copy? The current version is 2.51, not 2.5, and it works in FS98 through to FS2004. It only actually needs FSUIPC on FS2002, because there's a 'bug' in FS2002 which is fixed by installing FSUIPC. This 'bug' (actually an odd unexpected difference) doesn't apply to FS2000 or before, or to FS2004. Regards, Pete

You must type just "SquawkBox", exactly. No ".exe" part. Only Gauge and DLL registration uses the filetype. And the key must be correct. Please look at the Sticky thread in this Forum for correct keys and spelling. Pete

There's no such SDK, but the one to write Gauges (in the Panels SDK) is the closest. GAU files are DLLs but loaded by Panels.dll on demand rather than by FS on initialisation. The interface, the method to get FS load, the same. So write it as a gauge then rename it and move it. It's a little more complicated of course. To start with you need to write the code so that it runs without impacting FS performance. If you are only interacting with the user via menus or hotkeys, then that probably isn't a worry. There are no functions of FS9 to get into the menus. You use standard Windows API functions to determine when the menu is being drawn or created, and add your entries then. Regards, Pete

I don't think it will look like that if you set graduated visibility. What I think you are seeing is not the haze layer itself, but the graphic for a thin layer of cloud graphic deliberately placed at the top of the visibility layer by FS in order to answer very severe criticism of the way the ground was too sharp below when climbing out of the haze. I think this cloud graphic stops after a certain distance for the same reason cloud graphics do, and the main answer is to make sure the slider for cloud graphics is full right, in the Options-Settings-Display-Weather dialogue. I cannot fix or change graphics in FSUIPC, I don't know how to. If you don't want the visibility limiting at all when above the visibility layer, then this sort of view would have to be 'fixed' by adjusting FS's graphics settings. But I recommend you try FSUIPP 3.05 vis facilities, see what you think. Regards, Pete

This is exactly what I would expect to see if you had the speed setting wrong in GPSout.ini. Regards, Pete

Well, there's no other' magic' involved. If you've got a good COM port selected and the right speed (NMEA default is 4800 bps, but I use the highest supported by the receiving program). You need to check your cable too. If HyperTerminal or something similar can use it to exchange chat between the two PCs then GPSout can use it. The program is really very very simple, there is nothing to go wrong, and it has been in use now for over 4 years. Don't forget the cable, although it only needs 3 wires for GPSout, must have Rx to Tx and vice versa (i.e. 1-1, 2-3, 3-2). I didn't say it wasn't, but you are now trying to find out why you aren't getting the correct signals out of your COM port. There are only a few possible choices: 1. The COM port is dead or faulty 2. You aren't selecting the right COM port 3. The COM port is already in use by some other application 4. The speed is set wrongly 5. The cable is wrong -- faulty or not "twisted". 1-3 you could check by trying the other COM port. 4 & 5 should be ditinguishable by using Hyperterminal or something similar to see if you get any data, albeit rubbish -- if it is at the wrong speed it will be rubbish, which your NMEATOOL is probably not designed to recognise or even tell you about. Pete

Hmm. I can't reproduce that here. How do you do it? I'm not understanding something here. The options in AdvDisplay are really meant to be set as needed once, then left. Why would you need to keep changing them? If you do want to change them all the time, should they be hot-key options? You know there's already a Hot Key option in FSUIPC to hide/show the AdvDisplay window, don't you? Recent in what terms? Since AdvDisplay 2.11 you mean? The way it provides the menu facilities is pure standard Windows APIs and has never been changed. It has no control over when the drop down closes -- it cannot happen as far as I know till you select one of the items or click someplace else. Perhaps one of your add-ons is activating this sort of focus diversion? Regards, Pete

What is that? I don't see that here? I assume that's the edge of the visibility 'cloak' below you, drawn as far as the limit in the Display options or somewhere else? I still think the visisiblity effects in FS2004 are far, far superior to those in FS2002, which was awful in that regard. FS2000 wasn't bad, but the additional weather visuals in FS2004 make it much better. Regards, Pete

Got it! Thanks. There's a lot of "interesting stuff on that site! Phew! Pete

So far all a Google search turns up for me is the fact that IMAGECFG is provided in the NT SDK and in MS VC++. Well I've got the "Platform" SDK which is supposed to cover NT too, and I have MSVC++ 5 and 6, and I can't find this utility in either. I've also searched the NT DDK I have, and the MSDN disks. Looking up IMAGECFG in the MSDN it says it can be found on the NT 4 disk itself, in "Support\Debug\i386". Unforrtunately this doesn't seem to apply to the Win2000 nor WinXP disks. Evidently it's been removed. Any ideas, please? Regards, Pete

[quote name="arno_nl2000 I have no idea of they are 16 bit' date=' how can I find that?[/quote] Well, they can't be MORE than 16-bit as the offsets are at intervals of 2 (2 bytes = 16 bits). So they are either single byte or 16bit values. Most likely the latter, but the clue would be in how they are used, what they contain. If they never contain values other than 0 or 1 then they are just BOOLeans, and so the size doesn't really matter much. If they can never have values larger than 255 (or -128 to +127 if signed) then they are bytes. Since I don't know scenery design I couldn't even hazard a guess, but anyone who actually uses these variables should presumably know what they are used for and therefore how much they can contain. Great! Thanks! Pete

I know nothing about scenery, scenery design, or variables, but I would be delighted to add details of your findings to the FSUIPC SDK if I can understand them better. Is this list of yours understandable to scenery designers? Are all variables 16-bit signed or unsigned values? Is the list applicable to FS2000, FS2002 and FS2004 or only some of these? Just checking my mapping tables, I see that the whole range of offsets, from 0D0E to 0E49 inclusive are still "virgin" in that they remain unmolested from FS98 days, so presumably your findings may also even apply to FS98? I am planning (again!) to get to work on the update to the SDK next week, so I could add such details, when you verify. Thanks! Pete

Better to start off using something that checks whether ANY data is coming from the FS COM port -- something like HyperTerminal, for example. Sounds exactly like you don't have FSUIPC installed. If with FSUIPC installed and a valid (available) and working COM port assigned for GPSout, there is no way you can actually stop the output whilst FS is running and in normal flight modes. Regards, Pete

Not at all! I'm glad you got it solved. Very strange that it could have the effect of preventing the Modules menu from appearing though. I still don't understand why that happened. Regards, Pete

You can undock it too, move it onto a second monitor if you have one. Doesn't it remember the state of the ATC window if you save a Flight? I've not tried ithang on, I will now: ... Yes! If you re-size and move the ATC window, then save a Flight, next time you reload that flight, even in a different session, the ATC window comes back in its new position and size. In other words it acts just like any other FS window. If you want it that way by default, tell FS that the flight is the default when you save it. Well, the first part isn't needed as I've just shown. The second is near impossible as far as I can determine. The whole thing is not a "normal" window, as least when it is docked. I think it is all done by DirectX stuff, which is a tale of mystery and horror for me! :? I did spend quite some time in FS2002 trying to work out ways of trapping and diverting the ATC text (as I did with Adventures in AdvDisplay), but I failed miserably. I wanted to be able to move it all to another PC altogether (via WideFS and ShowText), as well as provide the opportunity for other applications to read the commands and be able to issue responses. I may have another look at this one day, but I got nowhere in amny many hours last time so I'm not hopeful I'm afraid. Really? aren't you using Version 3.05 then? The visibility facilities now for FS2004, in version 3.05, actually exceed the provisions in FS2002, quite substantially. You have the limits, the smoothing and the graduation all operating now much better and more consistently than in FS2002, and looking superb too. Please try them. Why do you think they are inadequate? :cry: It doesn't need fixing by me! What you are seeing is the drawing limit. Go to Options-Settings-Display-Weather and make sure you have all three of the top sliders fully right. The effects are FAR superior then! If this knocks your frame rate too much, apply the FSUIPC visibility limits and graduations to bring back the normal good-looking haxe to compensate. I find FS2004 has fixed just about all the complaints regarding dire visibility effects in FS2002. In FS2002 the whole visibility thing was a terrible step back from FS2000! FS2004 is better than FS2000 in this regard and I cannot think of a higher praise! :D Regards, Pete

Sorry, I don't know anything about any Elite controls at all. Have you contacted Elite support? Don't they provide a driver for their controls, and support it? I'm really not sure why you are asking me. If the only way the Elite controls provide reverse thrust selection is by calibration through FSUIPC, then they should also be able to tell you how to do this. In FSUIPC's "joysticks" page the only section which provides reverse thrust zones on the same axes as the normal throttles is the section dealing with 4 separate throttles. Have you assigned the separate throttles in FS first, and calibrated them in Windows? You should do this before you start using FSUIPC's calibrations. Regards, Pete

No, not particularly. I hate there to be problems, and wish I knew how to help more. At present all I can do is try to relay what information I actually know about the problem. Incidentally, after I sent the last reply, I loaded up FS2004 on my system with those Parhelia drivers I mentioned, and deliberately tried to reproduce a "black screen" problem again. After a number of swaps between full screen mode (which is over 3 monitors at 3840 x 1024) and normal single monitor maximised windowed (at 1280x 1024), I got no problem... However, one time when I was in maximised windowed mode I "restored" the window to a smaller size. That worked, but when I pressed ALT+ENTER to go to full screen mode from the smaller window, all that happened was that window went black and the mouse pointer sat on it fluttering like mad. I again pressed ALT+ENTER and got the same but with the menu. It seemed that FS2004 wasn't "hung" as such, but the 3D window view was certainly irrevocably turned black. I closed FS okay, but then got the usual "program crash, report to MS" window. According to the details in that it was D3D9.DLL (I think -- I may have mis-remembered it), certainly part of Direct 3D. So, I decided to upgrade to DX9b (from DX9a) after all ... I've done that, I'm now on DX9b, and I tried the exact same sequence again, and couldn't get the black screen this time. Not that whatever problem it is is necessarily fixed by DX9b, just that this particular instance of it is. Yes, well. Actually, to my knowledge, that sort of statement has been made with every version of Flight Sim, ever since I can remember. MSFS has always been the ultimate test of your system, its drivers, and so on. There have always been problems in systems shown up by the latest version of FS and nothing else. I'm truly sorry I have been of no help to you, but I've explained everything I know about this problem. I do hope you find the solution for your specific system. If I do find out anything else, I will be sure to let folks know, probably here. Regards, Pete

No. I don't think it is an FS9 problem but it is between DX9 and video drivers. It was able to be completely solved by everyone that I know of, eventually, by some combination of changing video drivers, video cards or DX version. In some cases it took a lot of hassle, chopping and changing, not always to later drivers, sometimes earlier. I'm sorry, but all the evidence I heard about, and experienced myself, does actually point that way. What else can I say? I know of no other theories. I think one of the top experts in this area is Katy Pluta. She frequents the FS2004 forum, near here. Perhaps you might like to post a question there and see whether she, or others there, can help? Sorry, I cannot really help further. I was certainly one of the sufferers of this problem -- very much so, using some earlier versions of the Matrox Parhelia drivers -- but the current 1.04 edition of the Parhelia drivers are standing up very well. I am still on DX9a -- I did consider updating to DX9b but I thought I'd leave well enough alone for now. :) Regards, Pete

The only way would be to use the button programming facilities in (a registered version of) FSUIPC and re-assign the Gear switch action to something else. Any re-programming in FSUIPC takes precedence over the default actions of the PFC switches and buttons. Go to the Buttons page in FSUIPC, operate the Gear switch, re-program it. Regards, Pete

Writing 1 byte from a row of bytes will only write the first byte, of course, as you surmised. Reading N bytes into any area in your program where you've only reserved N-1 or less bytes for the data will overwrite whatever follows. If the data area is on the Heap is could result in errors or crashes later, with heap links destroyed. If the data is declared globally or as "static" then it will again overwrite whatever follows it, which may be difficult to determine (look at a ".Map" file if your compiler provides one). If the data area is dynamic (i.e. declared locally in a procedure or subsection of code), then it is on the stack, and the extra bytes will overwrite other values and even possibly the return address for the procedure, so causing a crash later, when the procedure exits. All these things would be the same if you read more data from any source, for instance a file, into an area not big enough. None of it is specific to FSUIPC. Regards, Pete

Best way to identify them is to got to the FSUIPC Buttons page, and use it to pretend to program the buttons. When you press a button, the Joystick number and Button number will show on that page. Pete

Not so much numbering. Byte 0 just means the 1st byte, the one at relative address 0. And so on. If you were using an array of bytes BYTE bHotKey[4]; then byte 0 is bHotKey[0], .... byte 3 is bHotKey[3]. Ah, if you manipulate it as a 32-bit word, instead of 4 separately addressable bytes, then all you need to know is that in Intel processors (and their compatible non-Intel relations), the "least significant" comes first and the "most significant" comes last. this is termed "Lo-Hi" format. Motorola processors (68000) are Hi-Lo instead. Not sure about the others. So, your 32-bit value 0x12AB34CD is actually stored in memory in 4 successive bytes as 0xCD, 0x34, 0xAB, 0x12 making 0xCD byte 00x12 byte 3. Incidentally, this "numbering" method is also used for bit numbers. so "bit 0" is the Least Significant bit (value 1), and so on. Regards, Pete

Actually I'm hedging my bets. I've got two PCs I want to upgrade -- one I use with the Parhelia for airliner flying, and another with the Aerosoft GA28R which I use for VFR flights in a Piper. I can't easily use the same system for both because the equipment (the huge GA28R versus all that PFC Jetliner stuff) is too heavy! :o I was thinking of getting a complete new system and shuffling the others down one. The "weakest" (an Athlon 700) then sort of falls off the end and goes to a relative! :) But, I've been pricing things up and decided I can do it all by merely replacing motherboard, processor and memory, and do both the IFR and VFR systems together for much less than a complete new system! So, I'm looking at these two upgrades: IFR (with Parhelia): P4 3.2GHz with 800 MHz FSB, MSI 875P Neo IS2R mobo, with 2 x 512Mb PC3200 memory, matched pair for dual channel access. VFR (with nVidia Ti 4600): Athlon 3200+ with 400 MHz FSB, Asus A7N8X Deluxe Rev 2 mobo, also with 2 x 512Mb PC3200 memory, matched pair, dual channel These would replace a P4 2.4GHz and Athlon 1800+ respectively. As far as I can tell from reading through all the reviews these motherboards and RAM configurations are the fastest you can get at present. Problem at present is the Athlon 3200+ -- I can only get the 333MHz FSB version. The others are on a "long lead time". So maybe I'll only upgrade the one for now. And I will take note of the business of processor "affinity". Thanks! Regards, Pete

If you are the sole user, then really your proper course of action is to register FSUIPC. However, if this is freeware which may be distributed without profit, then you can get a free access key for it. Contact me on petedowson@btconnect.com (as requested in the sticky announcement on freeware keys, as well as in the original announcement about FSUIPC going payware), and I'll send you details of the registration system for applications. Regards, Pete