ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

[H. Craig Miller]

I've been finding that the freeform fin editor is not as responsive compared to the previous version in 15.03 (on my Mac at least). I like the new design of the editor UI, but the lack of responsiveness makes it a bit frustrating to use.

Could you describe what you mean by less responsive? What are you expecting and what is occurring?

 

[Charles_McG]

Kind of like this idea/feature, for RSO's it would save us a bit of time without having to look up a thrust curve. Usually I am most concerned about the first .5 seconds of the burn after that the rocket should be stable or its probably going to be ugly.

@neil_w - I added my general sim table configurability request in github. I rolled in the quoted idea of early mean T:W as one of the examples. Though in my version, I just called it acceleration. I'm pretty sure T:W is the same as acceleration in Gs.

 

[rocketgeek101]

Could you describe what you mean by less responsive? What are you expecting and what is occurring?

All the functionality works as I expect. By less responsive I just mean that when dragging points around with the mouse to define the fin shape, it feels much less fluid or more laggy than on the previous version. Enough that it makes it more difficult to use sometimes.

Video compares 15.03 with beta 04.

 

[neil_w]

I have felt slowness all throughout the UI on many occasions, but not always. What kind of Mac are you using?

 

[tsmith1315]

New poll question!

Does anyone use the sliders in the component editor? If so, what for?

Yep.

Didn't pay attention to sliders for a while. Since discovering them, I use them for eyeballing proportions and positions. Get it close, then fine tune with numbers.

I'd miss them if they went away.

 

[rocketgeek101]

I have felt slowness all throughout the UI on many occasions, but not always. What kind of Mac are you using?

It's an M1 MacBook Pro.

 

[bad_idea]

Yep.

Didn't pay attention to sliders for a while. Since discovering them, I use them for eyeballing proportions and positions. Get it close, then fine tune with numbers.

I'd miss them if they went away.

Same here. Took me a while to notice then but now find them very useful for getting a part near where I want it, to be finetuned thereafter.

 

[neil_w]

It's an M1 MacBook Pro.

I have found on my M1 iMac that, in general, the new beta is a bit sluggish compared to 15.03. I don't know why this is, since both are running in Rosetta.

A while back I did some testing with an ARM native build and it was *much* snappier, although I don't recall specifically testing the fin editor. Maybe I'll give that another try to see the state of things.

Unfortunately, distributing an ARM-native build will have to wait for the 3D fixes, because the current 3D library doesn't work *at all* on ARM.

 

[Grant_Edwards]

Unfortunately, distributing an ARM-native build will have to wait for the 3D fixes, because the current 3D library doesn't work *at all* on ARM.

Worrying about shipping "native" builds of a Java application! James Gosling is turning in his grave...

