RUBE Weather Module

[Guest]

Updated version frontpaged on the Armaholic homepage.

RUBE Weather Module - Script v120220

RUBE Weather Module - Addon v120220



Arma 2

[oldbear 390]

Whaooo , impressive piece of work !

New on front page at Armed Assault.info

Link to mirror :

RUBE Weather Module (addon) (v 20-02-2012) : http://www.armedassault.info/index.php?game=1&cat=addons&id=1917

RUBE Weather Module (script) (v 20-02-2012) : http://www.armedassault.info/index.php?game=1&cat=addons&id=1918

[KeyCat 131]

Awesome work mate!

I read the FAQ regarding MP but I would love to see MP someday, IMO this would be a good addition to a MSO persistent server.

You have other good stuff in that library aswell, thanks for making and sharing!

/KC

[wolffy.au 9]

Excellent work Ruebe - I really need to read that wall of text sometime, but yes, we can run it on MSO in MP as you described.

I will look at making your script server side, and then just pushing the inital and forecasted figures (as the current MSO weather system already does) to the players, for their local clients to see the same effects. I won't say too much more, as I should read your novel in the OP before making any assumptions! :D

Well done!

[domokun 515]

Maybe this is a dumb question but does this mod ensure that weather effects are synchronised in MP?

[zapat 56]

Rübe, you never cease to fascinate me (to the degree which is rather embarassment. :) ). This is something intensively deep again: and I love every part of it! ( How many hours approx. has gone into this BTW? :)

My only (philosophical) concern is: does a project like this worth it?

And please don't get me wrong here: I would like to know your way of thinking, and I hope you understand my question.

I kinda know why you do this: planning and achieving something like this is a "game" in itself, and in addition it fits the simulation line Arma represents.

The basic idea is good: limited randomness, which creates typical weather. But will somebody ever play for 5 days? If not, then you'll probably okay with one smooth transition, with dynamic missions you are kinda okay with random (or semi-random) starting weather. Or am I wrong?

[rübe 127]

FYI there's a chap called PTW 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...

While this sounds like a plan, I'm not really comfortable with the idea of spawning particle sources for all units in the players range. Particles are a friggin cpu-hog and snow plus radiation-/ground-fog is already heavy.. then stuff blows up and houses are burning... I'm afraid adding breath-particles to the mix isn't a good idea, considering it's quite a small detail.

I might give it a shot nevertheless and see if it satisfies me. And for the impatient: just tap into the weather engine and adapt that script accordingly. Shouldn't be too much of a hassle, though you need to think about how you're going to approximate humidity/air moisture. From the temperature you can get a pretty good approximation of how much water the air can hold, but from there, you're on your own and you'll probably have to work with overcast/precipitation.

I would love to see MP someday, IMO this would be a good addition to a MSO persistent server.

I will look at making your script server side, and then just pushing the inital and forecasted figures (as the current MSO weather system already does) to the players, for their local clients to see the same effects. I won't say too much more, as I should read your novel in the OP before making any assumptions! :D

Just keep the generator and the produced forecast server-side. Then you'll need a new server-side weather-engine that produces and broadcasts the weather for all clients. That engine/fsm will be quite similar to the existing one, with the main difference that it will not be object-/player-centric. And finally you'll need to come up with a completely new (but compareably easy/lightweight) client-engine, that simply does what get's broadcasted - unless you really wanna have some components player-centric nevertheless. Guess you wanna have stuff like wind exactly the same for all clients.

How many hours approx. has gone into this BTW? :)

64? :p

My only (philosophical) concern is: does a project like this worth it? ... But will somebody ever play for 5 days? If not, then you'll probably okay with one smooth transition, with dynamic missions you are kinda okay with random (or semi-random) starting weather. Or am I wrong?

Playing for 5 "human" days straight is certainly not the point of this module. And it doesn't matter if single missions are only short, say below the time needed for a noteable weather change. That's actually not even the point of this module even if it can be used in such a fashion (the guys above seem to be interested in this kind of useage, ha!).

