Jump to content

Photo
- - - - -

RUBE Weather Module


  • Please log in to reply
73 replies to this topic
Thread Starter
ruebe
ruebe

    Unfit for duty

  • Members
  • 953 posts

#1

Posted 16 February 2012 - 13:47

Preamble

The simulation of weather in this series has been lacking since forever. Actually I think the "weather engine" hasn't been touched since ofp 1.0 (ok, rainbows have been added at some point, but that's it).
Granted, we have the most basic components of weather to play with, such as overcast, fog, wind and rain. But it has always been only that; some components of weather (with some very simply constraints), but no coherent system of weather (or even seasons). But weather should be more than the sum of it's parts. And that's where the RUBE weather module steps in and tries to fill the gap (or at least illuminate and explore it a little).

Sure, there are already some weather modules/addons present. But they focus mostly on effects or worry about synchronisation in multiplayer games. None of them however solves the problem I was interested in to begin with: if weather shall be a crucial component in (strategical/tactical) decision making, then it needs to be forecastable. What weather can be expected for today and what for the next few days? Should we postpone that sniper-mission or rather strike now?



RUBE Weather Module

The RUBE weather module is a pseudo-scientific weather machine consisting of three main components:

  • A season model that defines the clima,
  • a weather generator which creates a forecast for n days and
  • a weather engine that executes todays weather.

Posted Image (click to enlarge)

the season model

A season model consists of monthly averages of the following key components:

  • temperature (Tmin, st. dev., Trange)
  • precipitation (day/month probability, avg. intensity)
  • fog (day/month probability; linked with given precipitation data)
  • wind (avg. speed)

Season models are saved in separate files (see prague.sqf, bamiyan.sqf or kandahar.sqf ), can be freely extended and are choosen by default (depending on the map/world) or at will. Data is gathered from public weather sites, available all over the webs.

There are other climatic/seasonal aspects that are beeing modeled, which are mostly based on the maps latitude (such as daylight hours or polar-ferrel-hadley cells and stuff).



the weather generator

First let's get the terminology straight: a forecast is a set of n days of weather-data with n >= 3, s.t. we have at least the previous days, the current days and the next days weather-data (the weather engine will need the previous and next days data too).

Then the weather generator has basically two tasks:
  • it creates a forecast of n days from scratch or
  • it advances a forecast by one day.

The weather generation process tries to produce coherent weather situations, instead of simply throwing dices for each single component. To accomplish this, atmospheric pressure has been introduced.
But first things first: we start with a random normally distributed temperature (minimum and range) as the season model dictates. We end up with a maximum temperature (min + range) that is either way too low, fine or way too high, compared to the dictated distribution's mean. This difference is used as a bias for the local pressure, s.t. rel. lower temperatures tend to result in high pressure situations (mean above average pressure) and higher temperatures in low pressure situations.

So we have a local pressure, and we may compare that local pressure to the average pressure and thus we gain our first pressure coefficient in the range of [-1,1], where -1 means an extrem low, 0 a stable and 1 an extreme high pressure situation.

All nice and dandy, but that's not good enough, right? Of course not. What we need next, is an environmental/surrounding pressure and then we can compare the local pressure to the environmental pressure and end up with a pressure coefficient II, again in the range of [-1,1], where -1 means an extreme local low, 0 stable and 1 an extreme local high situation - compared to the environmental system.

The goal was somewhat coherent weather situations, right? That's why the environmental pressure get's biased according to how many local low situations we need; that is, how much it shall rain/snow according to the season model. If we need lot's of precipitation we should get enough of local lows, by biasing/increasing the environmental pressure.

Equipped with these two pressure coefficients, out of which the second is clearly the "stronger", we can build the following matrix, which will act as our pressure system:

   
   Sy | coeffII x coeffI  | temp. | prec. | over. | fog   | wind  |     ???
   ---|-------------------|------------------------------------------------------
    0 |         |low      | +1    | +2    | +2    | -2    | +2    | warm core low
   ---|   LOW   |---------|-------|-------|-------|-------|-------|--------------
    1 |         |stable   |       |       |       |       |       |
   ---|         |---------|-------|-------|-------|-------|-------|--------------
    2 |         |high     | -1    |       |       |       |       | cold core low
   ---|---------|---------|-------|-------|-------|-------|-------|--------------
    3 |         |low      | +1    |       |       |       |       |
   ---| STABLE  |---------|-------|-------|-------|-------|-------|--------------
    4 |         |stable   |  /    |  /    |  /    | +2    | -2    |
   ---|         |---------|-------|-------|-------|-------|-------|--------------
    5 |         |high     | -1    |       |       |       |       |
   ---|---------|---------|-------|-------|-------|-------|-------|--------------
    6 |         |low      | +1    |       |       |       |       | warm core high
   ---|  HIGH   |---------|-------|-------|-------|-------|-------|--------------
    7 |         |stable   |       |       |       |       |       |
   ---|         |---------|-------|-------|-------|-------|-------|--------------
    8 |         |high     | -1    | -2    | -2    | -2    | +2    | cold core high
   ---|---------|---------|-------|-------|-------|-------|-------|--------------
   
      \________/ \_______/
       humidity x temperature   > "biased by ..."
   
                                  \______________________________________________/
                                   pressure conf./system then further biases the 
                                   remaining (-temp) main weather components
                                   
                           \_____/
                normally distributed to begin 
                with and used to bias Plocal  
                which determines coeffI    

