PSX weather model

[Hardy Heinlin]

No, I'm not working on it :-)

I'm just planning the layout of the Instructor window and I'm wondering how many weather areas I should offer this time.

(This is about internal weather generation. External network injection is another story, that will get extra features.)

PS1 has five weather areas.

In PSX there could be more. Perhaps 7 or 10.

Before you say "20", consider all the work the user has to do when filling all 20 area pages with weather data.

I plan to implement three modes:

1. Network weather (injected by any addon)
2. Manual weather design using several weather areas
3. Quick & simple weather design valid for the entire earth

No. 3 is useful for quick training setups. This allows No. 2 to be more complicated, as it's just an option.

Nevertheless, do we need more than 5 weather areas?

The transition between the areas is interpolated and the parameters I have in mind to activate an area are UTC (start time of the new weather), lat/lon of area core, radius. The rest of the earth will get an automatic weather generation based on ISA, locations and time of the year. – That's actually another area.


Cheers,

|-|ardy

[Jeroen Hoppenbrouwers]

In case areas can appear and disappear depending on time, and they can be positioned such as to generate weather not by flight phase or altitude but by lat/lon+radius, I think you open such a broad area of applications that the number of areas isn't that important any longer. They will need a "copy from" function anyway.

I can imagine a system where there initially is one area (call it Zero). That is the whole Earth, as an exceptional feature (no lat/lon and unlimited radius). Any extra area starting at one is initially a copy of area Zero. Only the parameters changed are memorised; all other parameters remain a reference to area Zero. So if you change Zero, you also change all other areas unless they contain an override (weather inheritance).

Each area has the same options, including a "copy from" which offers a dropdown menu so that you can copy the changed parameters from another area if you want that (default is Zero). A mirror button could be "Create new area from the current area". It would copy all changed parameters and become current highest area number plus one.

Next to start times, you may need stop times, though I can imagine if you copy an area, you just need the start time as the rest will overlap and cancel out the old area.

If you use the lat/lon+radius system, it may be little work to add a translation vector (nm per hour and compass direction)...

I would let the number of areas run up to 50, as there is little reason to limit this to a lower number. More areas mean more resources, more to set up, more CPU... but the limit isn't interesting.

Area 51 is, of course, a natural limit.


Jeroen

PS. External programs could have two modes of operation. One is to continuously inject weather with PSX current position as center. This is nice for what you experience now and here, but does not show distant problems on radar (and possibly no distant lightning in the windshield). A nicer model, more work for the addon but better, lets the add-on create areas at will on specific points, but less often (say, one general update per 15 minutes, or 30, or 60 as that is METAR cycle). I assume this is what MSFS stuff à la ActiveSky does?

PS2. Lat/lon of course in FMC position notation, so you can also use maps with beacons and fixes to put in weather areas. PB/PB, PB/D, etc.

[Hardy Heinlin]

50 is your magic number, huh? :-)

(50 TCAS aircraft!!)

..

The copy feature you suggested is pretty much what I want to build. The slight difference to my plan is: As soon as any variable on an area page has been changed, the area's "global link" checkbox automatically unchecks. This ensures that any manually designed area keeps its "composition" as intended by the composer in case someone changes the global settings. I think this protection is necessary because the variables inside an area use to require a certain consistency, e.g. it can't be raining (commanded by global) when there's no cloud in that area, or e.g. it can't have Arctic temps (commanded by global) when the area's coords are in the Sahara.

|-|

[Jeroen Hoppenbrouwers]

True; both the "inheritance" and the "override" options have their merits. Your argument about consistency likely wins.

[Peter Lang]

I plan to implement three modes:

1. Network weather (injected by any addon)

If we can get the weather from the internet, say all 15 minutes, this should be enough to conduct flights in rather real conditions.

For training purposes normally you have smaller areas. Somewhere in the vicinity of an airport or somewhere enroute with the problem to get to an alternate immediately.

For this training purpose 5 weather areas should be ok. Perhaps it is possible to decide if these 5 areas shall cover the complete 5000+ NM for the flight or just an area of about 250 NM.

Just my thoughts
Peter

[Hardy Heinlin]

I guess I'll make 7.

+ Rest of the world

= 8

...

This has nothing to do with the network. This is about the internal weather generator.

I can't imagine somebody wants to fill 50 weather pages. In many route sectors the sequence of the entered numbers would resemble an interpolation anyway.

Yes, they cover the whole flight. Or ... in other words ... the situation which you load from the disk. The settings are valid until you change them – next hour, or tomorrow, or next year ...

By the way, any changes on the Instructor window can be made "on the fly" without pausing the sim. The Instructor is a floating and resizeable window.


|-|

[Jeroen Hoppenbrouwers]

I just wanted to suggest to not implement n areas hard-coded, but to create a class "weather area" and instantiate as many objects as needed, using a number to access them, not tabbed pages. Then it does not matter whether you have one or fifty areas as long as you have sufficient CPU. A limit here seems so arbitrary.