But no. My intention is not to play missions for hours or even days (in "human" time). The point is to have continuous weather in "game-time" with the crucial feature called forecast. Imagine there's that continuously ongoing and pretty much open campaign. There's your base. You have an environment which lives and with which you can interact and missions will be available all over the place. You can do whatever. You save by sleeping at your base. You've got your alarm-clock the choose when to wake up. And then you have your forecast report. What are you going to do? And when? Your environment won't change so fast, so most stuff will be available/open for some time... (and btw. the environment itself may be scripted to "(re-)act" depeding on the weather, to make stuff more plausible/reasonable/believable... and in the end predictable, so you may factor in even more stuff into your reasonings while planing stuff you're going to blow up.)

That's the main point for such a module. It works in conjunction with an alarm-clock/a sleep-mechanism. Thus the main requirement for the weather engine was the ability to produce only "punctual" continuity. That is, the weather machine's main task is to init the weather with respect to the daytime (besides the forecast data, obviously).

And don't worry. I haven't written this module as an end in itself. It's a requirement for my further plans in taking over the world and stuff. :annoy:

Edited February 22, 2012 by ruebe
ahhhrggg, my eyes are bleeding! (typo)

[panther42 52]

You have my vote Ruebe, to at least take over the weather forecasters where I live...:D

[zapat 56]

I gave it a bit more time and now I totally got your point. :) It is awesome!

Just because you know that the weather system is working the cohesion and atmosphere created in time skips are something you don't get with random weather.

I just wasn't aware of it until now: time skip has always meant different weather for me, but I've just realized something was missing: I wasn't skipping time, but started a new "blank sheet" instead.

Now I can FEEL the time skip. :) It is not fake, it is real! :)

Magic....

A question about burning cpu cycles for _this_: what is the approx. cost of this stuff? I've taken a quick look into the script: they are pretty long. But do those sqfs constantly monitoring, every now and then, or mostly at init? Is it as heavy as it seems, or rather light-weight when mission is on-the-fly?

Edited February 22, 2012 by zapat

[rübe 127]

Now I can FEEL the time skip.

Ahaha, yeah. That's the spirit! :cool:

A question about burning cpu cycles for _this_: what is the approx. cost of this stuff? I've taken a quick look into the script: they are pretty long. But do those sqfs constantly monitoring, every now and then, or mostly at init? Is it as heavy as it seems, or rather light-weight when mission is on-the-fly?

While the "heaviest" thing is most likely the generator, that shouldn't be a problem at all, since the generator is most likely used only once (at init behind some loading screen) but at maximum once a day (unless you plan to pull of some kind of weirdo tricks...). So that part is kind of negligible.

So you'll only need to consider the weather engine, which works with 2 kind's of cycles/loops with different clock each:

• outer cycle/loop: calls _doCycle which does the "heavy" stuff, such us simulating all the currently active random walkers, evaluating the disturbance mask, calculateing/updating the temperature, adjusting the color-filter and all the active particles. This function gets called roughly every 10-20th second or something. And then, after _doCycle has been called, we either move on (from the overcast- to the fog-cycle for example) or we go to the inner cycle/loop:
  
• inner cycle/loop: calls _doRefresh which simply (re-)positions all the particle sources to "follow" the player, that is, if the player has some velocity, particle sources will be placed in front of that vector, trying not to outrun their effects... But basically we do not much or next to nothing in here. So that's more or less an idle loop, waiting until we call _doCycle again in the outer cycle/loop... Oh, and the inner cycle is clocked to ~1 second (until a transition from that state is available again...).
  

So stuff isn't called non-stop. But with _doCycle do indeed come some heavier functions, that might waste too much (but I don't know, since I haven't done any tests yet). And there is at least some room for optimization. Worst offenders are probably the color-function (which is one, no, three (r, g, b) heck(s) of a combined bézier...) and then probably already the particles, so snow and especially radiation-/ground-fog.

But really, I have no idea how "bad" it is.

