ANNOUNCEMENT: OpenRocket 23.09 is now available for download

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Happy dance time!! Downloading the .jar file does it. It opens and runs and on a pi 5 It's even snappy. I haven't had time to explore yet as I've got something else to do but will try it out fully later and report back. Install the Java runtime environment as per the instructions on the raspberry tips site. Then download the jar file from open rockets site. Run it with java -jar OpenRocket-23.09.jar
And I'm half through an upscale Estes Bandit to 2.5 inch PS 2 size.
 
A small break :)

After that, something we've been talking about for a looong time is improving design warnings to users. We're also gonna improve/modernize the project structure and documentation, hoping that can attract new developers.
Sibo, Grand kudos to your and the other individuals delivering v23.09. I'm still new to my way around the upgraded app, but do have a question on design warnings. Where would one find documentation on warning messages and guidance on how to resolve them? In a current design, I have numerous "Thick fins may not simulate accurately' and warnings on the phantom body tubes for pods: "Forward end of airframe is open (radius is > 0)".

I've wandered through the wiki, tried searches both on the web and on TRF, but still struggling to find a reference. Would welcome references from anyone on this thread.

Thanks!
 
It doesn’t exist right now. It’s been in my todo list to write a tutorial about this. I suppose I should get to it.

It would also be good if the program had some explanations built-in, but in the short term an external reference is more likely.
 
Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.
 
Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.
Found that out when I tried to create a camera shroud as a thick short fin. Didn't like it.
Is a camera shroud doable? Would it simulate drag in one place and any weight offset/ drag causing an arc in the flight?
eg https://www.additiveaerospace.com/products/mobius-shroud
 
Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.
Thanks for the response. Attached is the design - a 3x Orbital Transport upscale, based on some previous work by Stephen Heilman.

Lot's of 1/8" 'thick' fins, enclosures, etc. and lots and lots of pods. As I'm still a noob to OR, I expect that I may not be setting up the pods correctly / consistently, hence the errors in that regard. I'm still in the process of adding all the components and was planning that, once I entered everything in the design, I was going to 'circle' back through to address warnings, check materials, finish, etc.

So in addition to the two warnings previously noted ( that are the bulk of the list ), I did note that there is also 'Discontinuity in rocket body diameter' - which I assume will be easy to resolve as well as a 'Too many parallel fins' - which I may need to live with...

Appreciate any guidance that can be provided!
 

Attachments

  • Orbital Transport 3x Upscale (v1.0).ork
    64.2 KB
It doesn’t exist right now. It’s been in my todo list to write a tutorial about this. I suppose I should get to it.

It would also be good if the program had some explanations built-in, but in the short term an external reference is more likely.
Just a comment/thought.

My previous employer had a phenomenal control system, but terrible error codes - honestly sometimes they were just wrong (i.e. someone hits an e-stop and the error would say oil temp is high. . . ). Our sister company had a sub-optimal performing control system, but insanely great documentation on error codes built into the software (i.e. Oil temperature is high. Ensure water inlet temperature is less than 90 deg and outlet temperature is not greater than 120 deg. Verify recirc flow. Verify oil level. etc.).

Customers loved their system from a user standpoint, not from a performance standpoint. They won, we didn't.

If you're going to do the work to create a guide/tutorial, it might be worth doing it in such a way that its easier to implement directly in the software at some point. By that, I am thinking create a database of the options and use HTML/CSS to produce the written document vs. just writing it in MSWord and then someday trying to implement it into the software by recreating the work you already did.

Again, just a comment/opinion. I'm not a real software guy at all, but when I see something implemented well, I try to think about the what's and why's. Anytime you can prevent double work, especially on a passion project vs. a paid gig, that seems helpful.

Thanks for all the work you do on OR.

Sandy.
 
May have just discovered a bug, Bug Report submitted via email. It occurs whenever I try and change the tailcone on the rocket design from conical to ogive shape, the program starts to tweak out and I have to shut down OR, it happens just as soon as I make the change from Conical to Ogive.
 
