ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

[H. Craig Miller]

I have likely overlooked the discussion, but when I run simulations the 'Velocity at Deployment' shows "N/A". Is that a bug or is it something that I have wrong in my drawing?

Please post the design (.ork) file for the model that you are attempting to simulate.

 

[bibbster]

Please post the design (.ork) file for the model that you are attempting to simulate.

Here you go, sir!

 

[H. Craig Miller]

Deployment requires something to deploy... I added a Spherachute parachute for you (change that to what you intend to use). You may want to check out the new parachute manufacturers' product lines that have been added to OpenRocket with beta 3, you may find something you like or would like to experiment with.

 

[bibbster]

Deployment requires something to deploy... I added a Spherachute parachute for you (change that to what you intend to use).

Oh brother. Completely overlooked the missing chute. Thanks, sir.

 

[neil_w]

Oh brother. Completely overlooked the missing chute. Thanks, sir.

We should have a warning for that. You're not the first person to run into this.

 

[bibbster]

We should have a warning for that. You're not the first person to run into this.

A hand that comes out of the screen and slaps me would be ideal.

 

[neil_w]

A hand that comes out of the screen and slaps me would be ideal.

(another big advantage of flat screens... no room for a fist to hide in there)

 

[bibbster]

View attachment 519477



(another big advantage of flat screens... no room for a fist to hide in there)

Good thing or I'd be in a world of hurt!

 

[JoePfeiffer]

(Oops)

 

[bibbster]

Thanks, Joe, but Mr. Miller got me squared away. You are correct though, I failed to add a type of deployment.

 

[tsmith1315]

@tsmith1315
So is the BMS tube wall thickness actually 0.012 or 0.020? Depends on which number in the BMS listing is wrong...hard to say without an actual sample or getting BMS to confirm/deny.

Dave- I now have a BMS T204/ST-20 in hand and it's measuring 0.021" to 0.0225" wall thickness with a cheap digital caliper. OD is measuring 2.039" - 2.044". Even with a coupler in place, it's tough to measure diameter without deforming it. With similar wall thickness as Semroc, I'm calling it the same OD as the Semroc T20 at 2.042" for my calculations.

 

[waltr]

Best way to measure tubes is to wrap a piece of paper around the tube and put a marks at the overlap. Then remove the piece of paper, lay flat and measure the distance between the marks. This is the tube circumference. Divide by Pi (3.1416) to get the diameter.

 

[Tobor]

Dave- I now have a BMS T204/ST-20 in hand and it's measuring 0.021" to 0.0225" wall thickness with a cheap digital caliper. OD is measuring 2.039" - 2.044". Even with a coupler in place, it's tough to measure diameter without deforming it. With similar wall thickness as Semroc, I'm calling it the same OD as the Semroc T20 at 2.042" for my calculations.

I have had really good results measuring OD of a body tube by first placing a CR inside at the end of the BT and then measuring there with my dial calipers.

waltr's way also works well.

 

[caveduck]

Dave- I now have a BMS T204/ST-20 in hand and it's measuring 0.021" to 0.0225" wall thickness with a cheap digital caliper. OD is measuring 2.039" - 2.044". Even with a coupler in place, it's tough to measure diameter without deforming it. With similar wall thickness as Semroc, I'm calling it the same OD as the Semroc T20 at 2.042" for my calculations.

Thanks! Seems like it's intended to match the original 2.040 ST-20. Paper tubes are indeed notoriously hard to measure accurately since they deform so easily. Calipers will compress them, and even using a coupler isn't foolproof because the tubes will stretch, and the tube+coupler can still be deformed by the measuring device. A friction clutch micrometer gives the most consistent results, but it doesn't prevent deformation; it just makes it repeatable

I've been told that the smaller tubes "as manufactured" can vary from the specified size by 2-3 thousandths, and Aerotech once said that larger tubes are only guaranteed +/- .005" from spec.

 

[tsmith1315]

I've been told that the smaller tubes "as manufactured" can vary from the specified size by 2-3 thousandths, and Aerotech once said that larger tubes are only guaranteed +/- .005" from spec.

Thanks for that tidbit, I've been curious about it.

The OR database is very helpful, and I really appreciate the additional info in the new version. In planning some scale builds, I want to be as accurate as possible with off the shelf materials. But, I don't want to find myself nitpicking down to the level of tube tolerances.

 

[bibbster]

It may have been discussed, but when selecting 'Close design' the entire app closes as if selecting 'Quit'. Not a big deal to open the app again, but it would be nice if it would remain open to start another design or open another existing design, unless selecting 'Quit'.

 

[neil_w]

It may have been discussed, but when selecting 'Close design' the entire app closes as if selecting 'Quit'. Not a big deal to open the app again, but it would be nice if it would remain open to start another design or open another existing design, unless selecting 'Quit'.

