Pete Dowson

Sorry, I've absolutely no idea how to do that. FSUIPC is in no way connected to anything in the graphics parts of FS and I wouldn't now where to begin. It really isn't an area I can contemplate getting into. The only way I can think that you might be able to do it is make the line a very long thin aircraft, an AI one, and manipulate it in slew mode through the AI control interface in FSUIPC. Regards, Pete

I don't think I understand the question. There's an offset to set the transponder. You can program it any way you like. If you want to send the FS controls you mention you can do so via offset 3110, but bear in mind that the controls to do selection that way have to be consecutive and contiguous. They don't work with some of the more sophisticated panels around because they send controls continuously, and these interfere. If you could say what it is you want to do I could maybe help a bit more? Pete

Ah .. glad you found the solution. Thanks for telling me. Yes, and thank you for confirming that it was that version. If I were to have to investigate a problem I would certainly need that information, so it is always best to state it up front. Ah sorry, I see. I didn't mean to confuse or denigrate your confirmation of the version. The last change was a minor alteration to make it parameter-compatible with a new facility in FSUIPC 3.51 -- a one-line change in the FSUIPC interface AdvDisplay provides. Pretty much all the changes for a long time have been of that ilk. As I say, I didn't mean to confuse, only illustrate that anything seriously affecting windows would have been evident before now over the years. Even if it was only with FS2004, that's getting on for two and a half years already. With this in mind it seemed much more than likely to be related to video cards, drivers or settings. Regards, Pete

Wind smoothing is one of the more popular features in FSUIPC and it most certainly does work on FS2004. If your "other partner" has experienced problems with this he/shw most certainly has not come here to report them. The wind smoothing facility is designed to work with any source of weather. I don't fly on-line myself, but I don't know of any way the on-line weather programs can subvert the smoothing algorithm. But you shouldn't let me persuade you. Get some other on-line fliers actually using FSUIPC to tell you. There must be many. Regards, Pete

Well, I will for now. But there's a problem to solve still. With that set to its default "No", the wind at the aircraft as measured by the ASI is 180 degrees out. That must mean something. That is the 'bug' I set out to fix in the first place, and I've had to allow it back. You can only really see this measurement easily on the ground, because when flying the larger TAS and complex vectors mask what is going on, and particularly makes it difficult to relate the instrument readings directly. More experiments, in scientific conditions, are going to be needed to get to the bottom of it. I'm not sure when I'm going to have such time to investigate further, so the option stays. I just don't like it. Regards, Pete

Yes, that is a bit strange. Maybe the panel designer was going to put it somewhere but couldn't find space? ;-) Great! Good flying! Pete

Well, not really. FSUIPC does flag the case of being in a menu (the one you mention), and there's a "ready to fly" flag which is set when the first flight and scenery and so on has been fully loaded, but FSUIPC cannot predict what the user is then going to do. After loading FS and allowing his default flight to load, he may then go into the menu, change his location, his time, his aircraft, almost anything. I don't know of any way of predicting user intentions, sorry. The ready to fly flag is at offset 3364 (and is FS2004 only), the menu and dialogue flags are in offset 3365. Please read the notes associated with these, which are listed in the table in the Programmer's Guide document, part of the FSUIPC SDK. These are about the best I can do. Regards, Pete

