Repository navigation
ENH: Export Open Rocket Files #270
Description
Flight trajectory simulation is a challenging engineering task. Therefore, we often rely on several different simulators to make sure we did not get anything too wrong.
Furthermore, some university competitions require the submission of a specific format of flight simulation file.
In order to facilitate both of these scenarios, RocketPy should be able to export the current simulation case to an Open Rocket File.
Proposed Milestone
v1.1.0
Activity
Gui-FernandesBR commentedon Apr 17, 2023
Generating .ork files can be quite complex. Reading it is another task, and may be simpler to do.
Therefore I'm moving this issue to another milestone
[-]Export Open Rocket Files[/-][+]ENH: Export Open Rocket Files[/+]ting-hong-shieh commentedon Aug 14, 2026
I reviewed the current OpenRocket implementation to turn this into a smaller first milestone.
For a reproducible compatibility target, I suggest pinning the exporter tests to OpenRocket
release-24.12, commit133b558de556f0282f51c3f53f3b3fc633b4310a. In that release:GeneralRocketSaverwrites a ZIP archive whose main entry isrocket.ork, followed by any decal assets;OpenRocketSaverwrites XML file version 1.10; andGeneralRocketLoaderaccepts ZIP, GZIP, and uncompressed XML input.The OpenRocket source is GPLv3-or-later with an additional packaging permission. Any fixture copied from that repository should retain its source commit and license notice. I would implement the format independently from the documented output and generated fixtures rather than copying saver code into RocketPy.
Proposed first milestone: export only
rocket.orkas UTF-8 XML inside the ZIP container expected by OpenRocket 24.12.The first mapping could cover one rocket/stage, a synthesized body tube, nose cone, trapezoidal or elliptical fins, tail, rail buttons, dry mass/inertia, and one solid motor. Before implementation, one modeling decision needs maintainer agreement: RocketPy does not represent an OpenRocket body-component tree directly, so should the exporter synthesize a single body tube from the Rocket radius and axial component bounds, or require the caller to provide export geometry explicitly?
I recommend explicit export geometry when the body length cannot be derived without ambiguity. That makes lossy output visible at the API boundary.
Tests
Import and broader round-trip support should be separate milestones. If this scope and the explicit-geometry rule are acceptable, I can turn the mapping into a concrete API sketch before opening a draft PR.
Gui-FernandesBR commentedon Aug 14, 2026
We need to reflect on what would be the best architecture of this implementation.
The way I see right now, the RocketSerializer project would be the best place to start with this new feature.