Hiding Compononts in OpenRocket

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

El Phantasmo

Well-Known Member
Joined
Mar 2, 2010
Messages
359
Reaction score
1
I don't see a way to hide components in OpenRocket. Am I missing something? It'd be nice to hide some things to better focus on components you're currently working on or easily see what their effects are. Just in the model view, not the tree view, but the tree view would show you in some manner that the item is hidden. Also, can the hidden item have an option that so long as it's hidden it has no effect on the rocket but resets once unhidden?
 
Hi,

No such functionality in OR at the moment. I've been considering the possibility of adding some sort of support for model variations. This would basically select a rocket design configuration (for example different payloads), in addition to the motor configuration. Any input on how this would best be implemented is welcome.

Cheers,
Sampo N.
 
I've never wanted to hide anything, but I have wanted things like different payloads or different sustainers. For the latter, you could model the booster separate from the sustainer and have a mate surface specified: both front and aft if desired. That way, when you load two different .ork's, their relative position on the design tree would indicate which one's forward and which one's aft mate surfaces to use for positioning.
 
Hi,

No such functionality in OR at the moment. I've been considering the possibility of adding some sort of support for model variations. This would basically select a rocket design configuration (for example different payloads), in addition to the motor configuration. Any input on how this would best be implemented is welcome.

Cheers,
Sampo N.

Sampo,

I've been working on a model that will take a removeable motor mount. The motor mount will be a 2 or 3 or 4 BP engine cluster or a single 29mm APCP motor. What I did to be able to quickly eval different combinations was to treat each motor mount as a Stage. Then I set it as if each motor mount fired at the same time (basically a massive parallel stager), but only loaded engines for one possible combination per simulation. The only downside was the weight of all the tubes for each motor mount was taken into consideration...but since my models tend to be heavy compared to what OR calculates initially anyway...

Could you do something like that...using a variant of the Stage programming to allow hiding and unhiding parts?

FC
 
I did a search and found this thread.

I to need the option of hiding componants.

In my case I have a camera (mass componant) mounted to the rocket with I'd like to hid.

Why not just put a check box in front of each componant? Checked is active (seen in draw window), unchecked is inactive (hiden in draw window).
 
2023 here and the software still doesn't have this feature?
 
I did a search and found this thread.

I to need the option of hiding componants.

In my case I have a camera (mass componant) mounted to the rocket with I'd like to hid.

Why not just put a check box in front of each componant? Checked is active (seen in draw window), unchecked is inactive (hiden in draw window).

Submit a Pull Request with the code to enable this feature!
 
It has certainly been requested, but it has not bubbled up very high on the priority list up to this point.

Is the desire here to simply hide it from the rocket diagram, or to exclude it from the design when it is unchecked? The former is straightforward but not IMHO very useful; the latter is definitely useful (and what I would want) but non-trivial to implement.
 
I solved the issue by simply making a copy of the sim file, removing the items (e.g. external camera) and siming the new file. Not elegant but I get what I need :)
 
I solved the issue by simply making a copy of the sim file, removing the items (e.g. external camera) and siming the new file. Not elegant but I get what I need :)

Here is a very recent feature request that I think is the same as what's being discussed here: https://github.com/openrocket/openrocket/issues/2263

Here is another one that adds the capability of tying selections to motor configs (potentially a very useful enhancement, although it seems like it would add considerably UI complexity): https://github.com/openrocket/openrocket/issues/2000

I feel sure there was yet another version of this request further back in the past but I can't find it now.

Do these requests cover what you're looking for here?
 
@neil_w : FR 2263 would be what I'm looking for and likely many others.

I could add different cameras with housing to the rocket and select each separately when siming the rocket, just as an example.
 
Here is another one that adds the capability of tying selections to motor configs (potentially a very useful enhancement, although it seems like it would add considerably UI complexity): https://github.com/openrocket/openrocket/issues/2000

That would be very useful. I've ended up making different versions of a sim to go with different motor categories. For example, the additional weight of an AT 18/20 case requires more NC ballast than 18mm Estes motors, but can also handle the additional weight. That much weight severely trims the performance of a C6-7 and turns a B6-6 into a slug. So I have made "18-20" versions of sims just so I can look at them without having to go back and forth on NC ballast depending on what motor I want to think about.

ETA: The same situation exists with larger motors, e.g. different numbers of grains when you get into reloadable motors. Or if you want to look at performance when adapting down, being able to attach the adaptor assembly to the motor selection(s) would be a tremendous convenience.
 
