OpenRocket... A few items for my wish list.

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Here are the details:
https://www.pro38.com/products/pro54/motor/MotorData.php?prodid=1281K360-13A
Certified at 1280.9! Take that OR!

I'm beginning to think it's due to some inconsistencies in the data that it's pulling from wherever it's pulling it.

The H45 is under the I motors as well. Listed as 322N(1% I) where Thrustcurve lists it's certified total impulse as exactly 320.0 - still H, but under the I motors in OR. There are other inconsistencies I and others have noticed as well.

Also I noticed the OR code rounds 0.4 down and 0.5 up - should be round all up as 1280.1 is a K , 320.1 is an I.

So in keeping with the theme of this thread,

Wish list item #1, round all total impulse values up internally.
Wish list item #2, "debug" the motor database.
 
Another thing that would be convenient is a calculated thrust-to-weight column in the simulation results section so that you could see at a glance what it would be for each configuration.
For example: Motor choice A 6.7:1, motor choice B 4.1:1, I'll go with choice A...
 
...

I would add semi-transparent materials to the list as well. Plexiglass fins or actual clear payload bays would be cool.

Quoting myself...? I've submitted a pull request in GitHub for this change so we'll see if it makes it in to the next release or not. Gotta try.
 
Another thing that would be convenient is a calculated thrust-to-weight column in the simulation results section so that you could see at a glance what it would be for each configuration.
For example: Motor choice A 6.7:1, motor choice B 4.1:1, I'll go with choice A...

What?!?!?! You have a sophisticated flight-simulator in your hands and you want to reduce it to 1960's era rules of thumb? Why bother with OR? Use MindSim, or a pencil, instead.

The correct answer is: Motor choice A 95 fps off the rail, motor choice B 48 fps off the rail, I'll go with choice A...
 
What?!?!?! You have a sophisticated flight-simulator in your hands and you want to reduce it to 1960's era rules of thumb? Why bother with OR? Use MindSim, or a pencil, instead.

The correct answer is: Motor choice A 95 fps off the rail, motor choice B 48 fps off the rail, I'll go with choice A...

Good point... :lol:
 
This was PM'd to me, but I like the sound of it... A way of zooming in on the 3D images, as well as having layers that can be turned on (and off) so you can look inside an assembly (like an AV bay or baffle).
 
I downloaded OpenRocket, unzipped it and installed it and it didn't work. I needed JavaScript. I downloaded it, unzipped it, installed it. OpenRocket didn't open.
Neither JavaScript nor OpenRocket where on the "path" where the OS could find them. Print a copy of your environment at the command prompt.

You can type "path" by itself to look at your path statement.
Type "dir /s JavaScript.*" to locate JavaScript. Copy that information and include it to your Path statement.
I think you need to be an administrator to do this part. You type the word "Path". You will see what is in the Path, go to the end of the Line and put the JavaScript directory in the path statement, hit "Enter". OpenRocket will now find JavaScript when you type OpenRocket at the command prompt and open.

This is how it works for me.

I hope this helps.

Carlos McCauley
NAR 214512
 
I downloaded OpenRocket, unzipped it and installed it and it didn't work. I needed JavaScript. I downloaded it, unzipped it, installed it. OpenRocket didn't open.
Neither JavaScript nor OpenRocket where on the "path" where the OS could find them. Print a copy of your environment at the command prompt.

You can type "path" by itself to look at your path statement.
Type "dir /s JavaScript.*" to locate JavaScript. Copy that information and include it to your Path statement.
I think you need to be an administrator to do this part. You type the word "Path". You will see what is in the Path, go to the end of the Line and put the JavaScript directory in the path statement, hit "Enter". OpenRocket will now find JavaScript when you type OpenRocket at the command prompt and open.

This is how it works for me.

I hope this helps.

Carlos McCauley
NAR 214512
 
I downloaded OpenRocket, unzipped it and installed it and it didn't work. I needed JavaScript. I downloaded it, unzipped it, installed it. OpenRocket didn't open.
Neither JavaScript nor OpenRocket where on the "path" where the OS could find them. Print a copy of your environment at the command prompt.

OR uses Java, not JavaScript. They are totally different.
 
I've come to the conclusion that for all the UI and general usability enhancements that I would like (and there are many, and I'll still probably post about them), support of Rocksim-style pods is by far the single most important feature that I would want, and I would trade everything else for it. The present inability to properly model external pods, or fins attached to fins, or whatever, is severely limiting. For MPR and HPR the designs tend not to go too crazy with that stuff, but for LPR it's essential. Well, "essential" is relative I suppose, but without it there are just whole classes of designs you can't do.

