rübe 127 Posted February 16, 2012 (edited) 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. (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: weather-details.txt weather-summary.txt 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) 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 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 2012-02-16: ### First published iteration. 2012-02-20: ### Weather Engine: Tmin and Trange were fixed throughout the day, based on todays data only, creating noticeable uncontinuity at 24:00 -> 00:01. Now they will be interpolated (as has been originally planned), s.t. todays temperature data will be linearly mixed with either the previous or the next days data: previous : 50% ----> todays data: 50% ----> 100% ----> 50% next : ----> 50% 12:00 ---> 24:00 ---> 12:00 ---> 24:00 ---> 12:00 (today) (advance to next day) thus we'll end up with continuous temperatures, while advancing to the next days data. BTW: This is the reason why Tmin and Trange are _not_ based on random walkers/oscillators. (components that are based on them transition seamlessly thanks to the engine's cycles, while the temperature gets calculated by a function based on daytime) Note that there is still a small jump in temperature at 24:00 -> 00:01 since the function modeling the diurnal cycle (Pearson Type-III distribution) isn't exactly continuous. This jump is negligible however (usually below one degree celsius). - Forecast report calculation has been adapted accordingly. ### Weather Engine: faster removal of particle-effects without intensity. (once dropped to zero/below threshold, particle sources were only removed at the end of a full cycle. They're removed within a subcycle now; _getCycleDelay ~= 10-20 sec.) ### Weather Engine Interface: new constant 'enable-auto-advance-forecast', which was only accessible from within the running weather engine's state machine. ### Weather Engine Interface: new command 'hard-reset-weather-engine' to reset without smooth transition/full cycle to the new forecast data. ### Forecast Report: new function 'RUBE_weatherCreateForecast' to calculate the data for a forecast report. The forecast report is now decoupled from the weather/forecast data and nomore calculated on the fly, s.t. there can co-exist as many forecast reports as you like. This, for example, allows to still have the "journal" from yesterday around, while you send Hans to get todays "journal" with a newer/up-to-date forecast report... ### Forecast Report: revised script 'fn_weatherReport.sqf' which enables/attaches forecast reports on objects ships with required/optional tagged parameters now. ### Weather Engine Demo Script/Mission: - runs now whether the weather module has been placed onto the map or not. (though I still don't recommend this, since we need to hard-reset the weather engine, which might be a bit wierd right at the start of the mission, but whatever...) - demonstrates different co-existing forecast reports. (they all get updated after a new day has begun, s.t. the last n forecast reports are beeing kept; oh and there's no notable delay anymore for the reports to update, since we advance the forecast manually by script now, instead of waiting for the engine/fsm to auto advance...) - note that the demo skips n days right at the beginning of the mission to create n old forecast reports for the "journals". - radio call added to manually hard reset the engine (to be used after time has been skipped for example; otherwise the engine needs a full cycle (overcast and fog) to transition to the new data. 2012-03-27: ### Season Model: added failsafe model (prague) as default for unknown worlds. ### Fixed script-version ### Season Model: three new season models added: - model: arauca (Columbia) class: Tropical rainforest climate (Af) - model: kano (Nigeria) class: Tropical wet and dry or savanna climate (Aw) - model: oulu (Finland) class: Continental Subarctic or Boreal (taiga) climates (Dfc, Dwc, Dsc) I hope that suits you well enough for now Sir _William. :) ...and defaults have been set for some of the community made islands: - lingor -> arauca - isladuala -> kano - tropica -> kano - thirsk/w -> oulu - namalsk -> prague - sbrodj -> prague - fallujah -> kandahar 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: www.armaholic.com play.withsix.com Edited April 19, 2014 by ruebe version: 2012.03.27, (added some mirrors) 1 Share this post Link to post Share on other sites
Rydygier 1317 Posted February 16, 2012 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! Share this post Link to post Share on other sites
giallustio 770 Posted February 16, 2012 Outstanding work...No words :D Share this post Link to post Share on other sites
jedra 11 Posted February 16, 2012 "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! Share this post Link to post Share on other sites
Serclaes 0 Posted February 16, 2012 I can only second that: phenomenal job! I'll be sure to check the code out too! Share this post Link to post Share on other sites
kremator 1065 Posted February 16, 2012 Wow ... nice one. Something like this in MSO (that means that missions CAN last for days) would be ideal! Share this post Link to post Share on other sites
mr burns 132 Posted February 16, 2012 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! Share this post Link to post Share on other sites
b00ce 160 Posted February 16, 2012 Sweet Jesus. Great work, I'd try it out but I'm afraid my brain would implode. Share this post Link to post Share on other sites
jeza 5416 Posted February 16, 2012 Outstanding! Armaholic Informed Share this post Link to post Share on other sites
flashleitz 11 Posted February 16, 2012 B00M...bastic,Ruebe! Outstanding work. much appreciated,mate! Share this post Link to post Share on other sites
das attorney 858 Posted February 17, 2012 Awesomesauce. Really like it. Good use of the filters too! :) Share this post Link to post Share on other sites
Guest Posted February 17, 2012 Impressive work :) Release frontpaged on the Armaholic homepage. RUBE Weather Module - ScriptRUBE Weather Module - Addon Share this post Link to post Share on other sites
Robster 11 Posted February 17, 2012 Whoaaa! Really impressive! Share this post Link to post Share on other sites
dmarkwick 261 Posted February 17, 2012 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? Share this post Link to post Share on other sites
Grey-Legolas 10 Posted February 17, 2012 No words, Great work! Share this post Link to post Share on other sites
tpw 2315 Posted February 17, 2012 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. Share this post Link to post Share on other sites
domokun 515 Posted February 17, 2012 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? Share this post Link to post Share on other sites
rübe 127 Posted February 17, 2012 (edited) 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 February 17, 2012 by ruebe Share this post Link to post Share on other sites
dmarkwick 261 Posted February 17, 2012 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. Share this post Link to post Share on other sites
Rydygier 1317 Posted February 17, 2012 ...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. Share this post Link to post Share on other sites
Alex72 1 Posted February 17, 2012 Tested this (addon version) on Utes and placed a unit. Placed RUBE Weather, Library and init the unit with: 0 = [] execVM "\RUBE\modules\weather\scripts\demo.sqf"; When i open the laptop (weather station) i got: Picture \rube\modules\weather\icons\dirany.paa not found And the weather station showed only sunny weather all week and underneath all icons its says either (or both): aay'C/scalar'C So i get no temps etc and the weather stays the same even though i move forwards several (many) days. I might do something wrong and i used the latest beta for the test. Anyway very impressive addon. Just got to make it work now. :) Share this post Link to post Share on other sites
rübe 127 Posted February 17, 2012 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. Ah, my bad. I could have listed the requirements for this module somewhere. So yeah, you need OA and I highly encourage you to baby-sit the neighbours kids, brew some homemade potato-schnaps and sell it or something and then go and get yourself a copy of OA. :p Tested this (addon version) on Utes and placed a unit. Placed RUBE Weather, Library and init the unit... Again: do not place down the module to run the demo-mission. The demo-script will load/init the weather module for you (and doesn't look/care if there's already a weather module there... guess I have to fix that.). Share this post Link to post Share on other sites
AZCoder 921 Posted February 19, 2012 This is all very impressive work and detail, good job! I also found the readme to be entertaining with good advice on using keyed parameters because I hadn't thought of doing that before, hehe. Share this post Link to post Share on other sites
rübe 127 Posted February 20, 2012 New version is up. Temperature is now (more or less) continuous at 24:00-00:01 (I finally rememberd where I've left, what my plans were and why the temperature isn't running on random walkers) and a forecast report's data is now decoupled from the weather data, s.t. forecast reports of different days may happily co-exist (which is reflected in the updated demo). But read the full changelog below in case you're not bored yet. Changelog: 2012-02-20: Weather Engine: Tmin and Trange were fixed throughout the day, based on todays data only, creating noticeable uncontinuity at 24:00 -> 00:01. Now they will be interpolated (as has been originally planned), s.t. todays temperature data will be linearly mixed with either the previous or the next days data: previous : 50% ----> todays data: 50% ----> 100% ----> 50% next : ----> 50% 12:00 ---> 24:00 ---> 12:00 ---> 24:00 ---> 12:00 (today) (advance to next day) thus we'll end up with continuous temperatures, while advancing to the next days data. BTW: This is the reason why Tmin and Trange are _not_ based on random walkers/oscillators. (components that are based on them transition seamlessly thanks to the engine's cycles, while the temperature gets calculated by a function based on daytime) Note that there is still a small jump in temperature at 24:00 -> 00:01 since the function modeling the diurnal cycle (Pearson Type-III distribution) isn't exactly continuous. This jump is negligible however (usually below one degree celsius). - Forecast report calculation has been adapted accordingly. Weather Engine: faster removal of particle-effects without intensity. (once dropped to zero/below threshold, particle sources were only removed at the end of a full cycle. They're removed within a subcycle now; _getCycleDelay ~= 10-20 sec.) Weather Engine Interface: new constant 'enable-auto-advance-forecast', which was only accessible from within the running weather engine's state machine. Weather Engine Interface: new command 'hard-reset-weather-engine' to reset without smooth transition/full cycle to the new forecast data. Forecast Report: new function 'RUBE_weatherCreateForecast' to calculate the data for a forecast report. The forecast report is now decoupled from the weather/forecast data and nomore calculated on the fly, s.t. there can co-exist as many forecast reports as you like. This, for example, allows to still have the "journal" from yesterday around, while you send Hans to get todays "journal" with a newer/up-to-date forecast report... Forecast Report: revised script 'fn_weatherReport.sqf' which enables/attaches forecast reports on objects ships with required/optional tagged parameters now. Weather Engine Demo Script/Mission: - runs now whether the weather module has been placed onto the map or not. (though I still don't recommend this, since we need to hard-reset the weather engine, which might be a bit wierd right at the start of the mission, but whatever...) - demonstrates different co-existing forecast reports. (they all get updated after a new day has begun, s.t. the last n forecast reports are beeing kept; oh and there's no notable delay anymore for the reports to update, since we advance the forecast manually by script now, instead of waiting for the engine/fsm to auto advance...) - note that the demo skips n days right at the beginning of the mission to create n old forecast reports for the "journals". - radio call added to manually hard reset the engine (to be used after time has been skipped for example; otherwise the engine needs a full cycle (overcast and fog) to transition to the new data. Share this post Link to post Share on other sites
domokun 515 Posted February 20, 2012 (edited) FYI there's a chap called TPW who developed a script that simulates the fogging that appears on breathing at dew point. I think that integrating this script with this mod would really improve it as it would provide an easy visual cue as to the temperature, not to mention that it could also indicate how hard a character is breathing... Edited March 28, 2012 by domokun Share this post Link to post Share on other sites