This is an existing feature request for the Mac version. The current behavior is generally consistent with Windows apps (close the last window and the app closes). Not sure about Linux.

 

[H. Craig Miller]

It may have been discussed, but when selecting 'Close design' the entire app closes as if selecting 'Quit'. Not a big deal to open the app again, but it would be nice if it would remain open to start another design or open another existing design, unless selecting 'Quit'.

For the way things currently work, see the OpenRocket Wiki regarding the difference between "Close" and "Quit."



Users may track this as Issue #1100.

 

[neil_w]

See issue 1100. This behavior is very un-Maclike (and annoying in general). I hope it can be changed in the future.

I'm not sure if Windows or Linux behavior should change, but on the Mac it definitely should.

 

[bad_idea]

Linux applications vary, since Linux itself isn't a single operating system to which everyone codes according to the same guidelines. Some Linux GUI programs close when the last document is closed, some do not. I prefer those that do not.

Edit to add: As a part-time Mac user too, I'm with you regarding the Mac.

That said, it's a minor niggle to me, not a big deal in any way.

 

[Hobie1dog]

I downloaded it onto my iMac and all I get is this:
“OpenRocket 22.02.beta.03” can’t be opened because it is from an unidentified developer.

 

[neil_w]

I downloaded it onto my iMac and all I get is this:
“OpenRocket 22.02.beta.03” can’t be opened because it is from an unidentified developer.

Instructions here: https://openrocket.info/downloads.html?vers=22.02.beta.03

 

[Winston]

Hm, does this happen for all your designs? I just compared a beta 1 and beta 3 export and both had the same file size (4 kB) for the 'A simple model rocket' design when saving as 'Save Only primary figures'

The attached file is a rough initial CG/CP feasibility study, not even close to a final design. It is saved as "Only primary figures", predicted to be 1k, but is 104k. Please let me know what you get when you load and then save it in the same save mode.

 

[SiboVG]

The attached file is a rough initial CG/CP feasibility study, not even close to a final design. It is saved as "Only primary figures", predicted to be 1k, but is 104k. Please let me know what you get when you load and then save it in the same save mode.

I see, well first of all, the predicted file size is just plain wrong. I've issued a new issue to fix the file size prediction.

The reason why your file size is so big is because of the textures in your design file. I see 4 different textures: balsa.jpg, chute.jpg, spiral-wound-alpha.png and wood.jpg. They take up 106 kB in the design file. The actual plain text design file is only 16 kB, as it should be.

So in short: the predicted file size is badly off and your file size is so large because of custom textures from your design.

 

[neil_w]

I see, well first of all, the predicted file size is just plain wrong. I've issued a new issue to fix the file size prediction.

The reason why your file size is so big is because of the textures in your design file. I see 4 different textures: balsa.jpg, chute.jpg, spiral-wound-alpha.png and wood.jpg. They take up 106 kB in the design file. The actual plain text design file is only 16 kB, as it should be.

So in short: the predicted file size is badly off and your file size is so large because of custom textures from your design.

I have a vague recollection of having the default textures for the different component types end up as custom textures in one of my ORK files. It was a long time ago and did not reproduce easily. Maybe that's what happened here.

 

[thzero]

I see, well first of all, the predicted file size is just plain wrong. I've issued a new issue to fix the file size prediction.

The reason why your file size is so big is because of the textures in your design file. I see 4 different textures: balsa.jpg, chute.jpg, spiral-wound-alpha.png and wood.jpg. They take up 106 kB in the design file. The actual plain text design file is only 16 kB, as it should be.

So in short: the predicted file size is badly off and your file size is so large because of custom textures from your design.

Why is there any "predicting" of file size?

 

[SiboVG]

Why is there any "predicting" of file size?

No idea, I'm also contemplating the value of that functionality

 

[Winston]

I see, well first of all, the predicted file size is just plain wrong. I've issued a new issue to fix the file size prediction.

The reason why your file size is so big is because of the textures in your design file. I see 4 different textures: balsa.jpg, chute.jpg, spiral-wound-alpha.png and wood.jpg. They take up 106 kB in the design file. The actual plain text design file is only 16 kB, as it should be.

So in short: the predicted file size is badly off and your file size is so large because of custom textures from your design.

Yes, I looked at the raw file during my investigation prior to posting this and saw those *.jpg designations and thought that the fact that I had simply looked at the 3D version with finish might be the reason for the file sizes. The textures are automatically assigned to the saved file by the material choices, but only if the 3D view with finish is viewed before saving?

Anyway, the only reason I brought up the file size issue in the first place is because some web sites might limit the size of files that can be attached.

Finally, THANK YOU you for such a great application.

 

[Rocketless]

Is there a library of files that others have done on rockets and if so, how do I access it?

 

[prfesser]

Here is a pretty extensive library of Rocksim files for Estes rockets.