Last edited:
Here is another one that adds the capability of tying selections to motor configs (potentially a very useful enhancement, although it seems like it would add considerably UI complexity): https://github.com/openrocket/openrocket/issues/2000
That's essentially the functionality I hack into being with my dummy motor files, but only for mass. For example, when I need to sim the mass of a JLCR for some motors, I add a 21g (or whatever) fake motor to a zero-mass motor mount located at the center of the parachute and set its ignition to "never". Configurations where I don't need the JLCR leave that tube empty. (Of course this only affects the sim on the way up. Post-deployment simulation is unaffected and therefore inaccurate for the case of JLCR use). I do the same thing for removable nose weights, flying trackers on higher flights but not lower ones, etc.

Being able to set up different physical configurations like "leave the avbay out and use a shorter body tube with motor X" would be even more powerful, but of course even harder to code.
 
ETA: The same situation exists with larger motors, e.g. different numbers of grains when you get into reloadable motors. Or if you want to look at performance when adapting down, being able to attach the adaptor assembly to the motor selection(s) would be a tremendous convenience.
I have sometimes created special motor files with the added mass and diameter in the case of motor adapters.
 
I did a search and found this thread.

I to need the option of hiding componants.

In my case I have a camera (mass componant) mounted to the rocket with I'd like to hid.

Why not just put a check box in front of each componant? Checked is active (seen in draw window), unchecked is inactive (hiden in draw window).
@Leo --

I'll bet the devs have already considered how such an attribute would work but I would prefer the default to be Unchecked is Active ...

This is why ...

Since this is a new attribute for rocket components, and since it would be 'unusual' to hide components in the .ork file, maybe the attribute should be called 'isHidden' and the default should be 'N' ( aka NOT Hidden ) ?

IsHidden could be evaluated as: HideThisComponent = ( IsHidden == 1 ) ? 1 : 0 // if not Hidden then Show

This way existing components would continue to work as they have always worked before and I wouldn't have to Edit each component on all my .ork files.

Data conversion from version 22.02 to version ???? would create a new Field for each component, leaving the default setting for IsHidden as 0 or NULL ?

Thoughts ?

-- kjh
 
Internal implementation and UI are completely separate. For simple enable/disable functionality, internal implementation is straightforward and not a concern.

UI is a much more interesting question. It would be trivial to make something that just works (checkboxes next to every component), harder to make something that is not overly intrusive and distracting. I would tend to agree that the best way to think of it is as a "disable" feature, with "active" as the default (i.e. "unchecked".) I'm not yet completely sold on the idea that an always-visible checkbox for every component is the best approach, but it might be. Maybe only bring up those checkboxes when asked, and keep them hidden the rest of the time. Disabled components could be greyed out in the tree for normal display. Just thinking out loud here.

Things get *much* more interesting if you try to envision the next step, which is to have different enable/disable configurations for different motor configurations. This would be (I think) an incredibly valuable feature but a concept for a sensible UI has eluded me so far. Internal implementation is also a lot more complex.

Most likely we'd need to just implement the simple version first, and worry about the fancier version later. It is an interesting problem to think about, though.

BTW there's discussion of some forward-looking features in the "developer discussion" forum on our Discord: https://discord.gg/udvHdZGr6h. All are welcome. I love talking about this stuff.
 
Last edited:
Things get *much* more interesting if you try to envision the next step, which is to have different enable/disable configurations for different motor configurations. This would be (I think) an incredibly valuable feature but a concept for a sensible UI has eluded me so far. Internal implementation is also a lot more complex.
So hard to turn my brain off once I start thinking about this sort of thing. Hmm, how about something like this:
  • Enable/disable is indicated, by whatever means, in the component tree for the currently selected motor configuration (top right of the rocket display at bottom). Visual is the same as if enable/disable is global. You could also change the setting of the component for the currently selected motor config.
  • Inside the component configuration, we add a new tab. Inside that tab we have a list of motor configurations, and a "disable" checkbox for each configuration. This gives an easy way, for each component to both bulk-set the settings all at once, and also to *see* all the settings at once.
An alternative approach is control the enable/disable settings from the motor configurations tab, but I'm not sure that would offer any advantages.
 
Last edited:
@neil_w --

There is a motor <configid> component in each simulation ...

If a component is hidden at the motor configuration, that would affect all simulations that reference that motor.