May have just discovered a bug, Bug Report submitted via email. It occurs whenever I try and change the tailcone on the rocket design from conical to ogive shape, the program starts to tweak out and I have to shut down OR, it happens just as soon as I make the change from Conical to Ogive.
conical is the default tailcone. I've just tested with Linux version 23.09 and have no issues changing to ogive.
1716023953006.png
 

Attachments

  • Tailcone Test.ork
    1.1 KB
@rharshberger --

Adding an 'it seems to work OK for me too '...

Running OR 23.09 on Linux ( Slackware64 15.0 ) with openjdk 17.0.11

I used a hose clamp for motor retention on the first two flights after rebuilding "T'Pring's P'Toy".

But I noticed that the rocket did a slight YEET soon after the rocket left the rod.

I noticed that the ends of the worm gear on the hose clamp were just slightly wider than the 1.9 inch airframe so I reverted to masking tape motor retention with a "poor man's masking tape tail cone" for a 29mm AT H180W.

No YEET on my most recent flight ...

After you reported your issue, I tried all the transition profiles without any issues.

Even when I reset d0 = 1.91 in, d1 =1.91 in and length =0.01 in for 38mm motors.

Here are a couple examples:

Conical Masking Tape Tail Cone:
tp-conical-tape-tail-cone.png

Ogive Masking Tape Tail Cone:
tp-ogive-tape-tail-cone.png

vul-48.ork is attached ( I tried to remove my custom motors from the .ork but I may have missed some )...

HTH.

-- kjh
 

Attachments

  • vul-48-no-custom-motors.ork
    6.4 MB
Last edited:
May have just discovered a bug, Bug Report submitted via email. It occurs whenever I try and change the tailcone on the rocket design from conical to ogive shape, the program starts to tweak out and I have to shut down OR, it happens just as soon as I make the change from Conical to Ogive.
Email to where exactly?

I too cannot reproduce this one.
 
Email to where exactly?

I too cannot reproduce this one.
JoePfeiffer has replied to my email already that contained the BugReport.

I am running Win 11 Pro so it may be something to do with Windows or Java related to Windows, I am not a programmer. I did update my video driver after discovering this event and retested, same result as the issue continued. I can close OR and save the file, restart the program and it will open the saved file with the ogive transition, I haven't messed with the program and wont have time to do so for most of the weekend. Just moving the mouse over window elements or buttons are enough to create the additional "windows" seen in the pictures.


Processor 13th Gen Intel(R) Core(TM) i9-13900K 3.00 GHz
Installed RAM 32.0 GB (31.7 GB usable)
System type 64-bit operating system, x64-based processor
Pen and touch No pen or touch input is available for this display
Edition Windows 11 Pro
Version 23H2
Installed on ‎10/‎6/‎2023
OS build 22631.3593
Experience Windows Feature Experience Pack 1000.22700.1003.0




OR23issuePic1.jpgOR23issuePic2.jpgOR23issuePic3.jpg
 
Sorry....will do what I can to help
Not much you can do I don't think. We've had a number of reports of this but it seems to be hardware-dependent, and none of us have hardware than can reproduce.

It is odd, however, that for you it is triggered specifically by the operation on the transition. That may be a new one for us... although I don't know what conclusions to draw.

1716056884980.png
 
Not much you can do I don't think. We've had a number of reports of this but it seems to be hardware-dependent, and none of us have hardware than can reproduce.

It is odd, however, that for you it is triggered specifically by the operation on the transition. That may be a new one for us... although I don't know what conclusions to draw.

View attachment 645895
Out of pure ignorance, would doing a teamviewer session with the bug reporter on his/her hardware be helpful? I've always hated non-repeatable bugs. Yuk.
 
Not much you can do I don't think. We've had a number of reports of this but it seems to be hardware-dependent, and none of us have hardware than can reproduce.

It is odd, however, that for you it is triggered specifically by the operation on the transition. That may be a new one for us... although I don't know what conclusions to draw.

View attachment 645895
There is a known issue with Windows 11 opening multiple windows when trying to get to a file.

Wonder if it could be an autosave causing it when the profile is changed. Worth a try to see if it goes away.
 