Pods please.
 
the thought occurred to me the other day when I was marking the cp location on my L2 bird that, it would be nice to have the cp/cg locations referenced to the aft end of the rocket(it is a lot easier to measure 17" from the aft end than it is to measure 66" from the tip of the nose).
Rex
 
the thought occurred to me the other day when I was marking the cp location on my L2 bird that, it would be nice to have the cp/cg locations referenced to the aft end of the rocket(it is a lot easier to measure 17" from the aft end than it is to measure 66" from the tip of the nose).
Rex

I'd like it to be a little more specific than that. When you say aft end, do you mean the end of the fins (for rear swept fins), or the aft end of... say the motor tube or retainer?

Of course, you could just take the length of the rocket in the sim, and subtract the CG/CP points from that, and that would give you your numbers working from the other end.
 
Last edited:
I'd like it to be a little more specific than that. When you say aft end, do you mean the end of the fins (for rear swept fins), or the aft end of... say the motor tube or retainer?

Of course, you could just take the length of the rocket in the sim, and subtract the CG/CP points from that, and that would give you your numbers working from the other end.

Keep it simple, from the aft end of the airframe.
 
I've come to the conclusion that for all the UI and general usability enhancements that I would like (and there are many, and I'll still probably post about them), support of Rocksim-style pods is by far the single most important feature that I would want, and I would trade everything else for it. The present inability to properly model external pods, or fins attached to fins, or whatever, is severely limiting. For MPR and HPR the designs tend not to go too crazy with that stuff, but for LPR it's essential. Well, "essential" is relative I suppose, but without it there are just whole classes of designs you can't do.

Pods please.

I agree. I did all sorts of what to me is magic in OR to create my damned SA-5 Gammon file, and pretty as she is in my eyes, it is worthless for gathering any flight sim data. I would think that external boosters would fall under the "Pods" characteristic.

Oh, and oblique cones too!!!

None of this "Phatom Crap" that makes the flight sim spit out worthless drivel.
 
I agree. I did all sorts of what to me is magic in OR to create my damned SA-5 Gammon file, and pretty as she is in my eyes, it is worthless for gathering any flight sim data. I would think that external boosters would fall under the "Pods" characteristic.

Oh, and oblique cones too!!!

None of this "Phatom Crap" that makes the flight sim spit out worthless drivel.

If the parts could be manipulated in the Y axis (radial offset), we could do that... And I might be able to sim those fins on the Crossfire.
 
So I decided to try the unstable development branch of OpenRocket...

:eyepop::jaw::clap::pop:


15.03dev_1.JPG

15.03dev_2.JPG


Rail buttons, side boosters and pods! Oh my!
 
Don't tease me like that. Can that implementation handle fins attached to fins? Hard to tell from those screenshots...

As far as I can tell from messing around with it for 15 minutes is that you can, if you have a body tube of some sort to attach them to. Something like creating a pod, then creating a phantom tube to which another fin is attached.

I know how I'm going to be spending my evening after the kids are in bed.
 
As far as I can tell from messing around with it for 15 minutes is that you can, if you have a body tube of some sort to attach them to. Something like creating a pod, then creating a phantom tube to which another fin is attached.

That is disappointing if true. We need to be done with phantom body tubes. Still, this certainly seems to be a step in the right direction.

I know how I'm going to be spending my evening after the kids are in bed.

How unstable is it? I'm tempted to give it a try.
 
That is disappointing if true. We need to be done with phantom body tubes. Still, this certainly seems to be a step in the right direction.



How unstable is it? I'm tempted to give it a try.

Slightly noticeable but not a hindrance. For example, loading a preset for the nose cone the values like diameter and length, etc didn't appear changed until you re-opened the edit box. Another was in the motor selection screen, I couldn't add a "new configuration" unless I clicked "copy configuration" first. Some minor things like that.

I guess they are currently working on improving the simulation accuracy of all the goodies they're adding.
 
I'm not a tutorial guy however I just went through the entire process on my newer Windows 10 computer and wrote down each step since I know Eclipse can be a pain to get working properly. Sure, there are other ways and other IDEs, but this is one of them that works just fine.

You can either build and run straight from Eclipse, or export a .jar file to run it like the normal version so I have included steps for both.

