Skip to content
Fusion Space
Loft
TipDocs

Documentation

How Loft computes what it shows, where the model is weak, and how its accuracy is measured. The repository is open — the math here is meant to be checked, not trusted.

Limitations log

A candid record of where the model is weak. Admitting this earns more trust than claiming precision — and it's the honest thing to do for a tool people fly on. Entries are dated; the list grows and shrinks as the model changes. If you hit a limitation that isn't here, please add it.

Known limitations (2026-07)

Flight dynamics are 3-DOF, not 6-DOF

The solver integrates translational motion in the vertical plane with thrust and drag along the flight path. It does not model rotation: no weathercocking, no wind-induced angle of attack, no pitch/yaw damping, no coning or rod-whip. Consequences: boost-phase turning into wind is approximate, and wind “drift” during boost is under-modelled. Apogee, max velocity/Mach, rail-exit speed, and descent are the reliable outputs; horizontal drift is dominated by the (well-modelled) descent under canopy.

The visible consequence is that wind speed barely moves the apogee. Wind enters the ascent only through the airspeed the drag is taken at, which a crosswind changes by a fraction of a percent; the altitude a real rocket loses to wind is lost by weathercocking into it, which is rotation and is not integrated. On a corpus design carrying five stored simulations of one airframe at 0, 5, 10, 15 and 20 mph, OpenRocket's own apogees fall 1,602 → 1,549 m (−3.3%) across that range while Loft reads the same 1,634 m at every wind speed. Read Loft's apogee as the still-air figure, and treat a windy day as costing something on top of it.

For the same reason the rail angle is accepted only from 0 to 45° from vertical. Past that the vehicle is being thrown rather than launched: the gravity turn a rotating rocket would fly is not modelled, so the trajectory stops describing the flight — at 120° the solver returned a confident apogee of zero. A what-if outside the range in which it means something is brought back into that range rather than flown.

Drag is the largest error source

