Extending OpenRocket - Revision history

Plaa at 15:37, 13 January 2015

2015-01-13T15:37:36Z

← Older revision		Revision as of 15:37, 13 January 2015
Line 87:		Line 87:
	! Description		! Description
	\|-		\|-
	! void startSimulation(SimulationStatus status)		\|
	\| Called when starting a simulation.		void '''startSimulation'''(SimulationStatus status) <br>
			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) <br>
			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) <br>
			AccelerationData postAccelerationCalculation(SimulationStatus status, AccelerationData acceleration)
			\| Called before and after computing acceleration of the
	\|}		\|}

Plaa: Start documenting simulation listeners

2015-01-09T22:17:42Z

Start documenting simulation listeners

← Older revision		Revision as of 22:17, 9 January 2015
Line 70:		Line 70:

	<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>.		<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.
			\|-
			\|}

Plaa at 23:00, 26 December 2014

2014-12-26T23:00:18Z

← Older revision		Revision as of 23:00, 26 December 2014
Line 64:		Line 64:

	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.		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>.

Plaa at 22:21, 26 December 2014

2014-12-26T22:21:05Z

← Older revision		Revision as of 22:21, 26 December 2014
Line 56:		Line 56:

	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.		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.

Plaa at 19:30, 26 December 2014

2014-12-26T19:30:23Z

← Older revision		Revision as of 19:30, 26 December 2014
Line 23:		Line 23:
	Simulation extensions allow modifying simulations before or during a simulation. They allow controlling almost every aspect of a simulation.		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:		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"		{\| class="wikitable"
Line 49:		Line 50:
	\|}		\|}

	~~'''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~~.
			=== 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.

Plaa at 21:11, 25 December 2014

2014-12-25T21:11:47Z

← Older revision		Revision as of 21:11, 25 December 2014
Line 1:		Line 1:

	~~== Extending OpenRocket ==~~

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


	=== Plugins ===		== 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.		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.
Line 21:		Line 19:


	=== Simulation extensions ===		== Simulation extensions ==

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

Plaa at 21:08, 25 December 2014

2014-12-25T21:08:59Z

@@ Line 27: / Line 27: @@
 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.
+{| class="wikitable"
-* 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>.
+! Interface / abstract class
-'''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.
+'''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.

Plaa at 20:47, 25 December 2014

2014-12-25T20:47:28Z

← Older revision		Revision as of 20:47, 25 December 2014
Line 19:		Line 19:

	'''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.		'''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.

Plaa at 19:50, 25 December 2014

2014-12-25T19:50:34Z

← Older revision		Revision as of 19:50, 25 December 2014
Line 10:		Line 10:

	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.		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.		'''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.

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..."

2014-12-25T19:18:09Z

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..."

New page

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

'''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.