While this is heavily simplified and quite artificial, I think such a pressure system is actually really nice to work with; as central driving force (or conductor) of the weather, which puts a little bit of meaning into this soup.

Anyway, as the matrix already suggests; the remaining components are all more or less biased by this pressure system (and so will be lot's of the weather functions used by the weather engine for the "micro"-weather).


"Advancing" the forecast; weather trends, evolution & mutation

Now, we aren't simply going to toss the dices individually for each day (respectively for a new day, while every nth day gets to the n-1th position). While the seasonal averages could be easily met this way, that would result in a pretty chaotic sequence of weather.
And second, our forecast-data should actually represent a weather forecast, that is: the weather-data of the next day should only change marginally (or only occasionally a bit more), while every day further into the future can change way more, up to drastic changes.

Both problems are addressed with the same mechanism: there's a simple formula for a days forecast stability:
_forecastStability = {
   //  n=1   n=2   n=3   n=4   n=5   n=6   n=7
   // .934, .801, .595, .417, .283, .188, .123, ...
   (1.54 * (_this / (exp _this))^0.5)
};

Generally that's the relative amount (for each/most components) that won't be touched. So the forecast of the next day changes roughly by 7% or something. That change is accomplished most of the time by (linearly) blending single components of weather data. And for this there are several alternatives: a day has at least one link (to the previous or next day) and at max two such links. We'll use these links as sources for our blending process and if there are two sources and stability is low enough, we might even drop the original source altoghether, thus merging the previous with the next day... And we can also produce such a source (for a component) from scratch (as if we would generate a new, average day). Some of this I've called evolution, some mutation... it doesn't matter. What matter's is, that this process generates the desired forecast character - thanks to the forecast stability, and second we'll get a quite natural evolution of weather, with trends that might hold for a while and weather breaks every once in a while.


a small statistical test suite

Now, some of you may have already noticed that I pursue two heavily clashing paradigms: first I began with a declarative seasonal model and next I'm about to model weather in a "meaningful" way, where the single components "pseudo-scientifically" interact with each other... what the...?! I mean, either you work with a good declarative model and that's it, or you go and try to model nature - no matter what some components may average to in the end, as long as it all "makes sense" (with respect to the simulation).

Or in other words: do we really need a season model and what should it actually consist of? Wouldn't latitude and maybe some data about the height and precipition be already enough? Honestly I don't know, and this is up to discussion or simply a question of design.

Anyway, by going that hybrid route (and then that evolution/mutation process - eeek), it became really hard to know whether the generator actually did his job good or if he was just fucking around with me, producing some random output that has nothing to do with the given season model (or only by chance). That's why I've written a small statistical test suite to help me meet the seasonal model's averages and to see how coherent the generated forecast actually is (some stuff really should correlate, other stuff rather not. But mind you, we don't wanna end up with perfect correlations...).

The point is: I highly encourage anyone messing with the generator function (or even while defining a new season model) to make use of that test suite (included in the package somewhere) aswell.

The generated output (you're supposed to study) will end up looking something like this:

Btw. single components may be excluded from the analysis.


the weather engine

At this point we have forecast data consisting of weather-data for n >= 3 days:

      ------------  --------------  -----------  ---------- 
      | 0: prev. |  | 1: current |  | 2: next |  | 3: ... | 
      |    day   |  |    day     |  |    day  |  |    day |
      ------------  --------------  -----------  ----------
      
      |---------------------------------------------------->
      

where the data structure for a single day (currently) looks like this:
   [     
      0: temperature    -> [
                              0: Tmin, 
                              1: Trange
                           ],
                           
      1: precipitation  -> [
                              0: intensity (0 OR ]0,1]),
                              1: disturbance mask (array; will be slapped on at the very end)
                           ],
                           
      2: overcast       -> [
                              0: intensity ([0,1])
                           ],
                           
      3: fog            -> [
                              0: intensity ([0,1]),
                              1: duration 1, sunrise ([0,1]),
                              2: duration 2, day     ([0,1]),
                              3: duration 3, sunset  ([0,1]),
                           ],
                           
      4: wind           -> [
                              0: speed in m/s ([0,oo]),
                              1: direction in degree ([0,360])
                           ],
                           
      5: pressure       -> [
                              0: local atmospheric pressure at sea level, in Pa 
                                 (somewhere around ]98000, 104000[ with a mean of 101325),
                              1: environmental/surrounding atmospheric pressure at 
                                 sea level, in Pa
                           ]
   ]


