- Creates PNG file filter
- Adds new file filter to translation file
- Makes Exported Chart's Width & Height as it is displayed
- Changes Button From Print Icon to "Save As Image" text
Note that the lowest point on the fin is guaranteed to be either the first point which is at (0, 0) or the last point, which will have a y coordinate of 0 if on a body tube, greater than 0 if on an increasing transition, or less than 0 on a decreasing transition (boattail).
The original plan was that there would be an InstanceContext for every instance of every RocketComponent, with some active and some not (just as RocketComponents may be active or not). The implementation has resulted in InstanceContexts only being created for active RocketComponents, so the active field is superfluous.
If there are multiple independent motor clusters in a stage, each of them can attempt a separation event. When the second event happens, there is no longer an active upper stage, so the separation results in a simulation branch with no active stages. This causes a NaN exception as the mass is 0.
For parallel stages, this is much more likely to be the user's intent. The previous behavior caused stage separation the moment of ignition, so the booster set essentially flew as a second, independent rocket. With this change, the parallel stage stays with the center stack until the ejection charge files (note that OR treats a rocket with a -0 ejection delay as having an ejection charge at motor burnout).
Note that this change to the default behavior is also applied to axial stages, but is also appropriate in that case. For the vast majority of low power rockets, the booster burnout ignites the next stage, so "next stage ignition" and "current stage ejection charge" are simultaneous. For high power rockets, the next stage ignition has to be customized anyway.
This has been lurking -- we're not actually supposed to be calling getAverageThrustThrust when we're past the end of the thrustcurve (there's a test for whether the motor is active before calling it), but another bug in the parallel staging code exposed it.
Instead of requiring motor "designation" to match either the actual designation or the common name, require it to be a substring of the actual designation or that the common name be a substring of the actual designation. Many motors in stored rocket files have "designations" that resemble, but do not match, actual designations and common names.
Don't match on diameter or length when loading files. Motors with errors in the old database (eg M1850) would fail to be recognized.