Sorry, I don't seem to see anything odd. What am I supposed to see there? I'm really not understanding what you mean by "frozen". Certainly, the AdvDisplay winow is a separate window from anything in FS, and its operation and presence should never have any effect whatsoever on anything else in FS. If it does, then there is likely a video driver bug -- the video driver is rendering things wrongly. Perhaps I could be more specific if I knew what you meant by "frozen". BTW, although you say "latest version", there's really been no significant change in Advdisplay for many years. The last major change was to allow "locking", several years ago, which locks the window to a particular video position regardless of FS's displays. The window is actually not part of FS at all, it isn't a "child window" of FS and has no actual relationship with FS's displays. Even in "docked" mode it is only the position on screen which is computed based on the position of the panel part to which it is docked -- just like "locked" but with a programmed relation. In its initial window more, with the title bar, as per your illustration, it is just another Windows window. I'm afraid, if there is a problem with the display rendering, you will need to look at the video driver or FS's own video settings. Maybe one of the options in FS itself will help, like "render to texture" -- try switching that off if on or vice versa. Sorry, I know I'm not being very helpful, but (a) I don't understand what you are reporting, and (b) it sounds like something to do with video rendition on screen, which I'm afraid is totally out of my hands. Regards, Pete

I've just noticed that, in ASVE at least (it may have been there in ASV too, but I've installed ASVE over it now) there's an Option setting to diasable "direct wind control". Maybe I had it disabled? I don't know. But it sounds like that is the facility which is driving the bit of FSUIPC which chabged from 3.50 to 3.51, so another possible test, to verify this, would be to change that ASVE option. This isn't in place of the previous tests I suggested with 3.551, but another possible work-around and confirmation. I'll put 3.551 up in an hour or so. Just doing some final checks here to make sure I haven't broken anything. ;-) Regards, Pete

Aha! In that case there are two likely scenarios: 1. They are actually controlling the fuel switches in their own code, or using alternative methods. In this case you will need to find out if they allow keypress assignments for them and if so, program your switches accordingly, or 2. They are intercepting the controls before they get to FS and preventing them operating because of some other interlocking requirement not yet met. You probably have to go through all the overhead settings to make sure you are in a position to enable those switches -- for instance, is the relevant engine spooling up and the N2% value in the correct range? This really is now more a question for PMDG, if it isn't documented already. Regards, Pete

Okay. I've now downloaded and installed ASVE, build 367. It does no different from my older ASV build 325 as far as the direct control of winds is concerned. however, they both do actually use the feature which I thought I fixed in 3.51. (ASV must be one of the very few programs which do use it). What I cannot understand is how 325 seemed to be perfectly okay with FSUIPC versions 3.507-3.51 here. The problem with the way the direct wind application (through offsets 2DE0 and 2DE8) works is that it appears to give the reverse wind effect on the aircraft itself -- for instance, as measured with the ASI on an aircraft static on the ground, nose to wind. In other words, setting a 30 knot wind from 270 via those offsets, with FSUIPC 3.50 and before you'd need to point the aircraft's nose to 90 to measure the 30 knots on the ASI. That can't be right! Probably the fix for this which I added in 3.507-3.51 was wrong, but it most certainly did correct this anomaly, which was the intention. Maybe that was a fluke and in fact there's another fix which will do the job without the incorrect side effects on the crosswind and headwind values you've been getting with ASV. So, I am working on an interim release, 3.511, which by default does the same as 3.50 did for these offsets, but which also contains an INI file parameter ("AircraftWindRev") which, if set to "Yes" will reverse the direction applied sent to offset 2DE0 before applying it to FS. (This is different to the previous "fix"). Please look out for this in the Interim Versions announcement, top of this forum, and try it with the same sorts of tests you have been doing already -- they have been very helpful, thanks. Please try 3.511 as it comes, and then with AircraftWindRev=Yes in the INI, with the exact same weather if possible, and reporting the same variables, please. I'm going to try to do the same here, but I badly need corroboration as these things have not appeared wrong here at all so far. Thanks, Pete

I'm still checking this, but I have only just discovered that there is a new version of ASV called ASVE. All my tests have been with Build 325, which seems to before this "E" was added. I had no knowledge of the later versions. B325 certainly behaves impeccably here. The change between 3.50 and 3.51 is significant here because it CORRECTS an error (originally due to a misunderstanding about certain internal FS variables) which has been in all versions of FSUIPC 3 before 3.51 (or rather 3.507, which was available here for testing for 5 or 6 weeks -- apparently no one using ASVE bothered to try it and tell me these things). It is looking like ASVE was changed to try to allow for this error in pre 3.51 versions -- instead of someone talking to me and arranging for it to be fixed. When it was reported (not by ASV sources) I fixed it, so the counter-measures which may have been taken in ASVE are now incorrect. This is the way it is looking, but I am working on it now to compare ASV 325 and ASVE 367 to prove to myself whether this is the reason or not. Please see previous messages in this thread too. Regards, Pete

Strange. I don't suppose you could read either of them? If you checked the "normal log" option in the Monitor page they would be written to the FSUIPC log file -- probably making it quite big quite quickly by the sound of it, so only do it whilst its paused, the stop it again. Is that over many tests, or just one of each? Because there's really been no changed in FSUIPC in areas like temperature setting. That's really puzzling. Of course the TAT would be affected slightly by the wind direction changes, because of the different pressure on the body, but compared to the airspeed I would have thought that effect to be negligible. It is also odd that there's any wind difference, because by switching wind smoothing off (I assume you did than in FSUIPC and in ASV? Because ASV can override that and does, by default I think) you actually bypass all of the FSUIPC "interference" in all the values listed, including the only difference in the weather between 3.50 and 3.51. There's one very important value missing from the list. Unfortunately you omitted the heading. The "track" is no use because the tail and crosswinds, and the X and Z wind values, are relative to the aircraft body, which is the heading orientation. I also assume this was in level flight, otherwise some of the figures cannot be related. The values for GS and TAS shown by the ND are certainly correct in that they match the values FS is using in both cases. The FMC must be computing crosswind and tailwing from the given wind rather than reading the aircraft X and Z values -- in the 3.51 case above the FS-computed crosswind (X) from 2DC8 is 13 knots and the headwind (Z) from 2DD8 is 32 knots. The 3.50 values are 35 knots and 2 knots respectively, agreeing with the FMC. One thought has just struck me. I'm wondering if ASV tries to control the winds at the aircraft directly -- by writing to offsets 2DE0 and 2DE8. The correction in 3.51 was made in applying values written to 2DE0, for the wind direction. It was found that the value FSUIPC was actually writing was 180 degrees opposite to what should have been written. I fixed this, but perhaps, experimentally, Damien found the error, didn't tell me about it, and "fixed" it by writing 180 degree-different wind directions here. This would certainly cause some havoc, even if the wind smoothing was turned off. And it presents a quandary if so. Do I, in FSUIPC, maintain an error because programs have been changed to "correct" for it, or expect the programs to be fixed? Really, if indeed, this is what has happened, then the ASV team should have sorted out the discrepancy with me when it was frst noticed. To check for this, do you think you could run your test once again, but this time Monitor just 2DE0 and 2DE8, both as FLT64. If you like, check the "normal log" option below so the values get written to the log. then you can show me that. Sorry for all the hassle. This is indeed a puzzle. If this is the problem, I can provide an interim version of FSUIPC which will have an INI parameter to revert to the incorrect wind setting -- or, rather, do the 180 degree reversal when the value is written to 2DE0. Then, if it is ASV, the parameter can be removed when and if it is ever fixed. I do have ASV installed in my cockpit (but not on my test machines unfortunately), and I'll try to do some checks myself tomorrow as well. In case it is ASV build dependent, can you tell me the exact version/build you are using, please. I'm not even sure I am up to date. Thanks, Pete