1. Download openrocket-unstable.zip from GitHub. There are two branches: master and unstable. Master is the one we all have, unstable has all the latest stuff they're working on.
2. Download the appropriate eclipse IDE for java from here. Mine was the Windows 64-bit "eclipse-java-mars-R-win32-x86_64.zip"
3. Extract the eclipse .zip file to a new folder
4. Create workspace folder. Mine was "D:\workspace"
5. Unzip the openrocket zip file into the workspace folder. e.g. "D:\workspace\openrocket-unstable"
6. Run eclipse, it should ask for the location of the workspace folder. Set it to what was created earlier e.g. "D:\workspace"
7. In eclipse, close welcome screen, go to File -> Import then expand General, click "Existing Projects into Workspace", click Next.
8. Make sure the radio button for "Select root directory:" is checked, then click Browse. Find the openrocket-unstable folder e.g. "D:\workspace\openrocket-unstable"
9. There should now be several entries under "Projects:". Make sure all are checked, should be 7 of them. Click finish.
10. Wait for "Building workspace" in bottom right corner to finish. Might take a while.
There may be errors if you don't have Android SDK installed - no problem as long as OpenRocket Core and Swing don't have errors

To create an executable .jar file to run from:
1. Go to File -> Export, expand Java, select "Runnable JAR file", click Next.
2. in the Launch configuration drop-down, select "OpenRocket - OpenRocket Swing"
3. Under Export destination, select where you want the jar file to be and name it eg. "D:\OpenRocket-15.03dev.jar"
4. Click Finish, click OK through the warning.
5. Next dialog box will mention warnings. Finished with warnings is OK.
6. Find where you chose to export the jar file to, launch the same as you do normally with OR. e.g. double-click the jar file in Explorer or in the command prompt from the location of the file, "java -jar OpenRocket-15.03dev.jar"
7. Enjoy!


To build and run from Eclipse:
1. In Package Explorer, right-click on the "OpenRocket Swing" project, select "Run as" -> "2 Java Application"
2. Then scroll down and select "OpenRocket - net.sf.openrocket.startup"
3. Click OK
4. Wait
5. Enjoy!
 
I was hoping for that too, but nope. We already have a decent work-around for that thanks to K'Tesh.
Sorry, I haven't kept up...is the work-around just for appearances, or does it sim correctly?

Attached is a BT-101 based V-2 model I created in Rocksim...I would be curious to see how Jim's method in OR compared with the same sizes...I have suspected that some of the work-arounds provide more "wetted" fin area than is actually there, making the rocket seem more stable than it really is. RS says the CP is 23.0144 inches from the nose tip.

Not casting aspersions here, just curious if the technique is mathematically sound for stability calculations...if so I need to study up on the technique!!! But it would be wonderful if OR could do it straight forward like RS does, even to the point of being able to directly import an RS sim.

EDIT: ps: the ability to have "negative" free form fin points would help with this type of fin also...I've seen that listed in this wish list somewhere too...
EDIT II: I attached a the fin layout in case you don't understand the point above...

View attachment V2_BT101.rkt

V2_BT101.jpg

V2_BT101_Fin.jpg
 
Last edited:
Sorry, I haven't kept up...is the work-around just for appearances, or does it sim correctly?Attached is a BT-101 based V-2 model I created in Rocksim...I would be curious to see how Jim's method in OR compared with the same sizes...I have suspected that some of the work-arounds provide more "wetted" fin area than is actually there, making the rocket seem more stable than it really is. RS says the CP is 23.0144 inches from the nose tip.Not casting aspersions here, just curious if the technique is mathematically sound for stability calculations...if so I need to study up on the technique!!! But it would be wonderful if OR could do it straight forward like RS does, even to the point of being able to directly import an RS sim.EDIT: ps: the ability to have "negative" free form fin points would help with this type of fin also...I've seen that listed in this wish list somewhere too...EDIT II: I attached a the fin layout in case you don't understand the point above...
While you can't do -Y values for fins, you can always create a Phantom Body Tube that is set to your fin's lowest point, then apply the fin to that PBT (using an offset if needed). The annoying part is that you'll pick up a discontinuity warning, and likely get a lot of -X value points that you'll have to figure out, but it is what it is, and allows you to do what retain the correct shape.
 
Here's a visual example for the workaround:

Capture1.JPG

Capture2.JPG

Capture3.JPG

As long as the phantom body tube has zero length and therefore zero surface area, I believe accuracy should be pretty close as well. Not for competition, but for every day flying I think you're going to get more variation from the motor itself.
 
Back
Top