Pete Dowson

Well, they are the values FS is computing and using. Are you sure you are converting correctly? The GS is in METRES/SEC not KNOTS, so you need to convert to compare. 1 knot = 1 nm/hr. 1 nm = 1852 metres Therefore 1 metre/sec = 3600/1852 knots, i.e multiple m/sec by 1.94. There shouldn't be any difference between the two as far as GS, TAS and IAS are concerned. It's you headwind that stays directly on your nose as you turn which is the most peculiar. I really cannot think of any possible explanation for that! Regards, Pete

So you didn't even need to use the "ThrottleSyncEngine2=Yes" option I put in for you? That's good. It sounds like the levers are within reasonable tolerance after all. :) Pete

No, sorry. It is an oversight. In fact version 3.153 is identical to 3.20 -- the number 3.153 was the final Release Candidate during testing, and no change has been made to code since then. I used all the increments between 3.141 and 3.153 in the extensive testing over the last month. Regards, Pete

No, sorry. I think that program was based on a Microsoft tool and there should certainly be one for FS2004 in their forthcoming Traffic SDK, whenever that is released (hopefully it won't be long now). I really am not interesting in duplicating stuff. Regards, Pete

Sounds extremely weird. I hope other SB users can help here. FSUIPC is not controlling winds -- what is controlling the weather in your setup? There is a problem in FS2004 with occasional 180 degree windshifts, but you would most certainly notice these as they would affect the performance of the aircraft quite markedly! I have never heard of headwinds that follow your nose as you turn -- that sounds impossible to produce in FS2004 for sure. I don't know where SB is reading things, nor whether you are using a default FS204 GPS or an add-on, but you could monitor the places inside FS where these things are maintained. In FSUIPC options, select the Logging page and look at the right-hand side. Here you can enter up to 4 variables to be monitored. The GS is at offset 02B6 and is type U16. This is in metres/sec so you would need to do a rough conversion in your head to see if it looked right (a bit more than half to get knots). The default FS2004 GPS GS is at offset 6030, and is type FLT64, also in metres/sec. You can therefore compare them quite easily. You could also monitor the ambient wind direction (0E92, U16, in units making 360 degrees = 65536), and ambient wind speed (0E90, U16, in knots). These should be identical (in result) as the Shift+Z wind display. If you want to monitor TAS or IAS in place of any of those: TAS is at 02B8, as a U32, in knots x 128 IAS is at 02BC, same To monitor them in the message window on screen check the "Adv display" checkbox below. To log them in FSUIPC's Log, check that box -- but don't do that for too long as it make the file grow vey fast, and may also affect frame rates. I'd be interested to find out how you are getting a turning headwind to match your heading (!), but please note that I am away on holiday from this Thursday 19th Feb until Thursday 11th March, inclusive. Regards, Pete

Good. Of course FSUIPC is not driving the indicator LEDs or displays on Goflight equipment, so you don't win all ways. I'm not sure what to do about the displays. I may consider doing a sort of "GFINFO.DLL", along the lines of my EPICINFO.DLL, but I won't have time to do this for some time, I'm afraid. Just in case there are any questions on all this, I have to tell you that I will be away on holiday from this coming Thursday 19th Feb till Thursday 11th Mar, inclusive. Regards, Pete

Hmmm. That's a little worrying for me as I've done nothing specific which would account for that. I wonder what is going on. If your FSUIPC is not user-registered it may possibly be explained by the better method of identifying the modules and gauges calling FSUIPC's interface, but it doesn't seem likely that you aren't user registeredand none of that code is active for fully registered copies. I am glad you are pleased but I remain puzzled. :? Regards, Pete

Apart from the three visibility filters marked *** the FSUIPC filters really do nothing at all with default FS downloaded weather. Hmmm. I don't know. I just run them as they are, not fiddling with anything. I had a nice, short, flight today (the first one for "fun" for a while), from EGCC to EIDW -- my usual "test" run -- and used FSMeteo with today's weather and Radar Contact for ATC. Everything seemed perfect enough. The weather matched all the way, the graphics seemed accurate. I must admit I've never really seen any of these complete "mismatches" some folks have mentioned. I tend only to fly in Europe, and mostly out of EGCC. Perhaps this is a stateside phenomenon, or something geographical? Perhaps the weather sources for ActiveSky or FSMeteo are a bit more suspect over there? Sorry, I really haven't a clue. I think only the weather programmers can pull the information together to determine what exactly is going on. This is really down to FS graphics, over which I'm afraid I not only have no control but which about I am a complete dunce. However, the main (not only, mind) sorts of clouds which do that sort of thing are the very ugly 2D ones. In the Options-Settings menus find the Weather options and ensure you have, at least, the 3D clouds slider to to 100% (full right). In my opinion any other setting there wants shooting! For best results, set all the sliders on that page to max (all full right). This will probably slow your FS frame rates a bit. Then go get the Chris Willis high performance clouds from one of the web sites. (Sorry no link, but try Avsim or Flightsim). Things weather-wise in FS2004 are actually better than they were in FS98. They are better in some respects than they were in FS2000, but not many. They are heaps better in several ways (especially visibility) than they were in FS2002, which in my personal opinion was a step back from FS2000 in this department. But they are most certainly still far from perfect, and worse, they are very very complex -- it is understanding what the ? is going on sometimes which is the problem, not the weather itself. Really, in the end, just fly it and expect the unexpected -- just like English weather, it changes and is nowhere near 100% predictable. If you aren't a control freak it can be quite fun, mostly, honest! Regards, Pete

Actually they are wrong. There's no actual example like that in the docs. The relevant section is this: Your 8 should be 16 (shift state 8 + 8 to press), and your 16 should be 24 (shift state 8 + 16 to release). Try it. Yes, it needs to know for both. They are completely indpendent events as far as Wideclient is concerned. No. You program FSUIPC to send KeySend1 when pressed and KeySend2 when released, right? So WideClient does the KeySend1 action when it sees the KeySend1, and the KeySend2 action when it sees the KeySend2. Isn't that logical? The KeySend mechanism is just a message. The message is the parameter 1-255. What happens in the client as a result of the message is no concern to FSUIPC, and how FSUIPC got hold of this to send is no concern of WideClient. If it still doesn't work, then I've really no idea I'm afraid. It will be something in the way TeamSpeak is programmed. This was a problem with Roger Wilco as well, at least one of the versions. In order to send the keystrokes WideClient uses the keyboard playback facilities in Windows. These effectively emulate what programs see as a result of Windows keyboard event processing -- in other words, messages telling the program that such and such a key is down or up, or such and such a character is received. I suspect that the program is not using normal Windows keyboard input procedures. Maybe it is polling the keyboard and getting its "real state". If so there's no way I know of to fool it. Maybe there's a way of hooking into Windows lower down, to look like a keyboard, but it is very complex and not something I know about or want to get into really. As a last resort you could try setting "PostKeys=Yes" in the INI, but I really can't hold out much hope in that direction. Regards, Pete

Because the Flight file is only used when loading a Flight. You seem to have confused yourself somewhat. The FLIGHT (FLT) files contain complete flight initialisation details, including the aircraft to fly, the place to fly from, and even the state of the engines, radios, and so on. It is nothing to do with loading or reloading an aircraft on its own. For example, if you loaded another aircraft from the Aircraft menu, it wouldn't reload the FLT! The aircraft is controlled by the AIRCRAFT.CFG file. It is that which the Aircraft menu refers to when you select and aircraft. It provides the aircraft name, characteristics and so on, and also points to the Modelling (MDL), Texture, Sound, and Panel details. I really do think you should find the Microsoft aircraft container SDK and study that before you mess with all this. Regards, Pete

There's two ways to find out: 1. Program a Key or Button in FSUIPC's Keys or Buttons pages to do this action, then look in the FSUIPC.INI file to see what number it used (it'll be the 5 digit number after the "C" in the appropriate line), or 2. Go get the list of FS controls I made from http://www.schiratti.com/dowson. You should find lists for FS2000, FS2002 and FS2004 there. But I though you wanted to change the Model? That indicated to me that you knew all about aircraft modelling. Is this not so? The Aircraft.CFG file contains pointers to the Panel, the Model, the Sound and the Texture folders. I'm not sure what you want to change, but it will be one of those. You can get a Microsoft SDK which explains all about these "aircraft containers". I would suggest you get this and study it first before you mess around too much. Sorry, I have no link -- somewhere on the vast Microsoft website. Regards, Pete

This can only happen if you Escape or Cancel out of the options screen. All options are retained if you press Ok. All the previous setings, on all the pages, are retained if you exit any other way. This is deliberate in case you change your mind. It would be very annoying to lose things otherwise, and it really is a Windows standard to restore the settings on non-confirmatory exits. However, there are very few options (none as far as I know) that should be changed from the defaults when using ActiveSky or FSMeteo. What exactly are you wanting to change? Well, you want me to lie to you instead? If you couldn't get FSmeteo's weather to work in FS2002 I agree you don't stand a chance of getting any weather to work in FS2004. It is far more complicated. The weather in FS2002 was a doddle by comparison -- so what was wrong then? Perhaps some explanation of what you are doing and what you expect is in order? But please don't expect me to know anything about ActiveSky. I do use FSMeteo a lot of the time and it seems to work pretty well. I doubt if ActiveSky is any worse or better, they both strive for what perhaps is not quite fully attainable, but achieve a lot in the process. The "settings" in FSUIPC should be irrelevant. They don't control anything. Mostly they aren't really of any use in FS2004 -- they were carried over from FS2002 in the hope that they might be useful, but with the complexity of local dynamic weather, a "real atmosphere", that FS2004 attempts to simulate I don't really think the minor filters are that important. I think I've said all this elsewhere already, in fact. As for "not staying as set", I really need more specific information as to what you are seeing there. It sounds like you are not setting things correctly, or are attempting to set things which might be under the control of the weather program in any case. Rather than simply repetitively saying that "settings are lost", some step-by-step specifics may let me help you sort out what it is you are doing. However, I don't think any settings changing in FSUIPC will resolve what you feel is a big discrepancy in weather simulation. That's another question entirely and really nothing to do with any minor filter settings. It has no role whatsoever in weather serving. It offers an almost completely transparent route into FS's WEATHER DLL for writing and reading weather, both locally and (theoretically) globally. In FS2002 and before the only interface offered was global, and that was easier for the weather programs. Unfortunately, in FS2004, it has been discovered that there is really no such thing as "global weather". What is called that is now no more than the default weather for any weather stations not yet set. Everything in FS2004 weather is local -- and in areas with a high density of weather stations, the locality may be only a few miles. You may actually be able to see, from your aircraft, the weather from many stations at once. The clouds you see may not be the ones reported at your location -- those may only be the ones directly (or almost directly) above you. Not only that, but FS2004's weather changes, even with the dynamics switched to zero. The winds DO blow things around, the atmosphere moves. It is very complicated. It is the same in all these respects whether you use externally supplied weather or FS's own downloads. There are a few filter mechanisms offered in FSUIPC's options. Mostly these are hangovers form FS2000 and FS2002. Some are designed to help improve performance. Most were added in direct response to use requests. The latest of that type is the option to limit the maximum icing level in clouds, as folks found that FS2004's icing is rather overdone. Personally I think the only really useful options are those marked *** in the visibility page. Oh, I also like the additional cirrus layer option, that adds a bit of "class " to the sky, I think. I think mostly they were they same options. When FSMeteo ran it took control of many of them and allowed you to switch them on and off on its window instead. That control facility is still there. But I do realy think you are making much too much of the options. I'd recommend that you set "minimum weather defaults" in FSUIPC -- maybe enable graduated visibility and visibility smoothing, with some limits, and leave it at that. It sounds as if you are confusing yourself with all that stuff. No, never. Almost in their entirely, by user requests. I'm a sucker and too easily give in to requests. Sorry. Well, I think you give the the options too much credit and the weather designers not enough. You aren't talking about anything that amounts to much. Options like suppressing this, limiting that, are all demanded by folks who want "real weather" but not "quite that real", things like thin clouds, single cloud layers, etc etc are all to do with performance -- maybe clouds don't slow your PC down, but they do a lot of folks, and artificilally limiting the layer thickness did help a lot. Etc Etc. Personally I'd love to take them out. Maybe I will, but I fear the repercussions. The only weather option I actually had to take out because I couldn't implement it ("taxi winds") was sorely missed by many and created many more messages of complaint than the fact that I didn't remove all the rest! It doesn't "serve" as such, it just passes the requests on. It pretty much does nothing else, weather wise, in any case unless you ask it to. Just leave the options to default. Why so much complaint that you feel obliged to mess? And, in any case, pretty much none of that messing does much harm or makes much difference. Feel free to not touch them, if that's the way you feel. In fact I'd thoroughly recommend it. So far all I've got on this is that settings don't stick, or is it unstick? I'd be glad to work out why you are getting this impression, but I cannot without more details. I'm sorry about that. It's just that none of the settings set or unset themselves -- except temporarily when they are being controlled by an external program (such as FSMeteo). However, in the latter case the controlled options are greyed out and disabled anyway, to indicate this. Erthat question is a little confusing. But what other programs are there thayt you may have purchased and which require FSUIPC to be registered? A user registration of FSUIPC is necessary for use of the User Options (yes, including the weather filters). But for what payware programs is it necessary? Are these ones which are not accredited -- i.e. which are sold for use with FSUIPC with no licensing agreement to do so? By the way, after I've released the next updates for FSUIPC and WideFS (hopefully this weekend -- maybe Sunday with luck), I am only around for a few days before disappearing on holiday for three weeks. So if my side of this discussion dries up after next Wednesday, please forgive me. I'll be back on March 12th. Regards, Pete

WideFS can already produce keystrokes for you, using the KeySend facility. You can program a KeySend in FSUIPC's Keys or Buttons page on the Server -- assign a KeySend number as parameter when you do. then in the WideClient.ini file you assign to that KeySend number a keystroke. If you get Wideclient to load the program for you it is easier to get it to direct the keystroke to the right window -- e.g. if you rim the program as "Run1= ..." ypu just add ",Run1" to the KeSend parameter, after the keystroke definition. Regards, Pete

Yes, and it is implemented already. It is called "throttle sync" and was introduced into FSUIPC as long ago as 2.83 (two years back). You'll find it on the Hot Keys page as "multiple throttle synchronisation". In 3.12 I also added an extension to this which synchronised prop pitch and mixture settings too -- this is an option in the Technical page. Regards, Pete

Congratulations! Many happy returns of the day! Regards, Pete

Is this the Wilco 767 PIC? If so it certainly used to work -- I programmed quite a lot into the PFC DLL for that aircraft. But that was way back, version 1.2/1.3 I think. Perhaps it's changed. I don't touch it any more. The programmers were very uncooperative, even hostile, so I uninstalled it all and stopped developing for it. Regards, Pete

The default trim indicators aren't very sensitive -- there are many tiny steps between full down and full up and the default indicators show only a few, so it won't move for small changes. I use Project Megenta which has a numeric display going from -32 to +32 which is better, but still a little coarse. But anyway, as I said, you can adjust the sensitivity of the built-in facility to suit yourself. Regards, Pete

Because the Programmer's Manual is for programming FSUIPC, not for using FS2004! :) The "Reload user aircraft" FS control is an FS control. You can find it in the FS2004 Options - Controls - Assignments list, and also in FSUIPC's Keys and Buttons pages, in the drop downs for FS controls. You can send FS controls through FSUIPC -- see offset 3110. Regards, Pete

But if the unreliablility of the inputs from the axes is more than than the difference you want for steering you cannot reliably set such a difference in any case. It still makes no sense to have it switchable. If you need it you need it, if not you don't. If you have enabled it and use it it is because you find you cannot find points on your controls which give identical engine settings, and this matters because the aircraft you are flying is very sensitive to very small (2-3%) differences -- when flying. But surely 2-3% difference on the ground is not going to be of specific help in steering and even if it was you are relying on something from your controls which you are explicitly NOT able to rely on! It's a complete contradiction, if you see what I mean! Surely, for steering, just use a little more difference. Then the equalisation is removed in any case. Regards, Pete

Why would you want it switchable? It is only equalising the values when the difference is less than the maximum possible error on the PFC axes (ie twice the resolution). Once the difference is greater than that it is doing nothing in any case. Pete

Well you probably can but I very much doubt whether it will have any effect. That is going to be a derived value -- i.e. an effect, not a cause. Only maybe by using the FS "reload user aircraft" control after changing the current aircraft files. I suppose just writing the new model entry in the PANEL.CFG file (via, for instance WritePrivateProfileString API) before issuing the "reload user aircraft" would do it. It won't be instantaneous of course, because FS will reload the aircraft, panel, the works. Regards, Pete

That's not like anything I've ever heard of before. Do you have automatic quadrant selection enabled? You are getting the default if it cannot find a suitable quadrant. It will also default to than if NONE of the quadrants are checked as enabled. All this indicates is a timing difference. FSUIPC has to initialise the values. But it should have done that LONG before you can get into PFC's options. Version 1.84 of PFC is more careful how it initialises now. It does not start until you are ready to fly. If you had an avionics stack you'd not see the radio frequencies and so on get filled in until then. I did this because there were possibilities otherwise of PFC seeing switch changes and trying to send controls to FS before the aircraft is fully loaded. This can crash FS quite easily. Anyway, I will make the PFC options code obtain the Controls list data from FSUIPC dynamically, when needed, rather than rely on it getting them initially, once and for all. That should fix that problem. I'll send an interim update to you shortly. See if you can break that. :wink: Regards, Pete

That would be a scenery function, for scenery which has a way of doing it. I think it may be programmed by using a COM frequency, i.e. "pilot controlled lighting", but really scenery is not something I know anything about. You would get better answers from some scenery design Forum. No, I think it will be the way the scenery elements are programmed. There's no scenery lights switch that I know of. Regards, Pete

FSUIPC does not ask for a key code. You only use Keys in FSUIPC if you wish to register, and this is done through the Options (ALT M F), selecting one of the register buttons on the right-hand side. If you have an application which is actually asking for a registration number, then it is something to do with that application. Why do you think it is to do with FSUIPC? Please check with the support for the add-on application, whatever it is (you still haven't told me its name. Is it "Carrier Operations"? I've not heard of that one I'm afraid). Regards, Pete

Yes. Here is a sample the the output as received and processed correctly by Jeppesen FliteMap, with the settings I use, for instance: $GPRMC,122119.00,A,5324.1111,N,00212.6492,W,240.1,45.0,130204,6.1,W*6D $GPGGA,122119.00,5324.1111,N,00212.6492,W,1,05,0.0,1050.3,M,,,,*1F $GPGSA,A,3,01,02,03,,,,,,,,,,3.0,3.0,3.0*31 $GPRMC,122120.00,A,5324.1439,N,00212.5945,W,240.1,45.0,130204,6.1,W*6C $GPGGA,122120.00,5324.1439,N,00212.5945,W,1,05,0.0,1050.9,M,,,,*14 $GPGSA,A,3,01,02,03,,,,,,,,,,3.0,3.0,3.0*31 $GPRMC,122120.00,A,5324.1691,N,00212.5522,W,240.1,45.0,130204,6.1,W*61 $GPGGA,122120.00,5324.1691,N,00212.5522,W,1,05,0.0,1051.3,M,,,,*12 $GPGSA,A,3,01,02,03,,,,,,,,,,3.0,3.0,3.0*31 $GPRMC,122121.00,A,5324.1968,N,00212.5060,W,240.1,45.0,130204,6.1,W*6A $GPGGA,122121.00,5324.1968,N,00212.5060,W,1,05,0.0,1051.8,M,,,,*12 $GPGSA,A,3,01,02,03,,,,,,,,,,3.0,3.0,3.0*31 Show that to the NavGPS folks if you like. I think first you need to verify the connection. There is a MUCH greater likelihood of it being something wrong in the connection than anything else. The rest is really too simple to be likely to be wrong. Have you any simple program for the PocketPc which will show what is being received on the COM port? There is no other way I know to check this. Regards, Pete