ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

[H. Craig Miller]

I am very happy to contribute, great work being done here - can we get an idea of what the expenses are and how the money will be used? Thanks!

The current anticipated expenses are for the purchase of signing certificates to eliminate or reduce warnings displayed when downloading and installing OpenRocket.

A significant reason for the selection of OpenCollective as the fiscal host for OpenRocket was the ability to allow anyone to view all of the financial transactions for the project, contributions and expenses. By scrolling down the OpenRocket OpenCollective page, you will see how to contribute, projects separate from OpenCollective (if any), events (if any), a contributor list, a budget section, and OpenRocket news. In the budget section, anyone can view OpenRocket's recent expenses and transactions, or all transactions, with totals for the current balance, amount raised, and total disbursed.


The above is as of this writing.

The development team expresses its gratitude to all those who have contributed, and to all those who may in the future contribute. All expenditures are intended to be for actual out-of-pocket costs.

Again, thank you all for your generosity and support.

We hope everyone enjoys the new OpenRocket as it continues to improve and evolve.

 

[SiboVG]

I am very happy to contribute, great work being done here - can we get an idea of what the expenses are and how the money will be used? Thanks!

You can find all the details here: https://openrocket.info/donate.html. The first expense is getting a developer license on Windows and macOS to code-sign OpenRocket. This means that OpenRocket would be marked as a trusted app on Windows and macOS machines so that you don't get an abundance of warnings when you try to install OpenRocket. The second planned expense (although less important) is to purchase a RockSim license for our developers so that we can fix some of the RockSim import/export issues.

For the code signing on Windows and macOS, we estimate a total cost of around $300 for a one-year code signing plan (which will get us through code-signing apps until the end of 2023, when we will have to renew our code-signing plan). A RockSim license costs $123.60.

 

[SiboVG]

Ah, Craig has a faster typing speed than me

 

[mtnmanak]

Thanks for the update - may be something to take offline, but I am interested in digging a bit into Keeping The Lights On (KTLO) costs vs funding that will enhance dev.

From the notes above and the website, is the license the only KTLO cost you have or are there other operating costs? And, if I am reading the budget section correctly, is it saying the current KTLO cost is $472, of which you have raised $271, so you need about $200 to break even on operating costs for the year?

I quite happy to support this development. A sim is one of the most fundamental requirements of HPR. I do own a Rocksim license, but Rocksim, after a brief spurt of dev in 2021, does not seem to have been in active development for the better part of a year now, even though it has a number of Sev 1 bugs.

So, I think supporting OR is the right path for Rocketry right now.

What do you think you need for the yearly operations/KTLO costs?

Above that, what would extra funding do for you? Faster Dev? More features? Nothing?

If I gave you a $100, what will that get you? If I gave you $500, $1000, etc?

Once again, I am willing to help out here, just looking for some idea of what levels of funding you need to increase dev capacity or if you are just looking to cover KTLO costs.

If this is better discussed offline, feel free to ping me.

 

[SiboVG]

From the notes above and the website, is the license the only KTLO cost you have or are there other operating costs? And, if I am reading the budget section correctly, is it saying the current KTLO cost is $472, of which you have raised $271, so you need about $200 to break even on operating costs for the year?

Up until this point, OpenRocket did not have any yearly costs, other than the cost of hosting the OpenRocket website, which is currently paid for by Sampo Niskanen, the creator of OpenRocket. Don't know how much those costs are, but it may one day fall under the KTLO costs that will be funded by Open Collective.

The KTLO cost is not really $472. We should be able to pay it off with the $271 we've raised. We don't have the final prices yet, but that should cover it for now.

Also a side-note: the code-signing is not a must. We can still publish new OpenRocket releases after our one-year code-signing plan has elapsed, but you'll just get more installation warnings.

Once again, I am willing to help out here, just looking for some idea of what levels of funding you need to increase dev capacity or if you are just looking to cover KTLO costs.

Currently, increased funding should not decrease development time, since OpenRocket is an open source software that is inherently maintained by people for free.

Because the rewrite of the 3D game engine is a difficult and heavy task, we did ponder about potentially hiring someone to mock up a new, basic framework for the 3D engine, which we can then further develop ourselves. But that's something we'll have to discuss internally first, after we get the official release out. Discussing which game engine to pick, how to rewrite te old code etc. is one of our first priorities after the release.

