Pete Dowson

There are later versions available in the Interim Releases announcement at the top of this forum. Not sure I understand that (i.e. I can't envisage what you mean). If you haven't enabled throttle sync then there is no software connection whatsoever between separate throttle axes. In that case it may be a hardware problem, so you would need PFC's support. Now I am really confused. On the one hand you say you can't calibrate the throttles, and on the other that the throttle quadrant is okay! Which do you mean? Regards, Pete

Hi, I've posted two updates to FSUIPC in the top announcement here as part of an attempt to get the wind smoothing system working correctly (again). Please try them out and let me know what you think. I've reproduced the notes about them here, below, so you can see what is going on. Best regards Pete =============================================== FSUIPC.DLL Versions 3.511 and 3.512 I've posted two test versions at the same time in an attempt to find out if they both behave the same, wind-wise, or if one is better than the other. I am testing here, but wider usage is needed, please. The 3.51 fix in the wind smoothing algorithm which additionally makes the wind direction written to offset 2DE0 have the correct effect at the aircraft, now appears to be in error. The direct wind control facilities at offsets 2DE0 and 2DE8 are used by ASV (optionally, but defaulted). The fix applied to get the apparently correct effect at the aircraft via these offsets has the unfortunate side effect of making FS set incorrect crosswind and head/tail wind components. Worse, even weithout anything using direct wind control, with Wind Smoothing is enabled, the same, "corrected" algorithm is used and again applies the incorrect wind components -- although then these don't appear to be read as such by navigational instruments. I cannot make a lot of sense of all this at present, though after a couple of days of investigation it does appear to me that FS's wind simulation is rather different when the aircraft is on the ground than when it is in the air. I can 'fix' things on the ground, and in the air, but with different algorithms. Although I can detect the difference ("aircraft on ground") I cannot actually implement both fixes because the wind changes have a delayed effect on the aircraft. I've tried, but no matter what I do, things get screwed up for a while just after take-off, i.e. at the worst possible time. So I'm abandoning the attempts to get the wind control working on the ground. Hopefully I'll be able to do better with the next version of FS, as and when. Just by way of explanation of what the original change in 3.51 was all about: the problem in 3.50 and before with the wind direction written to 2DE0 was that the effect actually implemented in FS at the aircraft was a wind 180 degrees opposite, as could be found by turning a static ground aircraft into wind as measured on its ASI. The fix in 3.51 certainly fixed that, and quite a bit of exposure here (as 3.507) failed to detect the airborne inconsistencies which arose. The differences between 3.511 and 3.512 are in how much "fiddling" FSUIPC does with the winds inside FS when smoothing or providing direct control. Over the last two days I think I've proven to myself that some of the things I was changing don't matter, and may make things worse, so 3.512 eliminates that part of the code. Please try both 3.511 (without "AircraftWindRev=Yes") and 3.512 (it doesn't have that parameter), and let me know which you find better, if you notice any difference at all. Thanks! Regards Pete

Hi, I've posted two updates to FSUIPC in the top announcement here as part of an attempt to get the wind smoothing system working correctly (again). Please try them out and let me know what you think. I've reproduced the notes about them here, below, so you can see what is going on. Best regards Pete =============================================== FSUIPC.DLL Versions 3.511 and 3.512 I've posted two test versions at the same time in an attempt to find out if they both behave the same, wind-wise, or if one is better than the other. I am testing here, but wider usage is needed, please. The 3.51 fix in the wind smoothing algorithm which additionally makes the wind direction written to offset 2DE0 have the correct effect at the aircraft, now appears to be in error. The direct wind control facilities at offsets 2DE0 and 2DE8 are used by ASV (optionally, but defaulted). The fix applied to get the apparently correct effect at the aircraft via these offsets has the unfortunate side effect of making FS set incorrect crosswind and head/tail wind components. Worse, even weithout anything using direct wind control, with Wind Smoothing is enabled, the same, "corrected" algorithm is used and again applies the incorrect wind components -- although then these don't appear to be read as such by navigational instruments. I cannot make a lot of sense of all this at present, though after a couple of days of investigation it does appear to me that FS's wind simulation is rather different when the aircraft is on the ground than when it is in the air. I can 'fix' things on the ground, and in the air, but with different algorithms. Although I can detect the difference ("aircraft on ground") I cannot actually implement both fixes because the wind changes have a delayed effect on the aircraft. I've tried, but no matter what I do, things get screwed up for a while just after take-off, i.e. at the worst possible time. So I'm abandoning the attempts to get the wind control working on the ground. Hopefully I'll be able to do better with the next version of FS, as and when. Just by way of explanation of what the original change in 3.51 was all about: the problem in 3.50 and before with the wind direction written to 2DE0 was that the effect actually implemented in FS at the aircraft was a wind 180 degrees opposite, as could be found by turning a static ground aircraft into wind as measured on its ASI. The fix in 3.51 certainly fixed that, and quite a bit of exposure here (as 3.507) failed to detect the airborne inconsistencies which arose. The differences between 3.511 and 3.512 are in how much "fiddling" FSUIPC does with the winds inside FS when smoothing or providing direct control. Over the last two days I think I've proven to myself that some of the things I was changing don't matter, and may make things worse, so 3.512 eliminates that part of the code. Please try both 3.511 (without "AircraftWindRev=Yes") and 3.512 (it doesn't have that parameter), and let me know which you find better, if you notice any difference at all. Thanks! Regards Pete

Hi, I've posted two updates to FSUIPC in the top announcement here as part of an attempt to get the wind smoothing system working correctly (again). Please try them out and let me know what you think. I've reproduced the notes about them here, below, so you can see what is going on. Best regards Pete =============================================== FSUIPC.DLL Versions 3.511 and 3.512 I've posted two test versions at the same time in an attempt to find out if they both behave the same, wind-wise, or if one is better than the other. I am testing here, but wider usage is needed, please. The 3.51 fix in the wind smoothing algorithm which additionally makes the wind direction written to offset 2DE0 have the correct effect at the aircraft, now appears to be in error. The direct wind control facilities at offsets 2DE0 and 2DE8 are used by ASV (optionally, but defaulted). The fix applied to get the apparently correct effect at the aircraft via these offsets has the unfortunate side effect of making FS set incorrect crosswind and head/tail wind components. Worse, even weithout anything using direct wind control, with Wind Smoothing is enabled, the same, "corrected" algorithm is used and again applies the incorrect wind components -- although then these don't appear to be read as such by navigational instruments. I cannot make a lot of sense of all this at present, though after a couple of days of investigation it does appear to me that FS's wind simulation is rather different when the aircraft is on the ground than when it is in the air. I can 'fix' things on the ground, and in the air, but with different algorithms. Although I can detect the difference ("aircraft on ground") I cannot actually implement both fixes because the wind changes have a delayed effect on the aircraft. I've tried, but no matter what I do, things get screwed up for a while just after take-off, i.e. at the worst possible time. So I'm abandoning the attempts to get the wind control working on the ground. Hopefully I'll be able to do better with the next version of FS, as and when. Just by way of explanation of what the original change in 3.51 was all about: the problem in 3.50 and before with the wind direction written to 2DE0 was that the effect actually implemented in FS at the aircraft was a wind 180 degrees opposite, as could be found by turning a static ground aircraft into wind as measured on its ASI. The fix in 3.51 certainly fixed that, and quite a bit of exposure here (as 3.507) failed to detect the airborne inconsistencies which arose. The differences between 3.511 and 3.512 are in how much "fiddling" FSUIPC does with the winds inside FS when smoothing or providing direct control. Over the last two days I think I've proven to myself that some of the things I was changing don't matter, and may make things worse, so 3.512 eliminates that part of the code. Please try both 3.511 (without "AircraftWindRev=Yes") and 3.512 (it doesn't have that parameter), and let me know which you find better, if you notice any difference at all. Thanks! Regards Pete

It must be an extra one they (PMDG) have added for their aircraft. Interesting. I wonder if there are many others? Yes, its all just numbers to FSUIPCit just won't be able to list them in the on-line options drop-downs because they aren't listed and it doesn't know their names. Sorry, I don't know. You've got me there. If the XML can only use the PANELS.DLL's "trigger_key_event" call then it may not get passed the table look-up in PANELS.DLL. You'd need to be able to SendMessage to the main FS window (FS98MAIN class) instead. I don't know XML but you could do it in C. Regards, Pete

It may simply be that some navigational controls are using FS-computed wind component vectors (crosswind and headwind), whilst others are deriving these themselves. I would have thought that, for realism, a GPS method would be based on point-to-point computation in any case. Regards, Pete

Ah, sorry, I saw and answered your first message first! It should depend more on the source of the weather than the aircraft being used. Where is your weather from, please? Pete

Are you using ASV at all? Either way, please check the Interim Versions announcement at the top of the Forum and try version 3.511. This, by default, reverses a "fix" I put into 3.51 which seems to have some unwanted side effects. Pete

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