Weather engine; fundamentals and it's cycles

First let's note that the weather engine isn't omnipresent/global. Stuff is different in different places/at different altitudes. That's why the weather engine is bound to a central object which is usually the player (or maybe a game-logic or another unit during cutscenes).

Since we can't transition overcast and fog simultaniously (engine limitation), the weather engine works with two major cycles: first an overcast-, then the fog-cycle and then it will start all over again. Anything else will be transitioning constantly/in both cycles.

The weather engine can be reset at will, starting with a new overcast-cycle (and a seamless transition). Thus you could modify the forecast data manually and then reset the weather engine; and voila: scripted weather changes. On a similar note you could aswell "abuse" the forecast-stack, s.t. a single "day" now just represents a weather-definition you can advance to at will by manually advancing/manipulating the forecast-stack...

The weather engine is also capable of detecting a new day and "advancing" the forecast all on it's own. But you can disable this mechanism, in case you don't like it.

The particle effects (radiation/ground-fog and snow) can be disabled as well. So can the color filter be disabled (see below; toggable in the demo-mission).


A random walk

For most of these components the weahter engine initializes bounded, random walkers. The bounds are defined by the extrema of the previous, the current and the next day (and for some 0 anyway) and the initial position is defined by the current daytime. From there, it's a random walk within these given bounds and until a switch to the next day.
                            - 
                           / \  _     
                          /   \/ |        
                         /       \      ---------->
                        /         \    /     
                       /           ---/     
              <--------                   
                
       \______________/ \________________/ \_______________/
         0: previous      1: current day        2: next 
      
                   (bounded, random oscillation) 

So if these three days have similar data, you can expect stable weather over the whole day. But if the previous, the current and the next day differ by much, then all kind of things might happen, since the random walkers will operate within much larger bounds.

I'm not sure about the simulation clock/speed of these walkers yet, so this is about to be tweaked at some point.

While most of these walkers (or oscillators) are the base/source of a some component, there's most of the time another layer on-top of this to model phenomena on a much faster or more precise scale. In it's most primitive form that might be a simple random-choke function (for wind or precipitaion), that occasionally throttles the intensity to model smaller disturbances and stuff.


Temperature

Temperature is one of the few things that is not based on such a random walker. We have a minimum temperature (Tmin) and a range (Trange) for each day, s.t. Tmin + Trange = Tmax. Todays Tmin and Trange then get mixed with either the data from the previous or the next day to guarantee continuous temperature changes, even at 24:00 to 00:01.

The diurnal cycle (the amount or fraction of Trange that get's added to Tmin depending on daytime) is then modeled by a pearson type-III distribution. And finally the lapse rate is modeled too, so temperature decreases with altitude (Inversions aren't possible/modeled for now).


Precipitation, overcast and the disturbance mask

Just rain isn't good enough. Precipitation on the other hand is a nice level of abstraction. All we need then is a little function that decides, if it shall rain or snow (or even both/mixed). Since this is mostly based on the temperature, we'll get a natural snow line, since temperature decreases with altitude...

Anyway, random walks are hell of a ride, but that's not good enough - especially for overcast and precipitation. While it might be nice, if it's raining all day long (for a local low), there are other typical cycles we'd like to model. A typical heating storm in the afternoon/evening for example.
This is taken care of with the disturbance mask, which throttles overcast and precipitation (but never boosts it). Basically we're operating with a linearly interpolated key-frame approach, where we can define the minimum and maximum output/intensity on a daytime-basis. Clear sky in the morning, a heavy, rapidly forming storm in the evening. Yummy.

       ------------        ---------------        ---------------
       |          |        |   random    |        | disturbance |
       | forecast |  ===>  | oscillators |   X    |    mask     |
       |__________|        |_____________|        |_____________|
      
     (macro config.)      (micro evolution)   (typical characteristics)
     

The disturbance mask makes use of yet another oscillator, based on two sines, operating in the band defined by the current minimum and maximum. For one this models uncontrolled breaks/variance, and for two we have an exponent ontop of that oscillator: an exponent below zero leads to maximized output/only short quick breaks, while a large exponent above one leads to a minimized output with short peaks. Generally this exponent is based on the latitude, s.t. we have minimized output with peaks in polar regions and maximized output at the equator - thus modeling somewhat the polar-ferrel-hadley cells.

         --------------------         --------------------  
         |         / \      |         |   __     _       |
         |        /   --    |         |__/  \_  / \__/\  |
         |       |      \_  |         |       \/       \_|
         |     _/         \_|         |                  |
         |_  _/             |         |                  |
         |_\/_______________|         |__________________|
         0         18      24         0                 24
         
           ( thunderstorm )            ( widespread low )
               at 18:00     
                 

This of course is an opportunity to manually manipulate the weather as desired. That disturbance mask can be easily matched to your missions needs, before you launch the weather engine and there: a strom exactly at the time you'll need one. Of course, if the random walker's output is next to zero, the disturbance mask can't to anything...

And finally - to make things a bit more dynamic - there is a local pressure offset that comes with the disturbance masks use, s.t. what we take away with the disturbance mask (less overcast, less precipitation) will be added to the local pressure's base as temporary bonus. This might strenghten the current pressure system or it might eventually lead to a switch in the pressure system... which effect's other components (stronger wind, less fog, ...) and all hell breaks loose or something. :)


The fog cycle

The weather engine models a typical fog cycle, s.t. the probability for fog is lowest throughout the day, since humidity comes with the night. Fog is negatively linked to wind speed - especially the radiation/ground-fog (realized with extra particle effects).


Wind

Wind direction and speed both run on a random walkers and there's a random throttle function for wind-speeds. Also wind get's stronger with altitude.


Pressure

There's a random walker for both, local and environmental pressure, so the pressure system might suddenly swap/switch. Pressure coefficients/system is continously used in most weather functions to bias this and that and all kinds of things. :)

Pressure decreases with altitude (lapse rate; interpolated between a moist and a dry one, depeding on a simple approximation of humidity).


Color filter

Modeling seasons is currently next to impossible. But one can at least try. A lot of the seasonal mood is derived by the colors. That's why the weather engine constantly runs a color-filter, based on the variables:
  • temperature,
  • daytime and
  • season/date.

Most important is the temperature, which takes away red tones with low temperatures to get a cold/blueish picture. A strom in summer on the other hand should look rather warm and really not like poor weather in winter.

Daytime is used to amplify/exagerate sunrise and sunset. And the season/date is used in a similar way as temperature is beeing used, to give seasons a distinct tone, even if subtile.

Together with fog and snow, you should hopefully get the impression of winter, as opposed to lame vanilla chernarus' winters.

But if you don't like it, you can disable it. And I'm also thinking about making the color filter part of the season model. Maybe at some point.



the forecast report (dialogue)

Posted Image

We have weather data for n days, but that's pretty much useless without some nice, accessible representation...

There is a script RUBE\modules\weather\dialogs\fn_weatherReport.sqf that attaches an action to open a forecast-report to a given object. The dialog comes in two version: a digital one, supposed to be used with the notebook, and an analogue version for journal-like objects.

Right now both versions are identical (except for the colors). But I figured the "digital" version could have something more advanced, like a barometer. Remember, temperature differs with altitude, so it might be of advantage if one could calibrate that forecast-report.

Check out the demo for an example.

Guess what's left to do is a nice dialogue we may attach to the radio or some kind of alarm-clock-like object, offering a simple interface to set the alarm clock and an option to sleep up to that point.



Usage, examples and some ideas

The RUBE weather module is part of the RUBE library which runs as script-version or as addon (as you like). For the weather module, the addon-version is actually quite convenient, since it offers the weather module as game-logic you can just drag onto the map and you're good to go. Random, seasonally fit weather.

I've thought about offering two such versions for the editor, one for random, seasonal weather, and one that would respect the editor's weather settings (overcast and fog). But I figured that if you wanna have more control, then you wanna get full control and thus you'll just manipulate the forecast data as you need it. So you'd manually launch the weather engine anyway...


Launching the weather engine and the RUBE_weather game-logic

If you're using the addon, just drop the RUBE weather engine game-logic onto the map. The RUBE library will be loaded, weather generated and the engine will be launched for you.

If you're using the script-version, you'll need a description.ext with the following contents:
#include "RUBE\core.hpp"
#include "RUBE\x-core-IDC.hpp"
#include "RUBE\common.hpp"

class RscTitles
{
#include "RUBE\rsctitles.hpp"
};

class CfgSounds
{
#include "RUBE\sounds.hpp"
};