The subsonic drag buildup is defensible but simplified: fin pressure drag follows the fins' edge cross-section (square / rounded / airfoil), and both a diameter-increasing transition (shoulder) and a diameter-decreasing one (boattail) now carry their own pressure drag on top of the boattail's base-area effect, and a cone or blunt nose carries its own joint-angle pressure drag (near zero for the streamlined ogive noses most designs use). Fin-junction interference is still lumped into a small flat allowance. Skin friction is now summed surface by surface at each finish's own roughness rather than charging the whole airframe the roughest finish present — the old treatment over-dragged any mixed-finish build, which is most of them. The boundary layer is treated as fully turbulent— the standard rocketry assumption, since it trips near the nose — so there is no laminar run to solve (and no laminar-drag credit for an unusually smooth, slow flight). Base drag is applied in full whether the motor is burning or not — matching OpenRocket's stored per-step drag, which carries the full base drag throughout boost — rather than the blanket thrust-phase discount an earlier model used, which under-dragged a wide body flying a small motor severalfold (the exhaust fills only a little of a large base). Measured against OpenRocket's own “A simple model rocket” example (which stores its per-step drag), Loft reproduces the drag coefficient closely across the whole flight — friction, pressure, and base each within a few percent, boosting and coasting. On that example all five stored simulations now land within a few percent — the three C6 flights within ~0.4%, the B4 at +1.9%, and the low-impulse A8 at +3.6%. Driving this file is itself what caught a motor-data bug: the bundled B4 had been a mis-sourced, over-energetic curve (5.02 N·s — over the 5.0 N·s B-class ceiling), which flew the B4 ~26% high until it was replaced with the NAR-certified 4.30 N·s curve. The shared drag model matches OpenRocket's stored coefficient to within about a percent across all three motors. Across the wider corpus most designs now land within a few percent of OpenRocket, and the residual runs in both directions rather than the consistent over-prediction the earlier base-drag discount used to produce — a transonic design can read a few percent low, where the wave-drag estimate is roughest. The one shape whose residual is one-sided is a very short, wide body — a fineness ratio below about six, more a deliberate base-drag stunt than a typical airframe: its skin-friction form factor reads high, so Loft over-states that friction (about twofold on OpenRocket's own short-wide “base drag hack” example). A slender airframe — the usual case, and the one the corpus above validates — is unaffected. Always compare against your own design's stored OpenRocket numbers on the Validation page.

Transonic and supersonic drag are approximate

Above about Mach 0.8 the drag model leaves its validated envelope. It follows the correct shape— a transonic drag rise to a peak near Mach 1.15, then a supersonic decline — with base drag switching to its supersonic form, rather than the earlier model whose drag grew without bound (badly over-stating drag, and under-stating apogee, for fast flights). The peak now responds to geometry — the nose's fineness and contour (a Von Kármán ogive lowest, a blunt cone highest) and the fins' thickness and leading-edge sweep — so changing a nose or fin for a Mach shot moves the wave drag the right way. But it remains a bounded parametric estimate, not a per-geometry wave-drag solution: there is no shock/CFD model and no shape-specific supersonic pressure distribution, and the drag-rise Mach is fixed rather than derived. Note too that at low supersonic speeds a nose's wave drag is only part of the story — its wetted area and mass matter as much — so the fastest, highest flight isn't always the lowest-wave-drag nose. Any flight above Mach 0.8 is flagged extrapolated; treat apogee and max velocity for fast flights as rough, and expect the largest differences here. The flag follows the number rather than the page: the flight card, the dispersion, both sweeps and the stored-flight cross-check each mark it, and the sweeps mark it per candidate and per point, because a bigger motor or the far end of a swept range is usually what crosses the envelope while the rest of the table stays inside it.

Mass of curved shells is approximated

Nose-cone and transition shell mass (a wall of given thickness) is computed by subtracting an inward-offset inner contour — a good approximation, not an exact offset surface. Their shoulders(the collars that plug into the neighbouring tube) are now massed too — a real several-gram contribution on a small model that used to be dropped — as a tube of the shoulder's own wall plus a bulkhead when it is capped. Still not massed individually: fin fillets and micro-hardware. For designs that rely on an exact figure, prefer an explicit component mass override.

Fin planforms beyond trapezoidal are partly reduced

An elliptical fin's centre of pressure is now computed exactly for its planform — the Barrowman quarter-chord aerodynamic centre integrated over the elliptical chord gives (½ − 2/3π)·croot ≈ 0.288·croot from the root leading edge, which an independent 6-DOF engine (RocketPy) agrees with to within 0.01 caliber of static margin. Its mass CG is likewise exact — a half-ellipse is symmetric about its mid-chord, so its area centroid is 0.5·croot. Its drag now reflects the leading edge's sweep too: the half-ellipse tip sits at mid-root-chord, so the edge sweeps back about half the root chord — previously treated as unswept, which over-counted its stagnation pressure drag by ~22% on a heavily-finned minimum-diameter design (measured against OpenRocket's stored per-step Cd). Only the elliptical fin's normal-force slope still comes from an area- and span-equivalent trapezoid. A freeform fin's centre of pressure is now computed exactly from its actual outline — the Barrowman strip-theory quarter-chord centroid x̄ = ∫(xLE + ¼c)·c dy / ∫c dy over the polygon, which reduces to the trapezoid formula for a trapezoidal outline and to 0.288·croot for an elliptical one — so an odd planform is no longer flattened to an equal-area trapezoid for stability. It is computed at import and is span-scale invariant, so it stays valid when a geometry edit stretches the fin. Still reduced for a freeform fin: its normal-force slope (the equal-area trapezoid) and its mass CG (a mid-planform estimate — no closed-form area centroid for an arbitrary outline).

Two fin-drag inputs are still one number for the whole rocket

A rocket can carry several fin sets that differ — different thicknesses, different sweeps, different edge sections — and the drag buildup does not yet read all three per set. The edge cross-section does, as of August 2026: each set is charged for the section it actually carries, where before the draggiest section present was applied to every set. Two others do not, and on a design with several different sets they belong to no fin on it:

Both belong to no fin on such a design, and both change if the sets are reordered without the rocket changing — they read the last set the file happens to list.

Both are single-set-exact, so the great majority of designs are unaffected. Counted across the 35-design real-design corpus: 20 carry exactly one fin set and 2 carry none, leaving 13 with several — and of those, only 7 mix edge sections between them, while 11 mix thickness ratios and 11 mix leading-edge sweeps. So 28 of 35 are untouched by the per-set cross-section correction, and the two collapses above bite on 11 designs each. Where it bites is precisely the rocket a flyer has just built two different fin sets on, which is why it is being worked rather than left.

Why they are still here, measured three times. Correcting either one has been written, measured against the corpus and reverted — twice before, and again on 2026-08-01, when both were tried together. The reason is worth publishing, because it is not that the per-set treatment is wrong:

A collapsed value is not biased in one direction — it lands wherever the last set read happens to put it, so correcting it adds drag to some designs and removes it from others. It changes twelve of the 35 corpus designs, eight of which carry stored results to compare against, and across those eight it went both ways. The trouble is which designs it removes drag from: the two that move most are ones Loft already flies high, meaning it is giving them too little drag from somewhere else, so taking more away moves them further from the results their own file stores. On Complex.Two-Stage.CDX1, which starts at +4.5% and +12.4% apogee on its two motor configurations, charging each set its own thickness ratio moved the first to +5.0%; adding per-set sweep on top took it to +14.0%, past the ±12% the corpus asserts. The Red Hunter went +4.4% → +5.3% the same way. Across all 97 stored simulations the per-set thickness fix moved no accuracy median toward zero and one away from it (max Mach 1.99% → 2.03%); both together moved optimum delay 2.48% → 2.66%. Those are the figures as measured then (2026-08-02); the experiment has not been re-run and the census has moved twice under it, so read them as that day's comparison rather than against the current table.

So the remaining fin work is blocked on a different question than it looks: the drag those designs are missing has to be found first, and then the per-set corrections land on top of it rather than against it. Charging a fin set for its own geometry is right; doing it while another term is quietly compensating would trade a visible error for an invisible one. The cross-section correction shipped because it was the one of the three that moved these designs not at all.

Design what-ifs address the part you pick — for three kinds of part, not all of them

The Design workspace's what-ifs are a fixed set of fields, and most of them address one component. Pick a fin set, a body tube or a parachute — on the diagram or in the parts list — and the fields that describe that kind of part aim themselves at it: the field reads its starting value from that part, the edit is written to that part, and the panel names which part it is holding. With nothing picked each falls back to the role it always resolved — the frontmost fin set, the longest body tube, the largest canopy — so a design nobody has clicked flies exactly as it did.

Some fields are deliberately wider than one part, and each says so where it sits: surface finish and airframe material apply to the whole tree; body diameter reads the picked tube but scales the entire outer mould line, so the airframe stays faired rather than stepping at one tube; and fin position slides every set together, keeping the design's spacing. A boattail is anchored to the aft-most part of the airframe whatever is picked, because a tail cone part-way up an airframe is not a tail cone — and it fairs to whatever that part presents, which on a design that already ends in a cone is that cone's exit rather than the caliber of the tube above it. The exit field states the resulting ceiling and holds you to it, measured on the airframe you are flying, so a caliber what-if moves the limit with the rocket.

A fin set's root stays on the airframe

The group is what moves. A fin is bonded to the body, so the whole of its root chord has to sit on the stage it is attached to. The fin-position field states that range and holds you to it: a station outside it never reaches the flight while you are typing, and is pulled to the nearest end when you leave the box — the same way every bounded field here behaves. Because the fields slide the sets together, the limit is the tightest set's rather than the one the field is holding: on a design carrying six sets that difference is the whole airframe. A root longer than its stage has no station that fits at all, so it is shortened to the length the stage can carry, with the tip and sweep scaled to keep the fin's shape. A fin's tip may still overhang the tail — that is an ordinary shape, and nine of the corpus's designs are drawn that way — because what is bonded is the root.

Motor cluster count follows the same rule the fin fields do. It reads back off one mount and writes to every mount already holding that count— so its value stays a true statement about each mount it changes. A mount holding a different number is a part this field is not describing, and the field says how many of those the design has rather than rewriting them. It used to apply to every mount regardless: on a design with a centre motor and an air-start pod holding three, the field read 1 and committing any value flattened the pod's cluster to it. One file in the 35-design corpus has that shape. Picking a specific mount, the way a fin set is picked on the diagram, is not yet possible.

It matters for fins because real designs carry several sets and mean two different things by it. Of the 35 in-the-wild files in the corpus, 13 have more than one fin set (and 23 more than one body tube). Usually the sets genuinely differ — OpenRocket's three-stage example puts a 19.1 mm sustainer set beside 108.0 mm booster fins — and editing all of them together would destroy the design. But one file (a payload rocket carrying three 1-fin sets of 55.4 mm at the same station) is a single physical fin ring the file happens to store as three parts, where editing only one would fly an asymmetric rocket. So the fin fields act on the selected set — the frontmost until you pick another —and any set indistinguishable from it, same station and same dimensions, which is the group the panel's own readback describes. Picking a fin set on the diagram or in the parts list aims the fields at it, and the panel names the set it is describing. A design that still has sets outside the selected group says so above the fin fields. Fin position is the deliberate exception: it is a delta, so the whole fin group slides together and the design keeps its spacing.

Body tubes and canopies now work the same way, and the reach is most of the corpus: 23 of the 35 in-the-wild designs carry more than one body tube as Loft imports them, 17 more than one parachute — every dual-deploy design does, by definition — and 13 more than one fin set. Before a part could be picked, every tube but the longest and every canopy but the largest were unreachable: a flyer aiming to shrink a drogue resized the main instead, which moves landing speed and landing energy.

Transitions are addressable too, and authorable. A transition is where an airframe changes caliber; 12 of the 35 corpus designs carry one, 25 in all, and until recently not one could be touched. Picking one aims a length and an exit diameter at it. The exit is absolute and is applied after the whole-airframe caliber scale, so the number in the box is the one being flown even when body diameter is also set. The fore end is the joint with the part in front and is deliberately left alone: moving it would un-fair a joint you did not touch.

The parachute drag coefficient is the least-sourced number in the flight

Ground-hit velocity was the figure Loft agreed with least, and almost none of the gap was the descent model. Measured across the real-design corpus on 2026-08-03, the median disagreement with each file's own stored results was 8.3% over 94 simulations, against 3.1% for apogee at the time — nearly three times the error, on the number an RSO and a waiver actually check. It is now 0.8% over the 80 of those 94 that came down under a canopy and are not repeats of a run already counted, against 2.9% for apogee, and the engine did not change: what changed is that Loft compares its descent rate against the quantity each file actually stored, on the flights that quantity describes. RockSim stores the total speed over the ground, and so does OpenRocket from release 24.12 onward, while earlier OpenRocket files store the air-relative speed — which under an open canopy is the descent rate. See Accuracy for the full account. The coefficient itself is readable, attributed and editable on the design page.

The other 12 came down with nothing out, and they are the honest bad news. One RockSim design in the corpus stores fifteen runs of the same rocket — four with its parachutes out and eleven plugged, hitting the ground at 83–162 m/s — and it marks which is which, per recovery device. Those ballistic runs disagree by 14.9%, the worst figure in the census, and they were being averaged into the canopy number until 2026-08-04. That is not a parachute problem at all: a rocket with nothing out is descending on its airframe's drag at high speed and often at an attitude no 3-DOF solver resolves. The writing tool does not agree with itselfhere: those eleven runs are stored under one name, share every stated input, and their landing speeds fall into two clusters 1.94× apart — four at 83.3–83.7 m/s and seven at 161.6–162.0 — so no single deterministic answer can match both, and part of that 14.9% is the reference's own spread rather than Loft's error. The corpus suite names that group rather than averaging it away, and fails if a second one appears unlisted; for scale, the next-widest same-flight group anywhere in the corpus disagrees with itself by 1.004×. Loft is not the tool to plan a ballistic recovery with, and the number now says so instead of hiding inside a better one.

Where each figure comes from is now written down rather than implied. When a design file states a coefficient, Loft flies the file's. When it does not, five fallbacks apply, and only one of them has a defensible source: an OpenRocket auto coefficient means “use OpenRocket's own default”, so Loft resolves it to 0.8, the figure that tool would itself have flown — which is what 17 of the corpus's 24 OpenRocket canopies do. The other four state plainly that they have no published basis: RockSim exposes no parachute coefficient field at all, so there is nothing to resolve a missing one to, and RASAero II documents its own default as 1.33 where Loft falls back to 0.8.

That RASAero discrepancy is deliberately not corrected yet, and the reason is a measurement rather than a preference: every RASAero recovery device in the corpus states its own coefficient, so the fallback is reached by zero real files and changing it would move no flown number and could be validated against nothing. The airframe's own descent drag — a factor of its frontal area, one to two orders of magnitude smaller than an open canopy's — has no published source either and now says so in one place instead of being typed into three.

Splitting the error by where the coefficient came from

And the coefficient turns out not to be where the error lives.Splitting the corpus by whether each design's coefficient came from its own file or from a Loft fallback gave the same median disagreement to a tenth of a percent — 8.3% either way, across 52 file-stated and 40 fallback flights. That split has been re-measured twice since — against the corrected comparison, and again after the ring-bore fix — and still does not discriminate: 1.3% where the file states a coefficient and 1.0% where Loft supplies one. Two things follow, and both are worth stating plainly rather than leaving as an implied promise to improve:

So making the coefficient visible and editable — which is still owed, and is the one input in the recovery chain a flyer cannot reach — should be expected to improve honesty rather than accuracy. Where the accuracy actually goes is the RockSim question, and it is being worked as that rather than as this.

Static margin is withheld when a motor cannot be resolved

A configuration missing one of its motors gets no static margin — on any surface, including the parameter sweep. A design can carry more than one motor mount, and Loft only ships the thrust curves it ships: a cluster with one designation Loft has no curve for still flies, because the reduced ascent is a meaningful answer and the flight card says which motor is missing. Its static margin is not, because the margin is measured from the loaded centre of gravity and that CG is short a motor's mass — measured on a bundled sample with its motor made unresolvable, the margin reads 5.92 cal against a true 4.07, a 46% error in the reassuring direction. The flight summary has withheld it on that test for some time. Until 2026-08-08 the parameter sweep did not: it plotted and exported a whole curve of the same quantity directly below the cell that was withholding it — measured at 1.10 / 1.29 / 1.49 cal on a two-mount design, values straddling the one-caliber line fins are sized against. Nor did the what-if comparison card, which published the design's margin, the what-if's, and the signed change between them — and which is wrong in a second way the sweep is not: the two flights resolve their motors independently, so a motor swap onto a bundled motor gives a trustworthy current margin against an untrustworthy baseline, and the reported change is then a stability move nobody made. Both surfaces now withhold the figure and say why. The other things they show — apogee, the velocities, the flutter margin — are unaffected, because those are the reduced flight Loft does stand behind. Resolving every motor, by swapping in a bundled one under Design, brings the margin back everywhere at once.

Figures withheld rather than guessed

A flight that never reaches the ground reports no landing figures.The simulation runs to a 1,200 s cap, and a canopy large enough to descend slower than that allows for hits the cap still in the air. The solver carries a ground-hit speed and a landing energy of zero in that case — a sentinel, not a measurement — and those two numbers are exactly what a recovery setup is judged against, so they are now withheld rather than rendered: a flyer enlarging a canopy could otherwise watch the landing energy fall to 0 J and read it as success. The flight says which cap it hit and how to get the figures back.

Drift and the Monte-Carlo recovery radius are withheld on the same test, and were not until 2026-08-02. They are the one landing quantity that did not look like a sentinel. Where the ground-hit speed of an un-landed flight is a zero, its drift is the distance it had covered by the time the cap stopped it — a smaller, entirely plausible number, taken while the rocket was still travelling downwind. Summarised across a dispersion, those partial distances pulled the recovery area DOWN: it was understated, in the unsafe direction, on the figure whose only job is to say how large an area to plan for. Measured on a real design at a recovery size the field itself offers: none of twelve dispersed flights landed, the panel correctly withheld landing speed, and it printed a 58 m median drift and a 121 m recovery radius beside it. Both figures, the landing scatter, and the per-flight rows of the dispersion export now describe the flights that reached the ground and only those; the panel says how many of the set that is.

An open canopy bounds the integrator's step, and that bound has an envelope. A parachute's quadratic drag is stiff, so the explicit RK4 step is only stable while dt·λ stays inside its stability region. Loft shortens the step to hold that, with a floor of 0.2 ms — which covers a response rate λ up to about 13,900/s, i.e. a canopy ten times the design's own opening at roughly 670 m/s. Past that the floor binds before the bound does. No real deployment reaches it; it is recorded because it is the limit of the guard rather than of the physics. Until 2026-08-02 the bound was not applied at all before apogee, so a device opening at or before it integrated at the flat boost step: two real corpus designs returned an apogee of 2.07e13 m and a ground-hit speed of 7.52e32 m/s from recovery sizes inside the field's own range. Both now fly physically, and every design in the corpus is flown at 0.1×, 2×, 5× and 10× on every build to keep it that way.

Steps in the outer mould line

There is no drag term for a bare step in the outer mould line.Loft models a transition's own slope — a shoulder's joint angle, a boattail's — but a step has no length to take an angle over, so nothing charges it. Every flight of a stepped airframe therefore under-counts drag and reads optimistically on apogee and speed. This is not a state the editor invents, and it is not rare: across the corpus, 33 of the 115 airframe joints Loft can judge already step, in 13 of the 35 designs (median 11.75 mm of diameter), and 27 of those steps, in 9 designs, are larger than the 0.5 mm at which a step stops being a rounding artefact of a design stated in inches — those 27 run to a median 12.70 mm and up to 82.55 mm, the largest being a joint between two stages. A flight of any of them now says so and names the step, alongside the parts panel that has always named it for the part you are holding.

Nothing aft of a transition follows its exit diameter.Loft has no mechanism that resizes parts you did not pick, and inventing one would silently re-caliber an airframe from a single field. So narrowing a transition's exit opens a step at the joint behind it — which is the editor-reachable route into the gap above, and why the parts panel says so at the moment you make it.

And the model is discontinuous across that boundary. The shoulder term is charged on any transition with a length, so φ approaches 90° as the length approaches zero and a 1 mm transition is billed almost the full 0.8·ΔA — while the same diameter change with no transition at all is billed nothing. Both ends of that are defensible on their own and they do not meet in the middle. Loft reports the geometry rather than papering over the seam, and closing it properly needs the published step coefficient named below.

What it does not do is put a number on it, and that is deliberate. The obvious estimate is the shoulder model at its own abrupt limit — a joint angle of 90°, which leaves 0.8 × the frontal area the step adds. That 0.8 is Hoerner's measured flat-face value for a body meeting clean air, and a step is an annulus sitting inside the boundary layer of the body ahead of it, so the two are not the same case. Charged as though they were, the corpus moves the wrong way: 02.Two-stage.ork goes from agreeing with its stored apogee to 35.2% low, and Complex.Two-Stage.CDX1 from +4.5% to −20.8%. Rather than publish a correction that large with no source behind it, Loft reports the geometry it cannot charge and leaves the estimate withheld. Fairing the joint with a transition gets a figure the model can stand behind.

Reordering and the drag model

Reordering can put something other than a nose cone at the front, and the drag model has no term for that. Forebody pressure and wave drag are taken from whichever component is a nose cone, wherever it sits in the stack — so an airframe whose leading part is a body tube or a truncated transition is flown as though it were still streamlined. Measured on the demo-quirks sample: nudging the nose one place aft leaves apogee at 1,406.6 m, max velocity at 227.9 m/s and rail exit at 26.0 m/s, every digit unchanged, while only the static margin moves. It is the same shape of gap as the bare step above, and larger: a flat face is the whole forebody drag term missing, not a correction to it. So a flight that leads with a flat face says so, names the diameter, and reports the number as optimistic. None of the 35 corpus designs is in that state as imported — every real design leads with its nose — so this is a shape the editor can reach and a file does not.

Mass objects

Mass objects are addressable too. A point mass — an altimeter, a tracker, nose ballast — is usually the dominant non-structural weight on a design, and 26 of the 35 corpus designs carry one, 56 in all. Picking one aims a weight and a position at it; the position is a station from the nose tip and is clamped to stay inside the part holding it, because a point mass floating outside the airframe would still be flown. With nothing picked the fields hold the heaviest one a flyer could actually state — deliberately skipping the point mass a RASAero import mints to carry a whole stated launch weight, which is the design's own measurement rather than ballast anyone chose.

A mass object can also be slid along the airframe on the diagram, not only typed — it is the one kind whose whole geometry is a station, so it is the one that most needs a grip. The handle is a real slider: focusable, arrow keys nudge it, and the drag is one undo. It is bounded by the part holding it, and the station you ask for is the station that is flown — or, if you ask for one outside that part, the nearest point inside it. Both the field and the grip speak an absolute station from the nose tip, and both are resolved against the airframe as it will actually fly, so a length edit elsewhere cannot move the mass out from under them.

What is still fixed. Nose cones are not addressable, which costs nothing measurable — no corpus design has more than one after import. Nothing can be reordered yet: the other three kinds are placed by choosing an anchor — behind this part, onto this tube — and sized where they landed, because on a stacked airframe a body part's station is the sum of what sits in front of it rather than a free number. Moving one is reordering, and that is the next step for the in-app editor.

Adding and removing parts

Removing a part does work, on any component, and it is undoable: pick a part on the diagram or in the parts list and the panel offers to remove it, naming the part it will take. The removal takes everything mounted inside it — a body tube goes with its motor mount, its fins and its parachute — and drops any motor left without a mount, because a motor pointing at a mount that no longer exists would otherwise be flown with its mass at the nose tip. One structural rule is enforced: the last body tube cannot be removed, and the panel says why instead of producing a rocket with no body and a confident number computed from it. Removing the nose cone or the only motor mount IS allowed, because refusing what is merely unwise would be a go/no-go verdict and Loft does not give those — a design with no propulsion is something it already reports rather than inventing a flight for. One caveat on the nose, since it is the kind of thing that should not be discovered by surprise: Loft has no flat-face drag model, and flies a nose-less vehicle at a moderate fineness-3 ogive's nose drag instead. So a rocket with its nose removed is flown more optimistically than it would really fly. Removing a nose to see the rest of the airframe is fine; reading the apogee off it is not.

Adding a part works too, for six kinds. Pick a body tube and the panel offers to put another body tube behind it, a fin set onto it, a transition behind it, and a mass object, a coupler or a centring ring inside it. Pick anything else and it still answers on all six: the two that go behind reach a nose cone and a transition, which have an aft face to fair to, and the parts that take none of them say which would. The gesture is “another one of these, here” rather than a form: the new part inherits what its neighbour can supply and derives the rest from the design, because a shape nobody drew is worse than one more field. A tube takes its caliber, wall, material and finish from the part it joins. A fin ring is cloned from the design's own set, so it matches the fins already flying — every corpus design carries one and so does the starter, and where a design genuinely has none the control is not offered rather than a shape being invented. A transition reads its exit off the airframe: it fairs to whatever sits behind the anchor, and where nothing does it becomes a tail cone contracting to the median of the real contracting transitions in the corpus. Where a design supplies no answer at all — two sections already at the same caliber — it runs straight through and waits for you to shape it, rather than inventing a step. The editor's fields aim at the new part the moment it exists, so the next number typed changes what you just made; each add is one undo step, named after the kind; and an authored part is removable, exportable and re-importable like any other, because it is the same internal model an imported part lands in. A mass object is the fourth kind and the one whose placement isa station: it mounts inside the part you picked, at 0.3251 of its length — the median of the 16 real mass objects in the corpus placed that way inside a body tube — carrying the corpus's median weight of 45 g until you say otherwise. Unlike a coupler or a centring ring, it has no radius and touches no outer mould line, so what it needs is not a bore but somewhere inside to sit: a nose cone, a body tube, an inner tube, a coupler or a transition — 218 of the 569 parts across the 35-design corpus, which is what puts nose ballast and an av-bay inside the coupler where a flyer actually builds them. Everything else says why not rather than offering: a centring ring, a bulkhead and an engine block are plates 1.3–32 mm thick rather than bays, and a fin set's length is its root chord, a canopy's its packed size, a shock cord's the cord itself — none of them an interior span a station could mean anything inside.

A total that does not move when a part is added

One thing worth knowing before you read a total that did not move: where a design states the weight of a whole assembly or stage outright, Loft counts no mass for the parts inside it — so a part added there, or removed from there, changes the balance and not the total. The design is right and the model is following it; the panels say so, before the click and after it. Across the corpus that covers 22 of the 218 places a mass object can be added — body tube 10, coupler 4, nose cone 3, inner tube 3, transition 2, over four designs. That figure is the one measured directly: 50 g authored into each of the 218 in turn, counting the hosts where the design's dry total does not move. Asking instead whether the whole DESIGN states a lumped weight answers 20, and the two it misses are real — a stage-level override in EscapeVelocity.ork and one inner tube in The Red Hunter.ork — so the question has to be asked of the part, not of the file.

Undo and redo

Every edit is undoable, not only a removal.Undo and redo sit in the design header and name what they will do — “Undo the fin span”, “Undo removing Payload Bay” — and Ctrl/⌘+Z, Shift+Z and Ctrl+Y drive them from the keyboard, except inside a text box, where the shortcut still belongs to the box. One gesture is one undo: a drag of a diagram handle applies its field on every animation frame and a number typed digit by digit applies one per keystroke, and both come back as a single step to where the gesture began. “Reset to as-designed” is a step like any other, so clearing every what-if at once no longer throws the work away irrecoverably. Two limits: the stack holds the last 100 steps, and it does not survive a reload— a resumed session comes back with its edits applied and an empty history, the same as the desktop tools, which do not persist undo across a save either. Picking a part is not an undo step; it aims the fields at another component without changing the rocket. Nor is an entry the field refuses: a value outside a field's range never reaches the flight at all, so there is no impossible state for an undo to return to.

One consequence worth knowing, because it follows from the fields being a fixed set rather than a per-part record: a field holds ONE value at a time, so with a length or span already typed, picking another part of the same kind re-aims that value onto the part you just picked. The panel names the part it is holding, so this is visible rather than silent — but it means picking a tube to read it while an edit is live does change which tube the edit applies to. The fin-flutter fix hint names the worst-margin set, which on a staged design is often not the one the fields are aimed at — across the corpus that hint fires on 60 flights and 16 of them name a set outside the selected group. It says so rather than pointing at a field that would change a different set, and picking that set is a way to act on it.

Tube fins are modelled as ducts, and read ~1 caliber conservative

Tube fins are flown, not skipped. They are treated as what they are — short open cylinders the flow passes through — so they get a duct normal force CNα = 2·ΣN·πri²/Aref at the tube mid-chord, plus friction on both walls and stagnation and base drag on the square-cut wall annulus at each end. Two independent oracles bound the result. On OpenRocket's own tube-fin example the apogee error falls from +88% to −8%, and Loft's centre of pressure lands ≈0.9 caliber forward of the CP OpenRocket stores step by step (0.7 vs 1.6 calibers of margin) — the conservative side, but a real residual, not a rounding difference. On RockSim's tube-fin file the apogee error falls from +87% to −2%, and the duct normal-force slope and mid-chord CP land within 1% and 2.6% of chord of the values that file itself stores for the same set. What is not modelled: tube-to-body and tube-to-tube interference drag, any lift the tubes carry as a ring wing beyond the captured streamtube, and the shielding of the airframe that sits inside them. Ring tails (a single large ring) are still skipped.

Fin flutter is an estimate, not a certification

The fin-flutter speed Loft reports is the simplified NACA TN 4197 closed form (see Methods). It is a preliminary-design figure, method-dependent to roughly ±20% — the fuller method, with a chordwise mass-balance term, tends to sit lower — and it assumes a uniform, isotropic fin of the design's stated material stiffness. A real fin's construction (tip-to-tip lamination, a spar, a bonded-on airfoil, grain direction in wood) changes its stiffness and so its true flutter speed. The shear modulus comes from matching the design's material name to a table, and G10 fibreglass is assumed (and labelled as such) when the material is missing or unrecognised. Loft therefore keeps a recommended margin and cautions when it is thin; it never reports a fin as flutter-safe. Treat it as a reason to add thickness or reduce span, not as a pass/fail. When the margin is thin Loft also names the thickness that would reach the recommended margin (a closed-form inverse of the same estimate, erring a touch thick) — but it inherits the estimate's ±20% method spread and its uniform-isotropic-fin assumption, so it is a starting point for a real structural design, not a substitute for one.

And the stiffness that estimate rests on is now cited — where a citation exists. Flutter speed goes as the square root of the shear modulus, so it is the most leveraged input in the whole calculation, and until 2026-08-02 all fourteen values were uncited “representative engineering figures” sitting under a method that cites its source precisely. Chasing them found they were round US-customary numbers — 3,800 ksi, 89,000 psi, 13,000 psi — inherited from the hobby fin-flutter literature rather than any primary materials document.

Two were wrong.Basswood shipped at 0.17 GPa against the 0.511 GPa the USDA Wood Handbook supports — low by a factor of three — and balsa at 0.09 against 0.138. Both are corrected, derived as EL × 1.10 × GLT/EL from FPL-GTR-282 ch. 5 (the 1.10 is the handbook's own correction for the shear deflection inside a bending test). GLT rather than GLR because a tool cannot know whether the flyer's stock is quarter- or flat-sawn, so Loft takes the lower. Aluminium and titanium now carry MIL-HDBK-5J's own figures (26.2 and 42.75 GPa).

Six still have no published value, and they say so rather than reading like the others.Phenolic, acrylic, polycarbonate, PLA, ABS, acetal and wound cardboard: the manufacturers' datasheets publish tensile and flexural moduli, and shearstrength, but not shear modulus. For cardboard none is likely to exist at all — a wound kraft tube's stiffness is set by winding angle, ply count, adhesive and paper grade, none of which any vendor states. Two more are indefensible as a single number whatever the source: a carbon fin's in-plane modulus spans an order of magnitude with layup (Loft takes a unidirectional-lamina lower bound, 5 GPa), and published G10 figures run 2.9–11.7 GPa (Loft keeps the low end, deliberately, because it is also the fallback for any material it does not recognise).

Every one of those errors ran in the same direction — too little stiffness, so too low a flutter speed, so a margin reported as thinner than it is. That is the right way for a safety estimate to be wrong, and it is still not a number this tool should have been handing out without saying where it came from. A flag that cries wolf teaches flyers to ignore it.

Serial staging is simulated; parallel and strap-on staging isn't

In-line (serial) multi-stage flights are simulated: the booster lights at launch, each stage above air-starts when the one below burns out (plus any ignition delay for a boosted coast), and the spent stage separates on the event the design specifies — at burnout or upper-stage ignition for ordinary staging, or at its own ejection charge for a payload/dual-section rocket that stays whole until near apogee, with the recovery deploying on that separation. That separation event is read per motor configuration: a design can drop its booster at staging on one motor set and hold it to an ejection charge on another, and each config now flies its own way (previously the per-config override was dropped, so a booster could ride a slow sustainer all the way to apogee — a large apogee error). Its structure and empty casing then leave the flight, so mass and drag step down and the sustainer climbs on its own. A separated stage's own descent is only partly modelled: solely the top stage is flown to the ground, so a booster's full trajectory and drift aren't integrated — but a spent lower stage that carries its own recovery now gets a terminal-velocity landing-speed (and landing-energy) estimate (from the mass that leaves at separation and its largest canopy), which raises a caution if that stage comes down firm and a warning if it lands hard enough to risk damage; and one that drops with no recovery is flagged as a ballistic, untracked range hazard rather than silently ignored. Still not modelled: the booster's downrange drift, and an apogee- or altitude-triggered separation, which falls back to the burnout default. Parallel (strap-on) stages and pods are still not simulated; a design that contains them is imported with a visible warning and its OpenRocket-vs-Loft comparison is withheld, since the flown vehicle then differs from what the design's stored results describe. Stability is evaluated for the attached stack and for the sustainer alone after separation (a stage can be stable in the stack yet unstable flying solo), but it is still a static-margin estimate, not a 6-DOF turning solve.

A stage whose motors never light is flown as dead mass, and the flight says so

A stage below the top can fail to fire in three ways: it holds no motor at all, the motor it holds cannot be resolved to a thrust curve, or that motor carries an ignition trigger that never arrives — a never event, or a burnout event on the bottom-most stage, where nothing below it ever burns out. In every case the stage produces no thrust while still adding its mass and drag. Loft flies that vehicle honestly, so the altitude and speeds reported are correct for the rocket as modelled — but that rocket is not the staged flight the design appears to describe, and the flight now names the stage and says so.

What happens to the dead section depends on what is beneath it, and the warning says which. A serial stack parts at one joint and takes everything below that joint with it, so a dead stage sitting under a stage that still burns is dropped at that stage's separation; a dead stage with nothing live below it is carried to apogee. Measured on Loft's own starter design: authoring a booster takes it from 993.642 m to 1,491.464 m with one separation, and deleting that booster's motor mount drops it to 638.973 m with no separation at all — 35.7% below the altitude the design flew before the booster existed. On a two-stage design the same gesture leaves a separation intact, because the stage above the dead one still fires.

This is reachable both by editing and from a file. Adding a booster is refused outright where the stage it would be seeded from carries no motor mount to clone, but that check runs at the moment of adding, and the mount inside an authored booster is an ordinary component the flyer can delete afterwards. A tube with no motor mount can now be given one, which is what lifts that refusal — of the 35 real design files, 24 offer the gesture on their aft tube and one of the two that refuse a booster is unblocked by it. The mount does not arrive empty: an empty one never lights, so Loft puts the design's own motor in it and says so on the panel, because a tube that never had a mount has no motor of its own to prefer. The other refused design stays refused, and correctly — no motor anywhere in it resolves, so there is nothing to put in a mount. Loft cannot yet give one mount a different motor from another; the motor picker is a whole-design what-if, so a design with several mounts flies the same motor in all of them. One of the 35 real design files in the corpus is also in this state as imported — a three-stage design whose bottom stage carries a burnout trigger with nothing below it — which Loft has always flown that way without ever saying so on any surface. That file stores no apogee of its own, so its flight is one of the cases the stored-results comparison has no number to check against. An unpowered top stage is deliberately not flagged: that is a dart, which is an ordinary design, and three of those files are exactly that.

Motor clusters are modelled coaxially

A motor cluster is simulated as its full complement of identical motors — an OpenRocket “4-ring,” for example, flies four motors, with the thrust and propellant of all four counted. They are placed on the centreline rather than at their true radial offsets: for the vertical-plane apogee, velocity, and mass this makes no difference, but the roll/pitch inertia contribution of the offset motors isn't modelled (and rotation isn't solved anyway — see above). Within a single cluster the motors always light together — a staggered ignition or a partial-cluster failure across the identical motors of one mount isn't modelled. (A motor on a separate mount with its own ignition delay is air-started at that delay; see the air-start note below.)

The extra motor tubes are counted only where the design describes them. A cluster held in an inner tube is that many inner tubes, and their structural mass is counted that many times. A cluster held by the airframe tube itself is a different shape: the design gives Loft a count and an overhang but no geometry for the extra tubes, so their structure is not counted at all — there is one airframe however many motors are inside it. That under-counts a real build by the mass of the additional motor tubes and centring rings, which is small and always in the conservative direction for apogee. Loft will not guess it; a design that models those tubes as components has them counted like any other part.

Air-start ignition is timed but not event-triggered

A second motor on its own mount can be timed to air-start after an ignition delay, and Loft honours that delay (read from the flown configuration), so within-stage air-start studies fly with the right timing rather than lighting everything at launch. What is not yet modelled is an air-start keyed to a flight event other than a fixed delay — for example ignition at a target altitude or triggered by an accelerometer. Such a motor is treated as its delay-from-activation, which is exact when the design uses a plain delay and an approximation otherwise.

Saving a design preserves a freeform fin's outline

A freeform (arbitrary polygon) fin is defined only by its outline, and Loft keeps that outline on the design rather than reducing it away on import, so Download .ork writes the real shape back. Measured across 35 real design files: 8 carry a freeform fin set — 9 sets in all — and every one survives a save and re-open with its static margin unchanged to three decimal places.

Until 2026-08-02 the outline was discarded and a trapezoid of equal area was written in its place. Where a planform tapers hard no trapezoid can match the area without shortening the root — which would move the fin along the airframe — so the exported fin came back larger than the one drawn, and the effect landed on static margin, which is a number to act on: 6 of the 8 designs shifted, median 0.08 cal, worst 0.69 cal, and one lost its over-stable warning outright. That is fixed; it is recorded here because a design saved by an older copy of Loft still carries the trapezoid, and no later version can recover a shape that was never written down.

One case still reduces: a fin set with no outline to keep — an elliptical set, or a freeform set read from a design an older Loft saved — is written as the equal-area trapezoid described above, because there is nothing better available to write.

Wind model

Wind is a steady surface value, or an interpolated winds-aloft profile with the live-weather re-run. There is no turbulence, gust, or shear-layer modelling, and no correlation with the (un-modelled) rotational response.

The winds-aloft profile is a forecast for one hour, not an observation: Loft reads the hour matching the live surface reading and states that hour on the Conditions panel. It is a model's view of the air above the pad, so treat a drift figure as an estimate of where the wind is expected to put the rocket rather than where it will. The profile is also fetched once, at the moment you tap — it does not follow the clock while you keep working.

Monte-Carlo dispersion propagates only the inputs you set

The dispersion tool jitters five inputs — motor total impulse, dry mass, aerodynamic drag, rail angle, and wind speed — around their nominal values and flies each sample through the same solver. Dispersing the drag coefficient matters because drag is the single largest error source, so its uncertainty (a scale on the zero-lift Cd, ±10% 1σ by default) belongs in the apogee band; without it the spread reads tighter than the physics warrants. It is still not a full uncertainty budget: thrust-curve shape variation (only the overall scale is varied), centre-of-gravity shift (the dry mass is scaled uniformly, so the CG holds), and ejection-timing scatter are not dispersed, and every sample inherits the model's own systematic errors (a bias the scale can't remove — it widens the band around the nominal, it doesn't re-centre it). Because the flight is 3-DOF with a steady wind and no rotational dynamics, the landing scatter captures the drift response to wind and rail lean but not weathercocking, gust response, or wind-shear turbulence. Read the bands as the spread due to the inputs you dispersed, layered on top of the single-flight limitations — not an absolute confidence interval.

Recovery deployment is idealised

A device deploys on its event and honours its deploy delay — the vehicle free-falls on body drag until the canopy opens — but the canopy is then modelled as opening instantly to its full drag area: there is no inflation transient, no opening-shock load, and no reefing. A motor-ejection deployment fires at the motor's actual ejection charge (burnout plus the design's delay), so a mistimed delay shows up honestly — an early, still-ascending deployment (flagged, since it can zipper or shred), or a late one that opens at speed after a free-fall, or a delay so long the charge would fire after the rocket is already down (flagged as a ballistic descent). The deployment velocity Loft reports is the worst-case speed at canopy open across every device — so on a dual-deploy design it is the main's under-drogue opening speed, not the drogue's near-zero apogee deployment, which is the shock that actually matters (and lets the fast-deployment caution fire on a hard main). The shock force itself is not computed. Where the design states no ejection delay at all, an ejection-triggered device falls back to deploying at apogee; where it states the motor is plugged, nothing opens and the descent is ballistic and flagged, since Loft will not assume an altimeter deployment the design does not describe. The steady descent rate is compared against the ~3–6 m/s most designs aim for, and a firm or hard landing under an undersized canopy is flagged — but that check is on descent rate alone; it doesn't weigh the airframe's mass or fragility, so treat it as a prompt to check your recovery sizing, not a verdict. When a landing is flagged firm or hard, Loft names the canopy drag area (and an equivalent diameter) that would bring it down to a gentle ~5 m/s — a closed-form goal-seek consistent with the flown descent, so a canopy sized that way actually lands at that speed — but the shock force, the airframe's tolerance for it, and the real canopy's drag coefficient are still yours to judge.

Override-subcomponents (resolved for mass)

A component's own mass/CG override is honoured, and OpenRocket's “override mass of all subcomponents” flag is now applied too: when a section states a measured mass for its whole assembly, that figure stands in for the section and everything inside it, so the internals are no longer added on top (the old behaviour double-counted them, inflating dry mass and shifting the CG). This now applies when the override sits on the stage itself, not only on a component — a stage is a component assembly in OpenRocket, and a whole-stage measured weight is the common way a builder records a finished rocket's mass. A stage override lumps the measured mass at the stage's natural centre of gravity (or its override CG), leaving stability intact while the mass reflects the real figure. The lumped mass otherwise sits at the overriding component's CG, matching OpenRocket, and the outermost override wins over any nested one. Still partial: a subcomponents override of CG alone(with no mass override) isn't propagated to the subtree, and the lumped assembly's rotational inertia is a scaled estimate — immaterial to the 3-DOF flight, which uses mass and CG.

Under-specified airframe diameters are inferred

When a design leaves its whole airframe at auto radius with no dimensioned section for the tubes to inherit from — anchored only by, say, a boat-tail end or an internal part — Loft sizes the airframe to the rocket's largest known radius rather than flying it as a zero-diameter needle. That keeps drag, mass, and stability self-consistent, but the inferred diameter is a best guess: an import warning names it, and you should confirm the airframe diameters against the design before trusting apogee or velocity. At the other extreme, an implausibly large diameter — a unit error (millimetres entered as metres) or a corrupt file — is refused outright rather than flown: the enormous reference area would otherwise send the fixed-step solver divergent and report a nonsensical altitude, so Loft stops with a clear message asking you to check the dimensions instead.

Motor database is a curated subset

The bundled database covers a representative set of common motors across classes ¼A–N — the common Estes/Quest/Apogee low-power motors, AeroTech D–N single-use and reload motors, mid-to-high-power Cesaroni, Loki and Animal Motor Works G–N reloads, up to the 98 mm Cesaroni and AeroTech N-class research motors, and a HyperTEK hybrid — but not the entire ThrustCurve.org catalogue (that would bloat the offline bundle). The set is grown by driving real in-the-wild design files and bundling whatever they reference that is missing. Every curve is authentic ThrustCurve.org data, matched to its published certified total impulse. If your motor isn't found, Loft says so rather than guessing; fuzzy matching by class-and-thrust core can, in rare cases, match a same-core motor of a different propellant. That is not hypothetical — a real design calling for an AeroTech F67C fell through to the F67W, a different propellant with 28% less impulse in a shorter casing, and flew 29.6% low against its own stored results until the F67C was bundled. The match quality is always shown, and an approximate one is worth checking. The resolved designation is always shown so you can check it. Genuinely custom or experimental motors — an amateur or research motor with no published certification data — have no curve to bundle, so they stay unresolved rather than being matched to an unrelated maker's motor of the same class. When no motor in a configuration resolves, there is no thrust to fly — Loft withholds the flight results, plots, and OpenRocket comparison entirely and names the motor it couldn't find, rather than showing a misleading zero-altitude “flight.” When a configuration resolves only some of its motors (for example a design with different motors in separate mounts), the flight is simulated on those alone — so its thrust is under-counted and apogee and velocity read low — and a prominent warning says how many motors were missing.

RASAero import is geometry, weight and CG — not RASAero's aerodynamics

RASAero II .CDX1 files import through the same internal model as the other formats, so the flight is computed by Loft's solver, not RASAero's. The adapter covers what a RASAero design is made of — nose cone, body tubes, fin cans, transitions and boattails (including a boattail declared inline on a tube), fin sets with their sweep and airfoil section, launch lugs and rail guides, the launch site, and the two recovery events — and it carries RASAero's own stored apogee, max velocity and time-to-apogee as a cross-check. A fin set mounted on a tapered section is flown too — the aerodynamics take a fin's body radius from the airframe at the fin's own station, so a taper needs no special case, and dropping such a set loses all of its drag and lift, which is much the larger error. What it does not yet cover: a second booster stage (only the stages above it are flown, and the comparison is then withheld because that is a different vehicle) and explicit protuberances.

The first booster flies as its own stage.RASAero states a launch weight and CG for the sustainer and again for the stack with Booster 1 aboard, and the format doesn't say which of the two the Booster 1 pair describes. The file's own geometry settles it: on the corpus's two-stage example — whose booster spans 55.0–62.5 in — reading Booster 1 as the whole stack puts the booster's own centre of gravity at 61.3 in, inside the part and aft where its motor and fins are, while reading it as the booster alone would put it at 43.1 in, a foot forward of where the booster begins. Nothing balances outside itself, so Booster 1 is the stack on the pad; the booster is the difference in weight, balanced at the difference in moments. A file that can't support that reading — no booster weight, a weight at or below the sustainer's, or a derived CG outside the booster — is not flown staged, because a stage with an impossible mass is worse than one Loft says it skipped. The separated booster's own descent isn't tracked; only the sustainer is flown to the ground.

Mass is stated, not computed. A .CDX1 carries no materials and no per-part masses, so Loft flies the launch weight and CG the file states (see Methods). The consequence worth knowing: the mass distribution is a single point, so the airframe's own moment of inertia is not represented. That does not affect the 3-DOF trajectory Loft integrates, but it is a real gap the day rotational dynamics arrive.

Expect disagreement on a fast flight.On the corpus's one single-stage RASAero design — a minimum-diameter N1000W shot — RASAero stores 73,409 ft at Mach 2.32 while the same design in OpenRocket stores 45,636 ft at Mach 2.03: the two established tools differ from each other by about 60%. Loft reads lower again. Every one of those numbers is an extrapolation well past Mach 0.8, where Loft's wave drag is a bounded parametric estimate rather than a solved one, and Loft flags the flight as such. Treat all three as independent estimates that disagree, not as one number with two errors.

RockSim import is a common-subset adapter

RockSim .rkt files import through the same internal model as OpenRocket, so the flight is computed identically. The adapter covers the parts real designs use — nose cones, body and inner tubes, transitions, trapezoidal fin sets, rings and couplers, mass objects, recovery devices, launch lugs — and reads the motor(s) and stored results from each RockSimsimulation. A fin's edge cross-section (RockSim's TipShapeCode— square, rounded, or airfoil) is read too, so a thick rounded or airfoiled fin is no longer over-dragged as a square edge. Tube-fin sets import too; where the file leaves the tube bore at zero — RockSim's usual habit, which also makes it weigh the tubes as solid rods — the wall is taken from the airframe the tubes are cut from and the part is re-weighed to match, rather than flying tubes that mass like rods. A custom fin set imports at its real shape: RockSim writes the planform outline as a point list, and the span, root chord, area, leading-edge sweep and exact strip-theory centre of pressure all come from that outline rather than from the trapezoidal summary fields alongside it, which on a custom shape are RockSim's own approximation and disagree with it. A multi-stage .rkt flies serially, the same way a multi-stage .ork does — RockSim numbers its stages from the sustainer down to the aft booster, which is already the model's nose-to-tail order, so the solver's staging applies unchanged instead of the stack being flown as one lump carrying every stage's mass and drag to apogee. What it does not yet cover: ring tails (flown without them, with a warning) and pods and sub-assemblies (only the primary stack flies). A RockSim design tree doesn't pin a recovery device's deploy event the way OpenRocket does — that lives in the simulation setup — so an imported canopy is deployed by the motor's ejection charge, which is what the delay in a RockSim engine code is for and what the file's own stored results describe. A zero-delay (“-0”) configuration therefore opens the canopy at burnout, still climbing fast, and tops out far below its ballistic apogee: on a real USLI full-scale design that is 359 m against RockSim's own stored 323 m, where deploying at apogee instead read 2,086 m against the same 323 m. A plugged (“-P”) motor — which RockSim writes as a negative ejection delay — carries no charge at all, so the canopy stays packed and the flight is ballistic, with a warning: on those configurations of the same design that is 43.7 s of flight against RockSim's stored 42.6 s, where deploying at apogee instead read 345 s. Loft comes in at 152 m/s against RockSim's 83 m/s because it falls nose-down where RockSim tumbles; both agree nothing opened. What is not read is a RockSim altimeter-triggered or timed deployment set up outside the motor's charge — a plugged motor is very often flown exactly that way, so on such a design the ballistic warning marks what Loft cannot see rather than a certain outcome. Unlike an .ork, a .rkt carries RockSim's own per-part masses; Loft flies those directly (see Methods), so component CG comes from geometry while total mass is exactly as the file states.

Bundled sample designs use estimated stored figures

The bundled example designs (six .ork files, one RockSim .rkt and one RASAero .CDX1) ship with author-estimated stored results, not genuine OpenRocket or RockSim runs (Loft can't generate those here). The bundled “design tool vs Loft” comparison is therefore a demonstration; a real comparison uses your own file. See Validation.

Changing this list

Project rule: any change that adds or alters a calculation updates this log in the same change. When a limitation is fixed, its entry moves to a “resolved” note rather than quietly disappearing.