Creating Dynamic Weather in Arma 3

[meatball 25]

@tortu - Yeah, it does somewhat make changes to weather mediocre, but since this is running every 10 minutes, I don't think that's a bad thing. Weather over the short term has a lot more chance to stay the same as opposed to over the long term. Theoretically with the script you could a shift of .15 every 10 minutes and .90 in an hour. Of course, that'll never happen and things will trend to stay closer to the starting weather, but over the long term it can lead to broad changes in weather. I'm certainly open to any better ideas. Maybe Enigma will just revise his A2 dynamicWeather script and we can all just start using that. :)

@gamma - Ran a quick test, and you're right. Setting overcast to .5 will allow you to create rain. They must have changes that. I wish BIS would just publish the 'rules' of weather somewhere.

Edited October 2, 2013 by Meatball

[tortuosit 486]

I was thinking about this: you could keep a record about in which direction the current weather change was going (i.e. if last random value was negative or positive). With a higher probability than 50%, the next change should go into the same direction. This way the probability to reach extreme values increases.

However at the current state ArmA weather is pretty weird. Because the cloud coverage cannot be controlled by script as you already mentioned.

Edited October 2, 2013 by tortuosit

[Von Quest 1163]

Finally had a chance to play a bit with this. Not too much so I hope this is not in haste...

I would recommend to use human-friendly info rather than cold-data for the readout and

forecast. If rain is displaying 0.3, then what? Should be translated into something like

"Current - Light to Moderate Rain". Then maybe "Forecast - Heavy Rain Expected" You can

translate any value into text how you want. And the Wind? Two values? How is that used?

Here's a sneak peak of my similar Sniper Script:

if(windStr >= 0.25 && windStr <= 0.4) then {_windStr = "5-8mph | 8-13kph<br />*leaves and smaller twigs move<br/>";};
if(windDir >= 11.26 && windDir <= 33.75) then {_windDir = "SSW to NNE";};

You can display good text if using:

hint parseText  format [
					"<t align='center' size='2' shadow='true'>SkyWarn<br /></t>
					<t align='center' size='1' shadow='true'>==========================<br /></t>
					<t align='left' size='1' shadow='true'>VELOCITY :...... %1<br /></t>
					<t align='left' size='1' shadow='true'>DIRECTION :......... %2<br /></t>
					<t align='left' size='1' shadow='true'>BEARING :............. %3*<br /><br /></t>",
_windStr,_windDir,_blah,_blah select 2];

Just a snippet of example. Also, when using Random, your script can not do a forecast

since it is NOT known yet. It would be great to get a system that could change randomly

