Pete Dowson

Yes, of course -- the code in FS9.1 is not the same as in FS9.0, it is in effect a different version. If the FS9.0 version of FSUIPC was allowed to run inside FS9.0 it would crash the system at worst, and certainly not be able to work as intended at best. There are no such messages in FSUIPC. You must be thinking of something else entirely. What exactly is the message and what is producing it where? The changes from version 3.30 of FSUIPC to 3.40 are all listed in the History document and in detail in the Release Notes at the top of this forum. There are no others. How are you trying to get the Latitude and Longitude? If you just want to see it, FS has the function built in -- try Shift+Z. If you mean to read the position via the FSUIPC IPC interface, there is absolutely no difference whatsoever between any previous version of FSUIPC 3 and version 3.40 in reading such data by accredited programs. None at all. Try FSInterrogate and see! If you want more help, can you please be rather more explicit as to what you are talking about - programming? Another program? What? Regards, Pete

Hi Samuel, Enrico's uploaded a revised pmRemote build (build 23) which works okay. I'm pretty sure it must have been an expiry problem in 22. Regards, Pete

If you mean you do have to actually steer the aircraft to keep it straight on a taxiway on runway, then this is realistic. Like cars, you can't let them do their own thing unless you want any accident. All aircraft need some steering to stay in a straight line. However, assuming you mean that this is execessive and needs a lot of correection: If the brakes aren't slightly on, on one side (calibrate a larger dead or null zone for them), and the rudder is properly centred (make sure you have a good null centre zone there too), and you don't have any wind blowing you about (light GA aircraft are especially likely to weathervane, more so in FS than in the real world in fact), then the only other thing, apart from prop torque or prop wash over the rudder (but that will vary with throttle) would be rudder trim. However, if your rudder trim is off-centre, it will be off-centre in one direction, and not vary from side to side. Check also in FS's Options-Controls-Assignments that you don't have more than one control assigned for rudder axis (use the drop down to check all the joystick devices FS is listing). Regards, Pete

Look just above that line, to 0B7C. See? Every tank has a capacity value and a "% full" value. Apart from the tanks at offsets 0B7C to 0BA8 (the original FS98 ones), there are more at offsets 1244-1260, in the same format. You misunderstand. As documented, the % values are actually given as 128 x 65536 times the proportion. They aren't really percentages in fact (but they are described like that in FS). By DIVIDING by 128 x 65536 you get a proportion between 0 and 1. 0=empty, 1=full. I think this is corerect, anyway (I've not used them). If so, multiply by 100 for a proper percentage. The way these are described comes from MS toolkits and early FS5/95/98 documentation by others before me. Please try to use FSInterrogate for these sorts of questions. In general it is pretty good at deriving the correct value, and you can see how it works -- you can see the formulae it uses and get your results the same way. This is the main reason these development tools are provided. Regards, Pete

Well, yes, true -- because I have to use the magnetic track instead of the true track. I would certainly not entertain adding "fiddles" to GPSout to try to adjust the Magnetic Variation for FS's data freeze date to match another arbitrary date. The changes will be varied all over the world, and will still be changing in any case. Furthermore the main use of GPSout is to provide a correct moving map to match FS's scenery and NavAid data, not a new real-world flight GPS. The only, and correct way, to update FS's navaids and magnetic variation is to make or purchase updated scenery files. As I said, all of the magnetic variations are tabulated for every square degree in MAGDEC.BGL. Regards, Pete

You are in the wrong Support Forum, actually. You need the PM NewsGroup. However, in this particular case I may be able to help. Enrico uses the notation ".n" to mean "bit 0", so you do not say "5628.0 bit 0, it is either "5628 bit 0", or, in Enrico's terms "5628.0". As for what size is the byte, all bytes are, by definition, 8 bits in length. That's what "byte" means. However, sonce you only want to change one bit, surely the length is irrelevant? The length of 1 bit is 1 bit. Regards, Pete

