I'm going to have to spend some time with this. I think they probably shouldn't be shown all the time, although we didn't really come to agreement on exactly when. Definitely when selected... IMHO that is sufficient but others may not agree.

What about boosters? They're basically the same thing as pods, and could use a similar marker but different enough to be distinguishable.

What about boosters? They're basically the same thing as pods, and could use a similar marker but different enough to be distinguishable.

Also had the same thought, but don't know yet how we could distinguish them. I quite like the current marker shape, so I would preferably not change that too much. Maybe instead instead of using a plain grey marker, we can add a slight hue, for instance blue-greyish for pods and bordeau-greyish for boosters?

I'm still testing, but had a question. In back view, the marker that is in the center of the body tube, what is it's purpose? It acts like the "Center of the parent compnent" even when "Surface of the parent component" is selected. Is this the correct behavior?

I'm still testing, but had a question. In back view, the marker that is in the center of the body tube, what is it's purpose? It acts like the "Center of the parent compnent" even when "Surface of the parent component" is selected. Is this the correct behavior?

Good point. Come to think of it, do we even want/need the center marker in the side view? Because it doesn't give extra info that you can't get from the other markers and could even be confusing because of it uselessness.

I would say no, it serves no useful purpose where every pod spins around the center point and only the distance measurement changes, either measured from the "Center of the parent compnent" or from the "Surface of the parent component."

First of all, let me say that I really like the look and feel of the markers (and the way the markers auto size), and the markers function as I would have expected.

Insofar as visibility is concerned, I’m glad to see that the markers do not appear in the 3D views. As for visibility in the 2D views, I would suggest that one or more of the follow would be options:

1. A pod marker is only visible when that pod is selected, and children pods would also be visible when the parent pod is selected.
2. A pod marker is only visible when the box for visibility is checked on that pod set configuration pane.
3. A pod marker is only visible when the box for visibility is checked on the application preference pane for pod visibility.
4. A pod marker is only visible when the box for visibility is checked on the display window bar (similar to CG/CP).

My order of preference would be 4, 2, 3, but, in any case, if the one decided upon (2, 3 or 4) is set not to show the markers, then 1 would still display the markers when a pod is active/selected. My second choice would be 1, 4, 2, 3.

1. A pod marker is only visible when that pod is selected, and children pods would also be visible when the parent pod is selected.

This is my preference. The marker's purpose is to give a visual indication of where the pod instances are located (and also to help new users grasp the purpose of pods). You do not need that indication when the podset is not selected. It also eliminates the need for extra preferences because the preference would have been there for users who do not want to display the markers. If they do not want to display the markers, then they should just not select the podset.

So my proposition for a change for this PR is:

1. Remove the center marker and only keep pod instance markers, because it simply serves no use and could therefore be confusing
2. Only display the markers when the podset is selected
3. Also add markers for boosters, but with the podset markers having a blue-greyish color, and the boosters having a bordeau-greyish color

This is my preference. The marker's purpose is to give a visual indication of where the pod instances are located (and also to help new users grasp the purpose of pods). You do not need that indication when the podset is not selected. It also eliminates the need for extra preferences because the preference would have been there for users who do not want to display the markers. If they do not want to display the markers, then they should just not select the podset.