[no, he's not really dead]

I've never used anything other than the jar versions of OR on Linux, and they've always "just worked" [even the 3D stuff]. That's something that I've always found slightly surprising. All of the other large Java apps that I run (e.g. RC flight simulator, PDF tool suite, etc.) have always required separate distribution packages for every OS. I suspect that's more about the installer and "start menu" integration than the actual application itself.

NB: I don't really understand the intricacies of running large Java applications.

For the non computer-language people reading this, the whole point of Java (the programming language in which OR is written) was that you wouldn't have to build and ship different versions for different OSes. It does work that way for some applications, but Large Java applications often include their own dedicated private JRE (which is different for each OS).

 

[neil_w]

 

[JoePfeiffer]

Kind of like this idea/feature, for RSO's it would save us a bit of time without having to look up a thrust curve. Usually I am most concerned about the first .5 seconds of the burn after that the rocket should be stable or its probably going to be ugly.

Would it make sense for the average to be calculated over whatever time it takes to get off the rail?

FWIW, I don't end up looking at t/w at all -- I just look at speed off the rail, since that's what's really important.

 

[neil_w]

Would it make sense for the average to be calculated over whatever time it takes to get off the rail?

FWIW, I don't end up looking at t/w at all -- I just look at speed off the rail, since that's what's really important.

Agreed... T/W seems to me to be a rule of thumb that is useful in the *absence* of a full sim.

However, I don't think there's any downside to providing the info... if we can agree on what T/W really means.

 

[waltr]

I also look at speed off the rail as most important. However, at big launches the RSO uses 'Average thrust', the number in the motor designation, to determine if the rocket is allowed to fly. This may not be the best value but is easiest for the RSO to use.
It should not be too hard to show a TTW ratio based on loaded weight and Motor's Average thrust. Big question is where to show this. Maybe on the motor selection dialog.

 

[H. Craig Miller]

Insofar as what thrust-to-weight means, NASA has a basic definition with comparisons for beginners. As to what thrust to use, OpenRocket uses data directly from ThrustCurve, which provides average thrust, initial thrust, and maximum thrust. So, total weight (including motor) / initial thrust seems to be the correct approach.

As for where to display the information, as neil_w noted, thrust-to-weight is closely associated with acceleration (similar to speed being in ft/s and mach). So, put it next to acceleration in the display window:



Thoughts (including how many digits after the decimal)?

 

[rharshberger]

Insofar as what thrust-to-weight means, NASA has a basic definition with comparisons for beginners. As to what thrust to use, OpenRocket uses data directly from ThrustCurve, which provides average thrust, initial thrust, and maximum thrust. So, total weight (including motor) / initial thrust seems to be the correct approach.

As for where to display the information, as neil_w noted, thrust-to-weight is closely associated with acceleration (similar to speed being in ft/s and mach). So, put it next to acceleration in the display window:

View attachment 527403

Thoughts (including how many digits after the decimal)?

are you asking like 5.x or xx :1? If so more than to the nearest 10th is unnecessary IMO, so 5.x:1 ttw.

 

[rocketgeek101]

Insofar as what thrust-to-weight means, NASA has a basic definition with comparisons for beginners. As to what thrust to use, OpenRocket uses data directly from ThrustCurve, which provides average thrust, initial thrust, and maximum thrust. So, total weight (including motor) / initial thrust seems to be the correct approach.

As for where to display the information, as neil_w noted, thrust-to-weight is closely associated with acceleration (similar to speed being in ft/s and mach). So, put it next to acceleration in the display window:

View attachment 527403

Thoughts (including how many digits after the decimal)?

I like it! I think to display one digit after the decimal would be the best choice. Anything more isn't really meaningful.

 

[H. Craig Miller]

Follow feature request for Thrust-to-Weight ratio display as Issue #1531.

 

[neil_w]

By less responsive I just mean that when dragging points around with the mouse to define the fin shape, it feels much less fluid or more laggy than on the previous version.

The point-dragging slowness will be fixed in the next beta, thanks to the tireless @SiboVG. If there are any other specific areas of slowness that you've noticed, please report.

 

[gdjsky01]

View attachment 527301

BS. I've written in Java, and now Kotlin, for 25 years. It just freakin works. Period. The engineer coding it? Well who knows right?

 

[DeltaVee]

One thing I'd love to have is selection of everything in the simulations table selectable using <ctrl>-a. Every now and then, I want to rerun the entire table, and I have to select, scroll to the bottom and then shift-select. Not a big deal of course, just a bit tedious! Unless of course this has recently been added!

 

[SiboVG]

One thing I'd love to have is selection of everything in the simulations table selectable using <ctrl>-a. Every now and then, I want to rerun the entire table, and I have to select, scroll to the bottom and then shift-select. Not a big deal of course, just a bit tedious! Unless of course this has recently been added!

Created a feature request for it here.

 

[Tobor]

This is probably asking a lot from the dev team...

One of the problems I have with OpenRocket is it's reliance on the Windows Registry and the AppData folder tree. I understand the desire to use them from a programming POV, but as an end user, it's sorta a pita. This is even more true when Windows decides to fubar everything with a hard, unrecoverable crash.

Alterations I would like to see:
A) Allow users to easily backup the user added Materials DB and apply said backup as needed. Maybe include OR app settings as well?

B) Like the AppData folder for Thrustcurves, allow users to designate alternate locations for the Components and Plugins folders.

These two "features" would allow easy backup/restoration of this data as needed.

=======================

As an aside, my use case might be more extreme then the average user so I should explain my setup.

1) I have 3 different desktops and a laptop that I can use for OpenRocket, CAD applications like Fusion 360 and 3D printing software like PrusaSlicer.
---All systems have separate partitions/drives for OS, Apps and data storage

2) I use a batch file on my systems to backup the OR Materials registry key and then launch OR. This backup is stored in a NextCloud folder that is synced between my systems. Right now, if a particular system's OR Materials key is out of date, I have to manually apply to key to correct the issue.

3) I used mklink to create junctions of OR's AppData folders to the aforementioned NextCloud folder for syncing. This allows changes to any files within these folders to be shared with all other systems automatically.

tobor

 

[thzero]

This is probably asking a lot from the dev team...

One of the problems I have with OpenRocket is it's reliance on the Windows Registry and the AppData folder tree. I understand the desire to use them from a programming POV, but as an end user, it's sorta a pita. This is even more true when Windows decides to fubar everything with a hard, unrecoverable crash.