[Qavion]

If we can get the weather from the internet, say all 15 minutes, this should be enough to conduct flights in rather real conditions.

MSFS seems to have this annoying habit of changing the baro when you're a few hundred feet above the runway. I guess this is not only due to the 15 minute time period, but because the real weather in MSFS might only be updated every few hours.

To get real weather, won't you have to have an expensive contract with one of the weather services? (I've forgotten if/how it was done in PS1).

Cheers.
Q>

[Zinger]

a. About the weather add-on option, I'd like an ability to utilise historical saved weather in addition to near real time. It gives crews the opportunity to rehearse flight in unique weather, previously encountered.
b. Since FSUIPC is no longer a required add-on for FSX, smoothing of sudden weather changes to avoid unrealistic aircraft behavior (such as the unexpected drop on final) is also desirable.

[Jeroen Hoppenbrouwers]

Plain weather reports (METARS) are available for free from several sources; I have been regularly getting them for my old SB747 program. Although none of these sources is guaranteed to be complete and up to date, they are quite okay for hobby flying. It is more difficult to get winds and temps aloft data and general weather predictions of the "here is the front" type, especially in digital form. Plenty of maps out there, but...

In case a METAR feed is available, it should be simple to swap the live feed for a fixed disk file of historical METARs, possibly a few files in chain for moving weather. The same of course for winds/temps aloft.

PS1 has always smoothed weather changes, including the baro setting, so I don't expect further problems with PSX.

[Richard McDonald Woods]

There are many who use the HiFi Simulations products (AS, ASX and ASA) to inject the weather to MSFS. I assume that those pilots will also require that the same weather is injected into PSX.

AS under FS2004 uses FSUIPC/WideClient to inject its weather. ASX and ASA use only SimConnect (a part of FSX) to inject their weather. So it looks as though PSX, if it is going to share weather in the MSFS environment, will have to accept both FSUIPC/WideClient and Simconnect weather inputs.

Ditto for weather environments other than MSFS.

Sounds more and more complex!

Cheers, R

[Jeroen Hoppenbrouwers]

AS under FS2004 uses FSUIPC/WideClient to inject its weather. ASX and ASA use only SimConnect (a part of FSX) to inject their weather. So it looks as though PSX, if it is going to share weather in the MSFS environment, will have to accept both FSUIPC/WideClient and Simconnect weather inputs.

It does not need to. Everything concerning MSFS linkup, including weather, will go via the VisualPSX connector. PSX itself will not need to provide any non-native interface.


Jeroen

[Richard McDonald Woods]

Great! Much simpler than I thought, then!
Cheers, R

[Jeroen Hoppenbrouwers]

Well, for most people, except for Garry  :mrgreen:

[Will]

I agree with Hoppie's idea of class "Weather" with any number of instances.  But I also think that most people who have ever flown with online weather will get easily frustrated without it... One of the most exciting things about planning a long-haul trip is using real forecasts and then dealing with contingencies as they come up.  So I'd expect that the typical PSX user will not be as interested in multiple native weather areas, and in fact may only use the native settings for dialing the clouds down to practice takeoffs and landings at challenging wx
scenarios.  (Of course, I could be wrong here.)  So I'd expect that more users would get more mileage out of a smoothly functioning realtime weather injection system than an elegant internal world.

I always loved Tom Whang's SimWx, where you could call up METARs and TAFs all over the world through ACARS.  That was nice, and really made the ship feel like it was in a real universe.

[torrence]

I agree generally with Will.  I've always been interested in weather in PS1 and SimWx was a big help.  Such weather injectors of choice ought to be fairly easy to implement with PSX being built with networking in mind.  

A feature of SimWx that I liked in addition to the real time weather was the SimMETAR option which allowed you to quickly build a weather/location scenario with a few sliders and typing or use of a set of pre-set wx conditions (e.g. Clear Day, 0/0, Non pr app, T/O min, Cat I, II and III minimums).  It constructed a METAR for those conditions and injected it.  Very useful for training.  Hardy might want to use some of this SimMETAR interface logic as  an example when setting up the new PSX internal weather settings.

Cheers,
Torrence

[torrence]

Based on Hardy's screen-shots of Instructor station pages, it looks like, as usual, he's probably way ahead of me on thinking about the weather interface too (although he hasn't shown that screen yet).

Cheers,
Torrence

[Hardy Heinlin]

Hi Torrence,

I'm not sure if I'm ahead of you :-) The WXR page is still blank. I think the WXR page cannot be completely handled by sliders only. There's not enough room for the many adjustment features I'm having in mind. It'll be a mix probably.

Cheers,

|-|ardy

[Roddez]

Hardy, will the global weather model include the ITCZ and other well know localised weather phenomena and standard jet streams, with some randomised values?

[Hardy Heinlin]

Too early :-)