I've thought you guys would tell me/complain early enough. :p

[tpw 2315]

Hi Rube

I've been having a bit of a play with your amazing weather module. Obviously it does and can do an enormous amount, but basically I'm happy for the module to just do a couple of things:

1 - generate random weather on custom maps. Usually desert or central asian maps.

2 - return a temperature value which I can use as a trigger for foggy breath. E.g. temperature < 5 deg C causes foggy breath. I'm aware that this is also dependent on humidity but c'est la vie.

I'm not that concerned with forecast, colour filters etc

To this end I set up a very simple script to start generating random weather, using the Bamiyan season data, and disabling the colour filter stuff.

if (isnil "RUBE_fnc_init") then {   [] call (compile preprocessFileLineNumbers "RUBE\init.sqf")};
waitUntil{!(isnil "RUBE_fnc_init")};
[] execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};
"bamiyan" call (RUBE_weather getVariable "set-season-model");
[] call (RUBE_weather getVariable "generate-weather");
RUBE_weather setVariable ["enable-color-filter", !(RUBE_weather getVariable "enable-color-filter"), true];
[] call (RUBE_weather getVariable "reset-weather-engine");
[] call (RUBE_weather getVariable "start-weather-engine");

This all seems to work, and I get random weather, a temperature value I can grab using (RUBE_weatherEngine getFSMVariable "_temperature"), and no colour fx.

The only problem is that I always get the following error popping up before the mission starts: Scripts RUBE\modules\weather\seasonmodels\.sqf not found

I can pretty much guarantee I'm doing something wrong. Any clues? Thanks!

[verde13 0]

Hi Rube

I've been having a bit of a play with your amazing weather module. Obviously it does and can do an enormous amount, but basically I'm happy for the module to just do a couple of things:

1 - generate random weather on custom maps. Usually desert or central asian maps.

2 - return a temperature value which I can use as a trigger for foggy breath. E.g. temperature < 5 deg C causes foggy breath. I'm aware that this is also dependent on humidity but c'est la vie.

I'm not that concerned with forecast, colour filters etc

To this end I set up a very simple script to start generating random weather, using the Bamiyan season data, and disabling the colour filter stuff.

if (isnil "RUBE_fnc_init") then {   [] call (compile preprocessFileLineNumbers "RUBE\init.sqf")};
waitUntil{!(isnil "RUBE_fnc_init")};
[] execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};
"bamiyan" call (RUBE_weather getVariable "set-season-model");
[] call (RUBE_weather getVariable "generate-weather");
RUBE_weather setVariable ["enable-color-filter", !(RUBE_weather getVariable "enable-color-filter"), true];
[] call (RUBE_weather getVariable "reset-weather-engine");
[] call (RUBE_weather getVariable "start-weather-engine");

This all seems to work, and I get random weather, a temperature value I can grab using (RUBE_weatherEngine getFSMVariable "_temperature"), and no colour fx.

The only problem is that I always get the following error popping up before the mission starts: Scripts RUBE\modules\weather\seasonmodels\.sqf not found

I can pretty much guarantee I'm doing something wrong. Any clues? Thanks!

Have the same error with the pbo version.

[zapat 56]

Rübe:

#include <\RUBE\core.hpp> shouldn't be #include <RUBE\core.hpp> in description.ext?

The first one CTD for me with core.hpp not found error.

I cannot launch the non-addon version: the mission now loads without errors, but nothing gets a value in the module. Only anys and scalars are in the debughint (using demo).

And is there a way to know the dependencies of the module? lib\core, lib\strings and fn at first blink?

Because loading all the AI and stuff is kinda needless. I'm not sure if I need to care about this, it is not that much anyways, I just like it clean and clear. Me loco too :)

Edited February 24, 2012 by zapat

[rübe 127]

The only problem is that I always get the following error popping up before the mission starts: Scripts RUBE\modules\weather\seasonmodels\.sqf not found

Have the same error with the pbo version.