... and then just look at RUBE/modules/weather/init-editor.sqf for a first example (this is the script that get's called for the addon's game-logic):
// make sure the RUBE function library is loaded
if (isnil "RUBE_fnc_init") then
{
   [] call (compile preprocessFileLineNumbers "RUBE\init.sqf");
};
waitUntil{!(isnil "RUBE_fnc_init")};

// init weather module
_this execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};

// and start right away with default settings
[] call (RUBE_weather getVariable "start-weather-engine");

Here _this is the game-logic from the editor. But we can aswell just pass garbage to that init function as in:
[] execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};

What you need to know is that RUBE_weather is a game-logic, where all related stuff is saved, such as the forecast data and even the "interface" to this very module.

At the point "start-weather-engine" is called in the example above, no season model has been selected and no forecast data has been generated. "start-weather-engine" will take care of this and run with defaults.
Guess most of the time, we'll do that manually to gain more control. So here's a more elaborate example:
[] execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};

// debug stuff
RUBE_weather setVariable ["debug-generator", true, true];
RUBE_weather setVariable ["debug-engine", false, true];

// select season model
"bamiyan" call (RUBE_weather getVariable "set-season-model");

// set forecast size
RUBE_weather setVariable ["forecast-days", 6, true];

// initialize forecast/weather data
[] call (RUBE_weather getVariable "generate-weather");

// now we could manually manipulate the forecast data, only
// today disturbance mask or whatever...

// ready? set, go!
[] call (RUBE_weather getVariable "start-weather-engine");


demo mission

Posted Image