Alterations I would like to see:
A) Allow users to easily backup the user added Materials DB and apply said backup as needed. Maybe include OR app settings as well?

B) Like the AppData folder for Thrustcurves, allow users to designate alternate locations for the Components and Plugins folders.

These two "features" would allow easy backup/restoration of this data as needed.

=======================

As an aside, my use case might be more extreme then the average user so I should explain my setup.

1) I have 3 different desktops and a laptop that I can use for OpenRocket, CAD applications like Fusion 360 and 3D printing software like PrusaSlicer.
---All systems have separate partitions/drives for OS, Apps and data storage

2) I use a batch file on my systems to backup the OR Materials registry key and then launch OR. This backup is stored in a NextCloud folder that is synced between my systems. Right now, if a particular system's OR Materials key is out of date, I have to manually apply to key to correct the issue.

3) I used mklink to create junctions of OR's AppData folders to the aforementioned NextCloud folder for syncing. This allows changes to any files within these folders to be shared with all other systems automatically.

tobor

Well OR uses a Java package/library that handles the preferences and it stores them in specific places based on the type of OS OR is running on. And with Windows it defaults to the registry.

If there is a better option, more up-to-date option, I'm sure OR will gladly take a pull request.

Material and engine databases were one of my areas of interest too, to get them into at very least the standard AppData folder (which again is just a component that uses default location based on the OS you are running on).

A PR request here too would be great.

 

[neil_w]

One thing I'd love to have is selection of everything in the simulations table selectable using <ctrl>-a. Every now and then, I want to rerun the entire table, and I have to select, scroll to the bottom and then shift-select. Not a big deal of course, just a bit tedious! Unless of course this has recently been added!

This will be in the next beta (@SiboVG strikes again).

Might I ask how many simulations you have in the list? Are they different motor configurations or different simulation conditions with a smaller set of motor configs? Just trying to understand how people use the program.

 

[rocketgeek101]

I often work in a weird mix of imperial and metric units when designing a rocket. Would it be possible to make it so that OpenRocket remembers your last selected unit for a given component configuration field? Let's say I have my default rocket dimensions set to cm, and I create a body tube and specify the length in inches (by changing the units in the dropdown to the right of the field). The next time I open that body tube configuration window (or create a new body tube) I would like it to default to displaying inches (or whatever unit I last selected) for that field rather than reverting to the default (cm in this example).

 

[ShadowSpire48]

I need to get a GitHub account to report bugs so I can report the one I've dealt with. OpenRocket acts like fins on transitions aren't allowed when importing a rocksim that has them such as a Tomahawk Cruise Missile so the fins have to be re-created (assuming you can figure out the dimensions of the fins beforehand). It also makes the CP/CG relationship a bit off lol

 

[H. Craig Miller]

I need to get a GitHub account to report bugs so I can report the one I've dealt with. OpenRocket acts like fins on transitions aren't allowed when importing a rocksim that has them such as a Tomahawk Cruise Missile so the fins have to be re-created (assuming you can figure out the dimensions of the fins beforehand).

This is a known issue.

Currently, OpenRocket has only "basic" compatibility when importing Rocksim designs. OpenRocket does not correctly import/export the following Rocksim features:

• Boosters
• Pods
• Subassemblies
• Ring tails
• Rail buttons
• Fins on transitions

And, a number of other features.

Unfortunately, at this time, as OpenRocket features become more versatile, the compatibility issues between OpenRocket and Rocksim may continue to broaden.

 

[ShadowSpire48]

This issue has been reported.

Ah didn't know. I just created a GitHub account and posted the report on there lol

 

[Charles_McG]

The beta 4 behavior when duplicating a motor configuration is to automatically open the aft most motor for selection, and I’m finding this highly annoying. I duplicate configurations for lots of reasons, including changing upper stage motors, staging settings and recovery settings.

I tried preselecting the upper stage motor (so the cell was highlighted) to see if OR would take the hint - but it doesn’t. Making any auto-dialog context sensitive, like checking what tab/cell was active, would be more helpful.

 

[neil_w]

The beta 4 behavior when duplicating a motor configuration is to automatically open the aft most motor for selection, and I’m finding this highly annoying. I duplicate configurations for lots of reasons, including changing upper stage motors, staging settings and recovery settings.

I tried preselecting the upper stage motor (so the cell was highlighted) to see if OR would take the hint - but it doesn’t. Making any auto-dialog context sensitive, like checking what tab/cell was active, would be more helpful.

Good feedback, will submit a request. Might get back to you with questions.