I'm sorry, but I couldn't reproduce this error. Would any of you mind, uploading the complete mission you have so far? What version of Arma are you running? And are you using a custom world/map? And if so, does it also happen on official maps? (I've just noticed, that my default season model selection script would fail, given an unknown world/map. (will be fixed in next version). But aslong as you manually select a valid season model - which is what you're doing - there shouldn't be any problem at all.)

Oh and: you aren't placing an extra weather module onto the map, are you? Because that code you've got there (runs from init.sqf, right?) will already load a weather module. And some extra code would be needed to handle this situation (see demo script).

And some minor remarks: instead of

RUBE_weather setVariable ["enable-color-filter", !(RUBE_weather getVariable "enable-color-filter"), true];

simply write:

RUBE_weather setVariable ["enable-color-filter", false, true];

That's not only shorter, but also much more clear (and robust). What if I change my mind and disable the color filter by default? Ha. ;)

And second: there is no need to reset the weather-engine before you've even launched it. So this here should be a little bit cleaner (though you're code runs fine too - at least over here):

if (isnil "RUBE_fnc_init") then {   [] call (compile preprocessFileLineNumbers "RUBE\init.sqf")};
waitUntil{!(isnil "RUBE_fnc_init")};

[] execVM "RUBE\modules\weather\init.sqf";
waitUntil{!(isnil "RUBE_weather")};

"bamiyan" call (RUBE_weather getVariable "set-season-model");
[] call (RUBE_weather getVariable "generate-weather");

RUBE_weather setVariable ["enable-color-filter", false, true];
[] call (RUBE_weather getVariable "start-weather-engine"); 

Sorry for this lousy answer. But I really need more information. From your error message I can conclude that "_model" (in season.sqf) ended up as empty string, but I don't really see why and how that could happen.

#include <\RUBE\core.hpp> shouldn't be #include <RUBE\core.hpp> in description.ext?

:o

Damn it! Those shitty includes drive me crazy.

So yeah, you're right of course; I can't use absolute paths for the script-version. I didn't notice that this won't actually work, since I have a RUBE directory (if only as junction) in my Arma2 folder to make file patching work... And aslong as that folder is there, things will of course work at my place - obviously not at yours...

But it turns out, that we're not done yet. Further includes down the road still won't work for the script-only-version, since I can't hop to parent folders while using relative paths. *grrrr F**. S*** ***K*** Z*** **q***!!!!

:mad:

Btw. Vote over here: https://dev-heaven.net/issues/5121.

Well, for now use the addon-version. I'll look into this and see what the best solution is. But that "domination's workaround" mentioned in the ticket above (copying included files all over the place) is nuts and friggin ugly and... ahh it hurts. So I don't really know yet... bäähh :|

And is there a way to know the dependencies of the module? lib\core, lib\strings and fn at first blink?

Yeah, that's already a good start. As for the functions (fn) beeing used, just grep over the modules directory, looking for "RUBE_".

Because loading all the AI and stuff is kinda needless. I'm not sure if I need to care about this, it is not that much anyways, I just like it clean and clear. Me loco too :)

While you certainly do not have to load/compile all that stuff, I wouldn't worry about that (that bit of consumed memory won't hurty anyone). And I certainly wouldn't recommend this; what happens if the next version uses more/other functions and introduces new dependencies? You'd have to manage such changes too all the time, which means managing things twice... but if you don't mind. I won't either.

[zapat 56]

Damn it! Those shitty includes drive me crazy... But it turns out, that we're not done yet.

Yep, this makes two of us. Umm, actually 17 as it seems. :) I hope you can solve it nicely somehow.

I certainly wouldn't recommend this; what happens if the next version uses more/other functions and introduces new dependencies?

Yes, exactly this is why I ask. As far as I see in your directory setup, I'm gonna be okay with lib core, and fn:they are pretty handy too, I've been using some of them already.They have branching dependencies too so I wouldn't tinker with them, and I can live with those being loaded. But I guess I can ditch AI, recepies and bushes, which are pretty good as well, I just don't need them right now.

