RUBE Weather Module

[zapat]

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?

[ruebe]

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!

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?

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.

[panther42]

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

[zapat]

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?

[ruebe]

Now I can FEEL the time skip.

Ahaha, yeah. That's the spirit!

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.

[tpw]

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]

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]

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

[ruebe]

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?

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***!!!!



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]

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.