The wind field
A tornado does not throw air around at random. What buffets a player standing nearby and what tears a block out of the ground come out of the same formula, a modified Rankine vortex, the one that then carries every piece of debris through the sky. The model adds what a textbook leaves out: an inflow that converges toward the axis near the ground, a rising ring at the core wall, a sinking column once the storm turns violent enough to hollow out, and the translation of the whole system, which makes one side of its path far worse than the other. The one special case, the ground itself, where air has nowhere left to go but up, gets its own section at the end of this page.
A formula, not a grid
There is no precomputed grid behind any of this: every tornado works out its wind speed fresh at the exact spot something asks for it, sixty times a second for a player or once for a single block tested by the destruction sweep. Past eight times the core radius the answer comes back as exactly zero, with no residual tail: for the smallest tornado, an EF0 with a six-block core, that means the wind stops dead forty-eight blocks from the axis. That hard cutoff is what lets several active tornadoes add their fields together without either one reaching clear across the map.
Twice the same equation
For a player standing in the grass or a block tested for destruction, these formulas run in Java, on the processor, every single time. For debris, which can number in the hundreds around one tornado, the same equation exists a second time, written as an OpenCL kernel, and the swarm prefers that copy whenever a graphics card is available. Setting useGpu to false sends everything back to the processor for good; setting it to true only asks for another try, with no crash and nothing to restart if no card answers, and no minimum size either: even a handful of debris will still reach for the card if one is there. The server log records which of the two paths ran, and the diagnostic command splits the count in two: so many pieces stepped on the card, the rest on the processor.
Without a compatible card, or with the card switched off, advection falls back to the processor path: a pool of threads sized off a general server setting, defaulting to every core but two. A server with no graphics card loses nothing in correctness, only headroom in how many debris it can carry at once, because it is the same arithmetic on both sides, checked kernel against kernel during development rather than trusted on faith.
Both paths are built to stay right down to the last digit rather than merely close: the kernel refines its own division and square root in double precision, because some cards' drivers only hand those back accurate to eight digits, which is enough to send a vortex drifting apart after a few seconds of flight. A player comparing the same tornado with and without a graphics card should see nothing different, apart from how many pieces the sky can still carry at once.
A radius that follows the wind
The core radius, the one number that scales everything else in the field, tracks how strong the wind is rather than being hand-picked per tornado: six blocks at the floor of the scale, then growth governed by a tunable exponent, radiusGrowthExponent, 1.5 by default. That same radius sets how wide the funnel looks as it forms overhead, covered on the on-screen rendering page.
Vertical motion
The updraft aloft: above the ground, vertical wind traces a rising ring anchored to the core wall, worked out on its own terms rather than as a simple share of the tangential wind. A weak tornado is just one tube rising the whole way up. Past the wind speed of an EF2, a sinking column starts hollowing out the middle, and by the speed of an EF4 it has taken its full shape: the core becomes a hollow ring with a well of falling air down its centre, which is also what breaks it into satellite vortices instead of staying one clean tube. Below EF2 that column does not exist at all. At the crest of the ring, the updraft tops out at: six tenths of the tornado's peak wind, a fixed share, cast into the calculation rather than sitting in a settings file.
The corner flow: right at ground level, air converging toward the axis eventually meets the core wall with nowhere left in front of it, and the only way out is up. It is in that layer, only a fraction of the core radius thick, that vertical wind moves fastest anywhere in the tornado, faster than the very top of the rising ring above it. A model that skipped this corner flow would leave a piece of debris sitting in the grass while the whole funnel passed straight over it.
The special case of the ground
Before any of the rotation even runs, the field carries one number fixed for the whole storm: the height of the cloud deck, cloudBaseAltitude, 183 blocks by default and adjustable in the settings file. That figure is absolute, not measured from the local ground: one altitude for the whole storm, whatever the land does underneath it. Without that choice, a tornado standing on a hill would push its wall cloud straight through the deck the sky is already drawing above it, one of the few mistakes no camera angle can hide.
The column's normal height is measured between the ground and that cloud altitude, but nothing stops a tornado from forming much closer to it than usual. Near a peak within forty-odd blocks of the deck, the room left over can drop under the forty blocks a funnel needs to still read as one: in that case the height stops following the real gap and falls back on that floor instead, even if the cloud base and the top of the column end up overlapping slightly rather than drawing a tornado cut down to nothing.
The wind that pushes an entity and the wind that pulls a block apart do not reach the same distance. An entity stays inside the field out to eight times the core radius, while destruction stops at two point six times that same radius. Between the two, the ground can shake and shove a player without a single block around them moving at all: the destruction range is deliberately the shorter of the two, kept close to the core wall where the wind is actually doing the work.
The sweep that tears blocks out does not walk the whole disc before starting over: once blockBudgetPerTick runs dry for that tick, it stops cold and picks up next tick exactly where it left off, with nothing skipped and nothing repeated. On a young tornado, whose budget dwarfs anything one pass can tear out anyway, this never shows; against a structure far denser than average, the same patch of ground can take several ticks running before it finally gives way completely.
The push itself never goes through any of the game's own knockback machinery: a victim's speed slides toward the wind's own speed through a plain blend rather than one sudden shove. The damage, for its part, borrows two damage types built for the mod instead of reusing an existing one, vortexdread:wind and vortexdread:debris, each with its own death message. A creative or spectating player sits outside the reach of either, at any wind speed.
This whole calculation runs every tick, for every active tornado, against every living entity inside its influence box. Below eight metres a second at the exact spot a target is standing, the wind stops counting as a force at all: it is weather, and nothing gets applied, no velocity and no damage. That floor keeps a stray breeze at the outer edge of the field from ever shaking a player's camera before they have even seen the cloud.
A target already caught in the flow does not get free the moment the wind eases slightly: crossing a lift threshold specific to each victim is what decides whether the wind's vertical pull actually applies, or stays capped at zero, pushing only down or sideways and never up. What that lift then does to a target, damage included, and what a piece of debris does on its own on the way past, is the subject of the debris page. A creative player remains the one unconditional way out, at any speed.
One side effect comes from how the vertical profile is built up by height: the lift is zero right at ground level, establishes itself within the first few percent of the column, then eases slightly again on the approach to the cloud. A ground floor and the top of a tower built under the same tornado therefore do not take the same vertical push: the middle floors get the worst of it, not the ground floor and not the very top.
| Setting | Effect | Default |
|---|---|---|
| turbulence | Amplitude of the curl noise layered onto the clean field, as a fraction of the local wind. At zero, a perfectly smooth field with no striations on the core wall at all; the default already sets that wall boiling. | 0.22 |
| coreRadiusAtEf0 | Core radius of a tornado at the floor of the scale, in blocks. Everything else in the field, from the wall to the influence radius, scales off this one number. | 6 blocks |
| radiusGrowthExponent | How fast the core widens as the wind picks up. A more violent tornado is therefore, on average, both faster and wider. | 1.5 |
| travelSpeed | Translation speed of the whole system across the terrain. Adds onto the rotating wind, which is what makes one side of the path worse than the other. | 8 blocks/s |
| trackWander | How far the tornado's heading can drift from one tick to the next. Set to zero, the track becomes a perfectly straight line, which no real tornado has ever managed. | 1.6 deg/s |
These five settings live in the server's configuration file, alongside the ones that decide a tornado's life and shape rather than its effect on the world, covered on the configuration page. None of it is locked in at the moment a tornado forms: every tick rebuilds the field from whatever turbulence or coreRadiusAtEf0 currently hold, so a tornado already in flight follows any change to these values as soon as it takes effect, without waiting to dissipate first.