Have I said thanks for the anwers and all of the stuff? No? Thanks! Yes? Thanks again. :)

Edited February 24, 2012 by zapat

[tpw 2315]

Hi Rube

Thanks for your detailed answers. Here's a bit more info that might help you:

1 - I'm using the PBO version

2 - I have not placed a rube weather logic

3 - The Scripts RUBE\modules\weather\seasonmodels\.sqf not found error only appears when using a custom map.

[darkxess 60]

Hi Rube

Thanks for your detailed answers. Here's a bit more info that might help you:

1 - I'm using the PBO version

2 - I have not placed a rube weather logic

3 - The Scripts RUBE\modules\weather\seasonmodels\.sqf not found error only appears when using a custom map.

Same here, tried the PBO version on Duala and having that smae error, went on to Chernarus and it worked fine.

Other than that, im loving it! thanks :)

[VoodooMTL 12]

So I'm using the addon version, and am trying to figure out how to set up a notebook to display the forecast without using the demo mission.

Did anyone figure out what needs to be in the object init so that it gives me the forecast?

After a lot of trial and error, and consulting the script version files, I've managed to add the action to the notebook, but now I'm getting an error message, and no forecast appears on screen, just the work "any" plastered all over the place.

Again, I'm trying to do WITHOUT running the demo mission, with the game logic modules on the map.

[rübe 127]

Hi guys,

sorry for the long delay and for not having fixed things (script-version, non-official maps, ...) yet.

I hope I'll find some time this weekend or maybe next week or so...

:eek: oohhhh... :p:cool:

Did anyone figure out what needs to be in the object init so that it gives me the forecast?

After a lot of trial and error, and consulting the script version files, I've managed to add the action to the notebook, but now I'm getting an error message, and no forecast appears on screen, just the work "any" plastered all over the place.

You need to run the script /RUBE/modules/weather/dialogs/fn_weatherReport.sqf to attach the forecast report to an object, but you've figured out that by now. So the next important thing to understand ist this: the forecast report is now completely decoupled from the weather-data, which means that you need to create a forecast-data from the weather-data before you can open a forecast report. Guess that's you problem now.

To do this, you need to call RUBE_weatherCreateForecast (see example in demo.sqf) which returns this data. Store this somethere (in a global variable or somewhere else - the idea here is that multiple forecast's of different days can be present at the same time); this is what you need to pass along to the fn_weatherReport.sqf script as "forecast" parameter (again, see demo.sqf for an example, a few lines below the call to RUBE_weatherCreateForecast).

I hope you manage to get this working now with this information. Otherwise just post again and maybe show what you have so far.

tweak on!,

rübe

[VoodooMTL 12]

I still can't get it to work, but to be honest, I'm not very good at all with scripting, so I have a hard time understanding your explanation.

I figure it would help if I posted the code I put in the init. I mostly C&P'd bits from your demo.sqf file.

theWeatherReports set [0, ([(RUBE_weather getVariable "date"),           (RUBE_weather getVariable "forecast")] call RUBE_weatherCreateForecast)     ]; theNotebook setVariable ["RUBE_forecastData", (theWeatherReports select 0), true]; 0 = [["object", theNotebook], ["forecast", (theWeatherReports select 0)],     ["online", true]] execVM "RUBE\modules\weather\dialogs\fn_weatherReport.sqf";

Would you consider adding an actual demo mission for the next release in which the different objects have their own inits that could be used as templates?

EDIT: On an unrelated note, I also find out that the demo mission somehow doesn't react well to planes being on the map, whether empty or piloted by the AI. The weather module will be completely disabled if there's a plane on the map... don't know if it was already a known issue. Helicopters seem to work just fine though. This seems to be limited to the demo mission - when running a map with the game logic modules, the weather works just fine.

Edited March 10, 2012 by Voodoo Operator

[rübe 127]

Sorry for the lousy support and all the lag and delay and stuff... :cool:

But behold, a new version is up:

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

Please tell me if the script-version now really works and all (guess it really should, but you never know...).

Hope I didn't introduce too many new bugs and stuff. haha.

And beware, the "description.ext" file looks a bit different now (new entry for the x-core-IDC!);

current minimal description.ext for the script version:

#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>	
};

