Analysis from Justin Hanney indicates that the CPU is constantly
processing paint events in the ScaleScrollPane.Ruler. Change the
updateSize method to not revalidate and repaint since the
paintComponent method also invokes the updateSize to ensure it is
drawing components of the right size.
This change also refactors the ChangeListener implementation to
have the RulerClass implement the method instead of using an
anonymous class for event handling when ruler units change.
Additionally, this change adds a revalidate call to the scrollPane
to fix an issue where the ruler is not repainted when switching views
from 3D to 2D.
Fixes#615
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Previously, updateFigure was overridden in RocketFigure in order to
ensure that all component shapes were added to the rocket prior to
calling the paintComponent method. This is superfluous as the
paintComponent method already adds the shapes prior to rendering.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
NoseCones aren't rendered correctly when printing/exporting as PDF
due to the scaleFactor not being honored correctly in TransitionShapes.
There was a good refactor to move some of the scaling pieces out,
however the PrintableNoseCone didn't benefit from these changes.
This restores part of the scaleFactor bits to the TransitionShapes
in order to get the printing to correctly work again. This code should
be transitioned to the new method for scaling.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Stages need to be activated correctly in order to properly
calculate the mass for all components that contribute to
the current launch scenario.
This change ensures that all of the stages from the top-most
stage to the currently active stage are set as activated when
stage mass is being calculated.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Fix the number of motors that are reported. A previous change made
the MotorMount.getMotorCount() return the number of motors which
have been configured. However, according to the javadocs of the
MotorMount interface, the getMotorCount() method is supposed to
return the number of motors that a MotorMount can take for
configuring it. This restores the InnerTube and BodyTube getMotorCount
behavior and adds a new getMotorConfigurationCount() method to
provide the new behavior.
Additionally, the stageMass calculations in the DesignReport were
using a deprecated method which does not return proper component
weights. Change this to use the MassCalculator.calculateLaunch(...)
method, which is consistent with the RocketPanel behavior.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Clean up some of the code in DesignReport, including some
refactoring TODOs in the addMotorData method.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Some refactoring of the code for the RocketFigure class caused
changes which prevent the rocket from being rendered correctly
when printing a report or exporting as PDF. The issue was due
to shapes not being added to the rocket and pixel dimensions
being incorrect for the logic in the DesignReport.
This change ensures that rocket shapes are added when the
RocketFigure's updateFigure method is called. It also modifies
the PrintFigure to expose some of the underlying geometries of
the subject_bounds, which are necessary for the pixel and drawing
calculations used in the DesignReport.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Correct the logic for detecting if a motor has an invalid
FlightConfigurationId and throw an IllegalStateException only in the
case that it has an error.
Additionally, fix the lookup for the stageMass. The wrong value was
passed to the MassCalculator.getCGAnalysis(..) which resulted in
a NullPointerException.
Fixes#531
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
Corrected getPreviousSymmetricComponent and getNextSymmetricComponent to
stop searching and return null when a PodSet is encountered in search (so it
only returns the previous/next component if it's a child of the same pod).
Note this required modifying the function to explicitly get the radius
of the forward symmetric component rather than simply iterating
and assuming components would appear in order (as was the case with
iterating through getActiveComponents()).
The getPreviousSymmetricComponent() method contains a warning that it
doesn't account for external pods, so this will probably need to be
revisited and that method modified.
Commit a7c0cb2 removed the OrangeExtensions-1.2.jar file from the
swing project, but failed to remove it from the eclipse classpath.
This fixes that.
Signed-off-by: Billy Olsen <billy.olsen@gmail.com>
