Initial observation, is this the intended behavior and, if so, why?

• Stage: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.
• Boosters: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.
• Pods: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.

This behavior is different than other otherwise identical component override panes and may cause user confusion.

The Cd override appears to be functioning in all other respects (no anomalous behavior found), though, admittedly, I'm probably not fully knowledgeable in how to best test this feature.

Build 970
[Windows 11 Pro; Version 21H2; OS Build 22000.739; Windows Feature Experience Pack 1000.22000.739.0]
[Java "11.0.15" 2022-04-19 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.15+8-LTS-149)]

Initial observation, is this the intended behavior and, if so, why?

* Stage: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.

* Boosters: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.

* Pods: The "Override mass, CG, and CD of all subcomponents" is checked by default and will not uncheck.

This behavior is different than other otherwise identical component override panes and may cause user confusion.

It is the intended behavior and is also the current behavior. Component assemblies have no physical reality except as "containers" for other components, so setting their CD isn't meaningful except as an override for their subcomponents.

Though, now that you bring it up, we could enable that, and then setting a CD override on a stage (for instance) without overriding subcomponents would act as a "bias" on the calculated CD of the subcomponents.

Though, now that you bring it up, we could enable that, and then setting a CD override on a stage (for instance) without overriding subcomponents would act as a "bias" on the calculated CD of the subcomponents.

That would be a nice additional option of the override feature.

The more I thought about it the more I like the idea. By the time I was done with this PR I wasn't convinced allowing CD overrides was even a good idea, since an overridden CD can't change in the course of a flight like a calculated CD can. Allowing the override on a component assembly to act as an adjustment on its calculated CD does a better job letting users use a test flight to calibrate CD for better predictions of behavior with a different (likely larger) motor.

Functions as expected, no anomalies found.

As an aside, speaking of biasing, this approach allows the user to adjust the rocket's overall mass and CG using an internal mass component, and then jointly use the stage mass and CG overrides together (without affecting subcomponents) to simulate an adjustable nose weight. This and the Cd biasing is going to be a really nice addition to functionality.

Build 971
[Windows 11 Pro; Version 21H2; OS Build 22000.739; Windows Feature Experience Pack 1000.22000.739.0]
[Java "11.0.15" 2022-04-19 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.15+8-LTS-149)]

Will this need special documentation to explain how to use it, or will it be self-explanatory?

Probably both. Checking the override for all subcomponents is self-explanatory. But, the nuances offered by not checking that box, the biasing mentioned by @JoePfeiffer above, will need special documentation/instruction, Wiki, TRF, Facebook, and otherwise.

Thinking about it, a wiki page about how to use overrides would not be a bad idea...

Thinking about it, a wiki page about how to use overrides would not be a bad idea...

Working on it. . . will likely need input and review (on Slack) before posting on Wiki.

Btw good work on this @JoePfeiffer 👍 I know a couple of users who will really appreciate this.