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 notmodel 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.
Drag is the largest error source
The subsonic drag buildup is defensible but simplified: pressure drag on noses and shoulders is approximate, fin interference and surface-protuberance drag are lumped into a small flat allowance, and no boundary-layer transition point is solved. Expect Loft to sit within roughly ±10–25% of a full-fidelity subsonic apogee, and generally to over-predict apogee slightly because its drag is lower than a complete model's. Compare against your own design's stored OpenRocket numbers on the Validation page.
Transonic and supersonic drag are crude
Above about Mach 0.8 the drag model leaves its validated envelope: the transonic drag rise is a coarse multiplier and there is no proper wave-drag model. Any such flight is flagged extrapolated in the results. Treat apogee and max velocity for fast flights as rough.
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. For designs that rely on it, prefer an explicit component mass override. Fin fillets and micro-hardware are not massed individually.
Fin planforms beyond trapezoidal are reduced
Elliptical and freeform fin sets are reduced to an area- and span-equivalent trapezoid for both aerodynamics and mass. Tube fins are not yet modelled.
Single active stage
Multi-stage flights, air-starts, booster separation, parallel (strap-on) stages, and pods are not simulated; only the primary stack flies. These aren't dropped silently — a design that contains them is imported with a visible warning saying so, so you know the flown vehicle isn't the whole design.
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.
Override-subcomponents is partial
A component's own mass/CG override is honoured. The OpenRocket “override subcomponents” flag (which makes an override subsume a subtree) is not fully applied, so a design that relies on it may double-count some mass.
Motor database is a curated subset
The bundled database covers a representative set of common motors, not the entire ThrustCurve.org catalogue (that would bloat the offline bundle). 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. The resolved designation is always shown so you can check it.
Bundled sample designs use estimated stored figures
The two example .orkfiles ship with author-estimated stored results, not genuine OpenRocket runs (Loft can't generate those here). The bundled “OpenRocket 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.