Make sure the RUBE library is available (don't forget the description.ext in case you use the script version), choose some map and put down a player - but do not manually put down a weather module; the demo script will load one for you, mkay? Then execute the following code (you can simply put this in the init-line of the player):
0 = [] execVM "RUBE\modules\weather\scripts\demo.sqf";

... then launch/preview the mission. The image above illustrates what should get spawned infront of you. Actions are attached to the n objects and there are some radio calls available too (to teleport and stuff).


Test-suite

The test-suite (barely; it's just a quickly hacked together script) is available at \RUBE\modules\weather\scripts\test-suite.sqf in case you haven't found it already. I suggest you copy that file and change the parameters as needed or something.


Weather engine: constants

At this point I probably should say a bit more about that RUBE_weather logic. First, there are "constants" stored here, which you may overwrite at will. They (and their defaults) can be found in /RUBE/modules/weather/weather-constants.sqf. Besides some simple settings such as "enable-color-filter", "enable-particles-fog", "debug-generator", ... also the core data is stored (or rather initialized) here, such as "date", "forecast-days", "forecast", "season-model", and so on and finally there are actually "constants", such as "latitude", "longitude" and some physical constants.
Feel free to overwrite any of them as you see fit with a call to setVariable, prior to launching the weather engine.


Weather engine: interface

Instead of defining even more global functions with unbearably long names, I decided to put "public" weather functions into that RUBE_weather logic aswell, which makes up a pretty nice to use interface. It's defined in /RUBE/modules/weather/weather-interface.sqf and you've already seen how these are called in the above examples.


Weather engine: the finite state machine

Once the weather engine is started with a call to "start-weather-engine", a finit state engine will be launched and a pointer to it will be set to RUBE_weatherEngine, from where you can access anything inside the running weather engine (in case you need to; check out the demo script for an example).


Some ideas

Sure, the first thing that comes to mind is an indefinitely ongoing campaign that could make use of this module. Wanna have a forecast for the next few days? Well, then go grab the latest newspaper in the village... :P

But you could also make good use of the forecastability for any singleplayer mission, no matter how short they will be. Just setup a nice little intro scene and offer a forecast for the next few days. You're then given the mission and a limited timeframe. Thus, you could start the mission right now or rather not and gamble for better conditions.
Just setup an alarm-clock, so one can choose the exact point the mission shall be launched. Maybe one has to "sleep" once or twice... befor you're actually moveing out, starting the mission.
I'm pretty sure that could work very well, with a lovely atmosphere, the gamble with the weather and tactical thoughs about fog and windspeeds and stuff. :)

And as already hinted: the weather engine is pretty much free for any abuse. That is, you can script weather changes at will and with more or less full control by manipulating the forecast data and makeing good use of "reset-weather-engine". Just keep the minimal cycle delay/time in mind.


F.A.Q.

  • Does this work for multiplayer missions too? And if not, are you going to do something about it?
    No, the RUBE weather module will not work for your multiplayer missions. And there are no plans to do that.
    But feel free to write your own client variant of a weather engine, that is multiplayer-proof. Let the server generate the forecast, and then come up with some client version of the weather engine.

    But I'm not sure anyway, if it would be such a good idea to have player-centric weather clients for a multiplayer match. Sure, wind speeds differ indeed from place to place, but still... Maybe you'd better drop that idea, if you're going to do this.

  • Any plans of adding new season models?
    Sure. And you may help if you'd like to see good defaults for your preferred maps/worlds. If you come up with a good one, just drop me a note.

  • What about humidity? Air saturation and that kind of thing?
    Yeah, humidity is currently not really modeled/simulated. We work with the entity (or concept) "precipitation" and that's it.
    Humidity, where needed, get's approximated at times though: in the generator by mixing the given precipitation data (probability and intensity) and for the lapse rate humidity is approximated by the overcast or by the precipitation (=fully saturated) if there is any.
    Granted, that's quite lame and as soon as I gain a better understanding and maybe a vision about how "humidity" could be wired with the other weather components, this might get improved. Maybe. On the other hand this would probably require a completely different concept/design altogether, starting with a new structure/type of a season model and.... ahhh screw this. :P

  • Are you dumbass actually aware of the fact that the scales in arma-town are completely off? Height above sea-level my ass! (I've heared elevationOffset got introduced at some point, hrhr) The question..? Uhm, do I really have to repeat the part with the dumbass?
    Yeah, at some point (have you ever seen bushes pushed to the ground, because the wind speeds were a tiny wee bit too high?) it actually dawned on me what dumbass I am and that one can not simply apply real-world math to the arma universe. Scales are different/skewed here. Btw. has anyone reliable information about this? I can vaguely remember reading something about this somewhere...

    Anyway, some further tweaks might be needed in this regard. And remember that it's only pseudo-science we're doing here, with the goal to get something that resembles actual weather, physics and everything.

  • Do you really think it's a good idea to burn that much cpu cycles for _this_?!
    Hell yeah! Of course. Though, functions constantly called by the weather engine might indeed need some optimization (you tell me!). All these b├ęzier-curves could indeed hurt a little. We'll see if I need to simplify them or maybe even build a lookup-table or something.

  • Where are the friggin screenshots already?!
    You may find some over here. But since I run this on a shitty machine, those screenshots aren't nice or anything. Sure, you may recognize some pixels and stuff...

    Maybe some of you guys would be kind enough to make some exquisite shots of the weather module in action and post them in here? Maybe.

  • ...?
    Just read (and mess with) the code, now would you? :P And drop me a note if you think something is wrong or could be improved. I never claimed that I've got much clue about weather... :cool:
    (Pretty much everything is commented and there are even some ASCII-illustrations in there for you illiterates out there.. though, now that I think about it, I might have already spoilered too much... sorry.)

Changelog
Spoiler



Requirements:

  • ArmA 2: Combined Operations (ArmA 2 & ArmA 2: Operation Arrowhead)


Download

The RUBE weather module is included in the RUBE library, whose latest version is available under:
http://non.sense.ch/shared/rube-wip/.

Mirrors:

Edited by ruebe, 19 April 2014 - 11:45.
version: 2012.03.27, (added some mirrors)


Rydygier
Rydygier

    Chief Warrant Officer

  • Members
  • 3236 posts

#2

Posted 16 February 2012 - 13:57

When I saw, who is author of this thread, I knew, that this will be something special, deep and fascinating.

Well...

It is! :)

I love to know, that behind given effect hides a complex mechanism, that guarantees a realistic simulation of the phenomenon. Phenomenon... Hm. Yes. It is good word. Phenomenal job, Ruebe!

giallustio
giallustio

    Master Gunnery Sergeant

  • Members
  • 1373 posts

#3

Posted 16 February 2012 - 14:05

Outstanding work...No words :D

=BTC= Col.Giallustio

= BlackTemplarsClan =

Italian Tactical clan

Youtube


Jedra
Jedra

    Warrant Officer

  • Members
  • 2048 posts

#4

Posted 16 February 2012 - 14:08

"I never claimed that I've got much clue about weather..."

Well, if that's the case then you should start your own 'Bluffers guide to...' because I am utterly convinced of the contrary!!

I have a nice long weekend to myself so I will check this out!
Jedra's Addons
Arma 2 : Enhanced Skills Slider
Take On Helicopters : Take On Taxi | Jedra's Time Trials | Weapon Indicators | No Radar

Serclaes
Serclaes

    Master Sergeant

  • Members
  • 775 posts

#5

Posted 16 February 2012 - 14:21

I can only second that: phenomenal job!
I'll be sure to check the code out too!

kremator
kremator

    Major

  • Members
  • 7527 posts

#6

Posted 16 February 2012 - 14:32

Wow ... nice one.

Something like this in MSO (that means that missions CAN last for days) would be ideal!

mr burns
mr burns

    OFP slut

  • Members
  • 6052 posts

#7

Posted 16 February 2012 - 15:40

Holy cow ... i was gonna say tremendous effort after reading the first few sentences, then i scrolled down! :eek:


At this state, the only thing missing seems to be a Wetterfee :o
Keep it up!
Posted Image
REALISM! No, fuck that, FIRE THE LASER!

b00ce
b00ce

    Master Gunnery Sergeant

  • Members
  • 1401 posts

#8

Posted 16 February 2012 - 16:55

Sweet Jesus. Great work, I'd try it out but I'm afraid my brain would implode.
LG 34UC97 34" 3440x1440 monitor | 2x GTX-980 G1 Gaming
I7-5820k @ 3.3GHz | 16GB Corsair Vengeance DDR4 @ 2133Mhz
Samsung 840 EVO 120GB & 1TB SSDs | Seagate 3TB HDD
TM Warthog | Saitek Pro Flight Combat Pedals

jeza
jeza

    Master Gunnery Sergeant

  • Members
  • 1087 posts

#9

Posted 16 February 2012 - 17:20

Outstanding!

Armaholic Informed
jeza_3.jpg
Youtube
Ground Branch - Bringing back the old days of real tactical shooters

Foxhound - Breaking news: Armaholic informed by Informant not to post news before being Informed, Armaholic posts news anyway, Informant turns off Internet for two hours

Rig: MSI 780Ti Gaming Edition, 8gb1833,i7 4770k@4.5 Do that polite thing

flashleitz
flashleitz

    Private First Class

  • Members
  • 26 posts

#10

Posted 16 February 2012 - 17:26

B00M...bastic,Ruebe! Outstanding work.
much appreciated,mate!

das attorney
das attorney

    Warrant Officer

  • Members
  • 2955 posts

#11

Posted 17 February 2012 - 00:04

Awesomesauce. Really like it. Good use of the filters too! :)
Oblig sig

foxhound
foxhound

    Retired Moderator

  • Members
  • 11365 posts

#12

Posted 17 February 2012 - 10:03

Impressive work :)