Further to my last reply, and actually working things out (for a change ;-)), the full way to compute that GS would be, again by pythagoras: square root ((367 + 17)^2 + 33^2) because the heading vector is the TAS + tailwind (367+17). This actually gives 387, so the crosswind vector, in this case, does only add 3 knots. So there's something odd going on. But I need more data to know what that might be. Certainly comparative figures for the SAME situation exactly (i.e a paused saved one) with 3.50 and 3.51 might be useful. And as well as the GS and TAS offsets I mentioned already, the Aircraft wind X and Z values -- these are: 3470 FLT64 ambient X-axis wind (i.e. lateral), m/sec 3480 FLT64 ambient Z-axis wind (i.e. longitudinal), m/sec There are two others which are relevant (unfortunately you can only monitor 4 values at a time, but if you are paused you could change over): 2DC8 FLT64 aircraft X-axis wind (i.e. lateral), ft/sec 2DD8 FLT64 aircraft Z-axis wind (i.e. longitudinal), ft/sec If you could establish the situation as in your illustration, pause it and save it, then record the Shift+Z values, the ND values, the FMC values and the above 6 values, then do the same with FSUIPC 3.50, I will try to analyse them and see if I can work out what is happening. Don't worry about converting all these values, just write them down accurately please. I'm wondering if PMDG have performed some extra computations to try to make up for something they may have found wrong in FSUIPC 3.50 and before, rather than reporting it for correction as one soul did. I don't use their aircraft so it isn't easy for me to work out what they are doing. Oh, and can you derive anything different from default aircraft? If it is only the PMDG FMC which has these computations wrong I would certainly have to discuss it with them. Regards, Pete

How do you work that out? The aircraft will move in the airmass. If that is sideways, it moves sideways -- relative to the ground. The actual groundspeed will be the resultant vector of the aircraft's TAS on its heading (NOT track) and the wind vector, not the TAS and just the tail or headwind. You seem to be thinking that crosswinds don't do anything to the path of the aircraft over the ground. Why? There should be no difference in 3.50, though that depends exactly what values are being compared between the two. Certainly, because of a correction in 3.51, the Aircraft Wind N and E values should be more accrate than they were before. Perhaps you got used to incorrect reported values before and now don't like the better ones? I think a lot more thought and research needs to be done on this before conclusions can be reached. You may need PMDGs help, to see what FS values they are using. I also mentioned how to check a few. If they are using others I can tell you about those too. Regards Pete

Sorry, the FS16.GAU is a real problem on some folks systems. I know it has been "fixed" by some folks, by reinstalling Windows and other drastic things. It isn't FSUIPC, but something peculiar about the way that one particular gauge is written. It seems to do things in the wrong order on some systems, in some circumstances. This has been going on for two years and no solution has been found. It works fine on all my systems and on most others. You only have two choices. Either pay for and register FSUIPC, or find an alternative TCAS gauge which works properly all the time. The Lee Hetherington ones are fine (ILH_TCAS or similar). Regards, Pete

The FMC also shows a crosswind of 33 knots. You forget, your aircraft is not travelling over the ground in the direction its nose is pointing, so the tailwind isn't the only additive to the ground speed. According to my maths the wind vector affecting the aircraft is square root ( 17 x 17 + 33 x 33) i.e. simple pythagoras. The answer: 37 knots! Dont's forget, the wind is pushing you sideways twice as much as it is forwards! You have to take the resultant wind vector to derive GS! No, there's no change in 3.51 in the winds reported, only, in very unusual and special circumstances, to the effective wind at the aircraft, which isn't actually readable. Without knowing where your PMDG aircraft is getting its information and calculating its figures I've no way to advise you, sorry. But if it is like the example you gave here, I suspect the simple maths of the situation are confusing you. Anyway, try checking the actual values reported by FS itself, just to see if its something wrong in the PMDG aircraft -- for instance, use a default aircraft. Shift+Z will show the ambient wind at the aircraft, with the heading you can therefore work out your tail and crosswinds by simple trig. For FS reported GS and TAS, if not shown on the aircraft's ND use FSUIPC's monitor (on the Logging page) -- check the Adv Display option there, and display the values in offsets 02B4 (GS) and 02B8 (TAS), both as U32 types, don't check 'Hex'. You'd need to pause to check the figures as the GS is given is metres per second x 65536 -- convert to knots -- and the TAS is in knots x 128. Regards Pete

