Pete Dowson

Not I, sorry. I tend to go backards and find older drivers if I have any nVidia driver problems here. Or, just stick to ones which seem to work well and never upgrade. I only start looking at new drivers when I upgrade PCs or video cards, which is about as often as new FS versions. Regards, Pete

Yes, I understood that. Probably because IVap is setting winds via the Direct Wind control. You still have not shown specific examples for the airborne problem you mentioned with 3.512. This is getting urgent! I must resolve it in the next few days. I cannot reproduce anything odd, when airborne, here at all. Please tell me the figures I mentioned, when airborne with 3.512. Yes, as I said, this is the problem which has always been there, and which I tried to fix in 3.51. It was this that has caused the problems here reported! It now looks to me to be unsolvable. I am currently testing a version of FSUIPC (3.513) which is the same as 3.512 except that it automatically switches off direct wind control when on the ground. Regards, Pete

Thanks. It should be the same, but I am testing a slight modification (which will be 3.513). It suppresses the direct wind control whilst you are on the ground. Since the wind direction set by direct control is 180 degrees out when on the ground, yet okay when airborne, it actually presents a bigger change or risk on takeoff, so, since I cannot fix the ground problem I will prevent it instead. There will be a parameter to undo this if needed, but I hope it won't be. I'll put 3.513 up as soon as I'm happy with it, maybe tonight. Regards, Pete

Ah, yes, in that case it certainly would indicate something odd with the pedals. Try enabling the Axis logging in FSUIPC (Logging page, one of the checkboxes on the left). Just enable it then slowly press left rudder, then disable it and view the FSUIPC LOG. See if there are any "out of order" values on the AXIS_RUDDER control. The eliminates extreme spikes, max deflection, which were actually inserted by some of the add-on aircraft in FS2002 9the 767PIC was one, I think). I never new why. I doubt if it will help here, though you can try it without harm. What may work for you is the FSUIPC Filter option, and maybe the Slope option to get a flatter area near rudder centre. For these you'd need to calibrate the rudder in FSUIPC of course. Whether it works really depends on what sort of incorrect value the rudder pedals are giving. Also check your rudder trim is centred. Not all of the aircraft have a rudder trim wheel, but find one that has and centre it there. It should stay centred for all, then, at least until you load another Flight with a different setting. Regards, Pete

Is this is a light aircraft, a prop? Maybe its some gyro effect of the way the prop is turning. This seems likely as, you say, it only affects turning left. Are you sure it isn't realistic for that aircraft? It happens when TAXIING!??? Phew. Don't know what that is. Sounds like the tyres don't have much grip!? No, nothing at all. I would check your aircraft realism settings if I were you -- in the FS Aircraft menu. Many of the effects are overdone to say the least. Try setting the sliders somewhere near the middle. That seems to give the most realistic results for most light aircraft, though it does depend a lot on the modelling. You'll find some really good professionally designed aircraft for FS are a lot better than the default ones too. Regards, Pete

I think you are still misunderstanding something. The protocol you are talking about is one used by GPS's to get more accurate positions vis differential signal analysers. Even the first lines of the place you point to shows that it isn't anything to do with the initial job of telling the GPS where it basically is: Differential corrections are are way of using multiple signals to make an original measured position even more accurate. They are used by surveyors and the like for plotting positions for building foundations and so on. Sorry, but I don't think any of this is relevant to the simple job of getting an FS position out of a PC and into a GPS, bypassing all of the GPS receiver functions. Trying to send differential correction signals to an operating GPS, to make its satellite measured position more accurate, certainly won't tell it where the FS aircraft is in the PC. Pete

It definitely sounds like a faulty video driver. Check it again when an update is available. Regards, Pete

That is only because, in general, it is more efficiebt. If you alow the system to assign them, then all the PCs periodically send out inquiries about the connections that exist. This creates more load and stuttering in FS. It really isn't related to anything in WideFS or WideFS needs at all, only FS performance. Are you using a router? Just reconfigure that too -- give it an IP address and turn off its need to search for IP addresses. Regards Pete

I think that is a specification reference for connection of external GPS aerial/receivers direct to a GPS. It relates to something called the "differential NavStar GPS service". See http://www.navcen.uscg.gov/pubs/dgps/rctm104/Default.htm I certainly don't think it is anything you can link to a PC nor drive with GSPout. Sorry. Regards, Pete

With FSUIPC 3.512 and a default Cessna, setting direct winds at varying directions, the head/tail/crosswind effects are all perfect in all my testing here. Can you please explain how you are measuring these odd things in the air? Check with the GPS, for instance. With an indicated wind (use Shift+Z) to your left the GPS TRK should read to the right of your heading, and vice versa. With a tailwind, the GS shown in the GPS should be higher than your IAS, and vice versa. All these things are true here. If they are not there please give actual examples, i.e. Wind (from Shift+Z, as MagDir / Speed -- ef 120/20 = 20 knot wind from 120 Mag) IAS from your instruments. GS and TRK from the GPS. As for the ground winds, I know they are 180 degree reversed. I am thinking of stopping the direct wind working altogether when on the ground. There's no way I can find to fix it. Regards, Pete

By "5.511" I assume you mean "3.511". Hmm. 2 out of 3 doesn't make sense. It either works or it doesn't work. By default, version 3.511 will operate exactly like 3.50 and before. How long have you been using FSUIPC and IVAO? I don't think this is new at all? I don't think the ground problem is fixable. I tried to fix it in 3.51 and it was that which caused all this. I'll see if I can do some checks here. It sounds like the IVAO software is using "direct wind control", like the option in ASVE. Does the IVAO program have an option someplace to turn that off? Not the winds, just the direct control? If so, please try that. Regards, Pete

On the ground? Or in the air? If in the air, and this is with FSUIPC 3.511 or 3.512, then that is weird, because that is just the opposite of what the others have been saying. If it is with 3.51 then change to 3.512. If with 3.512, please try 3.511. Regards, Pete

Oh, two quadrants? For the same console, or two separate consoles? If you simply mean you have two of the replaceable quadrants for the one console, then there's nothing in those to go wrong really -- they are just the levers. The console has 6 lever positions and six axes and six pots to match. If they work, they work with any quadrant. But you also said your rudders weren't working either. Are they connected via the same console? I'm afraid it still sounds like you need to talk to PFC. Pete

Something else is happening there, as FSUIPC has absolutely nothing whatsoever to do with graphics. The exchange of FSUIPC versions can only be a coincidence, or a simple change in timing of something in the graphics or in the memory arrangement. I suggest you try different video drivers or try different settings. Regards, Pete

Incidentally, you did not clarify the confusion in your earlier message, where you said on the one hand that you couldn't calibrate the throttles, and on the other that they worked fine! Which is it? I still don't understand that. And did you get the later version of PFC.DLL (1.989)? Regards, Pete

Don't enable throttle sync unless you really don't want to use the throttles independently! Have you contacted PFC? It really sounds like you have a hardware problem. Even the simple automatic calibration facility in PFC.DLL will make it very usable. You need hardware support. Pete

Version 3.511 or 3.512? Please don't test with 3.51 -- see earlier messages in this and other threads. Regards, Pete

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