Developer's Guide

This page contains information on the inner workings of OpenRocket and is meant primarily for developers interested in developing OpenRocket.

In addition to this page, information can be found in the Technical documentation chapter 5.

Obtaining the source code

Source packages for OpenRocket are available in the SourceForge repository.

Alternatively, the most recent development version can be obtained from the SVN repository. It can be retrieved simply using the command

$ svn co https://openrocket.svn.sourceforge.net/svnroot/openrocket/trunk OpenRocket

The above URL may be used to connect to the repository with other Subversion clients as well.

Notes for Newer Eclipse Users

You can get the Galileo version of Eclipse from the Eclipse Download Site. You should either pull Eclipse IDE for Java Developers or Eclipse for RCP/Plug-in Developers. I'm using Eclipse IDE for Java Developers. Neither of these is at the top of the list so be careful to pick the version.

When you create a workspace to load the project in, be sure to go in and set the default JRE and Java compliance to 1.6. Even if you've already set the system default for your computer to use Java 6 and you're running the IDE with Java 6, workspaces will default to Java 5 stuff. You need compliance at 1.6 or you'll get a lot of compile errors - particularly around use of @Override.

If you're getting errors, look at the build path and verify that you see 1.6 in the build path as shown above.

Marking TODO's

Often when writing code you know that something could be done better, but at the moment is either impossible or unreasonable. These are commonly marked with a TODO comment. The following convension is used to mark the importance of different TODO's:

• // TODO: CRITICAL: Some comment
  A bug or something that is not yet implemented, and must be corrected before any release is made. The Ant build script checks for these and prevents building if such a comment is found.
• // TODO: HIGH: Some comment
  An important issue that should be looked into within this or the next major release.
• // TODO: MEDIUM: Some comment
  Something that would make the software better, but does not represent a problem as such.
• // TODO: LOW: Some comment
  Something that would be nice to do better in the future

Units used in OpenRocket

OpenRocket always uses internally pure SI units. For example all rocket dimensions and flight distances are in meters, all masses are in kilograms, density is in kg/m³, temperature is in Kelvin etc. This convension is also used when storing the design in the OpenRocket format.

The only exception to this rule is angles:

• Angles are represented as radians internally, but in the file format they are converted to degrees. This is to make the file format more human-readable and to avoid rounding errors.
• Latitude and longitude of the launch site are represented in degrees both internally and externally.

When displaying measures to the user, the values are converted into the preferred units of the user. This is performed using classes in the package net.sf.openrocket.unit. The Unit class represents a single unit and it includes methods for converting between that unit and SI units in addition to creating a string representation with a suitable amount of decimals. A UnitGroup describes a measurable quantity such as temperature and contains the units available for that quantity, such as Celcius, Fahrenheit and Kelvin.

Rocket design loading and saving

(This section is based on email correspondence)

All file reading/writing is performed in the package net.sf.openrocket.file and subpackages. To implement a new document loader it is necessary to extend the class RocketLoader and implement the abstract method loadFromStream(InputStream). This method simply loads the document and returns an OpenRocketDocument object.

An OpenRocketDocument contains all the information about an opened document, primarily the rocket structure and the simulations. The rocket structure is a simple tree-like structure of RocketComponents. All of the components are in the package .rocketcomponent. A diagram of their hierarchy and a short explanation of each class is available in my thesis section 5.1 (http://openrocket.sourceforge.net/documentation.html)

I've implemented a simple XML reading framework (based on SAX), which simplifies reading by assuming that XML elements can contain only other elements or text content, but not both. Both the OpenRocket and Rocksim format abide with this restriction.

The framework is in the package .file.simplesax. The primary class that will be extended is ElementHandler, which contains three methods. openElement() is called when a new subelement is found, and it returns a new ElementHandler to handle that element (which can be the object itself), or null in order to ignore that element and all of its contents (for example for unknown elements). closeElement() is called when the subelement ends, and endHandler() is called when the element of the current handler ends. The JavaDoc should provide the necessary details.

There are a few ready handlers, the most useful of which will probably be PlainTextHandler. This handler accepts only text content and ignores all subelements. If the XML file contains <element>value</element>, then the handler can return a PlainTextHandler and handle the content within the closeElement() method, removing the need to write a specialized handler for that element.

The XML reading is initiated by calling SimpleSAX.readXML() with the input source and the initial ElementHandler.

The OpenRocket document loading is implemented in .file.openrocket.OpenRocketLoader. Here I've used a bit more boilerplate code to be able to define most of the rocket structure preferences without needing separate handlers for them.

The OpenRocket format (*.ork)

The OpenRocket native format uses the file extension *.ork. It is an XML format, which can optionally be compressed using GZIP. (The extension *.ork.gz is also accepted by the dialogs, though plain .ork is recommended.)

Currently the file format is not documented other than as the reference implementation, and no XML schema exists. This will hopefully change in the future. See #Units used in OpenRocket for details on units.

Every time the XML format changes, the file version number is increased. This version number is not linked to the version of OpenRocket that created the file, but instead describes the file format. Later versions of OpenRocket should attempt to store files in the oldest format that supports all the necessary features. The changes in the format are described in the fileformat.txt file in SVN.