over an hour or two (what's with the 10min?) and we could check-in somehow/somewhere

to see the predicted conditions which may or may not factor into the Mission Execution.

Not sure how. Just some initial thoughts I had so far. I love tinkering with projects like

this that add 'atmosphere' to the hobby. The combat stuff will take care of itself, but

it's scripts like these that add the 'sim' into the simulation. Keep it up! Thanks. ;)

[meatball 25]

Just a snippet of example. Also, when using Random, your script can not do a forecast

since it is NOT known yet. It would be great to get a system that could change randomly

over an hour or two (what's with the 10min?) and we could check-in somehow/somewhere

to see the predicted conditions which may or may not factor into the Mission Execution.

'Random' is relative because the script does know what the forecast is, it just picks a random number first and starts driving the weather towards that. As for the 10 minutes, it is a bit much, but there's two reasons behind it. First, when I wrote the script and was doing cloud updates (before they pulled simulSetHumidity) since the cloud changes would happen instantly, I needed to have weather updates more frequently so the changes were smaller and not so jarring when they happened.

Secondly, and more importantly, the current incarnation of A3 weather doesn't play very well with MP. You could easily set the script to just run new updates (with bigger possible changes) once every hour or two. The problem is, each client is then 'on it's own' to get from the current weather to the forecasted weather, and you could easily see differences in weather across the clients. So say you are at .2 overcast and set it to go to 1 overcast in two hours. Both clients should stay somewhat in synch as to overcast levels, but they may see differences in rain. Once client could see rain at .6, while another doesn't see rain until it hits .8 which totally throws off the immersion for players. The only way around it is to try to force the clients all to a consistent state at a more regular basis.

Of course, I've only been Arma scripting for a few months now, so I could be way off base.

[tortuosit 486]

[snip]

Edited October 5, 2013 by tortuosit

[Von Quest 1163]

Your right. The rain is all wonky in MP. I was coming from the perspective of lets say

for example; you show up at the FOB and receive your Mission for the next few hours.

The File states you have been assigned to assassinate a top Colonel who will be at

Area X for the next hour or so, then intel indicates he's likely to move to Area Y in

hours 3 and 4 with high probability.

With your Weather Script and Forecast, you could then plan and decide IF a long

range sniper shot is viable or not based on where you would want to setup the shot

and plan for the predicted weather conditions moving in.

When I used Random, the forecast for all variables was "any" (unless I set it up wrong).

[meatball 25]

When I used Random, the forecast for all variables was "any" (unless I set it up wrong).

Normally when you see 'any' pop up for the variable that's because it's not defined on that client/machine. Those should all be defined on both clients/servers as the mission starts but maybe the variables are getting called at some point before they're being defined/broadcast. How are you calling those variables?

[meatball 25]

Just a heads up, there is a bug report submitted on this. Go vote it up if you can, maybe we can get it fixed in the engine.

[tortuosit 486]

As for setOvercast not being applied: Maybe we need simulWeatherSync command? Not sure and cannot test currently. Also the setWind(Dir|Force|Str) and setGusts are very interesting, I will use them in my SP version... they work like the other commands and also have the transition time argument... setWindDir has azimuth argument which makes life much easier :) Unfortunately it's all not well documented, e.g. http://community.bistudio.com/wiki/setWindStr is not precise about the value argument.

@Meatball: I have made many changes for my weather SP needs, but I am pretty disappointed it is still useless basically because of setOvercast. Some more information and testing by users from here: http://forums.bistudio.com/showthread.php?152866-Development-branch-discussion&p=2525005&viewfull=1#post2525005 - Looks like the first argument is pretty obsolete and setOvercast does its job, but takes like 30 minutes...

Edited October 4, 2013 by tortuosit

[meatball 25]

You can get around the delay for overcast using skipTime.

skipTime -24;
86400 setOvercast 1;
skipTime 24;

While that will boost overcast up to 1, it unfortunately still has no immediate affect on cloud cover. To me, that's not as big of a deal, as I have that in my script. The only problem I can't get around this point is forcing a set cloud level on mission start based on scripting in any way. You can do it with the intel Overcast slider, which leads me to believe there's a command hiding/function somewhere or not available to us, but you cannot do it with scripting. What really makes things more confusing is if you script a mission to start with full overcast, it'll start with overCast 1, but no clouds. Yet if you exit/save, go back out to the unit selection screen and pick another unit and come back in, you have full overcast and cloud cover.

[Von Quest 1163]

Normally when you see 'any' pop up for the variable that's because it's not defined on that client/machine. Those should all be defined on both clients/servers as the mission starts but maybe the variables are getting called at some point before they're being defined/broadcast. How are you calling those variables?

1. The HINT box that pops up every 10 minutes works fine for the normal weather. But the "forecast" values were always "any". So there was never a forecast. (forecastOvercast,forecastHumidity,forecastRain,forecastFog,forecastWindE,forecastWindN)

2. Also, with the wind, you never addressed the TWO values. I'm confused on how anyone is supposed to use two values.

3. And as for the setup. Most of us don't know what a "params" are. I copied the below exactly into the description.ext file. But, the first line is commented-out though. So can the line still work in a description.ext file? Little confused. What is the 5 for? I just set it to 7 ( // paramsArray[7] ) and then set the default also to 7 ( default = 7; ) for random weather. I'm guessing I'm still setting this up wrong maybe?

    // paramsArray[5]
      class initialWeather {
         title = "Initial Weather";
         values[] = {1,2,3,4,5,6,7};
         texts[] = {"Clear","Overcast","Light Rain","Heavy Rain","Light Fog","Heavy Fog","Random"};
         default = 1;
      }; 

[tortuosit 486]

You can get around the delay for overcast using skipTime.

skipTime -24;
86400 setOvercast 1;
skipTime 24;

Well with this followed by simulWeatherSync followed by the first sleep, I'm able to get the cloud coverage. Sometimes. But also sometimes it's all clear, script runs and does setOvercast somewhere near 1, but I have clear sky. A second run of the script then will have clouds applied. There's so much strange things going on, I am kinda resigning. All the ideas I had do not really work. It seems the first argument in setFog etc. (the transition time) is heavily b0rked as well.

Edited October 5, 2013 by tortuosit

[gammadust 12]

Well with this followed by simulWeatherSync followed by the first sleep, I'm able to get the cloud coverage. Sometimes. But also sometimes it's all clear, script runs and does setOvercast somewhere near 1, but I have clear sky. A second run of the script then will have clouds applied. There's so much strange things going on, I am kinda resigning. All the ideas I had do not really work. It seems the first argument in setFog etc. (the transition time) is heavily b0rked as well.

My script, ArmA does not do what I want :(

//...
  86400 setOvercast forecastOvercast;
  864000 setFog [forecastFog, 0.01, 0];    // from here notice the 864000 > 86400 
  864000 setRain forecastRain;
  864000 setWindStr forecastWindStr;
  864000 setWindForce forecastWindForce; // windforce = [0..forecastOvercast]
  864000 setWindDir forecastWindDir;
//...

one order of magnitude later for those...

[meatball 25]

1. The HINT box that pops up every 10 minutes works fine for the normal weather. But the "forecast" values were always "any". So there was never a forecast. (forecastOvercast,forecastHumidity,forecastRain,forecastFog,forecastWindE,forecastWindN)

I think that's because you've got the parameters configured incorrectly. See my response to your third question below.

2. Also, with the wind, you never addressed the TWO values. I'm confused on how anyone is supposed to use two values.

I define the N/S and E/W winds in the paramsArray select and then run random values off those. You only need one value for N/S and one for E/W because the engine allows you to use positive and negative numbers. For example, a positive forecastWindN will blow to the North, where a negative forecastWindN will blow to the south. Review the setWind biki info for more details.

3. And as for the setup. Most of us don't know what a "params" are. I copied the below exactly into the description.ext file. But, the first line is commented-out though. So can the line still work in a description.ext file? Little confused. What is the 5 for? I just set it to 7 ( // paramsArray[7] ) and then set the default also to 7 ( default = 7; ) for random weather. I'm guessing I'm still setting this up wrong maybe?

That's not how parameters work. I may not be able to explain it well and there's probably better info out there, but in your description.ext file you code in selectable Parameters that the players can select from the unit selection screen. You set up a 'class' called 'Params' that is just an array of values. Each parameter option has values that can be chosen (and a default value) and the chosen value gets places in the Params array. Then you can grab that value for each specific parameter by selecting the correct value out of the 'paramsArray'.

I know, confusing. But in my case, I have 6 selectable parameters in my description.ext. The first parameter's value gets stuck in the array at slot 0, the second parameter gets put in the array at slot 1, etc. My Weather parameter you listed above is actually the sixth parameter in my code block, so I have to select number 5 out of the array to get that value and pump that into the weather code.

If you have no other parameters, that number would be 0 and you'd need the following code block in your description.ext:

class Params
{
// paramsArray[0]
      class initialWeather {
         title = "Initial Weather (Work in Progress - Cloud cover not working correctly on mission start.)";
         values[] = {1,2,3,4,5,6,7};
         texts[] = {"Clear","Overcast","Light Rain","Heavy Rain","Light Fog","Heavy Fog","Random"};
         default = 1;
      }; 
};

Then in the randomWeather.sqf just change the:

initialWeather = (paramsArray select 5);

to

initialWeather = (paramsArray select 0);

That's probably why you had problem number one. randomWeather.sqf was trying to pull information from an array that either didn't exist, or didn't have enough values.

If you don't want the players to have any options and always want the weather to be random, just don't put anything in description.ext and change the randomWeather.sqf to just set the default values to the random ones.

Change this block:

if(isServer) then {
// Make sure the # in the select below matches what # in the order of parameters your initialWeather class is in the description.ext
initialWeather = (paramsArray select 5);  
switch (initialWeather) do{
case 1: {forecastOvercast = 0;forecastRain = 0;forecastFog = 0;forecastWindE = 1;forecastWindN = 1;};			// Clear
case 2: {forecastOvercast = .45;forecastRain = .45;forecastFog = 0;forecastWindE = 2;forecastWindN = 2;};	// Overcast
case 3: {forecastOvercast = .70;forecastRain = .70;forecastFog = .05;forecastWindE = 3;forecastWindN = 3;};	// Light Rain
case 4: {forecastOvercast = 1;forecastRain = 1;forecastFog = .05;forecastWindE = 4;forecastWindN = 4;};		// Heavy Rain
case 5: {forecastOvercast = .75;forecastRain = .10;forecastFog = .30;forecastWindE = 1;forecastWindN = 1;};	// Light Fog
case 6: {forecastOvercast = .85;forecastRain = .20;forecastFog = .50;forecastWindE = 0;forecastWindN = 0;};	// Heavy Fog
case 7: {forecastOvercast = random(1);forecastRain = random(1);forecastFog = random(.20);forecastWindE = (random(14)-7);forecastWindN = (random(14)-7);};	// Random
};

To this:

if(isServer) then {
    forecastOvercast = random(1);
    forecastRain = random(1);
    forecastFog = random(.20);
    forecastWindE = (random(14)-7);
    forecastWindN = (random(14)-7);
};

---------- Post added at 16:34 ---------- Previous post was at 16:26 ----------

There's so much strange things going on, I am kinda resigning. All the ideas I had do not really work. It seems the first argument in setFog etc. (the transition time) is heavily b0rked as well.

Yep, I'm somewhat in the same place as well. At this point I don't think there is any way to fix the cloud coverage issue until BI fixes the problem or changes something with a patch.

Edited October 4, 2013 by Meatball

[gammadust 12]

Let me add something. When messing with the weather in search for parameters triggering the rainbow i noticed that the "manual/auto" setting in the advanced intel dialog appeared to have some influence in the responsiveness of settings. I opted ultimately to do my tests setting them all to "manual".

[tortuosit 486]

one order of magnitude later for those...

OK that was some dirty copy/paste in front of a "0", will have to retry with 86400. The point is the skip +/- 24h before and after that I think. But however, it's all very strange and I stopped testing... I read in another thread the transition always takes its time (looong minutes), so a lot of parameters are just useless. Well, documentation and A3 and weather are at a too early state I think.

BTW, does someone know the possible values of setWindStr? I didn't recognize any change in weather with the wind params setWind(Str|Force|Dir) For Str I assumed 0-10, but maybe its 0-1 like most others...

Edited October 4, 2013 by tortuosit

[gammadust 12]

yes... between (less than 30) and (less than 60) minutes to a requested/setting forecast.

think of it like you can only get the engeine to reach your modified parameter at the following in-game daytimes:

... | 12h00 | 12h30 | 13h00 | 13h30 | 14h00 | ... (spaning a full day each 30 minutes)

ie. changing the weather at 12h17 will result the change to be reached at 12h30.

ie. changing the weather at 13h32 will result the change to be reached at 14h00.

use nextWeatherChange to check how many seconds are left for the actual change to occur, after that the engine randomizes the weather once again.

[tortuosit 486]

think of it like you can only get the engeine to reach your modified parameter at the following in-game daytimes:

... | 12h00 | 12h30 | 13h00 | 13h30 | 14h00 | ... (spaning a full day each 30 minutes)

Thanks. I think weather scripting is completely useless if you are thinking in minutes of gaming time, not in hours/days.

http://community.bistudio.com/wiki/setOvercast

Syntax:

time setOvercast overcast

Parameters:

time: Number. In seconds

overcast: Number. Range 0 to 1

Return Value:

Nothing

Examples

Example 1:

50 setOvercast 0.5

I still don't see the point of the time parameters in all those set[Command] commands. Or will ArmA be able to setOvercast from 0 to 1 in 50 seconds (lets say at 12h)?

OK, a test for "not really appplying" initial weather.

skiptime -24;
  0 setOvercast 1;
  0 setRain 1;
  skipTime 24;
  simulWeatherSync;
  sleep 20;
  simulWeatherSync;
  sleep 654987987987

Before the "sleep 20", this initially brings rain and lightnings, blue sky, that blackish sky at the horizon. After the first sleep, it applies clouds. So the second simulWeatherSync is what makes my wishes apply.

skiptime -24;
  86400 setOvercast 1;
  86400 setRain 1;
  skipTime 24;
  simulWeatherSync;
  sleep 20;
  simulWeatherSync;
  sleep 654987987987

Same as above, but with no rain.

Edited October 5, 2013 by tortuosit

[meatball 25]

Figured out a few things, but still experimenting.

First, @tortu is right and simulWeathSync seems to do the trick and fix the problem with the mission start not having the correct cloud volume to match the overcast level. This block for starting weather seems to have cleared up the issues with that for me.

// Set up starting weather on server and all clients using initial weather values.
waitUntil {!isnil "serverWeather"};
skiptime -24;
86400 setOvercast forecastOvercast;
86400 setFog forecastFog;
86400 setRain forecastRain;
setWind [forecastWindE,forecastWindN,true];
skipTime 24;
simulWeatherSync;

Second, I've figured out that the new weather still has the old restriction that you can't do a setOvercast and a setFog at the same time. Ceeeb's comment from the setOvercast biki still seems to be accurate, "Only one script command induced weather change (either setOvercast or setFog) can be happening at a time. Starting a new weather change will immediately halt the current weather change. SetRain changes are independent and can occur simultaneously to a weather change. "

I know Enigma had that built into his old Dynamic weather script and I'll have to mess around with figuring out a better way to set server weather and push the changes to clients while not doing setOvercast and setFog changes at the same time.

[tortuosit 486]

O-M-G. Thanks for the info... BTW, in your last example, does it rain initially? Because see above last example of mine, with overcast/rain set to 1 it does not rain when I use a 86400 transition...

[gammadust 12]

i made a small video that might help.

in no case in my script have i required (or used) simulWeatherSync, maybe it might be useful to address some observable unsync issues i mention (raining - no cloud coverage | sun light dimmed - no cloud coverage), but i haven't tried.

This is not MP tested, but as far as weather manipulation on client at least the above is achievable. MP would only require centralizing this manipulation (ie on server) and transmitting the settings to clients.

Edited October 6, 2013 by gammadust

[meatball 25]

O-M-G. Thanks for the info... BTW, in your last example, does it rain initially? Because see above last example of mine, with overcast/rain set to 1 it does not rain when I use a 86400 transition...

It does, but it won't start immediately, but it should start raining relatively quickly (depending on your overcast/rain settings)

---------- Post added at 20:28 ---------- Previous post was at 20:17 ----------

in no case in my script have i required (or used) simulWeatherSync, maybe it might be useful to address some observable unsync issues i mention (raining - no cloud coverage | sun light dimmed - no cloud coverage), but i haven't tried.

The only place I've found simulWeatherSync to help is on loading the initial weather/script. And it definitely is required. If you start a mission with the following script:

skiptime -24;86400 setOvercast 1;skipTime 24;

You will get a dark dark sky, little sun, but not a cloud in the sky. As soon as you add the simulWeatherSynch; under the last skiptime the sky starts dark, little sun, and loaded with clouds.

[meatball 25]

Engima might be coming in to save the day. :) Edited October 8, 2013 by Meatball

[tortuosit 486]

Thx for the info, "Engima" btw... :)

[meatball 25]

Doh...heh, mixed that up. Fixed. Thanks @tortu