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
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:
Generally that's the relative amount (for each/most components) that won't be touched. So the forecast of the next day changes roughly by 7% or something. That change is accomplished most of the time by (linearly) blending single components of weather data. And for this there are several alternatives: a day has at least one link (to the previous or next day) and at max two such links. We'll use these links as sources for our blending process and if there are two sources and stability is low enough, we might even drop the original source altoghether, thus merging the previous with the next day... And we can also produce such a source (for a component) from scratch (as if we would generate a new, average day). Some of this I've called evolution, some mutation... it doesn't matter. What matter's is, that this process generates the desired forecast character - thanks to the forecast stability, and second we'll get a quite natural evolution of weather, with trends that might hold for a while and weather breaks every once in a while.
a small statistical test suite
Now, some of you may have already noticed that I pursue two heavily clashing paradigms: first I began with a declarative seasonal model and next I'm about to model weather in a "meaningful" way, where the single components "pseudo-scientifically" interact with each other... what the...?! I mean, either you work with a good declarative model and that's it, or you go and try to model nature - no matter what some components may average to in the end, as long as it all "makes sense" (with respect to the simulation).
Or in other words: do we really need a season model and what should it actually consist of? Wouldn't latitude and maybe some data about the height and precipition be already enough? Honestly I don't know, and this is up to discussion or simply a question of design.
Anyway, by going that hybrid route (and then that evolution/mutation process - eeek), it became really hard to know whether the generator actually did his job good or if he was just fucking around with me, producing some random output that has nothing to do with the given season model (or only by chance). That's why I've written a small statistical test suite to help me meet the seasonal model's averages and to see how coherent the generated forecast actually is (some stuff really should correlate, other stuff rather not. But mind you, we don't wanna end up with perfect correlations...).
The point is: I highly encourage anyone messing with the generator function (or even while defining a new season model) to make use of that test suite (included in the package somewhere) aswell.
The generated output (you're supposed to study) will end up looking something like this:
Btw. single components may be excluded from the analysis.
the weather engine
At this point we have forecast data consisting of weather-data for n >= 3 days:
------------ -------------- ----------- ----------
| 0: prev. | | 1: current | | 2: next | | 3: ... |
| day | | day | | day | | day |
------------ -------------- ----------- ----------
where the data structure for a single day (currently) looks like this:
0: temperature -> [
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 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.
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.
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 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.
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).
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:
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:
... 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");
// init weather module
_this execVM "RUBE\modules\weather\init.sqf";
// 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:
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";
// 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");
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):
... 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).
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).
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.
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...
(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.)
### First published iteration.
### 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
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
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
### 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
### 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
- 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
### Season Model: added failsafe model (prague) as default for unknown
### 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
- lingor -> arauca
- isladuala -> kano
- tropica -> kano
- thirsk/w -> oulu
- namalsk -> prague
- sbrodj -> prague
- fallujah -> kandahar
ArmA 2: Combined Operations (ArmA 2 & ArmA 2: Operation Arrowhead)