Not a problem, thenthanks for letting me know so quickly. I was getting all prepared with some extra logging and diagnostics, just in case. I think, sometimes, ASV or FSMeteo may be generating too much "wind variance". This is abrupt changes in direction, usually reported as "VRBL" or similar. FSUIPC doesn't smooth these (though they can be suppressed using the option to suppress all gusts -- that suppresses gusts and variance. I may add another option in the next version to limit the wind variance, possibly with the limit being inversely proportional to the wind speed. For example, something to give roughly these limits (only probably derived by a formula, to give a smoother scale): 0-5 knots, no limit (360 degrees allowed: i.e +/-180) 5-10, allow -90 to +90 10-20, allow -45 to +45 20-50, allow -22.5 to +22.5 over 50, allow only -10 to +10 Any comments? Regards, Pete

Okay, but try thingsyou can't do any damage. And then, if it doesn't work, come back with what you tried and we'll take it from there. It is much easier to help with specifics than a big amorphous unknown, which is what I see at present. There are too many things I don't know about the program you want to use and how it might be set up and worked. If it works fine by you pressing keys on its PC's keyboard, then the first, simplest, method I mentioned will be fine. Try it. Regards, Pete

No, sorry, there are no "routines". First you assign a button in FSUIPC to send a KeySend. Just assign a parameter of any previously unused number -- if this is your first, why not 1? In Wideclient.INI you assign KeySend01 to the keypress of your choice -- all the codes are clearly listed for you. Everything else depends upon how your voice thingy works. If it has the keyboard focus all the time, then the simple assignment of a keypress to the KeySend should work. If not, there are various alternatives, ranging fr om directing the keypress to a specific Window Class (which would involve some assistance from the author I suspect), or, more simply, making sure the program is actually loaded by Wideclient in the first place and just telling Wideclient which loaded program to send it to. There are a couple of variations which will only confuse you at this stage. All in all it is utterly and completely dependent on the target program. But all these things are covered in the WideFS documentation in more detail than I'm likely to be able to go into here. This is why documentation is produced in the first place. ;-) Regards Pete

Yes, you can do that, but it's a little complex to set it for keypresses. If your PTT is operating voice in Roger Wilco, or AVC, or Squawkbox 3, then simply assign the button to the PTT transmit on (when pressed) and off (when released). If you are using the latest FSUIPC and WideFS, the rest is taken care of for you. You don't need to use any special keypress. Regards, Pete

Ouch! Glad you sorted it. Thanks for letting me know! Regards, Pete

Agreed. In fact, in my opinion, the rendition of mist and fog was actually better in FS2000 than in either of its successors. Regards, Pete

One further note. I just checked, and when I said "Did you check to see if there was any "wind variance", gusts or turbulence being added by ASV? These are all possible and are not normally affected by FSUIPC smoothing or other options, except outright suppression in the latter two cases." in fact I was wrong -- the FSUIPC gust suppression does suppress wind variance as well. So all three influences can be suppressed in externally supplied weather, if you wish. Your report is most definitely sounding as if it is due to one of two things: either you have wind smoothing turned off, after all (as in the other reported case), or the downloaded ASV weather had some really weird values in it. More likely a combination of both. If you think neither to be the case still, send the files and I'll see what I can find -- but if it is a problem in FSUIPC I'm pretty sure it isn't new to 3.51. Regards, Pete

Phewthat's a relief. thanks for letting me know. One down one to go! ;-) BTW you should not need to reconfigure when merely replacing the FSUIPC.DLL file. I take great care to retain all the options in your existing INI file. But some folks automatically delete FSUIPC files when updating -- it isn't necessary. Only delete your old INI file if it is years ago when you last updated FSUIPC -- some of the defaults may have been changed or old parameters made obsolete. When updating simply copy the new DLL into the FS Modules folder. It will replace your previous one with no other changes needed. Regards, Pete