DCS Reference: Introduction to Dynamic Weather

The lack of a proper UI makes dynamic weather one of the more complicated things you can try to edit in DCS, aside from diving head-long into the scripting engine and into Lua in general. It therefore requires a fair amount of pre-existing knowledge and familiarity with not just DCS but with a number of outside tools and processes as well.

In addition, before jumping down this particular hole, the aspiring mission editor needs to understand what the end results of all that work will be, and in particular the limitations that will still exist — there are things that are still better done with static weather, and with a whole lot less fuss and fanfare than trying to replicate them using the dynamic weather system.

Tools and workflow

To create good, deliberate dynamic weather systems, you absolutely need the following:

• A good zip manipulation tool — editing dynamic weather is almost entirely done by directly doing manual edits to the mission definition stored inside a .miz file, and those are simply zip files with a different name. You will need something that lets you seamlessly browse, extract, and add to the file structure of a zip file. Windows' own Explorer only goes half-way since it can only explicitly handle .zip files, not the exact same file with a different extension.
• Notepad++ or a similarly competent text editor. No, not notepad. Ideally, the editor would have zip-browsing functionality built in, but there are some actual advantages to separating the file extraction from the file editing.
• A conversion tool for angles and distances (Windows 10's built-in calculator does this well enough).
• Patience.
• Patience.
• Possibly the CombatFlite package described in its own section.
• Patience.

You need these because the basic flow of weather creation is one of:

• Creating a dummy mission where you place trigger zones as a first approximation of the pressure fronts.
• Extracting the “mission” Lua file from the dummy .miz.
• Opening the mission file in your text editor of choice.
• Copying the trigger zone coordinates (and possibly sizes) to a weather parameters.
• Re-inserting the edited mission file into the .miz.
• Reload the mission.
• Preview, hate actual result.
• Start over.

In particular, the whole use of a dummy mission is an important step because tweaking weather patterns will require a lot of back-and-forth between editor and in-game, a lot of reloading of the mission, and a lot of placing otherwise pointless objects around the map to observe the weather effects in different areas. If this is done in a pre-existing mission, the processes of reloading and entering the mission will add up to a lot of time wasted on waiting, and you will also be manipulating a much more evolved and complex mission file where you risk breaking the entire mission because of a careless edit. Much better to do this in a preview dummy and then importing the weather alone, than ruining all the mission-making hard work that goes into creating a complete mission.

General considerations

While dynamic weather can do a lot of very fancy things that you do not often see in DCS, getting into weather editing comes with a number of caveats and restrictions that one needs to be aware of before starting anything.

Prerequisites

The descriptions on this page assume that you are already familiar with the basics of the DCS mission editor: how to place units and static objects, how to create and manipulate trigger zones, and where to find your personal collection of mission (.miz) files.

Setting up the mission editor display options for weather editing.

There are ample opportunity for confusion with the various references to some “mission” when talking about manual editing of weather. You need to be able to distinguish a “mission file” and the “mission” file because in spite of them both being mission files, they do and contain very different things. As an attempt at clarity, the convention in these reference pages is that:

• The file package you load in DCS, be it in the mission editor or when trying to fly a mission, will be referred to as the .miz file.
• The main file where weather manipulation will happen is simply called “mission” — a Lua file without the usual .lua extension. It is one of many files contained within the .miz file package.

The reader is also expected to already know how to use their zip and text editing tool, and in the case of Notepad++ how to set it to show Lua syntax — this helps in editing the mission file, but since it lacks the regular .lua extension, Notepad++ will not automatically apply the correct syntax highlighting. Similarly, the reader is expected to be familiar enough with the mission editor to change the different map display options and not be completely lost in the process, since weather is most easily edited with almost all map markers except “user objects” turned off.

Limitations

There are three main limitations of the dynamic weather system to be aware of:

• It works using elliptical (anti)cyclonic pressure systems that work best if they are kept to a reasonably small size. Making these systems large will spread out and weaken the effects, but will still display large pressure differences. Trying to get a significant weather effect requires ramping up the pressure difference to combat the weakening and spread, but that will also inherently mean that pressure will vary wildly and create ridiculous winds. Consequently, dynamic weather is far more suited for small (~100nm across) localised effects than something that covers the whole map — if that is what you want, static weather is usually a much better option.
• There is no currently known way of changing cloud layer altitude and thickness. Dynamic weather clouds will develop at roughly 8–10,000' MSL no matter what, which means you cannot really tune it to create, say, low-altitude clouds over Normandy, or high-altitude clouds over the Iranian or Navada highlands. The weather parameter names tease the ability to set a pressure system y-value to go along with the x- and z-axes, and while adding such a parameter does not crash anything, it also does not seem to have any effect whatsoever. Similarly, there is seemingly no way to directly control different wind layers with dynamic weather the way you can with the static model — you cannot set up separate surface, low- and high altitude wind velocities.
• The UI for editing dynamic weather is not only almost completely lacking, but the editor preview of the effects is not very detailed, nor entirely accurate. Actual in-game wind directions and strengths will often be off by a few degrees from what the preview suggests, and will only show with roughly 125km resolution — wind shifts can happen on much smaller scales than this and will not show up in the editor. Unfortunately, this is at odds with how dynamic weather is more suited for smaller pressure systems, as mentioned above. When manipulating a lot of smaller pressure zones, it can often be difficult to see the exact flow of the air currents in and around these areas. Only through testing and observation of in-game smoke effects and windsocks can the actual winds be determined. Hence the need for all that patience while the weather setup is being tested.

Something that may look like a limitation is the inability to set QNH (sea-level pressure). This is actually fully intentional as dynamic weather always uses standard atmospheric pressure (1013.25 hPa / 760mmHg / 29.92 inHg) as its baseline, and local and regional deviations in QNH are a result of the pressure fronts that form the basis of the dynamic weather system.

Units

One of the more annoying and initially confusing things about editing weather in DCS is that different units are used for different parts of the UI, and you will need to know what units are used where to get the results you want. This is doubly true since the best method of manipulating weather is by using trigger zones as stand-in objects, which themselves cannot quite decide what units to use.

The different units used in the trigger zone panels.

The long and short of it is this:

• The trigger zone editing panel uses feet to denote its radius.
• The trigger zone list shows the radius in meters.
• The trigger definitions in the mission file describe their radii in meters.
• There is no way to directly see the size of pressure zones other than using the RClick measure tool, which gives distances in nautical miles and angles in degrees.
• Pressure zone definitions in the mission file describe their radii in meters.
• Pressure zone ellipticity is expressed is a simple width-to-height ratio multiplier.
• Pressure zone rotations are expressed in radians (from -π to +π).
• Trigger and pressure zone coordinates in the mission file are expressed in meters.
• Map coordinates an be changed to display in X/Y meters by pressing LAltY to cycle through the various coordinate modes.
• Pressure zone excess is measured in the difference in Pascal from standard atmospheric pressure (101,325 Pa).
  • Note that most metric altimeters measure in hectopascals — i.e. hundreds of Pa — so a -100 Pa pressure excess equates to -1.00 on the altimeter.
  • Likewise, ±100 Pa = ±0.75mmHg = ±0.03 inHg for Russian and imperial altimeters.

For the most part, there is no need to worry about the coordinate display since copy-pasting them from trigger zones is the easiest way to precisely position pressure zones, and the mission editor already displays those positions readily enough.

Performance and bugs

Historically, there has been a lot of discussion of the performance impact of dynamic weather, especially in relation to the much simpler static weather alternative. Intuitively, static weather should be much easier to calculate, whereas dynamic weather requires constant checking against the weather parameters to figure out the local weather — exponentially so when multiple pressure fronts are used. This latter assumption in particular would be a strong argument against using multiple pressure systems to compensate for the previously mentioned issue with using dynamic weather mechanics over large areas.

However, player testing suggests that dynamic weather actually creates lesser performance issues than static weather, although this may simply be a matter of local graphical rendering of that weather than the weather simulation underneath. The jury is still out on the actual effects and (potential) performance impacts of the two methods, but the testing that has been done at least shows that intuition might not give the right answer.

Finally, there are numerous reports of syncing bugs in multiplayer (and some issues that even appear in SP maps). Most notably, cloud position is only something that happens client-side — an effect that equally holds true for static weather — so hiding from other players (and definitely from omniscient AI) underneath a cloud is far from guaranteed to work. The cloud might simply not be there on the other guy's screen.

In addition, there are noticeable “spin-up” required before the weather effects fully kick in. This can be seen to some extent in single-player, where rain and snow might be whirling around at huge speeds, suggesting wind strengths and directions that are completely at odds with what smoke effects in the same area would show. This effect will usually settle down after a little while, and smoke and precipitation will agree on the local wind conditions after a minute or thereabouts. This simulation spin-up is most likely also the cause of reports where multiplayer weather outright does not show up for some player, especially when cycling through external views: they have presumably missed (or not fully waited for) the weather sim spin-up for their location, and therefore get nothing, at least visually.