NWI Winds Aloft

[pilotjohn]

Hmm. I've never seen that -- in fact the code contains this:

n += sprintf_s(&szMetarToWrite[n], MAX_METAR_LENGTH - n, "%03d%02d%sKT%s%c%c ",
					dir, p->Wind[i].Speed, szGust, szAlt, chTurbulence[t], chShear[s]);[/CODE]

where chShear is "GMSI", and the s value is constrained to be in the range 0-3 inclusive. Can you show me any examples? Are you sure you aren't mixing the METARs being read with the ones being written?

I might be confusing what I've seen in read/write. If I find one I'll let you know.

Well, I think because it didn't work -- this is according to comments in my code, so I obviously did try it. However, we are talking about 5 years ago, and I cannot recall now whether I only tried with the RTM version or SP1 or SP2. I think SP2 because a lot of things got fixed then, but maybe, even if it worked by then, maybe I never changed it because it meant having even more messy code testing the version in use.

If you'd like to try it via the string mechanism and let me know, it would be easy enough to fix. I do have quite a lot of SP1 and SP2 only checks in these days (as well as ESP and Prepar3D versions 1, 1.1 and 1.2 -- so it's messy anyway!

It didn't work. It takes the parameter, and reads back correct for GLOB, but all the stations read back 180 of the direction given (if the variance is included) and the speeds are not set. So there's something definitely not right about it.

Along the lines of your notes in your code, do you have anything about cloud depth/height? I noticed you're setting it in the second field after &TT (CU, ST etc.) but it seems to be completely ignored, and even the documentation says it's unused. Reads of course, include a value.

[Pete Dowson]

It didn't work. It takes the parameter, and reads back correct for GLOB, but all the stations read back 180 of the direction given (if the variance is included) and the speeds are not set. So there's something definitely not right about it.

That does sound vaguely familiar.

Along the lines of your notes in your code, do you have anything about cloud depth/height?

Can't be set or read. Most annoying omission in the whole weather system for FSX. The height's are decided by some internal algorithm depending on base altitude and cloud type. Someone did work it all out once but I've not been able to find those details for years.

I noticed you're setting it in the second field after &TT (CU, ST etc.) but it seems to be completely ignored, and even the documentation says it's unused. Reads of course, include a value.

Yes, it's ignored on writes, and I think unreliable on reads. I think I currently work out thickness based on cloud type. If you find the read-back thickness is accurate now I can decode it, with an SP2 proviso.

Regards

Pete

[pilotjohn]

So the reason for the surface DEPTH is for it to be in effect from AGL (to DEPTH) regardless of the other MSL layers.

So for example, If I want surface winds to be 10KT with a depth 1000 feet, but I have a 60KT layer at 3000 feet, if I take off from a 6000 foot elevation airport, the surface winds will still be 10 KTS to 7000 feet (unfortunately they will instantaneously shear if the layer base is below the surface layer, but that's an FSX bug). This is great, but putting the next layer immediately on top of the surface layer may not allow for a good gradient under normal circumstances. It works because it looks like the next layer is ignored, but that's not what I really want.

As an example, I'm generating 10 equal layers to 30000 feet, but what I'd like is for the surface layer to be half the normal layer depth. So I'd like the surface to be 1500, and the next layer base to be at 3000. With the current calculations I don't have control over this since you automatically place the next layer on top of the surface layer.

Would it be possible for you to add a bit-flag in the NewWind structure (in Spare perhaps) that would treat UpperAlt without manipulation if the bit is set? That would seem like a simple solution without me having to write NWI struct to METAR translation, thus duplicating work and spending a lot of effort on it.

BTW, this is all for a random weather generator, that should be done soon (I'll post it). Here are it's features:

- Themes with randomized parameters

- Many pre-defined VFR, MVFR, IFR, LIFR themes

- Randomly picked themes with configurable probabilities (weights)

- Excluded themes (by weight) can still be selected through user input

- Custom themes can be provided as METAR input

- Temperature layers with different lapse rates

- Surface temperatures adjusted for latitude and season

- Graduated visibility layers

- Multiple cloud layers with order restrictions and MSL/AGL options

- Precipitation type based on cloud and surface temperatures

- Precipitation rate adjusted by cloud coverage

- Icing based on cloud temperatures and adjusted by cloud coverage

- Multiple wind layers with controllable shear

- Surface wind based on prevailing direction by latitude

- Winds aloft direction and strength based on latitude

[Pete Dowson]

As an example, I'm generating 10 equal layers to 30000 feet, but what I'd like is for the surface layer to be half the normal layer depth. So I'd like the surface to be 1500, and the next layer base to be at 3000. With the currently calculations I don't have control over this since you automatically place the next layer on top of the surface layer.

You want a gap, with zero or random or unpredictable winds? Why not simply place a dummy zero/zero layer on top of the surface layer?

Would it be possible for you to add ...

I want to avoid making any changes whatsoever to the weather code. It is complex and I've not really touched it for five years. I'd need a really good reason to mess, and so far either you haven't given one, or you have and I haven't understood it.

Sorry,

Regards

Pete

[pilotjohn]

You want a gap, with zero or random or unpredictable winds? Why not simply place a dummy zero/zero layer on top of the surface layer?

I want to avoid making any changes whatsoever to the weather code. It is complex and I've not really touched it for five years. I'd need a really good reason to mess, and so far either you haven't given one, or you have and I haven't understood it.

That gap is not 0 or unpredictable, it either continues the surface layer (if the the next layer has an instantaneous shear) or that's where the shear graduation is performed. As it is, it's simply ignored and graduation proceeds to the next layer (in FSX GUI you cannot actually place a layer there.)

Since you have a "Spare" field in the NewWind struct, I thought it would be the easiest solution to use part of it to signal that UpperAlt should be passed on as is without any manipulation. This would not touch anything else, and would not impact existing functionality.

There's no other way for me to achieve the desired affect without writing my own METAR translation code which would likely be a waste of effort, and likely error prone since you've done the bulk of the lifting. I'd like to make sure this generator performs correctly but I can't think of any way to trick your calculations to do what I want. If I could I would. So I'm hoping you're willing to provide the next best easiest thing which is a simple flag.

[Pete Dowson]

Since you have a "Spare" field in the NewWind struct, I thought it would be the easiest solution to use part of it to signal that UpperAlt should be passed on as is without any manipulation. This would not touch anything else, and would not impact existing functionality.

There's no other way for me to achieve the desired affect without writing my own METAR translation code

Unfortunately the main problem here is simply that I just don't understand. I just haven't got my head around what it is you think is wrong or need to do which can't be done as it is. It is all very well pointing out how easy it is and that it doesn't affect any compatibility, but I really do need to understand first, and i don't.

If you'd like to make it really really simple, perhaps with diagrams to illustrate what you are talking about, then I might get it? Best probably to use Email for this -- petedowson@btconnect.com.

Regards

Pete