You need to change one or other of the Keys. Both must be in exactly the same name and email (it does mention this in the documentation I think you'll find). If you send me both of the emails, the one for FSUIPC and the one for WideFS, and tell me which email address you want them to be in, I will make a new key for the other. If you want to change the FSUIPC registration you'll then need to delete the FSUIPC.KEY file from your FS Modules folder and re-register both. Send to petedowson@btconnect.com. Apologies if there's any delay, as I am out most of tomorrow (Tuesday) -- another visit to the eye hospital. Regards, Pete

Just download the ZIP from http://www.schiratti.com/dowson, and copy the DLL out of the ZIP into your FS modules folder. That's it. As I said, your registration covers all FSUIPC 3.xxx versions. You would only need to re-enter the details if you deleted your FSUIPC.KEY file, or re-installed Windows, or moved to another PC. Regards, Pete

You are mixing up two completely different ways of dealing with reverse. The reverser on page 7 is for a completely separate axis acting only as a reverser, it is nothing to do with calibrating a reverse zone on your main throttle lever. In the main throttle section on page 1, check the option to "map to 4 throttles". If you've calibrated there already you'll need to press "Reset" first to undo that. Now go to page 3 and calibrate throttle 1 with a reverse zone, an idle area and the forward thrust area. Follow the steps in the documentation. Regards, Pete

First, you do not purchase specific versions of FSUIPC. Your purchase is for any version 3.xxx. Second, you are certainly mistaken, because version 3.40 was not released until this month! It was released to coincide with the FS9.1 update, as changes had to be made to deal with the revised simulator. You need version 3.40 (or later -- version 3.41 is due soon). If you got FSUIPC in July that will be version 3.30 at best. As Microsoft said on their update site AND in their READ ME, you need to update to 3.40. To check the version of any of my programs or modules, simply right-click on it and select Properties then Version. Regards, Pete

Sorry, there's no point. I've investigated this. That parameter (WindVarFactor) is actually not used in FS2004 at all. The entire Weather code for FS2004 is separate from that for FS2002 and FS2000 (which are pretty much the same). I'm afraid that whatever you experienced when setting that parameter was merely a coincidence. I've looked to see if there is any way I can introduce it, and, really, there isn't. The system is so completely different. As far as I can see, the only way of getting wind and cloud turbulence (AND direction variance) is by switching my Wind Smoothing off. I will think about this, however, and see if there's a way I can detect the fact that there should be some turbulence, and allow this to occur even though the smoothing is applied. This will be a very complex operation, though, and I cannot start thinking about it until I have cleared the decks of those things I already have on my plate. Meanwhile, I strongly suggest you turn FSUIPC's wind smoothing off. If you avoid flying in parts of the world with a very dense collection of METAR stations (JFK, ORD, LAX, etc) then I really don't think you will see many of those nasty windshear direction changes in any case. As I said earlier, I actually found it quite difficult to make one happen in any case, when I was really trying! Regards, Pete

Hmmm. It sounds like that aircraft model is intercepting these things and acting on them before FSUIPC does. I can't really do much about that. Is there a DLL installed in the Modules folder by the aircraft? If so, you could try changing the InitDelay in FSUIPC, so it subclasses the main FS window (which processes all these inputs) after that mdule, so getting control before it. FSUIPC used to default to InitDelay=3000 but it's 0 in FS2004. Just put/change InitDelay=3000, or even higher, in the FSUIPC.INI [General] section before loading FS. If the 767PIC does all this from a Gauge, then there's no chance I'm afraid. I think you'll just have to "park" your trim axis or fly a different aircraft. Well, I really don't know what it's doing. The 767PIC was designed for FS2000 or FS2002 wasn't it? Is there a new one coming out? Regards, Pete

Yes, it is stored as Day of Year in offset 023E, with the Year in 0240. Check the Programmer's Guide in the SDK. Regards, Pete

No, I don't do that. But it won't help in any case. I just checked. Buld 22 of pmRemote doesn't even attempt to contact FSUIPC. There's no calls to it from the pmRemote program whatsoever. I reckon it has expired -- it was only a demo in any case. Maybe Enrico forgot to extend the expiry date in his build 22 update. I know build 20 expired. Regards, Pete

No, that is not a good idea. Best to simply calibrate the toe brakes so merely touching them does nothing -- i.e. with a bigger "dead" zone. There should be a reasonable amount of slack before any action occurs. Regards, Pete

There's the problem. The name of the gauge loaded is not the same as the name it is trying to register as. It is trying to "cheat" by pretending to be another gauge. Both those gauges do have (different) valid Keys, but the keys and names must match. I'd get back to your supplier and find out what's going on if I were you. Regards, Pete

You did remember to UNCHECK the automatic option to disconnect on AP, didn't you? If not then that mechanism will reset the bit. Regards, Pete

Oh, how odd -- but they use the Windows and 'Menu' keys? What is this 'Menu' key, please? I've not got one, at least not labelled as such. The Windows virtual keyname "VK_MENU" is actually the Alt key. I'm not sure if I can easily get hold of the Windows key -- I'm only processing normal Windows keyboard messages. I can check though. Doesn't it stop its use to get the Start stuff opened? [LATER] Okay. There are two "Windows" keys (LWIN and RWIN) and they are usable provided Shift or Control is pressed and held first. I could treat them both the same, as your "Win" key. I have another key, to the right of the right-hand Windows key, with a little menu drawn on it. Is that your "menu" key? If gives a Windows keycode of VK_APPS (0x5D), so I could use that. Is that the one you mean? If so, is it well known as the "menu" key? I must admit to never having even noticed it before, let alone pressed it! Regards, Pete

Can't you use assignments containing different combinations of Ctrl, Shift and Tab, with a normal key, only? Surely there are enough? Regards, Pete

Sorry, I have no idea, though the PFC one will be using separate throttle inputs for each engine whilst the simple single slider uses the generic all-engine throttle, akin to the 3 and 9 keys on the number pad. Have you asked Mr. Frolov (or is it Mr. Fanda?) about it? Possibly he intercepts and discards all attempts to assign individual throttles. You could test that theory by re-assigning your "standard slider throttle" to one of the specific engine throttle controls in FS (Options-Controls-Assignments). Or, possibly easier, map it to the 4 separate throttles in FSUIPC's Joystick options. Unfortunately, I really cannot keep abreast of all the different ways folks find to re-program FS in their aircraft. Sorry, no to both. Before this the only Dash 8 I'd heard of was the PSS one. Regards, Pete

There has been no change whatsoever in anything which pmRemote would use. It sounds like you have something else wrong. Best to check with PM Support. Also check the FSUIPC Log file to see if there are errors being reported. Maybe you have an improperly installed FS9.1 Update? Seems a lot of folks have. Check the list of changed FS modules in my FS9.1 announcement. Regards, Pete

Well, I was planning to release 3.41 this week if possible, mainly to deal with those mixed FS9.0 and FS9.1 systems folks have got themselves into and which are causing me too much support work otherwise. However, a few other things have come up and I am not so sure it will be this week now, but I hope so. However, I don't know if I can deal with this "turbulence as variance" thing quickly or reliably enough to fit that in for this release. I need to look at it and understand it first. I don't know how it is by-passing the wind direction smoothing part of the wind-smoothing routine, for instance. All I can say for now is that I will try to make time to look at it before release and if it looks easy and not dangerous I'll slip it in, but if it needs a lot more investigation and testing I will have to leave it to a later release, maybe 2-4 weeks off. Regards, Pete

Hmmm. Seems like you've found a deficiency in my smoothing :wink: -- the variance isn't subject to the smoothing and it sounds like that is what you are enjoying. I'll take a look at enabling the turbulence through variance again in a forthcoming release. Thanks, Pete

This is the one which converts wind turbulence (which didn't work anyway) into wind variance (changes in direction) which did. Both work in FS2004, which is why that facility was removed. That's a bug in FS2004 which unfortunately we now know won't be fixed till FS2006. However, it really isn't that common. It never affected me and it took me a long long time to reproduce it enough to convince Microsoft they had a problem! Well, FSUIPC fixes some things in FS2002 and some things differently in FS2004. It's user's choice I'm afraid. I can't fix everything. Regards, Pete

There won't be any at all unless you disable FSUIPC wind smoothing, assuming you have it enabled. The two facilities are mutually incompatible I'm afraid. No, there's no difference in any versions. It's all dependent on whether you want smoothing on or not. Is it? Which box is that, please? I'm confused now. I don't remember ever providing any "level of turbulence" box. there was a facility to convert FS's "variance" into "turbulence" with a settable strength, but that was because the wind turbulence didn't work. It does now, there's no point in converting it. Wind variance works as well, separately. You are talking about CLOUD turbulence, not WIND? Please, don't keep it a secret. What parameter was it? I will check. Honestly, I've not knowingly removed any facility still useful. If you are relying on one of the "random" turbulence facilities then, yes, it is supposed to vary. That wouldn't be anything to do with any parameter. Where is the weather coming from in the first place? FSUIPC cannot add these things to FS's own weather, only the weather from external weather programs, and I think most of those control the turbulence effects themselves. Please be a little more specific in each stage of your report, then I may understand it and be able to help. Regards, Pete