Release frontpaged on the Armaholic homepage.

Posted Image
RUBE Weather Module - Script
RUBE Weather Module - Addon


Visit Armaholic.com | Visit Carriercommandaholic.com
Posted Image
Public FTP available, just check the Armaholic.com FAQ.

HMM........wonder what it is huh?

Robster
Robster

    Gunnery Sergeant

  • Members
  • 454 posts

#13

Posted 17 February 2012 - 10:44

Whoaaa! Really impressive!
Posted Image

Posted Image

DMarkwick
DMarkwick

    Major

  • Members
  • 7298 posts

#14

Posted 17 February 2012 - 10:52

This sounds really great & and not a million miles away from my aborted weather project from years back. I should like to see this become part of my perma-mods :)

I dropped the weather module into Utes/Chernarus, and initiated the demo script on the player entity, but I didn't see any evidence of weather alteration. And the weather forecasts as reported by the in-demo methods reported steady unchanging weather. At the risk of sounding like a dullard, is there anything else I'm supposed to be doing?
Feel like ArmA is letting you down in some way? Watch this:
https://www.youtube....h?v=Fh3webkCo4Y

Grey-Legolas
Grey-Legolas

    Lance Corporal

  • Members
  • 44 posts

#15

Posted 17 February 2012 - 11:02

No words, Great work!

tpw
tpw

    Warrant Officer

  • Members
  • 2452 posts

#16

Posted 17 February 2012 - 11:21

I dropped the weather module into Utes/Chernarus, and initiated the demo script on the player entity, but I didn't see any evidence of weather alteration. And the weather forecasts as reported by the in-demo methods reported steady unchanging weather. At the risk of sounding like a dullard, is there anything else I'm supposed to be doing?


Yeah I'm pretty much seeing the same thing when using the pbo/logic version. The on screen display just displays "any" for all the weather variables.

domokun
domokun

    Sergeant Major

  • Members
  • 1731 posts

#17

Posted 17 February 2012 - 11:26

Sounds like Rube needs to implement the "British weather" module, where you can experience 4 seasons in one day ;)

Seriously I can't wait to try this. I've been waiting for realistic weather for SO long now (wind, rain, fog, etc), e.g.
Does anyone know if the wind has an impact on ballistics and/or aircraft?
Also does fog limit's AI visibility?
Finally does rain limit AI hearing?

Thread Starter
ruebe
ruebe

    Unfit for duty

  • Members
  • 953 posts

#18

Posted 17 February 2012 - 11:28

Thanks for the kind words, guys. I'm glad that there is interest in this kind of module and that you like the idea so far...

