FSUIPC and WINDS

[Pete Dowson]

Hi folks,

Well, I have some bad news, and some more bad news.

The bad news is that the direct wind facilities used by ASV and maybe other programs only seem to work well when the winds being set this way pretty closely agree with the winds the weather system wants them to be.

The way they are used for wind smoothing is usually okay because it is tending towards the way the weather system wants. But it looks like, sometimes (and I simply can't tell when), ASV is asking the direct wind system to set something rather different to the weather. I assume this is some transitional thing to do with layers and /or how FS2004 does its interpolations between weather stations.

The other bad news is that THIS IS NOT NEW in version 3.51......

I've been trying to analyse what is going on by going to extremes -- perfectly calm weather set, and a program which sets direct winds of 30 knots, changing slowly all round the compass. To make things really obvious in terms of track and GS/TAS differences I'm using a Cessna cruising on A/P.

Mostly, with FSUIPC 3.49, 3.50 and 3.51x the direct winds being set have the opposite effect to what you'd expect -- GS lower when it should be higher, track to the right when it should be to the left, and so on. But it isn't consistent.

I am trying all sorts of code changes, but so far I've not found a solution. All I can do is try to find the least horrible method and post this as the next "general release" version of FSUIPC next week.

What I don't understand is why this all started cropping up with 3.51, when as far as I can see the problems have been there for many months. Is it simply that folks are flying more in the winter months? It is very strange, expecially when, if anything, the reversal of the direct wind direction in 3.51 should have lessened the adverse effects considerably!

:cry: :cry: :cry:

Pete

[Pete Dowson]

Hi folks,

I think I've cracked it.

The problems occur when the winds FS wants to apply are calm -- i.e. zero knots.

The application of direct wind control in FSUIPC is by modification of the existing wind vectors, first to suit the new windspeed, then (in the same frame of course) to suit the new direction. The latter re-orientation is simply done by converting wind vectors to polar, rotating them according to the difference in directions, then converting back to cartesian.

All this time I've been studying this and trying to work out what I was doing wrong. the answer was -- nothing! All that part of the code was and is okay!

The problems occur when the FS wind is calm. THEN I have to compute the correct vectors myself, from "basic principles". That's where I got it wrong! I have the signs wrong in my sines and cosines, or something like that.

This also accounts for the discrepancy when the aircraft is on the ground. It was all my fault! What a twit! :-(

As to why it is having such an effect on these upper winds (jetstream), experienced by some here, I suspect what is happening is this. The default global weather in FS has no winds. When you are en route you do, in fact, often go through patches of sky which fall outside of any weather station's zone, or, perhaps more likely, in a zone for a station whose weather has not been set. When this happens, ASV is still trying to maintain your correct upper winds through its direct Wind control option. I suspect this is what it was added for in the first place.

Once the FS wind is calm, my incorrect computation of the direct wind vectors applies, and the results are .. awful.

I hope this explains everything. All the tests I've carried out here now show everything to be completely consistent no matter what sort of FS winds there are, or aren't, set.

So, please discard 3.513 and any earlier version 3.51x) and start using 3.514, available in the top announcement here.

Best regards

Pete

[dave_paige]

Hi Pete;

Once again I want to thank you for all your attention to this issue. I've been using 3.514 and everything is working just great. One suggestion I would make is when you make this a general release maybe you should make it 3.52. That way only the interim releases would have 4 digits and be easily distinguishable from general releases. Just a thought.

[Pete Dowson]

One suggestion I would make is when you make this a general release maybe you should make it 3.52. That way only the interim releases would have 4 digits and be easily distinguishable from general releases. Just a thought.

Yes, I usually do that, but I tend to add so many changes from one release to another I wanted to indicate that this was an incremental rather than 'new' version.

However, considering I hope not to release another for many weeks (I am on holiday in January, then other commitments loom), maybe i ought to leave it clear and tidy as you suggest.

Thanks,

Pete