Does it make sense instead to hide components in the indivitual <simulation> blocks under the [Flight Simulation] Tab ?

-- kjh

EDIT: p.s. one thing I would really like would be to override the motor overhang for each motor or simulation ... or maybe that's already possible ?
 
This might be a natural fit for the existing "Override" tab.
It might.
If a component is hidden at the motor configuration, that would affect all simulations that reference that motor.

Does it make sense instead to hide components in the indivitual <simulation> blocks under the [Flight Simulation] Tab ?
I believe that tying component enables to simulations (rather than motor configs) would add a lot of additional complexity for only a small increase in utility.
EDIT: p.s. one thing I would really like would be to override the motor overhang for each motor or simulation ... or maybe that's already possible ?
Not currently possible, but a reasonable feature request.

Why, though? In the vast majority of real world use, doesn’t the motor retainer dictate the overhang?
 
Why, though? In the vast majority of real world use, doesn’t the motor retainer dictate the overhang?

There are very long motors out there. For example the J510.

If I design a rocket for say the J570 ( 479mm ) but I want to sim a J510 ( 584mm ) I want to override the overhang for the J510 so it hangs out the back rather than having it automatically intrude into my AV-Bay ...

-- kjh

p.s. I don't use motor retainers unless external tape or hose clamps count :)
 
Last edited:
I believe that tying component enables to simulations (rather than motor configs) would add a lot of additional complexity for only a small increase in utility.
Looking inside the .ork file the motor configuration is an attribute of the simulation ( along with other attributes ).

If we modify the motor configuration then all simulations with that motor configuration would be affected.

OTOH, if there was an additional dialog under the simulation tab, then maybe some of the rocket design settings could be overridden for a single sim ?

That's what I was thinking.

-- kjh
 
There are very long motors out there. For example the J510.

If I design a rocket for say the J570 ( 479mm ) but I want to sim a J510 ( 584mm ) I want to override the overhang for the J510 so it hangs out the back rather than intrude into my AV-Bay ...
Hmm, fair. Why don't you create a feature request for it.
Looking inside the .ork file the motor configuration is an attribute of the simulation ( along with other attributes ).
Again, let's not worry about internals, but rather focus on user experience and functionality.
If we modify the motor configuration then all simulations with that motor configuration would be affected.

OTOH, if there was an additional dialog under the simulation tab, then maybe some of the rocket design settings could be overridden for a single sim ?
Yes. The problem is that each new location where you can set an override adds opaqueness to the operation of the program. It is already, IMHO, a bit unmanageable in certain areas, and I've been working to figure out how to clean it up. It's not easy.

For example, right now you can override recovery deployment settings in the motor configuration (under the "recovery" subtab). Apart from the fact that many folks probably don't even notice that the option exists, the setting is not shown nor reported anywhere else. So if you set it there and forget about it later on (or open a file created by someone else), you may have no idea why your sims are performing weirdly. And you have to know to go back in there to clear the overrides or whatever.

And it's already caused some considerable confusion that you can change settings for each simulation individually, but changing the *default* configuration doesn't change the settings for *existing* simulations... and again, unless you double-click into each simulation, you have no way to know which ones are using the default settings and which ones aren't.

Ideally, all these issues should be cleaned up at some point. In the meantime I hate to add to the problem unless a really strong case can be made. On this one I'm not convinced.

Oh, and one more thing: right now, in the rocket display at bottom, you can select among available *motor configs*. Therefore it is fairly easy to cycle through them and see the rocket parameters for each (including, in this case, which components are enabled/disabled). There is not presently any way to visualize differences among different *sims*.

Therefore, again, I'd prefer not to add any additional customization to individual sims beyond the sim parameters themselves.
 
I would probably do it this way if checks are not wanted in the overview for each component:
The user clicks on the component to open the configuration popup window. Under "General" or "Override" I would set a 'check' "Ignore this component" and in the overview I would set the component text in red to demote that the component is being ignored. Again, just a suggestion......
 
I would probably do it this way if checks are not wanted in the overview for each component:
The user clicks on the component to open the configuration popup window. Under "General" or "Override" I would set a 'check' "Ignore this component" and in the overview I would set the component text in red to demote that the component is being ignored. Again, just a suggestion......
I think I'd also add a contextual menu option to enable/disable.

Not red for disabled, though, probably something more like grey-out the disabled components (a more standard visual indicator). We'll be using colors for other purposes sometime soon. :)
 
Back
Top