Skip to content

Merge upstream unstable changes#12

Open
mishaturnbull wants to merge 5680 commits into
UND-ARC:unstablefrom
openrocket:unstable
Open

Merge upstream unstable changes#12
mishaturnbull wants to merge 5680 commits into
UND-ARC:unstablefrom
openrocket:unstable

Conversation

@mishaturnbull
Copy link
Copy Markdown
Member

Merges a few changes from the upstream repo. Hopefully will have some effect on issue #9.

@mishaturnbull mishaturnbull added the enhancement New feature or request label Mar 4, 2019
SiboVG and others added 29 commits March 27, 2026 12:08
We don't do a good job of modelling body tubes with some sort of opening to the front.  This comes up with things like booster sections post-separation; whatever is used for an interstage will typically have an open forward airframe. It might be interesting to try to model this, but questions of how to account for how deep the recess is at the front would need to be resolved. Maybe someday, not today.

Note that in the special case of a tube fin, which is simply an open cylinder with no internal structure, we do try to model it. But that's not a body tube or other closed symmetric component.

So, at launch and at stage separation time we check for an open forward airframe and flag an info-level warning to let the user know about it.  However, the vast majority of users don't care about simulating a booster post-separation and don't seem to understand that their boosters do in fact have an open forward airframe, so the warning unnecessarily alarms them and we get questions about it. Also, there are many situations where the rocket has much bigger issues and telling them about the open airframe is distracting.

As a result, with this commit we have two sets of heuristics used to filter out the warning.

1) Does the user care?  Within BarrowmanStabilityCalculator, we set the warning if we're analyzing the sustainer (if the user doesn't care what the sustainer does, why are the simulating?), and if the booster has a recovery device -- we're taking this as an indication the user cares what the booster does post-separation.  What this turns into is we only set the warning on booster stages with a recovery device.

2) Does the user have bigger fish to fry?  Here, if the stage (which could be the sustainer or the booster) is unstable it really doesn't matter what the sim says about performance. Also, if either a recovery device has already deployed or is going to deploy within the next half second, it doesn't really matter -- in this case, the user should be much more concerned with their chute shredding!
Since this depends on the current simulation status, this filtering happens in BasicEventSimulationEngine.
This avoids string-concatenated SQL (eliminating the SpotBugs SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE warning) and is consistent with the short, imperative style used in this repo.
Further refinement of open airframe warning filters.
Useful for when we want to implement #2263
SiboVG and others added 30 commits April 18, 2026 14:36
# Conflicts:
#	swing/src/main/java/info/openrocket/swing/gui/simulation/SimulationOptionsPanel.java
[#3120] Fix motor designation and common name handling
Translate messages_zh.properties to Chinese
Reduce profiler hotspots in simulation status, component transforms, and structure mass calculation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants