Pete Dowson

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

If the program you want to use is accredited for FSUIPC 3 then you don't need to register. If not, then you need to check with the author whether he is going to get it accredited or not. If not then you would need to register your copy of FSUIPC to use it. Regards, Pete

Leaving the box UNCHECKED, as it is by default, was supposed to leave the FS weather alone. It did, except for the wind smoothing. The reason the 3.049 Beta worked was that the mod I put in for that checkbox broke the wind smoothing altogether. I repaired that but, in the process, the wind smoothing activates itself for FS's own weather. It doesn't actually do anything, as the targets are the same as the current winds, but it seems that telling FS to set the exact same weather as it has already set constitutes "user-defined" weather. Oops. So, as well as leaving the box unchecked, uncheck the wind smoothing. I'll fix it soon enough. Sorry. Pete

These days the normal way would be to use USB devices instead of Game Ports. Isn't your SideWinder USB compatible? You can certainly have several joystick devices connected at once with USB. When motherboards sported a Game Port as well as Sound Cards you either had to disable one or the other, or make sure the sound card was one which could detect the other game port and configure its own to be on a different port. There also used to be multiple Game Port cards around -- I think there was one by Thrustmaster, for instance. But this is getting more difficult now. You may possibly find that adding another PCI sound card will do the job, but you will have lots of messing about to do to configure the drivers. I don't think the standard SB drivers cater for more than one card so you'd need a card with totally different and not incompatible drivers. If I were you I'd look at USB devices. It's a whole lot simpler, especially if you are using Windows XP. (Windows 98SE or Me work with USB devices, but can be awkward with more than one -- they seem to be prone to reassigning them differently each time you boot). Regards, Pete

I understand that, I was only giving advice for next time! Sorry you took it the wrong way. :cry: It also has statements on it where Enrico explains why. My name appears in lots of places it seems, but only this one is mine (well, its on loan to me, anyway. :) ). Sorry if it offended you, but I will correct the assertion that the Schiratti site is mine every time I see it, as otherwise I get all sorts of emails when people have downloading difficulties and so on. Any queries about any web site should be directed to the folks who own it or run it. Okay. I think you will find that SimMarket's customer service is excellent. You should have no problem, though they may well tell you off too! :D Regards, Pete

Sorry, I've really no idea. You want to talk to Luciano Napolitano, author of WidevieW, the main purpose of which was to link multiple FS's together smoothly. It did a better job than multiplayer, but I don't know if he's doing a version for FS2004. Regards, Pete

[quote name="SeanMcLeod Reason I thought it may be possible was because those appeared to be the only variables referencing flight control surface's positions' date=' plus the docs said they were 'writeable'. I assumed if they were really just 'indicators' then they would've been read-only.[/quote] Where does it say "writeable"? I don't normally say such things. Most things are writable, but that doesn't mean writing to them has any effect. For most indications whatever you write will simply get overwritten on the next frame as the sim re-computes it. Mind you, there have been surprises -- like writing to the accelerations can produce an acceleration. It is short lived, but it has been used to good effect for catapulting. They are the controls. I'm not talking about moving the joysticks themselves, I'm talking about the controls that the joysticks "actuate"! Exactly. You can also use those for "fly-by-wire" as I provide the inputs in another location. Like fly-by-wire. Disconnect the control inputs from the "actuators" and put your own algorithms in between. That's what those facilities are for. That's the way folks have used them. Yes, though I think most folks use the elevator trim instead, like the FS autopilot. If you want the plane to be ready trimmed when your A/P is disconnected I suppse you'd need to work out proper use of both. Who's FBW? Obviously if something else is doing the same as you there will be conflicts. Yes, that's what it says, more of less, isn't it? That's why the facilities are there. And not just elevator of course. If the input is connected, the input goes to the control. If you disconnect it, it doesn't. It is that simple. And I have never heard of any FBW in any MS aircraft. Regards, Pete