Would you consider adding an actual demo mission for the next release in which the different objects have their own inits that could be used as templates?

Here, check this out (place your addon-weather module onto the map and copy the following into your init.sqf or launch (execVM) it from there - the spawn is needed in case you just put it into your init.sqf). And try to understand the code. I hope the comments help somewhat.

[] spawn {
  // wait until we have the weather engine running
  waitUntil{!isnil "RUBE_weather"};
  waitUntil{!isnil "RUBE_weatherEngine"};

  /*
     create the forecast report's data

     - this is decoupled from the forecast report, respectively
       its dialog, s.t. you can have multiple forecast reports
       alive (from different/past days)

     - so if you only need one forecast report, just save it to
       some global and pass it to the dialog.
       If you wanna have multiple forecast reports alive, you 
       need to come up with your own scenario on how you're 
       going to manage them (e.g. for a campaign).
  */
  theForecastReportData = [
     (RUBE_weather getVariable "date"),
     (RUBE_weather getVariable "forecast")
  ] call RUBE_weatherCreateForecast;


  // get position infront of the player
  _pos = player modelToWorld [0, 2, 0];
  _pos set [2, 0];

  /*
     spawn the object (and other stuff) you're going to attach the
     forecast report dialog/action to. In this case we spawn a table
     and a notebook ontop of it, to attach the forecast report to 
     the notebook. But you can just spawn any suitable object and
     take that...
  */
  // returns: [0: table, 1: chair, 2: notebook]
  _itemSetB = [
     ["position", _pos],
     ["direction", ((direction player) + 175)],
     ["table", "FoldTable"],
     ["chair", "FoldChair"],
     ["items", ["Notebook"]],
     ["zerror", 0.2],
     ["enableSimulation", false]
  ] call RUBE_spawnTable;

  {
     player reveal [_x, 4.0];
  } forEach _itemSetB;

  // so (_itemSetB select 2) is our notebook, right?
  theNotebook = (_itemSetB select 2);

  /*
     finally attach the forecast report to the notebook
  */
  [
     ["object", theNotebook],
     ["forecast", theForecastReportData],
     ["online", true]
  ] execVM "RUBE\modules\weather\dialogs\fn_weatherReport.sqf";
};

On an unrelated note, I also find out that the demo mission somehow doesn't react well to planes being on the map, whether empty or piloted by the AI. The weather module will be completely disabled if there's a plane on the map...

oO, really? That sounds too strange to be true.

Can someone else confirm this?

tweak on!,

rübe

Edited March 27, 2012 by ruebe

[_William 0]

Thanks for the season models!

[rübe 127]

Thanks for the season models!

Your welcome. :)

Please let me know if:

• ... these models are any good or if they should be tweaked somehow. I hadn't much time to test them yet. Also it occured to me that I might need to tweak the diurnal fog cycle, as I've been testing thirskw: the days are much shorter up there and I'm not too sure the diurnal fog cycle, as currently implemented, factors this in in a reasonable way... (might need to adapt some control-points of _that_ bézier-curve)
  
• ... if there are any other season models you'd like to see or if some new defaults for other islands should be set.
  It's not too much work to come up with them.
  
• ... oh, and does everything (e.g. the script-version) now work as supposed?
  Does the rpt-file look good and all?
  

tweak on!,

rübe

[tpw 2315]

Gday Ruebe

Thanks for the update, addon version works perfectly now, no errors. Also, thanks muchly for the new season models (specifically the tropical one), which I'm too lazy to come up with myself!

Edit: It keeps working with helicopters on the map, haven't tried any planes.

[Guest]

New version frontpaged on the Armaholic homepage.

RUBE Weather Module - Script v2012-03-27

RUBE Weather Module - Addon v2012-03-27



Arma 2