Weather Enhancement Request

[Luke Kolin]

(This is coming from memory so please pardon me in advance if it's not accurate.)

If I recall correctly Peter, FSUIPC will allow external programs to set the weather directly, with very little checking in between. This can lead to a crash in WEATHER.DLL if an invalid cloud type is specified and the necessary bitmaps aren't present. While I don't get these crashes often, they are annoying especially near the end of a long flight.

Would it be possible to add an option to the registered version to filter out cloud types that are "invalid" - perhaps an INI setting that sets allowable values, and if the option is enabled then FSUIPC would check to make sure that the value it gets for a cloud layer when setting local weather is in the list of acceptable values.

This seems like a reasonably easy (well, easy for me - I'm just brainstorming and not actually writing anything!) way to improve the reliability of the sim and weather packages.

Cheers!

Luke

[Pete Dowson]

(

If I recall correctly Peter, FSUIPC will allow external programs to set the weather directly, with very little checking in between. This can lead to a crash in WEATHER.DLL if an invalid cloud type is specified and the necessary bitmaps aren't present.

This is true, but only of the new weather interface added for the much more versatile weather system in FS2004. The idea was (and is) to provide a virtually transparent interface direct to FS so that the weather programmers can experiment and do a really good job, unrestricted to the things I (personally) thought were correct in previous versions of FS, where the interface was certainly not transparent.

While I don't get these crashes often, they are annoying especially near the end of a long flight.

But you should never get them at all. They are indicative of a bug, and that would need fixing. What program is responsible?

Would it be possible to add an option to the registered version to filter out cloud types that are "invalid" - perhaps an INI setting that sets allowable values, and if the option is enabled then FSUIPC would check to make sure that the value it gets for a cloud layer when setting local weather is in the list of acceptable values.

Hmm. Do you know the acceptable values? I don't. I know which values are supported for standard Cirrus, Cumulus, Stratus and Cumulonimbus -- these are the types supported in previous versions. Are more allowed in FS2004? I don't know. FS95 and FS98 had a "user defined" type, whatever that is, and all sorts of other types have been listed in assorted sources.

Maybe they are not not supported if the bitmaps are missing? How would you tell? What matches bitmaps to cloud type number?

... to improve the reliability of the sim and weather packages.

Well, really the culprit program(s) should be fixed. I've been using FSMeteo and ActiveSky for many years and have never had one such problem occur. I don't know what program you are referring to, but shouldn't that work just as well?

As you say, the modification isn't hard. I wouldn't delete such a cloud, only convert its type number. say all unknowns to become stratus (the fastest), or maybe make it dependent on altitude. But really it isn't something I would like to do -- I'd rather the programs were fixed if possible. Can that (correct) method be checked first, please?

Incidentally, it is rather odd getting such a request 32 months (yes, not far short of 3 years!) after the facilities and programs were made available!?

Regards,

Pete

[Pete Dowson]

Would it be possible to add an option to the registered version to filter out cloud types that are "invalid" - perhaps an INI setting that sets allowable values, and if the option is enabled then FSUIPC would check to make sure that the value it gets for a cloud layer when setting local weather is in the list of acceptable values.

Please check the latest interim version, 3.556 (or later), above. There's now a facility (INI file parameter) to do just that.

Regards,

Pete