In case we do make decisions that increase our initial funding goal (~ $500), we will surely announce it.

 

[mtnmanak]

Up until this point, OpenRocket did not have any yearly costs, other than the cost of hosting the OpenRocket website, which is currently paid for by Sampo Niskanen, the creator of OpenRocket. Don't know how much those costs are, but it may one day fall under the KTLO costs that will be funded by Open Collective.

The KTLO cost is not really $472. We should be able to pay it off with the $271 we've raised. We don't have the final prices yet, but that should cover it for now.

Also a side-note: the code-signing is not a must. We can still publish new OpenRocket releases after our one-year code-signing plan has elapsed, but you'll just get more installation warnings.


Currently, increased funding should not decrease development time, since OpenRocket is an open source software that is inherently maintained by people for free.

Because the rewrite of the 3D game engine is a difficult and heavy task, we did ponder about potentially hiring someone to mock up a new, basic framework for the 3D engine, which we can then further develop ourselves. But that's something we'll have to discuss internally first, after we get the official release out. Discussing which game engine to pick, how to rewrite te old code etc. is one of our first priorities after the release.

In case we do make decisions that increase our initial funding goal (~ $500), we will surely announce it.

Thanks for the clarity - I will throw $50 into the pool. If it appears down the road increased funding would be necessary or helpful, happy to contribute more, thanks!

 

[SiboVG]

Thanks for the clarity - I will throw $50 into the pool. If it appears down the road increased funding would be necessary or helpful, happy to contribute more, thanks!

Thanks, appreciate it!

 

[H. Craig Miller]

Have you ever wanted an adjustable nose weight to compensate for different sizes of motors? By using the mass and CG overrides together, without overriding subcomponents, you can, and here’s how it’s done. First, add an internal mass component to match the mass and CG of the finished rocket. Then, check the Stage mass override and set the value to zero (this is the baseline for a small motor), and check the CG override, setting the CG to the distance from the top of the stage to the center of your adjustable weight. When you increase the size of the motor, simply increase the Stage mass override value until the CG is where you want it (adding that additional amount of weight to your rocket).

How to model an adjustable weight system in OpenRocket 2022.02 beta 5 and higher: OpenRocket Wiki

 

[bad_idea]

Hit another NaN issue, opened as 1777. With a build from source today, I'm unable to open any .ork - including the supplied examples - that has a motor inserted.

Haven't had time to step through building progressively with the commits in between my previous, working build from the 24th, so I'm not sure exactly when this started, other than in the past six days.

Edit: it appears to be happening only when I build with the latest commit. I updated the issue report.

Nope, not a bug. See below.

 

[SiboVG]

Hit another NaN issue, opened as 1777. With a build from source today, I'm unable to open any .ork - including the supplied examples - that has a motor inserted.

Haven't had time to step through building progressively with the commits in between my previous, working build from the 24th, so I'm not sure exactly when this started, other than in the past six days.

Edit: it appears to be happening only when I build with the latest commit. I updated the issue report.

Working on it

 

[bad_idea]

Working on it

You were right, Sibo. I ran ant clean and the problem disappeared. I closed the issue. Many thanks!

 

[neil_w]

I am compelled to mention here that @SiboVG has fixed the problem with the CG and CP markers in 3D view. In the next release (which hopefully will be the final) it'll be back to normal.

 

[DeltaVee]

I have a few sims set up for deployment at apogee... I'm using OR 22.02 beta 5, but I'm seeing ridiculous deployment velocities... in some instances over 100mph. These estimates used to be much lower and it seems as if the model gets borked and will always do that. Not every model seems to be doing this however. I could have done something a bit off I suppose but I can't find what... at least not yet. Has anyone else seen this?


Just added: It seems to be something that "plugged" motors are more susceptible to... eg H13-p G12-p etc.

 

[Charles_McG]

I have a few sims set up for deployment at apogee... I'm using OR 22.02 beta 5, but I'm seeing ridiculous deployment velocities... in some instances over 100mph. These estimates used to be much lower and it seems as if the model gets borked and will always do that. Not every model seems to be doing this however. I could have done something a bit off I suppose but I can't find what... at least not yet. Has anyone else seen this?


Just added: It seems to be something that "plugged" motors are more susceptible to... eg H13-p G12-p etc.

Look at your horizontal velocities - those long burn motors are prone to cruise missile mode.

 

[H. Craig Miller]

I have a few sims set up for deployment at apogee... I'm using OR 22.02 beta 5, but I'm seeing ridiculous deployment velocities... in some instances over 100mph. These estimates used to be much lower and it seems as if the model gets borked and will always do that. Not every model seems to be doing this however. I could have done something a bit off I suppose but I can't find what... at least not yet. Has anyone else seen this?

Just added: It seems to be something that "plugged" motors are more susceptible to... eg H13-p G12-p etc.

Could you post the .ork so that the design file can be analyzed?

 

[DeltaVee]

Look at your horizontal velocities - those long burn motors are prone to cruise missile mode.

Oh right! So if I drop the wind speed to zero then so does the deployment velo. It was hitting over 5000' so I didn't think that would be a major component but there you are. Sorry for the noise!

 

[waltr]

Also do a PLOT with 'Distance East' & 'Total Velocity' plotted. Then you will see the horizontal component of the flight.

 

[manixFan]

Oh right! So if I drop the wind speed to zero then so does the deployment velo. It was hitting over 5000' so I didn't think that would be a major component but there you are. Sorry for the noise!

Actually you illustrate a really important ability of OR and something I point out to college teams – they often assume low velocity deployments and as a result, underestimate the amount of energy the apogee recovery hardware sees. Using higher wind speeds helps them appreciate how much stress they might encounter even on a nominal deployment. (Nominal in terms of vertical velocity and altitude.)

Tony

 

[Charles_McG]

I was experimenting with the base drag hack this evening and found something related to Cd override. I seem to remember that Cd override is a work in progress, so this is just a note about how I'd -expect- it to work.

I overrode the Cd of the base drag cone - and it zero out the base drag as well as the friction drag. I only want to zero out the friction drag. So I guess I'd like to be able to control which Cd I was tuning.

 

[neil_w]

Right now I think base drag override is not supported. Honestly, that would be a pretty niche feature, although it's not impossible. Is there any likely use for it other than with the base drag hack? Better solution is to handle base drag CP compensation properly.

 

[Charles_McG]

Right now I think base drag override is not supported. Honestly, that would be a pretty niche feature, although it's not impossible. Is there any likely use for it other than with the base drag hack? Better solution is to handle base drag CP compensation properly.

I agree that better handling of base drag is a better solution - but what I was trying to say is that when I over-rode the Cd it took out the base drag as well as the friction drag (looking in the component analysis). I wanted to make the component frictionless smooth.

 

[neil_w]

I agree that better handling of base drag is a better solution - but what I was trying to say is that when I over-rode the Cd it took out the base drag as well as the friction drag (looking in the component analysis). I wanted to make the component frictionless smooth.

Gotcha.

 

[Handeman]

I agree that better handling of base drag is a better solution - but what I was trying to say is that when I over-rode the Cd it took out the base drag as well as the friction drag (looking in the component analysis). I wanted to make the component frictionless smooth.

I thought that was the point of the hack, to add Cd below the base to simulate the base drag. If you override the Cd, wouldn't that defeat the purpose of the hack? Confused...

 

[neil_w]

I thought that was the point of the hack, to add Cd below the base to simulate the base drag. If you override the Cd, wouldn't that defeat the purpose of the hack? Confused...

No, base drag is already factored in. The point of the hack is to include the effect of base drag on CP.

The confusion around the base drag hack is endless. I am hoping we can get something into the next release to address this.

 

[Charles_McG]

I thought that was the point of the hack, to add Cd below the base to simulate the base drag. If you override the Cd, wouldn't that defeat the purpose of the hack? Confused...

If you look at the component analysis under Tools, you can see that OR is calculating both a base drag (~ to the frontal/basal area, presumably) and a friction drag. I'm going to make a WAG and say that the Drag_friction is ~ to the flow over the surface, and that smoothness modifies it. I was testing to see if I could use the Cd override to zero out the Drag_friction beyond what the smoothness setting does - and how that would affect the resulting sim.

Anecdotally, people experience different results with leaving the base-drag-hack-cone in_situ when running the sim vs overriding the Cg to get the same stability. Peak of Flight #154 doesn't address the question. I have a hypothesis that the differences people are seeing in the accuracy of simmed apogee and time to apogee when using the hack in different ways is based the fraction of the Drag_friction of the hack cone compared to the rest of the model.