...but has anyone actually run the module yet? (I mean... there's a chance that maybe it's just a bunch of some crackheads code that doesn't actually do anything useful or what it's supposed to do. Maybe it doesn't even work or it just stinks like moose-ass or even worse... or maybe...)
:P

I dropped the weather module into Utes/Chernarus, ...


Ah, very well. I'm glad you gave it a shot, Sir. :cool:

..., and initiated the demo script on the player entity, but I didn't see any evidence of weather alteration. And the weather forecasts as reported by the in-demo methods reported steady unchanging weather. At the risk of sounding like a dullard, is there anything else I'm supposed to be doing?


Ok, so you've dropped the module/game-logic (running as addon - obviously) onto the map and then you've exectued the demo-script, right?

If that's the case: do not drop that module onto the map. The demo-script will load the weather module on it's own and there can be only one weather module at a time, so if there is already a weather module running, then... hm, I need to double check what actually happens then. Haven't thought about this situation yet.


...but I didn't see any evidence of weather alteration. And the weather forecasts as reported by the in-demo methods reported steady unchanging weather.


In case this "problem" persits, please come back and elaborate on what you'd expect to happen.


Yeah I'm pretty much seeing the same thing when using the pbo/logic version. The on screen display just displays "any" for all the weather variables.


Ok. I've tested this myself now and I can confirm, that this happens, when you manually put down an extra weather module and then run the demo. Again: you're not supposed to put down the weather module for running the demo. Just execute the demo and things will be taken care of. (granted: I could have really thought about this situation and handled it in code... duh)

Edited by ruebe, 17 February 2012 - 11:35.


DMarkwick
DMarkwick

    Major

  • Members
  • 7298 posts

#19

Posted 17 February 2012 - 11:36

Ok, so you've dropped the module/game-logic (running as addon - obviously) onto the map and then you've exectued the demo-script, right?

If that's the case: do not drop that module onto the map. The demo-script will load the weather module on it's own and there can be only one weather module at a time, so if there is already a weather module running, then... hm, I need to double check what actually happens then. Haven't thought about this situation yet.


Ah OK, I guess I misunderstood the functions of those two :) I thought the script simply spawned the weather-reporting items & base, but that it needed the module. I will try again later on tonight & use only one.
Feel like ArmA is letting you down in some way? Watch this:
https://www.youtube....h?v=Fh3webkCo4Y

Rydygier
Rydygier

    Chief Warrant Officer

  • Members
  • 3236 posts

#20

Posted 17 February 2012 - 12:00

...but has anyone actually run the module yet? (I mean... there's a chance that maybe it's just a bunch of some crackheads code that doesn't actually do anything useful or what it's supposed to do. Maybe it doesn't even work or it just stinks like moose-ass or even worse... or maybe...)


Oh, but this is not so important, how well it works... Approach to weather problem is here amazingly deep and require praises in itself, regardless of the effect... :) Effect is another matter and is as follows:

map: Utes. One player unit with needed exec in init field. Tent with equipment is on place, and that's it.

RPT:

Error in expression <
(_this select 1),
(getTerrainHeightASL _this)
]>
  Error position: <_this)
]>
  Error Brak )
File RUBE\fn\fn_getPosASL.sqf, line 42
Error in expression <
(_this select 1),
(getTerrainHeightASL _this)
]>
  Error position: <_this)
]>
  Error Brak )
File RUBE\fn\fn_getPosASL.sqf, line 42
Error in expression <));

if (_unit != player) then
{

_unit forceWalk true;
};

_unit forceSpeed 2.0>
  Error position: <forceWalk true;
};

_unit forceSpeed 2.0>
  Error Brak ;
File RUBE\fn\fn_makeDraggableLib.sqf, line 676
Error in expression <));

if (_unit != player) then
{

_unit forceWalk true;
};

_unit forceSpeed 2.0>
  Error position: <forceWalk true;
};

_unit forceSpeed 2.0>
  Error Brak ;
File RUBE\fn\fn_makeDraggableLib.sqf, line 676
Error in expression <h) > 1) then
{
_h = getTerrainHeightASL _this;
} else
{
_h = (getPosASL (RUBE_we>
  Error position: <_this;
} else
{
_h = (getPosASL (RUBE_we>
  Error Brak ;
File RUBE\modules\weather\weather-functions.sqf, line 102
Error in expression <h) > 1) then
{
_h = getTerrainHeightASL _this;
} else
{
_h = (getPosASL (RUBE_we>
  Error position: <_this;
} else
{
_h = (getPosASL (RUBE_we>
  Error Brak ;
File RUBE\modules\weather\weather-functions.sqf, line 102

Reason: I have only Arma2 1.10, and getTerrainHeightASL command is introduced in OA 1.55, also forceWalk: OA 1.51. Shame, but it is of course my problem, not script error.