In that case I would change the text to "Plugged", because that is the primary description of the option in the pull-down selector.

While we're here, should we also put in a bit of text that says you can type a custom value into the combo box as well?

While we're here, should we also put in a bit of text that says you can type a custom value into the combo box as well?

Yes. Aerotech and CTI high power motors all have a procedure to shorten the delay time, so it can be virtually anything the user wants.

New texts:

I was just doing some experimenting with this in 22.02 and found that for motors that offer a plugged option, you can't select it!

Try selecting an Estes A10-P; it immediately reverts to A10-0.

I was also surprised to see that for the A10, the -P option was shown as "Plugged (none)". I thought we were going to leave it at -P, since that is the way the motor is sold.

In other words, the behavior I expected was:

1. If the motor offered a -P option, we left the option list as it was
2. If the motor did not offer a -P option, we added a "plugged (none)" option to the end of the list

And of course, in case 1, it should actually allow you to select -P. :)

Functions as expected, no anomalous behavior found.

OR Build: 1587
Microsoft Windows 11 Pro; 10.0.22621 Build 22621.1105; Windows Feature Experience Pack 1000.22638.1000.0
Java(TM) SE Runtime Environment 18.9 (build 11.0.18+9-LTS-195)

I was just doing some experimenting with this in 22.02 and found that for motors that offer a plugged option, you can't select it!

See my first post, that is fixed in this PR.

I was also surprised to see that for the A10, the -P option was shown as "Plugged (none)". I thought we were going to leave it at -P, since that is the way the motor is sold.

In other words, the behavior I expected was:

1. If the motor offered a -P option, we left the option list as it was
2. If the motor did not offer a -P option, we added a "plugged (none)" option to the end of the list

And of course, in case 1, it should actually allow you to select -P. :)

I don't know if it's a good idea to have two separate plugged naming for the same functionality, may just confuse users. From the perspective of a user, they also don't care if the plugged option comes from the manufacturer, or from us.

What if we change the naming for all scenarios to "-P (Plugged)"?

See my first post, that is fixed in this PR.

Whoops sorry, failed to read the text below the screengrab.

I don't know if it's a good idea to have two separate plugged naming for the same functionality, may just confuse users. From the perspective of a user, they also don't care if the plugged option comes from the manufacturer, or from us.

I disagree with this; the distinction is real and relevant. It is useful to know if a plugged version is commercially available, vs. if it's something I'll need to to myself. To be fair this only applies to a relatively small set of motors.

I will also note that we've had this distinction since forever, and the only problem we've had is that folks didn't realize you could type "none" to create a plugged version of any motor, and we're fixing that now. Of course, the fact that we've been doing it this way is not necessarily a compelling argument to continue.

What if we change the naming for all scenarios to "-P (Plugged)"?

My vote is to retain the existing distinction: -P when the option is in the motor file, and plugged (none) or none (plugged) or whatever when it's an option that we're adding ourselves.

I don't feel extremely strongly about it, though, and will go with consensus. What say you, @JoePfeiffer and @hcraigmiller and @wolsen?

For our purposes, I think it's better to not have the distinction. In addition to whether or not a motor is sold as plugged, we've also got the ones for which plugging is such a routine, manufacturer authorized procedure that it might as well have the option of being sold that way (pretty much all medium and high power motors except the really big ones) vs. motors that users can plug in violation of the safety code (black powder with a -0 delay). What matters to us is just what the delay is, not how it got that way.

Would the text entry prompt be clearer if it said "(or you can type in a desired delay in seconds)"?

I can go along with that, and I like that wording for the text entry prompt.

New text:

I decided on a shorter version of Joe's suggestion, "(or type in a desired delay in seconds)", because otherwise the width of the combobox would become too wide. I can make the combobox width independent of the info text length, but I kinda like that they're the same width, makes it more obvious that they belong together.

I think you can shorten it even a bit more to "or type in desired delay in seconds" (get rid of "a"). Shorter and also better.

Functions as expected, no anomalous behavior found.

OR Build: 1589
Windows 11 Pro; Version 22H2; Build 22621.1265; Windows Feature Experience Pack 1000.22638.1000.0
Java version "11.0.18" 2023-01-17 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.18+9-LTS-195)

I think you can shorten it even a bit more to "or type in desired delay in seconds" (get rid of "a"). Shorter and also better.

Done.

Functions as expected, no anomalous behavior found.

Once this is merged, the motors on a few examples will need to be tweaked.

OR Build: 1596
Windows 11 Pro; Version 22H2; Build 22621.1265; Windows Feature Experience Pack 1000.22638.1000.0
Java version "11.0.18" 2023-01-17 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.18+9-LTS-195)

One more thing -- the plugged ejection charge delay should not appear until a motor is selected (just as the thrust curve selector doesn't).

One more thing -- the plugged ejection charge delay should not appear until a motor is selected (just as the thrust curve selector doesn't).

Fixed now + the delay box is now also disabled, just as the curves widgets are:

Unexpected behavior. It only allows changes in the default delay if there are more than one thrust curves to choose from.

Functions as expected, no anomalous behavior found.

OR Build: 1608
Windows 11 Pro; Version 22H2; Build 22621.1265; Windows Feature Experience Pack 1000.22638.1000.0
Java version "11.0.18" 2023-01-17 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.18+9-LTS-195)

Unexpected behavior. It only allows changes in the default delay if there are more than one thrust curves to choose from.

Wow, sorry wasn't really paying attention, thanks for catching it, should be fixed now.

Functions as expected, no anomalous behavior found.

OR Build: 1609
Windows 11 Pro; Version 22H2; Build 22621.1265; Windows Feature Experience Pack 1000.22638.1000.0
Java version "11.0.18" 2023-01-17 LTS; Java(TM) SE Runtime Environment 18.9 (build 11.0.18+9-LTS-195)