In other discussions, it's been noted that the Cd override is 'in development' - so i'm not really surprised setting it to 0 had an unanticipated effect.

 

[JoePfeiffer]

I *think* (so I haven't looked at the code nor played with sims to verify this) that the best way to use the base drag hack in a simulation is to add the nose cone after the body tube with mass and Cd both set to 0.

A *lot* of people mess around with simulations in many ways to get the altitudes right, but almost always in my experience the best way to do it is by adjusting the surface roughness. It's unfortunate that at present the roughness can only be set to discrete values; something I'd like to do (but am deferring until we get the final of this release out) is to let it be continuous. As obvious as that seems, it turns out discrete values are embedded pretty deeply in some value caching code so there's more rewrite than I want to do at this stage.

By the time I was done implementing the Cd override I was pretty sure it was generally a bad idea with very limited applicability (my first paragraph here being one of those applications). Unlike CG and mass, Cd varies with velocity. So any fixed value you set it to is going to be wrong for much of the flight. Other than a few specialized places like the base drag hack, the only way to use it that really makes sense is to apply it to a component assembly like a stage or a pod set and not apply it to subcomponents, so it acts as a bias to "tweak" the results a bit.

 

[neil_w]

I *think* (so I haven't looked at the code nor played with sims to verify this) that the best way to use the base drag hack in a simulation is to add the nose cone after the body tube with mass and Cd both set to 0.

I keep forgetting that Cd is there now and fully functional.

 

[RGClark]

The OpenRocket team is very excited to announce that the new version of OpenRocket is at long last available for everyone to try. For now this is a public beta, which means that there are known issues still to be worked out before the final release. Nonetheless, the current version is stable and usable enough for most folks to start using it full-time.

After a short summer break, Public Beta 5 is now available, featuring a whole swath of UI improvements along with a couple of new features and the usual assortment of bug fixes and tweaks.

IMPORTANT SUB-ANNOUNCEMENT: The OpenRocket project is now officially accepting donations to fund our operations. We don’t need much, but we will be incurring expenses going forward for code signing, which will eliminate the need to disable security when installing and running. For full details, head over to https://openrocket.info/donate.html

Download: https://openrocket.info/downloads.html?vers=22.02.beta.05
Full Release notes: https://openrocket.info/release_notes.html (see also the following post)

Please keep those bug reports and suggestions coming to this thread or straight to https://github.com/openrocket/openrocket/issues.

Here are the major new features:

• Pods!
• Drop-off boosters!
• Rail buttons!
• Attach freeform fins to nose cones and transitions!
• Coefficient of Drag override!
• Better tube fin support!
• Multiple-component editing!
• Contextual menus!
• Dave Cook’s fantastic rocket component library now included!

…plus endless smaller things to make day-to-day use more enjoyable.

The beta is being released in both packaged form and as a plain JAR file (for use with Java 11 or 17, but please note that there are problems with Java 17) at the link provided above. We strongly recommend the packaged installers for most folks.

Updated builds will be made available periodically during the beta period. OpenRocket can check for updates either automatically at startup, or manually. The settings for this feature are found at: Edit > Preferences > General.

This update has taken a long effort from a lot of people. Please give it a try, and let us know what you think. We hope to get back on a more regular release schedule (!) going forward.

Thanks again for your continued support!

Is it possible to have both installations in case the new one has problems?

An upgrade of capabilities in the original one I wanted to see is the ability to do a pitch over during the flight, and thereafter to do a gravity turn. The concept is described here:

https://en.wikipedia.org/wiki/Gravity_turn
Does the new version have this capability?

Bob Clark

 

[neil_w]

Is it possible to have both installations in case the new one has problems?

Yes. However, they do share the same preferences.

An upgrade of capabilities in the original one I wanted to see is the ability to do a pitch over during the flight, and thereafter to do a gravity turn. The concept is described here:

https://en.wikipedia.org/wiki/Gravity_turn
Does the new version have this capability?

Nothing was specifically added to support this as far as I know.

 

[JoePfeiffer]

An upgrade of capabilities in the original one I wanted to see is the ability to do a pitch over during the flight, and thereafter to do a gravity turn. The concept is described here:

https://en.wikipedia.org/wiki/Gravity_turn
Does the new version have this capability?

Bob Clark

No. We don't model off-axis thrust at all.