Not much you can do I don't think. We've had a number of reports of this but it seems to be hardware-dependent, and none of us have hardware than can reproduce.

It is odd, however, that for you it is triggered specifically by the operation on the transition. That may be a new one for us... although I don't know what conclusions to draw.

View attachment 645895
So I went back and did a bit more design work on the rocket, adding fins, making the body tube two pieces etc, then saved the rocket. Went back into the transition/tailcones edit screen clicked to change transition shape back to conical (just because) and it triggered the bug again. Looks like I can probably work around the issue knowing its there on my machine. I am not aware of any autosaves configured on my machine, usually I disable that kind of stuff as certain programs I have like to take a break doing it while I am in the middle of something requiring a fair amount of thought and having that interrupted mid design sucks.
 
So I went back and did a bit more design work on the rocket, adding fins, making the body tube two pieces etc, then saved the rocket. Went back into the transition/tailcones edit screen clicked to change transition shape back to conical (just because) and it triggered the bug again. Looks like I can probably work around the issue knowing its there on my machine. I am not aware of any autosaves configured on my machine, usually I disable that kind of stuff as certain programs I have like to take a break doing it while I am in the middle of something requiring a fair amount of thought and having that interrupted mid design sucks.
@rharshberger
The fault mentioned in the youtube link above mentions that it tries to open the folder 4 times before it gets it right. That looks like the number of windows you're getting. Try following the instructions in the video and see if it makes a difference. They won't make it any worse...
I'd apply it to the folder OR is located in and the folder you save your OR designs to.
:)
Norm
 
Last edited:
@rharshberger
The fault mentioned in the youtube link above mentions that it tries to open the folder 4 times before it gets it right. That looks like the number of windows you're getting. Try following the instructions in the video and see if it makes a difference. They won't make it any worse...
I'd apply it to the folder OR is located in and the folder you save your OR designs to.
:)
Norm
Did not work but thanks for trying, the number of windows is directly related to how many time my mouse pointer crosses over something like a button on the main window afaict without actually clicking on anything.
 
Did not work but thanks for trying, the number of windows is directly related to how many time my mouse pointer crosses over something like a button on the main window afaict without actually clicking on anything.
Still getting this bug, none of the recommended fixes have worked so far. At this point OR both 22 and 23 are not working. I am going to try installing version 15 and see if that works.
 

Attachments

  • OpenRocketIssues.jpg
    OpenRocketIssues.jpg
    138.7 KB
Last edited:
Still getting this bug, none of the recommended fixes have worked so far. At this point OR both 22 and 23 are useless to me. I am going to try installing version 15 and see if that works.
Run Linux from a thumb drive and use the Linux version. Let us know if it goes away. Is it possible it's your mouse/ driver. This will also give you a recovery option when windoze breaks.
 
Run Linux from a thumb drive and use the Linux version. Let us know if it goes away. Is it possible it's your mouse/ driver. This will also give you a recovery option when windoze breaks.
I dont do linux,and not a programmer type.The machine is setup for gaming and 3D design.
 
So I may have found a fix for my issue above, I opened properties and clicked on Run as Administrator AND clicked on Change high DPI settings then checked the "Use this setting to fix scaling problems for this program instead of the one in Settings. That's it, I only checked the two setting in the programs properties tab on the desktop. Before just as soon as I would click on the change Zoom in OR the multi window bug would pop up, at first I thought it might be the mouse as OzHybrid suggested....Nope, new drivers didnt fix anything, then tried compatability to Win8...nope again. After clicking on the two boxes in the picture below I believe my issue might be tied to the High DPI scaling setting. Its late so I cant play with the program tonight to see if it breaks but hopefully tomorrow.

Edit: had to play with it...messed with it for about 30 minutes, no issues so far too bad its taken me this long to find the possible issue.

Possible OpenRocket fix.jpg
 
Last edited:
Mostly, Linux is the same as Windows in look and feel. If you just run it from the thumbdrive, you're not installing it. I understand your reluctance to run it on the say so of someone you've never met......

I'll put together some instructions on how to create a bootable linux image on a thumdrive.
:)
 
Last edited:
Back
Top