The only disadvantage I see with this is that you cannot select a podset from the design view (you can't select the markers).

The only disadvantage I see with this is that you cannot select a podset from the design view (you can't select the markers).

I don't really see this as a significant disadvantage where a user would most likely be selecting a component of the pod, not the pod itself.

Okay, current behavior now looks like this (as described above):

Functions as described, no anomalies found. Looks really nice.

Build 804
[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)]

Very nice indeed! Comparing builds 802 and 804, my vote is (1) don't show the centered marker; as stated it serves no purpose and is confusing, and (2) show the markers whether selected or not. We have users who want to make selections in the design window... I'm actually a lot less opposed to having those markers show up whether the pod is empty or not, now that I see them in action.

@JoePfeiffer, is making the markers all visible by selecting the primary element (The rocket or stage) sufficient for you, or do you want the markers on all of the time? The pods can also be individually selected in the 2D pane after the primary element is selected.

I tested a number of TRF user designs that have nested pods, and showing all of the pod markers at one time became distracting. If you prefer making the markers all visible all of the time (whether selected or not), I believe that 4 above should also be implemented as stated below; I believe that there are many users that use/exchange screen grabs of the 2D views in which these users would not want the markers to appear.

[I]f the one decided upon (2, 3 or 4) is set not to show the markers, then I would still display the markers when a pod is active/selected.

In 4, the same checkbox would control both pods and boosters, the same as CG and CP.

I was thinking something like this for the implementation of 4:

The markers are really more closely associated with manipulating components than displays generally.

I gotta say I'm not a huge fan of putting a preference checkbox for it in OR's main window for two reasons:

1. It's not a general feature you're enabling/disabling. It only matters for those design that contain pod sets, and could therefore confuse users. Contrary to the checkbox for showing/hiding the CG/CP marker, which holds up for every design.
2. I think disabling/enabling the markers is not an often repeated action, so the majority of the time it will just take up space in the main window, with people hardly or not using it. Granted, the CG/CP marker also slightly suffers from this (although probably used more frequently than hiding the markers), but I still have my first argument to back up the CG/CP checkbox's existence 😉

I was contemplating @hcraigmiller's option 2 - adding a checkbox in the podset configuration window - for a while, but don't think that's the way to go. Adding the checkbox in a pod set's configuration window should effect to only changing the marker visibility for that pod set, not for any other pod set in the design. And that would just be overcomplicating an infrequently used feature...

Instead I would boil it down to only one checkbox in the application preferences of 'Show markers for pod/booster instances'. KISS (Keep It Simple Stupid) 💋

I'm okay with that.

Of course that's all in the assumption that we want the scenario of the markers being always, regardless of the pod set's selection state.

My opinion has been on a rollercoaster this PR, but you just gain new insights and experience when playing around with the different builds, but: I now think it's best to display the markers permanently, simply for the reason that when you click away from the pod set and the markers disappear, it almost feels like a bug. No other component has the behavior of the shape disappearing when you deselect the object, so the 'only display the markers when the podset is selected' can cause confusion...

Because I share screen grabs, I don't want the markers to be visible, except when the pod set is selected. I think being able to turn the markers off in preferences, but still being able to see the markers when the pod is selected in the tree is a huge benefit. Having to go to preferences every time I want to see the markers would be really annoying. I don't think it will look like a bug, I think it's a tremendous benefit.

Insofar as no other conponent having a similar behavior, this behavior is only needed for pods and boosters; no other components have an invisible attachment point.

My thoughts.

I agree with what Craig says above. The markers should always be visible when selected. The only question is when else to show them.

I also agree with Sibo that it should not be an always-visible checkbox. It's not important enough to warrant that kind of prime placement.

I think (1) always show when selected, and (2) a global checkbox preference that says "always show pods and boosters in rocket figure (or whatever it's actually called) is a very good starting point, and we'll wait for feedback. It's probably not reasonable to expect to be able to nail all the little fiddly UI issues like this on the first try when relying primarily on thought experiments. At some point you have to do user testing. Fortunately, we still have a bit of time to go in the beta period for this release, so we have time to get feedback before finalizing. And then there's nothing stopping us from changing it in the future if we need to.

Last build has the following behavior: always show the markers when the pod set/booster is selected & also show the markers if the pod set/booster is deselected, if the "Only show pod set/booster markers when the pod set/booster is selected" checkbox in the design preferences tab is disabled.

Demo (that also shows that the rocket view in all design windows gets updated when the marker preference changes):

I tested a number of TRF user designs that have nested pods, and showing all of the pod markers at one time became distracting. If you prefer making the markers all visible all of the time (whether selected or not), I believe that 4 above should also be implemented as stated below; I believe that there are many users that use/exchange screen grabs of the 2D views in which these users would not want the markers to appear.

My thought was to have them visible whether selected or not, but only when they have no children. I agree with Neil's earlier comment that they won't end up being visible for very long, since a normal workflow would be to create a pod set, and then start filling it out nearly immediately.

If there were to be a checkbox for "always markers", it should be in the simulation preferences window. I really don't think people are going to be turning it on and off much; they'll select a preference and leave it.

In my opinion it is ironclad that the markers must be shown while the pods are selected. You should always be able to see what you are editing. Beyond that it is murky. I like the current proposal (show while selected, plus global option to show them all the time) as a starting point, and we can refine from there. Personally I kind of think that finer-grained control might be desirable, but it would be mistake to over-complicate the implementation right at the start. Gotta go with the "minimum viable product" mentality here and get some feedback.

The "only show when there are no children" paradigm is broken by phantom tubes, which are necessary as ever when doing fins-on-fins. If the act of adding a phantom tube caused the markers to disappear, then the pods would be completely invisible at that moment.

(It'll be nice if at some point we can eliminate the need for phantom tubes, but that won't be for quite a while I would guess.)

I agree with the comment of @neilweinstock that ultimately user inout will be required if tweaks are to be made to this function as it evolves.

That said, I believe that the functionality of Build 805 is the best place to start, and should be used as the starting point. For those that want to see the markers all of the time, uncheck the box. For those that don't, check the box, but with the benefit of being able to see the markers when a parent of/or the pod is selected; best of both worlds.

My vote is to approve conceptually as is, test, and merge.

Functions as expected, no anomalies found.

Build 805
[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)]

Let's try it and see what the users say.

On phantom body tubes, they also ought to be represented -- maybe simply as a line?

LOL, that's even murkier. I usually set my phantom tubes to length and diameter = 0... that would show up as a single dot?

Oh! The few times I've used them I've set the length to the root chord of the fins I was putting on them.

See #1536.