OpenRocket wiki - User contributions [en]

Main Page

2020-09-27T11:59:26Z

Plaa: Update home page url

Feature comparison

2016-06-07T18:17:10Z

Plaa:

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|-
! Anti-piracy copy protection
| class="good" | None
| class="okay" | [http://www.paceap.com/ PACE]
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="good" | Yes
| class="good" | Yes
|-
! Photorealistic 3D rendering
| class="good" | Yes
| class="bad" | No
|-
! Export 3D design
| class="bad" | No
| class="good" | Yes (3DS)
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="good" | Experimental
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! Fins attached to fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="good" | Yes
| class="good" | Yes
|-
! Decals
| class="good" | Yes
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|-
! Computing custom variables
| class="good" | Yes
| class="bad" | No
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

== Usage ==

One attribute of interest when comparing pieces of software is how much each software is used and how much of a community exists around the software. While it's impossible to get an objective measure of the usage and community activity, [http://www.google.com/trends/ Google Trends] does a rather good job at providing an indication of the relative interest levels over time.

Since around 2014, OpenRocket and RockSim have received approximately the same amount of search hits. The first version of OpenRocket was released in May 2009, RockSim in 1997.

<trends q="RockSim,OpenRocket" date="1/2009 96m" cmpt="q" content="1" cid="TIMESERIES_GRAPH_0" export="5" w="700" h="330"/>

Feature comparison

2016-06-07T18:15:43Z

Plaa:

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|-
! Anti-piracy copy protection
| class="good" | None
| class="okay" | [http://www.paceap.com/ PACE]
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="good" | Yes
| class="good" | Yes
|-
! Photorealistic 3D rendering
| class="good" | Yes
| class="bad" | No
|-
! Export 3D design
| class="bad" | No
| class="good" | Yes (3DS)
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="good" | Experimental
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! Fins attached to fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="good" | Yes
| class="good" | Yes
|-
! Decals
| class="good" | Yes
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|-
! Computing custom variables
| class="good" | Yes
| class="bad" | No
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

== Usage ==

One attribute of interest when comparing pieces of software is how much each software is used and how much of a community exists around the software. While it's impossible to get an objective measure of the usage and community activity, [http://www.google.com/trends/ Google Trends] does a rather good job at providing an indication of the relative interest levels over time.

Since around 2014, OpenRocket and RockSim have received approximately the same amount of search hits. The first version of OpenRocket was released in May 2009, RockSim in 1997.

<trends q="RockSim,OpenRocket" date="1/2009 102m" cmpt="q" content="1" cid="TIMESERIES_GRAPH_0" export="5" w="700" h="330"/>

Feature comparison

2015-02-13T18:53:47Z

Plaa: Update trends section

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|-
! Anti-piracy copy protection
| class="good" | None
| class="okay" | [http://www.paceap.com/ PACE]
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="good" | Yes
| class="good" | Yes
|-
! Photorealistic 3D rendering
| class="good" | Yes
| class="bad" | No
|-
! Export 3D design
| class="bad" | No
| class="good" | Yes (3DS)
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! Fins attached to fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="good" | Yes
| class="good" | Yes
|-
! Decals
| class="good" | Yes
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|-
! Computing custom variables
| class="good" | Yes
| class="bad" | No
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

== Usage ==

One attribute of interest when comparing pieces of software is how much each software is used and how much of a community exists around the software. While it's impossible to get an objective measure of the usage and community activity, [http://www.google.com/trends/ Google Trends] does a rather good job at providing an indication of the relative interest levels over time.

As of 2014, OpenRocket and RockSim receive approximately the same amount of search hits. The first version of OpenRocket was released in May 2009, RockSim in 1997.

<trends q="RockSim,OpenRocket" date="1/2009 84m" cmpt="q" content="1" cid="TIMESERIES_GRAPH_0" export="5" w="700" h="330"/>

Extending OpenRocket

2015-01-13T15:37:36Z

Plaa:

OpenRocket is built to be extensible using plugins. You can implement your own functionality or download plugins implemented by others.

This document describes how to implement your own extensions to OpenRocket.

== Plugins ==

Extensions to OpenRocket are implemented as plugins. All interfaces that may have multiple implementations should be implemented using plugin interfaces internally. That way, external plugins may create new implementations.

A plugin is compiled into a JAR file and placed into the OpenRocket plugin directory. These JAR files are included in the OpenRocket classpath at startup and scanned for classes and interfaces annotated with <code>@Plugin</code>.

* A '''plugin interface''' is a Java interface that is annotated with the <code>@Plugin</code> annotation. These interfaces are scanned from the classpath at startup and can be queried by the code.
* A '''plugin implementation''' is a Java class that implements a plugin interface and is annotated with the <code>@Plugin</code> annotation.

In practise the plugin interfaces are defined by the internal OpenRocket code, and are extension points which internal and external plugins can implement.

'''Note:''' Many of the internal interfaces have not yet been changed to use the plugin interface. They will be migrated one by one. Help is appreciated.

== Simulation extensions ==

Simulation extensions allow modifying simulations before or during a simulation. They allow controlling almost every aspect of a simulation.

A simulation extensions typically consists of 2-4 Java classes described below. '''The recommended way of implementing these interfaces is by extending the abstract classes'''. This allows maximum compatibility with future versions of OpenRocket when new methods are added to the interfaces.

{| class="wikitable"
|-
!
! Interface / abstract class
! Description
|-
! Simulation extension
| ''<code>SimulationExtension</code>'' <code>AbstractSimulationExtension</code>
| Contains the extension configuration for a single simulation and a method that is called whenever the simulation is started. A new instance is created for each simulation that has the extension defined.
|-
! Simulation extension ''provider''
| ''<code>SimulationExtensionProvider</code>'' <code>AbstractSimulationExtensionProvider</code>
| An OpenRocket plugin that functions as a factory class for the simulation extension. It provides the extension ID, location in the UI menu and instances of the extension.
|-
! Simulation extension ''configurator''
| <code>SwingSimulationExtensionConfigurator</code> <code>AbstractSwingSimulationExtensionConfigurator</code>
| An (optional) OpenRocket plugin that provides a GUI for configuring the simulation extension.
|-
! Simulation ''listener''
| ''<code>SimulationListener</code> <code>SimulationComputationListener</code> <code>SimulationEventListener</code>'' <code>AbstractSimulationListener</code>
| A listener that can be attached to a simulation at runtime. The listener is notified of all actions during the simulation and it can modify and affect the simulation while it is being run. The simulation extension may add a simulation listener to the simulation run when it is started.
|-
|}

=== Simulation extension class ===

An instance of the simulation extension class is attached to each simulation that has the extension defined. It contains the configuration of the extension and a method that is called when the simulation is run.

You need to extend <code>AbstractSimulationExtension</code> and implement at least the <code>initialize</code> method. This method is called whenever a simulation run is started. It can modify the <code>SimulationConditions</code>, which contains the launch conditions of the simulation. It can also attach simulation listeners to the simulation, which allows interacting with the simulation while it is running.

=== Simulation extension provider ===

The provider is a factory class that creates instances of the simulation extension. It also provides an ID string identifying the simulation extension and the name and menu location of the extension.

When using <code>AbstractSimulationExtensionProvider</code> you only need to provide the constructor the simulation extension class and the name and menu location.

A single simulation extension provider can be used to provide multiple simulation extensions. For example, the provider could scan a directory for scripts and provide a simulation extension for each script file. The abstract class assumes you are only providing a single simulation extension.

=== Simulation extension configurator ===

The separate configurator provides a Swing GUI dialog to configure a single instance of a simulation extension. It is implemented as a separate plugin so that the plugin itself can be used also on platforms not supporting Swing (such as Android).

<code>SwingSimulationExtensionConfigurator</code> provides a ready framework where you only need to implement the <code>getConfigurationComponent</code> method, where you add the necessary components to a ready <code>JPanel</code>.

== Simulation listeners ==

'''Simulation listeners''' are pieces of custom code that are run during a simulation run. They can either be implemented in Java, or in a scripting language of your choise by adding the Simulation extension in ''User code'' -> ''Scripts''.

In Java, the recommended way of implementing a simulation listener is by extending the <code>AbstractSimulationListener</code> class and overriding the desired methods.

In scripts, you only need to implement the methods you need.

The methods, their arguments and return values are listed below. For scripting languages, replace with the corresponding object (for example in Ruby return <code>nil</code> instead of <code>null</code>). In many scripting languages, returning nothing or an undefined value will have the same effect as returning <code>null</code>. The methods may also throw exceptions to abort the simulation.

{| class="wikitable"
|-
! Method signature
! Description
|-
|
void '''startSimulation'''(SimulationStatus status) 
void '''endSimulation'''(SimulationStatus status, SimulationException exception)
| Called when starting and ending a simulation. The <code>endSimulation</code> method is provided the exception if the simulation is aborted by one.
|-
|
boolean '''preStep'''(SimulationStatus status) 
void '''postStep'''(SimulationStatus status)
| Called before and after taking a simulation step. The <code>preStep</code> method can prevent taking the step by returning <code>false</code>.
|-
|
AccelerationData '''preAccelerationCalculation'''(SimulationStatus status) 
AccelerationData postAccelerationCalculation(SimulationStatus status, AccelerationData acceleration)
| Called before and after computing acceleration of the
|}

Extending OpenRocket

2015-01-09T22:17:42Z

Plaa: Start documenting simulation listeners

OpenRocket is built to be extensible using plugins. You can implement your own functionality or download plugins implemented by others.

This document describes how to implement your own extensions to OpenRocket.

== Plugins ==

Extensions to OpenRocket are implemented as plugins. All interfaces that may have multiple implementations should be implemented using plugin interfaces internally. That way, external plugins may create new implementations.

A plugin is compiled into a JAR file and placed into the OpenRocket plugin directory. These JAR files are included in the OpenRocket classpath at startup and scanned for classes and interfaces annotated with <code>@Plugin</code>.

* A '''plugin interface''' is a Java interface that is annotated with the <code>@Plugin</code> annotation. These interfaces are scanned from the classpath at startup and can be queried by the code.
* A '''plugin implementation''' is a Java class that implements a plugin interface and is annotated with the <code>@Plugin</code> annotation.

In practise the plugin interfaces are defined by the internal OpenRocket code, and are extension points which internal and external plugins can implement.

'''Note:''' Many of the internal interfaces have not yet been changed to use the plugin interface. They will be migrated one by one. Help is appreciated.

== Simulation extensions ==

Simulation extensions allow modifying simulations before or during a simulation. They allow controlling almost every aspect of a simulation.

A simulation extensions typically consists of 2-4 Java classes described below. '''The recommended way of implementing these interfaces is by extending the abstract classes'''. This allows maximum compatibility with future versions of OpenRocket when new methods are added to the interfaces.

{| class="wikitable"
|-
!
! Interface / abstract class
! Description
|-
! Simulation extension
| ''<code>SimulationExtension</code>'' <code>AbstractSimulationExtension</code>
| Contains the extension configuration for a single simulation and a method that is called whenever the simulation is started. A new instance is created for each simulation that has the extension defined.
|-
! Simulation extension ''provider''
| ''<code>SimulationExtensionProvider</code>'' <code>AbstractSimulationExtensionProvider</code>
| An OpenRocket plugin that functions as a factory class for the simulation extension. It provides the extension ID, location in the UI menu and instances of the extension.
|-
! Simulation extension ''configurator''
| <code>SwingSimulationExtensionConfigurator</code> <code>AbstractSwingSimulationExtensionConfigurator</code>
| An (optional) OpenRocket plugin that provides a GUI for configuring the simulation extension.
|-
! Simulation ''listener''
| ''<code>SimulationListener</code> <code>SimulationComputationListener</code> <code>SimulationEventListener</code>'' <code>AbstractSimulationListener</code>
| A listener that can be attached to a simulation at runtime. The listener is notified of all actions during the simulation and it can modify and affect the simulation while it is being run. The simulation extension may add a simulation listener to the simulation run when it is started.
|-
|}

=== Simulation extension class ===

An instance of the simulation extension class is attached to each simulation that has the extension defined. It contains the configuration of the extension and a method that is called when the simulation is run.

You need to extend <code>AbstractSimulationExtension</code> and implement at least the <code>initialize</code> method. This method is called whenever a simulation run is started. It can modify the <code>SimulationConditions</code>, which contains the launch conditions of the simulation. It can also attach simulation listeners to the simulation, which allows interacting with the simulation while it is running.

=== Simulation extension provider ===

The provider is a factory class that creates instances of the simulation extension. It also provides an ID string identifying the simulation extension and the name and menu location of the extension.

When using <code>AbstractSimulationExtensionProvider</code> you only need to provide the constructor the simulation extension class and the name and menu location.

A single simulation extension provider can be used to provide multiple simulation extensions. For example, the provider could scan a directory for scripts and provide a simulation extension for each script file. The abstract class assumes you are only providing a single simulation extension.

=== Simulation extension configurator ===

The separate configurator provides a Swing GUI dialog to configure a single instance of a simulation extension. It is implemented as a separate plugin so that the plugin itself can be used also on platforms not supporting Swing (such as Android).

<code>SwingSimulationExtensionConfigurator</code> provides a ready framework where you only need to implement the <code>getConfigurationComponent</code> method, where you add the necessary components to a ready <code>JPanel</code>.

== Simulation listeners ==

'''Simulation listeners''' are pieces of custom code that are run during a simulation run. They can either be implemented in Java, or in a scripting language of your choise by adding the Simulation extension in ''User code'' -> ''Scripts''.

In Java, the recommended way of implementing a simulation listener is by extending the <code>AbstractSimulationListener</code> class and overriding the desired methods.

In scripts, you only need to implement the methods you need.

The methods, their arguments and return values are listed below. For scripting languages, replace with the corresponding object (for example in Ruby return <code>nil</code> instead of <code>null</code>). In many scripting languages, returning nothing or an undefined value will have the same effect as returning <code>null</code>. The methods may also throw exceptions to abort the simulation.

{| class="wikitable"
|-
! Method signature
! Description
|-
! void startSimulation(SimulationStatus status)
| Called when starting a simulation.
|-
|}

Extending OpenRocket

2014-12-26T23:00:18Z

Plaa:

Extending OpenRocket

2014-12-26T22:21:05Z

Plaa:

Extending OpenRocket

2014-12-26T19:30:23Z

Plaa:

Extending OpenRocket

2014-12-25T21:11:47Z

Plaa:

Extending OpenRocket

2014-12-25T21:08:59Z

Plaa:

== Extending OpenRocket ==

OpenRocket is built to be extensible using plugins. You can implement your own functionality or download plugins implemented by others.

This document describes how to implement your own extensions to OpenRocket.

=== Plugins ===

Extensions to OpenRocket are implemented as plugins. All interfaces that may have multiple implementations should be implemented using plugin interfaces internally. That way, external plugins may create new implementations.

A plugin is compiled into a JAR file and placed into the OpenRocket plugin directory. These JAR files are included in the OpenRocket classpath at startup and scanned for classes and interfaces annotated with <code>@Plugin</code>.

* A '''plugin interface''' is a Java interface that is annotated with the <code>@Plugin</code> annotation. These interfaces are scanned from the classpath at startup and can be queried by the code.
* A '''plugin implementation''' is a Java class that implements a plugin interface and is annotated with the <code>@Plugin</code> annotation.

In practise the plugin interfaces are defined by the internal OpenRocket code, and are extension points which internal and external plugins can implement.

'''Note:''' Many of the internal interfaces have not yet been changed to use the plugin interface. They will be migrated one by one. Help is appreciated.

=== Simulation extensions ===

Simulation extensions allow modifying simulations before or during a simulation. They allow controlling almost every aspect of a simulation.

A simulation extensions typically consists of 2-4 Java classes:

{| class="wikitable"
|-
!
! Interface / abstract class
! Description
|-
! Simulation extension
| ''<code>SimulationExtension</code>'' <code>AbstractSimulationExtension</code>
| Contains the extension configuration for a single simulation and a method that is called whenever the simulation is started. A new instance is created for each simulation that has the extension defined.
|-
! Simulation extension ''provider''
| ''<code>SimulationExtensionProvider</code>'' <code>AbstractSimulationExtensionProvider</code>
| An OpenRocket plugin that functions as a factory class for the simulation extension. It provides the extension ID, location in the UI menu and instances of the extension.
|-
! Simulation extension ''configurator''
| <code>SwingSimulationExtensionConfigurator</code> <code>AbstractSwingSimulationExtensionConfigurator</code>
| An (optional) OpenRocket plugin that provides a GUI for configuring the simulation extension.
|-
! Simulation ''listener''
| ''<code>SimulationListener</code> <code>SimulationComputationListener</code> <code>SimulationEventListener</code>'' <code>AbstractSimulationListener</code>
| A listener that can be attached to a simulation at runtime. The listener is notified of all actions during the simulation and it can modify and affect the simulation while it is being run. The simulation extension may add a simulation listener to the simulation run when it is started.
|-
|}

'''The recommended way of implementing these interfaces is by extending the abstract classes'''. This allows maximum compatibility with future versions of OpenRocket when new methods are added to the interfaces.

Extending OpenRocket

2014-12-25T20:47:28Z

Plaa:

== Extending OpenRocket ==

OpenRocket is built to be extensible using plugins. You can implement your own functionality or download plugins implemented by others.

This document describes how to implement your own extensions to OpenRocket.

=== Plugins ===

Extensions to OpenRocket are implemented as plugins. All interfaces that may have multiple implementations should be implemented using plugin interfaces internally. That way, external plugins may create new implementations.

A plugin is compiled into a JAR file and placed into the OpenRocket plugin directory. These JAR files are included in the OpenRocket classpath at startup and scanned for classes and interfaces annotated with <code>@Plugin</code>.

* A '''plugin interface''' is a Java interface that is annotated with the <code>@Plugin</code> annotation. These interfaces are scanned from the classpath at startup and can be queried by the code.
* A '''plugin implementation''' is a Java class that implements a plugin interface and is annotated with the <code>@Plugin</code> annotation.

In practise the plugin interfaces are defined by the internal OpenRocket code, and are extension points which internal and external plugins can implement.

'''Note:''' Many of the internal interfaces have not yet been changed to use the plugin interface. They will be migrated one by one. Help is appreciated.

=== Simulation extensions ===

Simulation extensions allow modifying simulations before or during a simulation. They allow controlling almost every aspect of a simulation.

A simulation extensions typically consists of 2-4 Java classes:

* The '''simulation extension''' implements the <code>SimulationExtension</code> interface. A new instance is created for each simulation that has the extension defined. It contains the extension configuration and a method that is called whenever a simulation is started.
* The '''simulation extension provider''' is a plugin implementation that functions as a factory class for the simulation extension. It implements the <code>SimulationExtensionProvider</code> interface.
* A '''simulation extension configurator''' is an optional plugin implementation that provides a GUI for configuring a simulation extension. It implements the <code>SwingSimulationExtensionConfigurator</code> interface.
* A '''simulation listener''' is a listener that is attached to a simulation at runtime. The listener is notified of all actions during the simulation and it can modify and affect the simulation while it is being run. The simulation extension may add a simulation listener to the simulation run when it is started. A simulation listener implements one or more of the interfaces <code>SimulationListener</code>, <code>SimulationComputationListener</code> and <code>SimulationEventListener</code>.

'''The recommended way of implementing these interfaces''' is by extending the abstract classes <code>AbstractSimulationExtension</code>, <code>AbstractSimulationExtensionProvider</code>, <code>AbstractSwingSimulationExtensionConfigurator</code> and <code>AbstractSimulationListener</code>. This allows maximum compatibility with future versions of OpenRocket when new methods are added to the interfaces.

Extending OpenRocket

2014-12-25T19:50:34Z

Plaa:

Extending OpenRocket

2014-12-25T19:18:09Z

Plaa: Created page with " == Extending OpenRocket == OpenRocket is built to be extensible using plugins. You can implement your own functionality or download plugins implemented by others. This doc..."

Feature comparison

2013-02-09T06:42:59Z

Plaa: /* Design features */

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="good" | Yes
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|-
! Computing custom variables
| class="good" | Yes
| class="bad" | No
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

Feature comparison

2013-02-09T06:37:59Z

Plaa:

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|-
! Computing custom variables
| class="good" | Yes
| class="bad" | No
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

Plugin system

2012-09-27T10:24:41Z

Plaa: /* Guice */

== The Problem ==

There are many cases where it is desirable to add a feature to openrocket which is useful in a specific context, but not really appropriate for inclusion in openrocket core. For this reason it is desirable to have some kind of plugin framework, as is found in many other applications.

In our case we refer to plugins as something that is installed onto the user's computer which is found by OR and provides additional functionality. The functionality might be simulation listeners, new motor types etc.

The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.

== Type of plugins ==

A list of different use-cases for plugins which have different kinds of requirements:

* Simulation listeners: Tied to a specific simulation, possible to select from a menu and configurable via a UI. Configuration needs to be stored/loaded from the ORK file.
* Auxilliary tools: Plugin adds options to some menu on the main window. Plugin may interact or modify the rocket. (Similar to rocket optimization)
* Optimization modifiers/targets: Defining new types of optimization targets or parameters.
* Startup tips: New startup tip types. (Not implemented yet)
* New motor types
* New simulation / aerodynamic computation engines

Some of these may be singletons, others contain state and need to be instantiated properly.

== Requirements ==

* Configuration
** Some plugins need configuration via a UI
** How to distinguish what is part of core and what is a plugin?
* Automatic discovery
** Drop a JAR to the plugin folder and it will be used.
* Localisation support
* Dependency management
** Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.
** I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo
* Plugins implemented in other languages
** Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)
* Simplified access to openrocket document / software state
** E.g. currently selected component
* Compatibility
** What happens when changes are made to the core that break the plugin?
** Should we have some API versioning that defines which plugins are compatible?

== Anti requirements ==

(Discuss)

== Implementation ==

Options for discussion:

=== JSPF ===
http://code.google.com/p/jspf/

Pro:
* Has direct functionality for loading all JAR files from a certain directory as plugins
* Straightforward to use
* Can auto-inject other plugins as dependencies
* Annotation-based plugin definition
* Light-weight (JSPF core is 320K)
* Works on Android (though automatic discovery is not possible)

Cons:
* Plugin-orientated, not directly meant for DI (though can be used for that somewhat)
* Plugins are always instantiated by JSPF, you cannot register a plugin instance. Thus massive use of provider interfaces would be required.
* All plugins are singletons. Need to use provider interfaces.

(''Provider interface'' means that you do not directly ask for a plugin, but instead ask for a plugin provider, which in turn returns 0-N plugin instances.)

=== ServiceLoader + home made ===
http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

Pro:
* Simple, built into the JRE
* Already used in some parts of OR
* Works on Android

Con:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* We need to write framework code for plugin management
* Plugin writers need to define the proper service META-INF (no annotations)

=== Reflections + home made ===
https://code.google.com/p/reflections/

Pro:
* Allows easily to search the classpath for annotations or interface implementations
* Full flexibility on plugin structure

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* Unknown does it work on Android
* The core is lightweight, but requires (at least) Guava and Javassist, altogether ~2MB

=== Spring ===
http://www.springsource.org/

Pro:
* Proper IoC framework, built for the purpose
* Supports AutoWiring of dependencies
* Should be possible to list all beans matching to an interface/annotation
* Modular, we need core+beans (~1MB)

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Unknown does it work on Android
* Need some boilerplate code for pluging functionality
* Might need provider interfaces (or some black magic using BeanFactories etc)

=== Guice ===
http://code.google.com/p/google-guice/

Pro:
* Probably more lightweight than Spring
* Proper IoC framework
* Works on Android
* Plugin-like systems may be supported using Multibindings (http://code.google.com/p/google-guice/wiki/Multibindings)

Cons:
* Unfamiliar to Sampo :)

=== Others ===

Other options that have been considered but seem too immature or too heavy to use:

* JPF (http://jpf.sourceforge.net/), seems more customizable and configurable than JSPF, but not sure do we need the extra muscle. Looks functional, but last activity was in 2007.
* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight service discovery mechanism, similar to (or used by) Eclipse plug-in system.
* Java Module System (JSR 277), slated for inclusion to Java 7, but wasn't. Seems pretty inactive (early draft from 2006) and seems to include language changes.

== A Rough Interface Design (from a plugin writers point of view) ==

'''''This section considers plugins from the point of view of "auxilliary tool" plugins, which is a minority use case. Take this section with a grain of salt.'''''

General operation:

The name for each plugin will correspond to an item in the plugins menu.
Subitems of each item in the plugins menu will be automatically generated as follows:
* About plugin : makes an about box, present for all plugins.
* for each 'enableable' modifier, a check box of the form [X] Enable ModifierName will be generated. When enabled, the enable method of the modifier will be called. This would then do what is necessary to modify OR to always run the plugin code, for example: make the simulation always load the simulation modifier.
* for each 'configurable' modifier, an item which opens the configuration window
* any additional menu items as defined in each modifier. For example, a rocket modifier might have an item which changes the selected component in some way.

Code design:

interface Plugin:
- name, version, URI, date, author, licence, description
- list of dependent plugin URI's and versions
- list of conflicting plugin URI's and versions
- list of modifiers

abstract class AbstractPlugin implements Plugin:
* everything required for loading, setting menu, translations etc
- getSetting(key), setSetting(key, value) : a simple mechanism for locally storing various settings
- getFile(name), storeFile(file), rmfile(name) : a simple mechanism for locally storing cache files etc

static class MyPlugin extends AbstractPlugin:
* the users implementation

files:
messages_?.properties : translations to use, inside plugin jar

interface Modifier:
- plugin this modifier is a member of
- enableable boolean
- enable(), disable()
- configurable boolean
- configurator
- additional menu items and actions

abstract class RocketModifier implements Modifier:
- enable(), disable() :
- getSelectedComponent() : returns currently selected rocket component
- onChange() : called when a component is changed
* various other helper methods as necessary

static class MyRocketModifier:
* the users implementation of something that works with or modifies the rocket design

abstract class SimulationModifier implements Modifier:
* basically everything currently in simulation listeners, possibly simplified (do we need 3 separate interfaces?)

static class MySimulationModifier extends AbstractSimulationModifier:
* the users implementation

abstract class configurator:
a class which automatically generates a standardised configuration dialog box based on just a simple list of variables and selectors.
Variables would be saved automatically when the OK button is clicked using plugin setSettings().

Plugin system

2012-09-26T13:11:55Z

Plaa:

== The Problem ==

There are many cases where it is desirable to add a feature to openrocket which is useful in a specific context, but not really appropriate for inclusion in openrocket core. For this reason it is desirable to have some kind of plugin framework, as is found in many other applications.

In our case we refer to plugins as something that is installed onto the user's computer which is found by OR and provides additional functionality. The functionality might be simulation listeners, new motor types etc.

The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.

== Type of plugins ==

A list of different use-cases for plugins which have different kinds of requirements:

* Simulation listeners: Tied to a specific simulation, possible to select from a menu and configurable via a UI. Configuration needs to be stored/loaded from the ORK file.
* Auxilliary tools: Plugin adds options to some menu on the main window. Plugin may interact or modify the rocket. (Similar to rocket optimization)
* Optimization modifiers/targets: Defining new types of optimization targets or parameters.
* Startup tips: New startup tip types. (Not implemented yet)
* New motor types
* New simulation / aerodynamic computation engines

Some of these may be singletons, others contain state and need to be instantiated properly.

== Requirements ==

* Configuration
** Some plugins need configuration via a UI
** How to distinguish what is part of core and what is a plugin?
* Automatic discovery
** Drop a JAR to the plugin folder and it will be used.
* Localisation support
* Dependency management
** Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.
** I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo
* Plugins implemented in other languages
** Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)
* Simplified access to openrocket document / software state
** E.g. currently selected component
* Compatibility
** What happens when changes are made to the core that break the plugin?
** Should we have some API versioning that defines which plugins are compatible?

== Anti requirements ==

(Discuss)

== Implementation ==

Options for discussion:

=== JSPF ===
http://code.google.com/p/jspf/

Pro:
* Has direct functionality for loading all JAR files from a certain directory as plugins
* Straightforward to use
* Can auto-inject other plugins as dependencies
* Annotation-based plugin definition
* Light-weight (JSPF core is 320K)
* Works on Android (though automatic discovery is not possible)

Cons:
* Plugin-orientated, not directly meant for DI (though can be used for that somewhat)
* Plugins are always instantiated by JSPF, you cannot register a plugin instance. Thus massive use of provider interfaces would be required.
* All plugins are singletons. Need to use provider interfaces.

(''Provider interface'' means that you do not directly ask for a plugin, but instead ask for a plugin provider, which in turn returns 0-N plugin instances.)

=== ServiceLoader + home made ===
http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

Pro:
* Simple, built into the JRE
* Already used in some parts of OR
* Works on Android

Con:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* We need to write framework code for plugin management
* Plugin writers need to define the proper service META-INF (no annotations)

=== Reflections + home made ===
https://code.google.com/p/reflections/

Pro:
* Allows easily to search the classpath for annotations or interface implementations
* Full flexibility on plugin structure

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* Unknown does it work on Android
* The core is lightweight, but requires (at least) Guava and Javassist, altogether ~2MB

=== Spring ===
http://www.springsource.org/

Pro:
* Proper IoC framework, built for the purpose
* Supports AutoWiring of dependencies
* Should be possible to list all beans matching to an interface/annotation
* Modular, we need core+beans (~1MB)

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Unknown does it work on Android
* Need some boilerplate code for pluging functionality
* Might need provider interfaces (or some black magic using BeanFactories etc)

=== Guice ===
http://code.google.com/p/google-guice/

Pro:
* Probably more lightweight than Spring
* Proper IoC framework
* Works on Android

Cons:
* Does not support autowiring, all dependencies need to be configured by hand (?)
* AFAIK does not offer a list of matching beans, i.e. may not be suitable for the plugin system

=== Others ===

Other options that have been considered but seem too immature or too heavy to use:

* JPF (http://jpf.sourceforge.net/), seems more customizable and configurable than JSPF, but not sure do we need the extra muscle. Looks functional, but last activity was in 2007.
* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight service discovery mechanism, similar to (or used by) Eclipse plug-in system.
* Java Module System (JSR 277), slated for inclusion to Java 7, but wasn't. Seems pretty inactive (early draft from 2006) and seems to include language changes.

== A Rough Interface Design (from a plugin writers point of view) ==

'''''This section considers plugins from the point of view of "auxilliary tool" plugins, which is a minority use case. Take this section with a grain of salt.'''''

General operation:

The name for each plugin will correspond to an item in the plugins menu.
Subitems of each item in the plugins menu will be automatically generated as follows:
* About plugin : makes an about box, present for all plugins.
* for each 'enableable' modifier, a check box of the form [X] Enable ModifierName will be generated. When enabled, the enable method of the modifier will be called. This would then do what is necessary to modify OR to always run the plugin code, for example: make the simulation always load the simulation modifier.
* for each 'configurable' modifier, an item which opens the configuration window
* any additional menu items as defined in each modifier. For example, a rocket modifier might have an item which changes the selected component in some way.

Code design:

interface Plugin:
- name, version, URI, date, author, licence, description
- list of dependent plugin URI's and versions
- list of conflicting plugin URI's and versions
- list of modifiers

abstract class AbstractPlugin implements Plugin:
* everything required for loading, setting menu, translations etc
- getSetting(key), setSetting(key, value) : a simple mechanism for locally storing various settings
- getFile(name), storeFile(file), rmfile(name) : a simple mechanism for locally storing cache files etc

static class MyPlugin extends AbstractPlugin:
* the users implementation

files:
messages_?.properties : translations to use, inside plugin jar

interface Modifier:
- plugin this modifier is a member of
- enableable boolean
- enable(), disable()
- configurable boolean
- configurator
- additional menu items and actions

abstract class RocketModifier implements Modifier:
- enable(), disable() :
- getSelectedComponent() : returns currently selected rocket component
- onChange() : called when a component is changed
* various other helper methods as necessary

static class MyRocketModifier:
* the users implementation of something that works with or modifies the rocket design

abstract class SimulationModifier implements Modifier:
* basically everything currently in simulation listeners, possibly simplified (do we need 3 separate interfaces?)

static class MySimulationModifier extends AbstractSimulationModifier:
* the users implementation

abstract class configurator:
a class which automatically generates a standardised configuration dialog box based on just a simple list of variables and selectors.
Variables would be saved automatically when the OK button is clicked using plugin setSettings().

Plugin system

2012-09-26T12:59:12Z

Plaa:

== The Problem ==

There are many cases where it is desirable to add a feature to openrocket which is useful in a specific context, but not really appropriate for inclusion in openrocket core. For this reason it is desirable to have some kind of plugin framework, as is found in many other applications.

In our case we refer to plugins as something that is installed onto the user's computer which is found by OR and provides additional functionality. The functionality might be simulation listeners, new motor types etc.

The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.

== Type of plugins ==

A list of different use-cases for plugins which have different kinds of requirements:

* Simulation listeners: Tied to a specific simulation, possible to select from a menu and configurable via a UI. Configuration needs to be stored/loaded from the ORK file.
* Auxilliary tools: Plugin adds options to some menu on the main window. Plugin may interact or modify the rocket. (Similar to rocket optimization)
* Optimization modifiers/targets: Defining new types of optimization targets or parameters.
* Startup tips: New startup tip types. (Not implemented yet)
* New motor types
* New simulation / aerodynamic computation engines

Some of these may be singletons, others contain state and need to be instantiated properly.

== Requirements ==

* Configuration
* Some plugins need configuration via a UI
* How to distinguish what is part of core and what is a plugin?
* Automatic discovery
* Drop a JAR to the plugin folder and it will be used.
* Localisation support
* Dependency management
* Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.
* I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo
* Plugins implemented in other languages
* Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)
* Simplified access to openrocket document / software state
* E.g. currently selected component
* Compatibility
* What happens when changes are made to the core that break the plugin?
* Should we have some API versioning that defines which plugins are compatible?

== Anti requirements ==

(Discuss)

== Implementation ==

Options for discussion:

=== JSPF ===
http://code.google.com/p/jspf/

Pro:
* Has direct functionality for loading all JAR files from a certain directory as plugins
* Straightforward to use
* Can auto-inject other plugins as dependencies
* Annotation-based plugin definition
* Light-weight (JSPF core is 320K)
* Works on Android (though automatic discovery is not possible)

Cons:
* Plugin-orientated, not directly meant for DI (though can be used for that somewhat)
* Plugins are always instantiated by JSPF, you cannot register a plugin instance. Thus massive use of provider interfaces would be required.
* All plugins are singletons. Need to use provider interfaces.

(''Provider interface'' means that you do not directly ask for a plugin, but instead ask for a plugin provider, which in turn returns 0-N plugin instances.)

=== ServiceLoader + home made ===
http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

Pro:
* Simple, built into the JRE
* Already used in some parts of OR
* Works on Android

Con:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* We need to write framework code for plugin management
* Plugin writers need to define the proper service META-INF (no annotations)

=== Reflections + home made ===
https://code.google.com/p/reflections/

Pro:
* Allows easily to search the classpath for annotations or interface implementations
* Full flexibility on plugin structure

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* Unknown does it work on Android
* The core is lightweight, but requires (at least) Guava and Javassist, altogether ~2MB

=== Spring ===
http://www.springsource.org/

Pro:
* Proper IoC framework, built for the purpose
* Supports AutoWiring of dependencies
* Should be possible to list beans matching to an interface/annotation
* Modular, we need core+beans (~1MB)

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Unknown does it work on Android
* Need some boilerplate code for pluging functionality

=== Others ===

Other options that have been considered but seem too immature or too heavy to use:

* JPF (http://jpf.sourceforge.net/), seems more customizable and configurable than JSPF, but not sure do we need the extra muscle. Looks functional, but last activity was in 2007.
* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight service discovery mechanism, similar to (or used by) Eclipse plug-in system.
* Java Module System (JSR 277), slated for inclusion to Java 7, but wasn't. Seems pretty inactive (early draft from 2006) and seems to include language changes.

== A Rough Interface Design (from a plugin writers point of view) ==

'''''This section considers plugins from the point of view of "auxilliary tool" plugins, which is a minority use case. Take this section with a grain of salt.'''''

General operation:

The name for each plugin will correspond to an item in the plugins menu.
Subitems of each item in the plugins menu will be automatically generated as follows:
* About plugin : makes an about box, present for all plugins.
* for each 'enableable' modifier, a check box of the form [X] Enable ModifierName will be generated. When enabled, the enable method of the modifier will be called. This would then do what is necessary to modify OR to always run the plugin code, for example: make the simulation always load the simulation modifier.
* for each 'configurable' modifier, an item which opens the configuration window
* any additional menu items as defined in each modifier. For example, a rocket modifier might have an item which changes the selected component in some way.

Code design:

interface Plugin:
- name, version, URI, date, author, licence, description
- list of dependent plugin URI's and versions
- list of conflicting plugin URI's and versions
- list of modifiers

abstract class AbstractPlugin implements Plugin:
* everything required for loading, setting menu, translations etc
- getSetting(key), setSetting(key, value) : a simple mechanism for locally storing various settings
- getFile(name), storeFile(file), rmfile(name) : a simple mechanism for locally storing cache files etc

static class MyPlugin extends AbstractPlugin:
* the users implementation

files:
messages_?.properties : translations to use, inside plugin jar

interface Modifier:
- plugin this modifier is a member of
- enableable boolean
- enable(), disable()
- configurable boolean
- configurator
- additional menu items and actions

abstract class RocketModifier implements Modifier:
- enable(), disable() :
- getSelectedComponent() : returns currently selected rocket component
- onChange() : called when a component is changed
* various other helper methods as necessary

static class MyRocketModifier:
* the users implementation of something that works with or modifies the rocket design

abstract class SimulationModifier implements Modifier:
* basically everything currently in simulation listeners, possibly simplified (do we need 3 separate interfaces?)

static class MySimulationModifier extends AbstractSimulationModifier:
* the users implementation

abstract class configurator:
a class which automatically generates a standardised configuration dialog box based on just a simple list of variables and selectors.
Variables would be saved automatically when the OK button is clicked using plugin setSettings().

Plugin system

2012-09-26T12:57:44Z

Plaa:

== The Problem ==

There are many cases where it is desirable to add a feature to openrocket which is useful in a specific context, but not really appropriate for inclusion in openrocket core. For this reason it is desirable to have some kind of plugin framework, as is found in many other applications.

In our case we refer to plugins as something that is installed onto the user's computer which is found by OR and provides additional functionality. The functionality might be simulation listeners, new motor types etc.

The plugin system has ties to dependency injection, and ideally one solution would cover both plugin discovery related items and dependency injection.

== Type of plugins ==

A list of different use-cases for plugins which have different kinds of requirements:

* Simulation listeners: Tied to a specific simulation, possible to select from a menu and configurable via a UI. Configuration needs to be stored/loaded from the ORK file.
* Auxilliary tools: Plugin adds options to some menu on the main window. Plugin may interact or modify the rocket. (Similar to rocket optimization)
* Optimization modifiers/targets: Defining new types of optimization targets or parameters.
* Startup tips: New startup tip types. (Not implemented yet)
* New motor types
* New simulation / aerodynamic computation engines

Some of these may be singletons, others contain state and need to be instantiated properly.

== Requirements ==

* Configuration
* Some plugins need configuration via a UI
* How to distinguish what is part of core and what is a plugin?
* Automatic discovery
* Drop a JAR to the plugin folder and it will be used.
* Localisation support
* Dependency management
* Some plugins may depend on others and be able to automatically load them. This in turn requires that plugins have a consistent identifier / URI and version number.
* I don't think we ''need'' plugin dependency management in the foreseeable future, and such a system may complicate things considerably. -Sampo
* Plugins implemented in other languages
* Should be possible to create a plugin that allows writing other plugins in scripting languages (e.g. JavaScript/Ruby)
* Simplified access to openrocket document / software state
* E.g. currently selected component
* Compatibility
* What happens when changes are made to the core that break the plugin?
* Should we have some API versioning that defines which plugins are compatible?

== Anti requirements ==

(Discuss)

== Implementation ==

Options for discussion:

=== JSPF ===
http://code.google.com/p/jspf/

Pro:
* Has direct functionality for loading all JAR files from a certain directory as plugins
* Straightforward to use
* Can auto-inject other plugins as dependencies
* Annotation-based plugin definition
* Light-weight (JSPF core is 320K)
* Works on Android (though automatic discovery is not possible)

Cons:
* Plugin-orientated, not directly meant for DI (though can be used for that somewhat)
* Plugins are always instantiated by JSPF, you cannot register a plugin instance. Thus massive use of provider interfaces would be required.
* All plugins are singletons. Need to use provider interfaces.

(''Provider interface'' means that you do not directly ask for a plugin, but instead ask for a plugin provider, which in turn returns 0-N plugin instances.)

=== ServiceLoader + home made ===
http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

Pro:
* Simple, built into the JRE
* Already used in some parts of OR
* Works on Android

Con:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* We need to write framework code for plugin management
* Plugin writers need to define the proper service META-INF (no annotations)

=== Reflections + home made ===
https://code.google.com/p/reflections/

Pro:
* Allows easily to search the classpath for annotations or interface implementations
* Full flexibility on plugin structure

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Does not do DI
* Unknown does it work on Android
* The core is lightweight, but requires (at least) Guava and Javassist, altogether ~2MB

=== Spring ===
http://www.springsource.org/

Pro:
* Proper IoC framework, built for the purpose
* Supports AutoWiring of dependencies
* Should be possible to list beans matching to an interface/annotation
* Modular, we need core+beans (~1MB)

Cons:
* JARs from plugin directory need to be added to classpath separately (not a bit thing with a custom ClassLoader)
* Unknown does it work on Android
* Need some boilerplate code for pluging functionality

=== Others ===

Other options that have been considered but seem too immature or too heavy to use:

* JPF (http://jpf.sourceforge.net/), seems more customizable and
configurable than JSPF, but not sure do we need the extra muscle.
Looks functional, but last activity was in 2007.
* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight
service discovery mechanism, similar to (or used by) Eclipse plug-in
system.
* Java Module System (JSR 277), slated for inclusion to Java 7, but
wasn't. Seems pretty inactive (early draft from 2006) and seems to
include language changes.

=== Plugin frameworks ===

Various plug-in frameworks exist for java, and may significantly reduce the time required to implement the plugin feature.

Directly coding the plug-in just requires the new interface to extend the
Plugin interface and to add the annotations to the implementation
class. This is a simple and light-weight solution which may well be quite suitable.

Of the alternative plug-in frameworks which exist, the most
interesting is JSPF (http://code.google.com/p/jspf/). Here
you can just say "load all JAR files from this directory as plug-ins"
and "add all plug-ins from the current classpath". You can then query
for plug-ins using a variety of methods. It seems very simple to use,
it uses pojos and pure interfaces, and plug-ins themselves are made
just by implementing the interface and adding some annotations.

JSPF also seems to work on Android, though the discovery system is
somewhat dysfunctional, and you need to list all of the plug-in
classes explicitly (http://code.google.com/p/jspf/wiki/RunningOnAndroid). This should be
okay, we just need to have an additional implementation for Android
that lists the necessary plug-ins for the basic functionality. I
don't see it as a problem if some of the extensibility is missing on
Android.

Other frameworks that have been considered:

* ServiceLoader class + startup scripting. Simple, built-in, but we
need to implement the plug-in system ourselves.
* JPF (http://jpf.sourceforge.net/), seems more customizable and
configurable than JSPF, but not sure do we need the extra muscle.
Looks functional, but last activity was in 2007.
* OSGi (http://en.wikipedia.org/wiki/OSGi), even more heavy-weight
service discovery mechanism, similar to (or used by) Eclipse plug-in
system.
* Java Module System (JSR 277), slated for inclusion to Java 7, but
wasn't. Seems pretty inactive (early draft from 2006) and seems to
include language changes.

== A Rough Interface Design (from a plugin writers point of view) ==

'''''This section considers plugins from the point of view of "auxilliary tool" plugins, which is a minority use case. Take this section with a grain of salt.'''''

General operation:

The name for each plugin will correspond to an item in the plugins menu.
Subitems of each item in the plugins menu will be automatically generated as follows:
* About plugin : makes an about box, present for all plugins.
* for each 'enableable' modifier, a check box of the form [X] Enable ModifierName will be generated. When enabled, the enable method of the modifier will be called. This would then do what is necessary to modify OR to always run the plugin code, for example: make the simulation always load the simulation modifier.
* for each 'configurable' modifier, an item which opens the configuration window
* any additional menu items as defined in each modifier. For example, a rocket modifier might have an item which changes the selected component in some way.

Code design:

interface Plugin:
- name, version, URI, date, author, licence, description
- list of dependent plugin URI's and versions
- list of conflicting plugin URI's and versions
- list of modifiers

abstract class AbstractPlugin implements Plugin:
* everything required for loading, setting menu, translations etc
- getSetting(key), setSetting(key, value) : a simple mechanism for locally storing various settings
- getFile(name), storeFile(file), rmfile(name) : a simple mechanism for locally storing cache files etc

static class MyPlugin extends AbstractPlugin:
* the users implementation

files:
messages_?.properties : translations to use, inside plugin jar

interface Modifier:
- plugin this modifier is a member of
- enableable boolean
- enable(), disable()
- configurable boolean
- configurator
- additional menu items and actions

abstract class RocketModifier implements Modifier:
- enable(), disable() :
- getSelectedComponent() : returns currently selected rocket component
- onChange() : called when a component is changed
* various other helper methods as necessary

static class MyRocketModifier:
* the users implementation of something that works with or modifies the rocket design

abstract class SimulationModifier implements Modifier:
* basically everything currently in simulation listeners, possibly simplified (do we need 3 separate interfaces?)

static class MySimulationModifier extends AbstractSimulationModifier:
* the users implementation

abstract class configurator:
a class which automatically generates a standardised configuration dialog box based on just a simple list of variables and selectors.
Variables would be saved automatically when the OK button is clicked using plugin setSettings().

Plugin system

2012-09-26T12:31:52Z

Plaa:

Tips

2012-09-25T14:01:17Z

Plaa:

This page collects a list of short (1-3 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

= General use =

* You can type in equations in the entry fields instead of numbers. For example, to double a length you can type '''3.1*2'''.

* The component tree will display any component comments as tool tips. You can set the comment on the '''Comment''' tab of the component configuration dialog.

* If you want to always load a specific .ork file, you can specify the filename as a command line argument when starting openrocket.

* You can choose your preferred units from '''Edit''' → '''Preferences...'''. You can individually change the units by clicking the unit symbol.

= Rocket design =

* A rocket design can have a number of ''motor configurations''. When simulating a flight, you select which motor configuration you use. You can edit the motor configurations using '''Tools''' → '''Motor configurations...'''

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.

* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''

* You can define custom materials by selecting '''Custom''' from the bottom of a material selection list.

* You can select ready components from the preset dropdown on the top-right of the component editing dialog. Tick the box in the table to add the component to the dropdown menu.

* You can select components by clicking them in the diagram, or edit them by double-clicking.

* To get the best accuracy possible, you can weight your components and enter the override the calculated weight on the '''Override' tab when editing components.

* You can define through-the-wall fin tabs on the '''Fin tabs''' tab when editing a fin set.

* Your rocket's surface roughness can affect flight altitude significantly. Select the appropriate roughness on the '''Component finish''' dropdown. You can set the same finish for all components by clicking '''Set for all'''.

* You will see immediate results of a flight simulation on the lower-left corner of the design diagram. This reflects a flight with your currently selected motor configuration.

* In case OpenRocket cannot reliably compute the aerodynamic properties of the rocket, you will see warnings on the lower-right corner of the design diagram.

* You can create clustered rockets easily using the '''Cluster''' tab when editing Inner tubes. Any motors or components attached to the inner tube will be present on all copies of the inner tube.

* Centering rings, Engine blocks, Couplers and Bulkheads can automatically compute the relevant dimensions from the other components when the '''Automatic''' checkbox is selected.

* You can simulate launch rails or pins by creating filled launch lugs of the corresponding size.

* Only body components and fin sets affect the aerodynamics of the rocket. Even if an internal component extrudes outside of the body tube, its effect will not be taken into account in simulations!

* You can add stages to your rocket by pressing '''New stage''' on the main screen. Stage separation is configured on the '''Separation''' tab when editing a stage.

* You can fully customize the simulation plots on the '''Plot data''' tab. Choose on of the preset configurations or experiment with the other options.

* You can export simulated flight data to be analyzed by another program using the '''Export data''' tab when editing a simulation.

* The ball on the right side of the simulation table indicates the state of the simulation. Red means that the design has been changed since the simulation was last run, yellow means the data has been loaded from a file, and green means it is up-to-date.

* If a potential problem occurred during a simulated flight, you will see a red exclamation mark (!) next to your simulation. Hover over the simulation to see what the warning is about.

* You can duplicate components or move them to another design by using normal copy-paste functionality.

* You can move components by drag-dropping them in the component tree.

* You can examine details on the stability and drag characteristics of your rocket using '''Tools''' → '''Component analysis...'''

* You can optimize the shape, size or mass of your rocket using '''Tools''' → '''Rocket optimization...'''

* Custom expressions allow you to compute flight parameters that are not computed by OpenRocket by default. You define them using '''Tools''' → '''Custom expressions...''' See [https://sourceforge.net/apps/mediawiki/openrocket/index.php?title=List_of_useful_custom_expressions the wiki] for ideas.

Tips

2012-09-25T13:59:22Z

Plaa:

This page collects a list of short (1-3 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

= General use =

* You can type in equations in the entry fields instead of numbers. For example, to double a length you can type '''3.1*2'''.

* The component tree will display any component comments as tool tips. You can set the comment on the '''Comment''' tab of the component configuration dialog.

* If you want to always load a specific .ork file, you can specify the filename as a command line argument when starting openrocket.

= Rocket design =

* A rocket design can have a number of ''motor configurations''. When simulating a flight, you select which motor configuration you use. You can edit the motor configurations using '''Tools''' → '''Motor configurations...'''

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.

* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''

* You can define custom materials by selecting '''Custom''' from the bottom of a material selection list.

* You can select ready components from the preset dropdown on the top-right of the component editing dialog. Tick the box in the table to add the component to the dropdown menu.

* You can select components by clicking them in the diagram, or edit them by double-clicking.

* To get the best accuracy possible, you can weight your components and enter the override the calculated weight on the '''Override' tab when editing components.

* You can define through-the-wall fin tabs on the '''Fin tabs''' tab when editing a fin set.

* Your rocket's surface roughness can affect flight altitude significantly. Select the appropriate roughness on the '''Component finish''' dropdown. You can set the same finish for all components by clicking '''Set for all'''.

* You will see immediate results of a flight simulation on the lower-left corner of the design diagram. This reflects a flight with your currently selected motor configuration.

* In case OpenRocket cannot reliably compute the aerodynamic properties of the rocket, you will see warnings on the lower-right corner of the design diagram.

* You can create clustered rockets easily using the '''Cluster''' tab when editing Inner tubes. Any motors or components attached to the inner tube will be present on all copies of the inner tube.

* Centering rings, Engine blocks, Couplers and Bulkheads can automatically compute the relevant dimensions from the other components when the '''Automatic''' checkbox is selected.

* You can simulate launch rails or pins by creating filled launch lugs of the corresponding size.

* Only body components and fin sets affect the aerodynamics of the rocket. Even if an internal component extrudes outside of the body tube, its effect will not be taken into account in simulations!

* You can add stages to your rocket by pressing '''New stage''' on the main screen. Stage separation is configured on the '''Separation''' tab when editing a stage.

* You can fully customize the simulation plots on the '''Plot data''' tab. Choose on of the preset configurations or experiment with the other options.

* You can export simulated flight data to be analyzed by another program using the '''Export data''' tab when editing a simulation.

* The ball on the right side of the simulation table indicates the state of the simulation. Red means that the design has been changed since the simulation was last run, yellow means the data has been loaded from a file, and green means it is up-to-date.

* If a potential problem occurred during a simulated flight, you will see a red exclamation mark (!) next to your simulation. Hover over the simulation to see what the warning is about.

* You can duplicate components or move them to another design by using normal copy-paste functionality.

* You can move components by drag-dropping them in the component tree.

* You can examine details on the stability and drag characteristics of your rocket using '''Tools''' → '''Component analysis...'''

* You can optimize the shape, size or mass of your rocket using '''Tools''' → '''Rocket optimization...'''

* Custom expressions allow you to compute flight parameters that are not computed by OpenRocket by default. You define them using '''Tools''' → '''Custom expressions...''' See [https://sourceforge.net/apps/mediawiki/openrocket/index.php?title=List_of_useful_custom_expressions the wiki] for ideas.

Tips

2012-09-25T13:58:39Z

Plaa:

This page collects a list of short (1-3 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

= General use =

* You can type in equations in the entry fields instead of numbers. For example, to double a length you can type '''3.1*2'''.

* The component tree will display any component comments as tool tips. You can set the comment on the '''Comment''' tab of the component configuration dialog.

* If you want to always load a specific .ork file, you can specify the filename as a command line argument when starting openrocket.

= Rocket design =

* A rocket design can have a number of ''motor configurations''. When simulating a flight, you select which motor configuration you use. You can edit the motor configurations using '''Tools''' → '''Motor configurations...'''

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.

* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''

* You can define custom materials by selecting '''Custom''' from the bottom of a material selection list.

* You can select ready components from the preset dropdown on the top-right of the component editing dialog. Tick the box in the table to add the component to the dropdown menu.

* You can select components by clicking them in the diagram, or edit them by double-clicking.

* To get the best accuracy possible, you can weight your components and enter the override the calculated weight on the '''Override' tab when editing components.

* You can define through-the-wall fin tabs on the '''Fin tabs''' tab when editing a fin set.

* Your rocket's surface roughness can affect flight altitude significantly. Select the appropriate roughness on the '''Component finish''' dropdown. You can set the same finish for all components by clicking '''Set for all'''.

* You will see immediate results of a flight simulation on the lower-left corner of the design diagram. This reflects a flight with your currently selected motor configuration.

* In case OpenRocket cannot reliably compute the aerodynamic properties of the rocket, you will see warnings on the lower-right corner of the design diagram.

* You can create clustered rockets easily using the '''Cluster''' tab when editing Inner tubes. Any motors or components attached to the inner tube will be present on all copies of the inner tube.

* Centering rings, Engine blocks, Couplers and Bulkheads can automatically compute the relevant dimensions from the other components when the '''Automatic''' checkbox is selected.

* You can simulate launch rails or pins by creating filled launch lugs of the corresponding size.

* Only body components and fin sets affect the aerodynamics of the rocket. Even if an internal component extrudes outside of the body tube, its effect will not be taken into account in simulations!

* You can add stages to your rocket by pressing '''New stage''' on the main screen. Stage separation is configured on the '''Separation''' tab when editing a stage.

* You can fully customize the simulation plots on the '''Plot data''' tab. Choose on of the preset configurations or experiment with the other options.

* You can export simulated flight data to be analyzed by another program using the '''Export data''' tab when editing a simulation.

* The ball on the right side of the simulation table indicates the state of the simulation. Red means that the design has been changed since the simulation was last run, yellow means the data has been loaded from a file, and green means it is up-to-date.

* If a potential problem occurred during a simulated flight, you will see a red exclamation mark (!) next to your simulation. Hover over the simulation to see what the warning is about.

* You can duplicate components or move them to another design by using normal copy-paste functionality.

* You can move components by drag-dropping them in the component tree.

* You can examine details on the stability and drag characteristics of your rocket using '''Tools''' → '''Component analysis...'''

* You can optimize the shape, size or mass of your rocket using '''Tools''' → '''Rocket optimization...'''

* Custom expressions allow you to compute flight parameters that are not computed by OpenRocket by default. You define them using '''Tools''' → '''Custom expressions...''' See [[https://sourceforge.net/apps/mediawiki/openrocket/index.php?title=List_of_useful_custom_expressions|the wiki]] for ideas.

Tips

2012-09-25T13:48:42Z

Plaa:

This page collects a list of short (1-3 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

= General use =

* You can type in equations in the entry fields instead of numbers. For example, to double a length you can type '''3.1*2'''.

* The component tree will display any component comments as tool tips. You can set the comment on the '''Comment''' tab of the component configuration dialog.

* If you want to always load a specific .ork file, you can specify the filename as a command line argument when starting openrocket.

= Rocket design =

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.

* You can configure all motor selections by selecting '''Edit configurations''' from the '''Motor configuration''' dropdown.

* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''

* You can define custom materials by selecting '''Custom''' from the bottom of a material selection list.

* You can select ready components from the preset dropdown on the top-right of the component editing dialog. Tick the box in the table to add the component to the dropdown menu.

* You can select components by clicking them in the diagram, or edit them by double-clicking.

* To get the best accuracy possible, you can weight your components and enter the override the calculated weight on the '''Override' tab when editing components.

* You can define through-the-wall fin tabs on the '''Fin tabs''' tab when editing a fin set.

* Your rocket's surface roughness can affect flight altitude significantly. Select the appropriate roughness on the '''Component finish''' dropdown. You can set the same finish for all components by clicking '''Set for all'''.

* You will see immediate results of a flight simulation on the lower-left corner of the design diagram. This reflects a flight with your currently selected motor configuration.

* In case OpenRocket cannot reliably compute the aerodynamic properties of the rocket, you will see warnings on the lower-right corner of the design diagram.

* You can create clustered rockets easily using the '''Cluster''' tab when editing Inner tubes. Any motors or components attached to the inner tube will be present on all copies of the inner tube.

* Centering rings, Engine blocks, Couplers and Bulkheads can automatically compute the relevant dimensions from the other components when the '''Automatic''' checkbox is selected.

* You can simulate launch rails or pins by creating filled launch lugs of the corresponding size.

* Only body components and fin sets affect the aerodynamics of the rocket. Even if an internal component extrudes outside of the body tube, its effect will not be taken into account in simulations!

* You can add stages to your rocket by pressing '''New stage''' on the main screen. Stage separation is configured on the '''Separation''' tab when editing a stage.

* You can fully customize the simulation plots on the '''Plot data''' tab. Choose on of the preset configurations or experiment with the other options.

* You can export simulated flight data to be analyzed by another program using the '''Export data''' tab when editing a simulation.

* The ball on the right side of the simulation table indicates the state of the simulation. Red means that the design has been changed since the simulation was last run, yellow means the data has been loaded from a file, and green means it is up-to-date.

* If a potential problem occurred during a simulated flight, you will see a red exclamation mark (!) next to your simulation. Hover over the simulation to see what the warning is about.

* You can duplicate components or move them to another design by using normal copy-paste functionality.

* You can move components by drag-dropping them in the component tree.

* You can examine details on the stability and drag characteristics of your rocket

Tips

2012-09-25T13:39:25Z

Plaa: tips

Tips

2012-09-25T13:14:08Z

Plaa: /* General use */

Feature comparison

2012-04-21T20:47:38Z

Plaa: /* Simulation features */ removed supersonic simulation - both have it and quality is arguable

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

Feature comparison

2012-04-21T20:46:46Z

Plaa: /* Simulation features */ corrected rocksim to 3dof

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 3DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

Feature wishlist

2012-03-28T04:43:28Z

Plaa: /* 3D view of the rocket */

{{Access}}

The feature wishlist details some desired features for OpenRocket, concentrating on ones that can reasonably well be implemented without deep knowledge of the OpenRocket internals. If you find something you'd like to contribute (or make something up yourself), please inform us about that on the [https://lists.sourceforge.net/lists/listinfo/openrocket-devel OpenRocket-devel mailing list] and we can help you get started.

This page complements the [http://openrocket.svn.sourceforge.net/viewvc/openrocket/trunk/TODO distribution TODO file], which contains more ideas in a shorter form. Please feel free to comment on the issues.

== UI improvements ==

There are various places in need of attention in the UI. The UI code is also in some places a bit messy, and should be cleaned up.

* Intuitive zooming of the plots
** normal magnifying glass buttons for zoom in/out
** currently click-drag towards the lower-right zooms in, towards the upper-left resets the zoom to original - very unintuitive (JFreeChar default)
** should be implemented as a generic component that could be used in various places
* Ctrl+scroll wheel should zoom in/out the rocket design (and maybe also plots)
* [[Component databases]]

== 3D view of the rocket ==

A 3D view of the rocket is greatly desired, but I have no experience in 3D programming. Below are a few ideas or a "wish list" (not all need to be implemented!)

* 3D view as an alternative to the side and back rocket view
** rotation using the mouse drag-and-drop
** either "normal" view or a translucent view, where the opacity of each component is something like 0.3-0.5
** decals - allow a user to define 1-n images that are positioned at some point of the rocket body or fins
** allow configuring a spiral wound for body tubes
** selecting components by clicking on them (like you can in the 2D view). Not sure whether it's a good idea to show the selected component in any special way though.
** allow defining "shininess" of the component (there's really something like 3 parameters controlling this, but for UX I think we should try to make a single parameter which works reasonably for all)

* An animation of a simulated flight
** general overview of flight (with possibility to magnify the rocket)?
** different camera angles to choose from, some ideas:
*** launcher view
*** profile view
*** a camera attached to the rocket pointing to the side / tail
*** a camera moving along with the rocket either from the top or side
** selectable launch scenery
** allow selecting whether xyz-axis are displayed on the rocket during flight
*** provides a visualization of what the rocket is doing during the flight
*** rocket movement often very hard to visualize looking at just graphs
*** may require additional flight parameters to be stored during simulation

== Printing support ==

Printing is one of the most asked-for features for OpenRocket. At the same time it would be natural to allow exporting the same as PNG, SVG or PDF.

Support can be implemented in various levels. At least the following are candidates for places where print/export may be desireable:

* fin templates, conical transition/nose cone templates, nose cone profiles
* the rocket design view
* the simulation plots (JFreeChart has some support built-in)
* printing a design report (see below)

== Creating/printing a rocket design report ==

The ability to create a report containing the most important design information to present to a RSO at a launch event. The structure of the report could be something like the following:

* Title
* Section describing the rocket in general without motors
** design name
** empty mass & CG
** CP position
** CP position at 5 degree AOA (or similar)
** number of stages
** parachute/streamer sizes
** max. diameter (caliber)
* Section for each motor configuration
** a summary of the motors, e.g. 3xC6-0; B4-6
** a list of the motors including the manufacturer, designation (maybe also info like burn time, grams of propellant, total impulse)
** total grams of propellant
** total impulse
** takeoff weight
** CG and CP position, stability margin
** predicted flight altitude, max. velocity and max. acceleration
** predicted velocity at chute deployment
** predicted descent rate
* Diagram of the rocket (positioned vertically on the right side of the first page)
** CP position
** CG position without motors and in each configuration (the labels should alternate on right and left sides to avoid being on top of each other)

The user flow could be something like the following:

* Select from menu Rocket -> Design report
* A dialog opens to ask which motor configurations to include in the report
** maybe ask paper size as well
* Simulations are run for each to get most up-to-date info
* Report is shown to user, allowing them to save or print it

Technical considerations:

* Predicted data readily available from OR (ask for details)
* The rocket plot can and should use the same rendering as the design window
* How to define launch conditions? Should the user select simulations to include in the report instead of motor configurations?

One issue is also in what format and how to create the report. Below are a few alternatives that have been considered, others are possible as well.

* Generate the report in HTML
** Pros:
*** easy to generate
*** can be displayed using a JTextPane
*** allows saving as HTML
*** easy to print from Java using JTextComponent.print()
** Cons:
*** including the plot might be problematic and requires a separate file when saving
*** rocket diagram needs to be in raster format
*** no support for smart pagination
* Use [http://itextpdf.com/ iText] or some other PDF generator
** Pros:
*** exported directly as PDF, only one file in output
*** more control, can produce more professional-looking output
*** rocket diagram can be in vector format
*** can be better paginated
** Cons:
*** may be more difficult to generate(?)
*** smart pagination may be challenging / require additional work
*** displaying and printing the report may need separate support (maybe using [http://pdfbox.apache.org/ PDFBox]?)
* Generate LaTeX document and figures for later compilation
** Pros:
*** Extremely high quality output
*** Equations, pagination, sections, hyperlinks and anything else you could want
*** Fully vectorised graphics
*** User can easily manually customise output file
*** Easy to program on the Java side as just generating plain text
** Cons:
*** Requires an external LaTeX distribution
*** Not everyone knows LaTeX.

== Memory profiling ==

OpenRocket seems to consume quite a lot of memory, and likely has numerous memory leaks. (During initial development the effort was on getting it to work, not managing memory.) Below are a few suggestions what could be done to improve the memory handling.

* Profile OpenRocket's memory usage to find potential leaks
* Implement a scheduled task that checks the memory usage every ten seconds or so
** Warn the user if 90% of available memory has been used
** Offer to send memory profiling data automatically to developers (?)

== Aerodynamic computation enhancements ==

While OpenRocket produces reasonably accurate results for typical model rockets, there are many cases which are in need of expert attention.

In most cases the implementation can be done by the core developers if only clear methods are available!

* Drag and CG estimation at higher supersonic speeds (>1.5M) are currently poor

* Support for additional components, such as external pods and tube fins
** Estimation of CG, CNa and drag coefficient are required

* Roll rate estimation is off by about a factor of two for unknown reasons (see sections 3.3 and 6.3 of the [http://openrocket.sourceforge.net/documentation.html technical documentation])

* Aerodynamic force computation using CFD (computational fluid dynamics)
** Should preferably use some standard package such as [http://www.csc.fi/english/pages/elmer Elmer] or [http://www.openfoam.com/ OpenFOAM]
** Communication either using JNI or stdin/stdout to a standalone executable
** Implementation requires at least:
*** creation of the simulation mesh
*** calling the computational method
*** deducing the forces and moments (preferably being able to separate the contribution of different components)
*** cacheing and interpolating data for efficient simulation
** Visualization would be a great plus!

Feature comparison

2012-01-26T20:40:29Z

Plaa: /* Printing */

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="good" | Yes
|-
! Stability information
| class="good" | Yes
| class="good" | Yes
|-
! Simulation results
| class="good" | Yes
| class="good" | Yes
|-
! Parts list
| class="good" | Yes
| class="good" | Yes
|-
! Component templates
| class="okay" | Nose cone, fin sets
| class="good" | Nose cone, fin sets, centering rings
|-
! Fin placement guide
| class="good" | Yes
| class="bad" | No
|-
! Export to PDF
| class="good" | Yes
| class="bad" | No
|}

Feature comparison

2012-01-26T20:28:33Z

Plaa: /* UI features */

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Side and top only
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T20:26:34Z

Plaa: /* Optimization and analysis */

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Two directions
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes, per component
| class="okay" | Yes, per stage
|-
! Drag analysis
| class="good" | Yes, per component
| class="poor" | Yes, per stage
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T20:22:02Z

Plaa:

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Any angle
| class="poor" | Two directions
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes
| class="unknown" | ?
|-
! Drag analysis
| class="good" | Yes, per component
| class="unknown" | ?
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T19:02:04Z

Plaa:

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $124
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Yes
| class="unknown" | ?
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Asymmetric fin configurations
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! Ring-tail fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="good" | Yes
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes
| class="unknown" | ?
|-
! Drag analysis
| class="good" | Yes, per component
| class="unknown" | ?
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T18:52:11Z

Plaa: description

This page provides a side-by-side feature comparison of '''OpenRocket''' and '''RockSim'''. Both represent the latest version of the software.

While hosted on the OpenRocket wiki site, we have attempted to make this an objective comparison between the functionality of the two software products. If you think something is wrong or omitted, please [[User:Plaa|contact us]].

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $120
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Yes
| class="unknown" | ?
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="unknown" | ?
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes
| class="unknown" | ?
|-
! Drag analysis
| class="good" | Yes, per component
| class="unknown" | ?
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T18:48:01Z

Plaa: styling

== General ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $120
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

== UI features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="good" | Yes
| class="unknown" | ?
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

== Design features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="poor" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

== Simulation features ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="unknown" | ?
|}

== Optimization and analysis ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes
| class="unknown" | ?
|-
! Drag analysis
| class="good" | Yes, per component
| class="unknown" | ?
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

== Printing ==

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Feature comparison

2012-01-26T18:00:41Z

Plaa: initial page

=== General ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! License
| class="good" | Open Source (GPLv3)
| class="poor" | Proprietary
|-
! Price
| class="good" | Free
| class="poor" | $120
|-
! Supported platforms
| class="good" | Windows, Mac, Linux
| class="okay" | Windows, Mac
|-
! Supported file formats
| class="good" | ORK, RKT
| class="poor" | RKT
|}

=== UI features ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Side/back view
| class="good" | Yes
| class="good" | Yes
|-
! 3D view
| class="bad" | No
| class="good" | Yes
|-
! Design view rotation
| class="best" | Yes
| class="unknown" | ?
|-
! Live CG/CP view
| class="good" | Yes
| class="good" | Yes
|-
! Realtime simulation
| class="good" | Yes
| class="bad" | No
|}

=== Design features ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Basic components
| class="good" | Yes
| class="good" | Yes
|-
! Freeform fins
| class="good" | Yes
| class="good" | Yes
|-
! Tube fins
| class="bad" | No
| class="good" | Yes
|-
! External pods
| class="bad" | No
| class="good" | Yes
|-
! Canted fins / roll stabilization
| class="good" | Yes
| class="bad" | No
|-
! Standard component libraries
| class="bad" | No
| class="good" | Yes
|-
! Decals
| class="bad" | No
| class="good" | Yes
|-
! Clustering support
| class="good" | Yes, modifiable
| class="pood" | Yes, one-time wizard
|-
! Staging support
| class="good" | Yes, unlimited
| class="okay" | Yes, 3 stages
|}

=== Simulation features ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Degrees of freedom
| class="good" | 6DOF
| class="okay" | 4DOF
|-
! Supersonic simulation
| class="poor" | Limited accuracy
| class="good" | Yes
|-
! Geodetic calculation (Earth coordinates, coriolis effect)
| class="good" | Yes
| class="bad" | No
|-
! Simulations extensible by own code
| class="good" | Yes
| class="bad" | No
|-
! Simulation animation
| class="bad" | No
| class="good" | Yes
|-
! Plotting any simulated variables
| class="good" | Yes
| class="good" | Yes
|-
! Exporting simulated data
| class="good" | Yes
| class="unknown" | ?
|}

=== Optimization and analysis ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! General design optimization
| class="good" | Yes
| class="bad" | No
|-
! Mass optimization
| class="okay" | Yes (using general optimizer)
| class="good" | Yes
|-
! Stability analysis
| class="good" | Yes
| class="unknown" | ?
|-
! Drag analysis
| class="good" | Yes, per component
| class="unknown" | ?
|-
! Roll analysis
| class="good" | Yes
| class="bad" | No
|}

=== Printing ===

{| class="comparison"
!
! width="20%" | OpenRocket
! width="20%" | RockSim
|-
! Schematic view
| class="good" | Yes
| class="unknown" | ?
|-
! Stability information
| class="good" | Yes
| class="unknown" | ?
|-
! Basic simulation results
| class="good" | Yes
| class="unknown" | ?
|-
! Parts list
| class="good" | Yes
| class="unknown" | ?
|-
! Nose cone profile
| class="good" | Yes
| class="unknown" | ?
|-
! Fin templates
| class="good" | Yes
| class="unknown" | ?
|-
! Fin placement guide
| class="good" | Yes
| class="unknown" | ?
|-
! Export to PDF
| class="good" | Yes
| class="unknown" | ?
|}

Main Page

2012-01-26T17:59:34Z

Plaa: feature comparison page

This is the wiki for OpenRocket, an open-source model rocket simulator. The OpenRocket documentation is written collaboratively here.

The main web site for OpenRocket is '''http://openrocket.sourceforge.net/'''

== English ==
=== OpenRocket Documentation ===

* [[User's Guide]]

* [[Feature comparison]]

* [[FAQ|Frequently asked questions]]

* [[Tips]]

* [http://openrocket.sourceforge.net/documentation.html Technical Documentation]

* [[Scripting with Python and JPype]]

* [[Resources]]

=== Developer resources ===

* [[Developer's Guide]]

* [[Creating guided tours]]

* [[Feature wishlist]]

== Français ==
=== Documentation d'OpenRocket ===

* [[Guide utilisateur]]

* [[Questions posées fréquemment]]

* [[Truc et astuces]]

* [http://openrocket.sourceforge.net/documentation.html Documentation Technique]

* [["Scripter" avec Python et JPype]]

* [[Ressources]]

=== Ressources pour les développeurs ===

* [[Guide du développeur]]

* [[Créer des tours d'horizon]]

* [[Fonctionnalités souhaitées]]

== Español ==
=== OpenRocket Documentación ===

* [[Guía del Usuario]]

* [[Preguntas frecuentes]]

* [[Consejos]]

* [http://openrocket.sourceforge.net/documentation.html Documentación Técnica]

* [[Recursos]]

=== Developer resources ===

* [[Guía del desarrollador]]

* [[Lista de futuras mejoras]]

== Italiano ==
=== Documentazione di OpenRocket ===

* [[Manuale dell'utente]]

* [[FAQ|Domande più frequenti]]

* [[Consigli]]

* [http://openrocket.sourceforge.net/documentation.html Documentazione tecnica]

* [[Programmando con Python e JPype]]

* [[Risorse]]

Main Page

2012-01-20T19:04:51Z

Plaa: reordering

This is the wiki for OpenRocket, an open-source model rocket simulator. The OpenRocket documentation is written collaboratively here.

The main web site for OpenRocket is '''http://openrocket.sourceforge.net/'''

== English ==
=== OpenRocket Documentation ===

* [[User's Guide]]

* [[FAQ|Frequently asked questions]]

* [[Tips]]

* [http://openrocket.sourceforge.net/documentation.html Technical Documentation]

* [[Scripting with Python and JPype]]

* [[Resources]]

=== Developer resources ===

* [[Developer's Guide]]

* [[Creating guided tours]]

* [[Feature wishlist]]

== Français ==
=== Documentation d'OpenRocket ===

* [[Guide utilisateur]]

* [[Questions posées fréquemment]]

* [[Truc et astuces]]

* [http://openrocket.sourceforge.net/documentation.html Documentation Technique]

* [["Scripter" avec Python et JPype]]

* [[Ressources]]

=== Ressources pour les développeurs ===

* [[Guide du développeur]]

* [[Créer des tours d'horizon]]

* [[Fonctionnalités souhaitées]]

== Español ==
=== OpenRocket Documentación ===

* [[Guía del Usuario]]

* [[Preguntas frecuentes]]

* [[Consejos]]

* [http://openrocket.sourceforge.net/documentation.html Documentación Técnica]

* [[Recursos]]

=== Developer resources ===

* [[Guía del desarrollador]]

* [[Lista de futuras mejoras]]

Main Page

2011-12-20T04:09:40Z

Plaa: reordering

This is the wiki for OpenRocket, an open-source model rocket simulator. The OpenRocket documentation is written collaboratively here.

The main web site for OpenRocket is '''http://openrocket.sourceforge.net/'''

== OpenRocket Documentation (English) ==

* [[User's Guide]]

* [[FAQ|Frequently asked questions]]

* [[Tips]]

* [http://openrocket.sourceforge.net/documentation.html Technical Documentation]

* [[Resources]]

== Developer resources (English) ==

* [[Developer's Guide]]

* [[Creating guided tours]]

* [[Feature wishlist]]

== Documentation d'OpenRocket (Français) ==

* [[Guide utilisateur]]

* [[Questions posées fréquemment]]

* [[Truc et astuces]]

* [http://openrocket.sourceforge.net/documentation.html Documentation Technique]

* [[Ressources]]

== Ressources pour les développeurs (Français) ==

* [[Guide du développeur]]

* [[Fonctionnalités souhaitées]]

== OpenRocket Documentación (Español) ==

* [[Guía del Usuario]]

* [[Preguntas frecuentes]]

* [[Consejos]]

* [http://openrocket.sourceforge.net/documentation.html Documentación Técnica]

* [[Recursos]]

== Developer resources (Español) ==

* [[Guía del desarrollador]]

* [[Lista de futuras mejoras]]

Tips

2011-12-18T05:57:35Z

Plaa:

This page collects a list of short (1-3 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.
* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''
* The component tree will display any component comments as tool tips. You can set the comment on the '''Comment''' tab of the component configuration dialog.

Tips

2011-11-17T21:24:03Z

Plaa:

Tips

2011-11-17T21:16:56Z

Plaa: tips page

This page collects a list of short (1-2 sentences) tips for using OpenRocket. Later on they may be included in the software as a "tip of the day" system.

* Motors can be attached to either body tubes or inner tubes. You can attach one on the '''Motor''' tab of the configuration dialog.
* You can scale a single component or an entire design using '''Edit''' → '''Scale...'''

Main Page

2011-11-17T21:12:44Z

Plaa: tips link

Main Page

2011-11-17T21:08:19Z

Plaa:

Main Page

2011-11-17T21:06:10Z

Plaa: separate english + spanish

FAQ

2011-11-17T19:13:52Z

Plaa: /* What information is stored during automatic update checks? */

{{Access}}

This page lists various frequently asked questions. Most of these are categorized as "How to" questions for various design issues.

== Using OpenRocket ==

=== How to use motor configurations? ===

OpenRocket uses the notion of '''motor configurations''' for rocket designs. Each motor configuration corresponds to a configuration you are planning on launching your rocket with. For example for a simple small rocket you could define three configurations, one using an A8-3 motor, one using a B4-4 motor, and one using a C6-3 motor. For a multi-stage or clustered rocket you can define and experiment with many other motor configurations easily and switch between them. You can define any number of motor configurations for a rocket design.

In the rocket design window, you can select which motor configuration is displayed in the figure by the dropdown labeled '''Motor configuration'''. Every design has a configuration named ''[No motors]'' in addition to the user-defined configurations, which contains no motors.

You can configure all aspects of motor configurations in the '''Edit motor configurations''' dialog. It can be opened from any motor configuration selector.

=== How do I define motors? ===

Defining motors and simulating using them in OpenRocket requires three steps: defining which components function as motor mounts, defining the different motor configurations, and defining which motor configuration to use in a particular simulation.

OpenRocket supports attaching motors in either body tubes or inner tubes. To make a component be a motor mount, open the configuration dialog for that component, move to the '''Motor''' tab and tick the box ''This component is a motor mount''. After that you can select motors for different motor configurations on the same tab. See [[#How to use motor configurations?]] for details on motor configurations.

Last, when you create a new simulation, you need to select which motor configuration it uses. This is done from the ''Motor configuration'' dropdown of the '''Launch conditions''' tab. The default motor configuration is the currently selected configuration of the design figure.

=== How do I create a clustered rocket? ===

Clusters can be created using the '''Cluster''' tab of an Inner tube. This allows you to cluster the inner tubes in various configurations, distances and angles. The motor selected for the inner tube will be used for all the inner tubes in the cluster, and any components (such as engine blocks) attached to the inner tube will be replicated for all of the inner tubes.

If you need more fine-grained control on what components are in which tubes, you can create the cluster this way and then split the cluster into individual components by clicking ''Split cluster''. You can then modify the individual components of the cluster. Note that you cannot re-assemble a split cluster (except with undo).

Note that you can create clusters of clusters by attaching inner tubes to other inner tubes, but ''the motors attached to such configurations will not be counted up correctly!'' This is a known bug that will be addressed in later versions.

The cluster techniques can also be combined with a [[#How do I create a staged rocket?|staged rocket]].

=== How do I create a staged rocket? ===

First, the components belonging to different stages must be attached to separate stage components. You can add stages to the rocket by clicking the ''New stage'' button on the main design window. Stages are always used from the lowest to the highest, and when an upper-stage motor ignites all lower stages are automatically dropped off.

The motor ignition event can be selected on the '''Motor''' tab of the body tubes or inner tubes. The default is ''Automatic'', which is suitable for small rockets, where the ejection charge of the lower stage lights up the upper stage motors. The lowest stage will be ignited at launch.

In larger staged rockets that don't have ejection charges the ignition event must be changed. The first stage to light up should ignite at ''Launch'' (or ''Automatic''). If the latter stages are ignited by an onboard computer that detects deceleration, they should be set to ''First burnout of previous stage''. (Note that this assumes the lower stage motors have equal burn lengths.) If the latter stage is ignited by a timer, the event should be set to ''Launch'' and a suitable delay added.

Each of the events can take an additional delay parameter. This allows taking into account for example the time for an ejection charge to light up the next stage or the time for an onboard computer to ignite the next stage. It can also be used for timed ignition, by setting the ejection event to ''Launch'' plus ''n'' seconds.

The staging techniques can also be combined with a [[#How do I create a clustered rocket?|clustered rocket]].

=== How do I create external pods to the rocket? ===

External pods are currently not supported by OpenRocket. This feature has been considered, but it requires more knowledge of how to reliably simulate such configurations. If you know about such simulation or would like to implement it, please [http://openrocket.sourceforge.net/contact.html contact us]!

Note that even though inner tubes can be displaced outside of the body tube, ''they will not affect the aerodynamics of the rocket''. This can provide a visual clue of what such a rocket would look like, but does not provide simulation accuracy. Similarly, extremely thick fins are still considered as fins, and won't likely produce reliable results.

=== How do I add motors to the database? ===

'''Since version 1.1.1''' you can define external files to be loaded into the thrust curve database. There are two ways to add the files:

* Copy the files to the OpenRocket configuration directory. This is environment-specific: 
{| border="1" style="margin-left: 2em"
| '''Windows:'''
| <tt>C:\Documents and Settings\username\Application Data\OpenRocket\ThrustCurves\</tt> or
<tt>C:\Users\username\AppData\Roaming\OpenRocket\ThrustCurves</tt> (typical)
|-
| '''Linux:'''
| <tt>~/.openrocket/ThrustCurves/</tt>
|-
| '''Mac OS X:'''
| <tt>~/Library/Application Support/OpenRocket/ThrustCurves/</tt>
|}

'''OR'''

* Instruct OpenRocket to load the files from another location. This can be done on the "Options" tab from the preferences.

Thrust curves can be loaded from RASP motor files (.eng), RockSim engine files (.rse) or ZIP archives containing the same.

'''Prior to version 1.1.1''' thrust curves needed to be added to the JAR file itself. The motors are loaded from the JAR file directory <tt>datafiles/thrustcurves/</tt>. Adding motor files in this directory will allow OpenRocket to load them. These can be added either from the command line using jar or by WinZip (though see the notes at [http://en.wikipedia.org/wiki/JAR_(file_format)#Problems_with_the_JAR_format Problems with the JAR format]).

== Other ==

=== What information is stored during automatic update checks? ===

When checking for updates, OpenRocket sends some non-personal information about the current installation. This information is used for statistical purposes (such as estimating what kind of load would be expected to [http://www.thrustcurve.org/ thrustcurve.org] when integrating with it, what Java versions should be supported, how much effort should be spent on parallelization, to what languages the software should be localized etc.) and also to quench the curiosity of the developers. We don't get any payment for the work we do, so knowing how much the software is used may help in motivating further development. :)

The information stored during the checks are:

# The OpenRocket version and build source (default JAR file or some Linux distribution for instance)
# A randomly-generated ID for the installation (does not contain any information about the user or system)
# The operating system name and computer architecture
# The Java runtime vendor and Java runtime version
# The country and locale of the user
# The number of processors in the computer
# The time when the check was made

Note that the user's IP address is ''not'' stored with this information. The IP address is likely stored in the Sourceforge web access logs, but the developers do not have access to this information.

The automatic checks for updates can be disabled in the '''Options''' tab of the preferences dialog.

=== Where to ask more information? ===

The best place to ask questions is the [https://sourceforge.net/apps/phpbb/openrocket/ OpenRocket forums], where other people can also answer and see the answers.

Other contact information can be found on the [http://openrocket.sourceforge.net/contact.html contact info page].

FAQ

2011-11-17T19:10:42Z

Plaa: /* How do I add motors to the database? */ clearing doc

{{Access}}

This page lists various frequently asked questions. Most of these are categorized as "How to" questions for various design issues.

== Using OpenRocket ==

=== How to use motor configurations? ===

OpenRocket uses the notion of '''motor configurations''' for rocket designs. Each motor configuration corresponds to a configuration you are planning on launching your rocket with. For example for a simple small rocket you could define three configurations, one using an A8-3 motor, one using a B4-4 motor, and one using a C6-3 motor. For a multi-stage or clustered rocket you can define and experiment with many other motor configurations easily and switch between them. You can define any number of motor configurations for a rocket design.

In the rocket design window, you can select which motor configuration is displayed in the figure by the dropdown labeled '''Motor configuration'''. Every design has a configuration named ''[No motors]'' in addition to the user-defined configurations, which contains no motors.

You can configure all aspects of motor configurations in the '''Edit motor configurations''' dialog. It can be opened from any motor configuration selector.

=== How do I define motors? ===

Defining motors and simulating using them in OpenRocket requires three steps: defining which components function as motor mounts, defining the different motor configurations, and defining which motor configuration to use in a particular simulation.

OpenRocket supports attaching motors in either body tubes or inner tubes. To make a component be a motor mount, open the configuration dialog for that component, move to the '''Motor''' tab and tick the box ''This component is a motor mount''. After that you can select motors for different motor configurations on the same tab. See [[#How to use motor configurations?]] for details on motor configurations.

Last, when you create a new simulation, you need to select which motor configuration it uses. This is done from the ''Motor configuration'' dropdown of the '''Launch conditions''' tab. The default motor configuration is the currently selected configuration of the design figure.

=== How do I create a clustered rocket? ===

Clusters can be created using the '''Cluster''' tab of an Inner tube. This allows you to cluster the inner tubes in various configurations, distances and angles. The motor selected for the inner tube will be used for all the inner tubes in the cluster, and any components (such as engine blocks) attached to the inner tube will be replicated for all of the inner tubes.

If you need more fine-grained control on what components are in which tubes, you can create the cluster this way and then split the cluster into individual components by clicking ''Split cluster''. You can then modify the individual components of the cluster. Note that you cannot re-assemble a split cluster (except with undo).

Note that you can create clusters of clusters by attaching inner tubes to other inner tubes, but ''the motors attached to such configurations will not be counted up correctly!'' This is a known bug that will be addressed in later versions.

The cluster techniques can also be combined with a [[#How do I create a staged rocket?|staged rocket]].

=== How do I create a staged rocket? ===

First, the components belonging to different stages must be attached to separate stage components. You can add stages to the rocket by clicking the ''New stage'' button on the main design window. Stages are always used from the lowest to the highest, and when an upper-stage motor ignites all lower stages are automatically dropped off.

The motor ignition event can be selected on the '''Motor''' tab of the body tubes or inner tubes. The default is ''Automatic'', which is suitable for small rockets, where the ejection charge of the lower stage lights up the upper stage motors. The lowest stage will be ignited at launch.

In larger staged rockets that don't have ejection charges the ignition event must be changed. The first stage to light up should ignite at ''Launch'' (or ''Automatic''). If the latter stages are ignited by an onboard computer that detects deceleration, they should be set to ''First burnout of previous stage''. (Note that this assumes the lower stage motors have equal burn lengths.) If the latter stage is ignited by a timer, the event should be set to ''Launch'' and a suitable delay added.

Each of the events can take an additional delay parameter. This allows taking into account for example the time for an ejection charge to light up the next stage or the time for an onboard computer to ignite the next stage. It can also be used for timed ignition, by setting the ejection event to ''Launch'' plus ''n'' seconds.

The staging techniques can also be combined with a [[#How do I create a clustered rocket?|clustered rocket]].

=== How do I create external pods to the rocket? ===

External pods are currently not supported by OpenRocket. This feature has been considered, but it requires more knowledge of how to reliably simulate such configurations. If you know about such simulation or would like to implement it, please [http://openrocket.sourceforge.net/contact.html contact us]!

Note that even though inner tubes can be displaced outside of the body tube, ''they will not affect the aerodynamics of the rocket''. This can provide a visual clue of what such a rocket would look like, but does not provide simulation accuracy. Similarly, extremely thick fins are still considered as fins, and won't likely produce reliable results.

=== How do I add motors to the database? ===

'''Since version 1.1.1''' you can define external files to be loaded into the thrust curve database. There are two ways to add the files:

* Copy the files to the OpenRocket configuration directory. This is environment-specific: 
{| border="1" style="margin-left: 2em"
| '''Windows:'''
| <tt>C:\Documents and Settings\username\Application Data\OpenRocket\ThrustCurves\</tt> or
<tt>C:\Users\username\AppData\Roaming\OpenRocket\ThrustCurves</tt> (typical)
|-
| '''Linux:'''
| <tt>~/.openrocket/ThrustCurves/</tt>
|-
| '''Mac OS X:'''
| <tt>~/Library/Application Support/OpenRocket/ThrustCurves/</tt>
|}

'''OR'''

* Instruct OpenRocket to load the files from another location. This can be done on the "Options" tab from the preferences.

Thrust curves can be loaded from RASP motor files (.eng), RockSim engine files (.rse) or ZIP archives containing the same.

'''Prior to version 1.1.1''' thrust curves needed to be added to the JAR file itself. The motors are loaded from the JAR file directory <tt>datafiles/thrustcurves/</tt>. Adding motor files in this directory will allow OpenRocket to load them. These can be added either from the command line using jar or by WinZip (though see the notes at [http://en.wikipedia.org/wiki/JAR_(file_format)#Problems_with_the_JAR_format Problems with the JAR format]).

== Other ==

=== What information is stored during automatic update checks? ===

When checking for updates, OpenRocket sends some non-personal information about the current installation. This information is used for statistical purposes (such as estimating what kind of load would be expected to [http://www.thrustcurve.org/ thrustcurve.org] when integrating with it, what Java versions should be supported, how much effort should be spent on parallelization, to what languages the software should be localized etc.) and also to quench the curiosity of the developers. We don't get any payment for the work we do, so knowing how much the software is used may help in motivating further development. :)

The information stored during the checks are:

# The OpenRocket version and build source (default JAR file or some Linux distribution for instance)
# A randomly-generated ID for the installation (does not contain any information about the user or system)
# The operating system name and computer architecture
# The Java runtime vendor and Java runtime version
# The country, time zone and locale of the user (provides location information within about 500-1000 km)
# The number of processors in the computer
# The time when the check was made

Note that the user's IP address is ''not'' stored with this information. The IP address is likely stored in the Sourceforge web access logs, but the developers do not have access to this information.

The automatic checks for updates can be disabled in the '''Options''' tab of the preferences dialog.

=== Where to ask more information? ===

The best place to ask questions is the [https://sourceforge.net/apps/phpbb/openrocket/ OpenRocket forums], where other people can also answer and see the answers.

Other contact information can be found on the [http://openrocket.sourceforge.net/contact.html contact info page].

Developer's Guide

2011-11-09T21:08:52Z

Plaa: updated SVN instructions

{{Access}}

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 [http://openrocket.sourceforge.net/documentation.html Technical documentation] chapter 5.

== Obtaining the source code ==

OpenRocket is primarily developed using [http://www.eclipse.org/ Eclipse], and it's the recommended IDE for compatibility. Developers are free to use other IDE's, but everything may not work out-of-the-box.

You need to install either [http://subclipse.tigris.org/ Subclipse] or [http://www.eclipse.org/subversive/ Subversive] SVN client plugin to Eclipse. Follow the instructions on their pages. The two plugins are relatively similar, but the documentation below uses the terminology of Subclipse.

After you have installed Subclipse, select File -> Import, select "Checkout Projects from SVN" under "SVN" and click Next. You need to create a new repository location using the URL https://openrocket.svn.sourceforge.net/svnroot/openrocket. Next, select the folder "trunk" (this is the base development branch) and click Finish. After loading you should have the full source in a ready project.

'''Note:''' The source packages available on the OpenRocket web site (*.zip) are meant for building the application from source code, '''NOT''' for development purposes. They do not contain all the project files etc.

For those who want to use the command-line, the OpenRocket trunk can be retrieved by simply:

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

=== Notes for Newer Eclipse Users ===
You can get the Galileo version of Eclipse from the [http://www.eclipse.org/downloads/ 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.

{|
| [[File:CompilerComplianceLevel.png|none|200px]]
| [[File:JavaBuildPath.png|none|200px]]
|}

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

== Running OpenRocket from Eclipse ==

After importing the project into Eclipse the 3rd party libraries should be automatically configured correctly. One additional step is required in order for OpenRocket to find the build.properties file for running OpenRocket.

# Open the class net.sf.openrocket.startup.Startup. Running this directly fails due to missing build.properties file.
# Select Run As -> Run Configurations...
# On the Classpath tab click on User entries, then click Advanced... -> Add Folders -> Select the OpenRocket base directory and click OK
# Click Run

This adds the base directory to the classpath, which is required for running OpenRocket. Unfortunately Eclipse does not support adding a general data directory to the default project classpath.

== 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:

* <code>// TODO: CRITICAL: Some comment</code> 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.
* <code>// TODO: HIGH: Some comment</code> An important issue that should be looked into within this or the next major release.
* <code>// TODO: MEDIUM: Some comment</code> Something that would make the software better, but does not represent a problem as such.
* <code>// TODO: LOW: Some comment</code> 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 <tt>net.sf.openrocket.unit</tt>. The <tt>Unit</tt> 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 <tt>UnitGroup</tt> 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
<tt>net.sf.openrocket.file</tt> and subpackages. To implement a new
document loader it is necessary to extend the class <tt>RocketLoader</tt> and
implement the abstract method <tt>loadFromStream(InputStream)</tt>. This
method simply loads the document and returns an <tt>OpenRocketDocument</tt>
object.

An <tt>OpenRocketDocument</tt> 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 <tt>RocketComponents</tt>.
All of the components are in the package <tt>.rocketcomponent</tt>. 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 <tt>.file.simplesax</tt>. The primary class
that will be extended is <tt>ElementHandler</tt>, which contains three methods.
<tt>openElement()</tt> is called when a new subelement is found, and it
returns a new <tt>ElementHandler</tt> to handle that element (which can be the
object itself), or <tt>null</tt> in order to ignore that element and all of its
contents (for example for unknown elements). <tt>closeElement()</tt> is called
when the subelement ends, and <tt>endHandler()</tt> 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 <tt>PlainTextHandler</tt>. This handler accepts only text content and
ignores all subelements. If the XML file contains
<nowiki><element>value</element></nowiki>, then the handler can return a
<tt>PlainTextHandler</tt> and handle the content within the <tt>closeElement()</tt>
method, removing the need to write a specialized handler for that
element.

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

The OpenRocket document loading is implemented in
<tt>.file.openrocket.OpenRocketLoader</tt>. 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 [http://openrocket.svn.sourceforge.net/viewvc/openrocket/trunk/fileformat.txt fileformat.txt file in SVN].
''Italic text''