OR challenge... How did I do this?

[K'Tesh]

Ok fellas... I came up with something new. For transparency I'm using OpenRocket 15.03dev version...

So, how do you do this?



Or this?



There was no manipulation of the images in any imaging software other than to crop out the window you see before you.

Theories?

 

[neil_w]

Pretty sure I know this. I'm guessing it didn't save and reopen properly.

 

[K'Tesh]

Pretty sure I know this. I'm guessing it didn't save and reopen properly.

And I think we have a winner!

 

[K'Tesh]

Now, if only the developers would get rid of that >=2 requirement.

 

[neil_w]

Now, if only the developers would get rid of that >=2 requirement.

It is still not clear to me if they intend to or not.

Slightly different design, same approach:


Nice idea, by the way. Definitely opens up some possibilities.

 

[K'Tesh]

It is still not clear to me if they intend to or not.

Slightly different design, same approach:
View attachment 327964



Nice idea, by the way. Definitely opens up some possibilities.

Yup!!! I've put it to them again... Hopefully this will break down the opposition to the requested support.

 

[K'Tesh]

And at the suggestion of Phill Ash

 

[neil_w]

Ha, good one!

 

[Buckeye]

Does the Cd and CP get calculated correctly?

 

[neil_w]

Does the Cd and CP get calculated correctly?

Almost certainly not.

 

[Buckeye]

Almost certainly not.

Then this exercise is meaningless for a rocket simulation software. For fancy renderings only, I would turn to Autodesk, or for the OpenSource crowd, Blender. Seem easier that way.

 

[dhbarr]

Then this exercise is meaningless for a rocket simulation software. For fancy renderings only, I would turn to Autodesk, or for the OpenSource crowd, Blender. Seem easier that way.

Appearance is a thing you can simulate .

I know I'm not going to bother learning Blender just for appearances, but pushing ORs limits is potentially much more attainable for me.

 

[Charles_McG]

Then this exercise is meaningless for a rocket simulation software. For fancy renderings only, I would turn to Autodesk, or for the OpenSource crowd, Blender. Seem easier that way.

I don't think OR has ever been exclusively about flight simulation. It handles lots of interior tubes, disks and parts that yes, contribute to Cg - but don't have to be rendered in semi-transparent views, like OR does. And can be faked with a master weight/Cg override. Nor is decal handling necessary. Or the in-flight photo generation.

My wish would be the ability to exclude parts for the purpose of flight simming. So I could take one of Jim's really accurate kit-sims and uncheck the parts that aren't flight-sim critical without having to delete them entirely.

Jim, if I understand your 'one pod only, sir' request, it's [partly] so you can split pods and put different decals on them. Full single-pod function might be most flexible, but if that's too much of a challenge for the developers (handling lopsided rockets), then maybe there's a middle ground. Split the pods, so they can be finished differently, but not allow them to be deleted (or have fin-on-pod or pod-on-pod edits). Not fully flexible. Maybe easier to implement and at least partly useful to an advanced kit-simmer like yourself?

 

[neil_w]

My wish would be the ability to exclude parts for the purpose of flight simming. So I could take one of Jim's really accurate kit-sims and uncheck the parts that aren't flight-sim critical without having to delete them entirely.

I have asked for this in the past, but I don't think it's something we'll be likely to get soon, if ever.

Jim, if I understand your 'one pod only, sir' request, it's [partly] so you can split pods and put different decals on them. Full single-pod function might be most flexible, but if that's too much of a challenge for the developers (handling lopsided rockets), then maybe there's a middle ground. Split the pods, so they can be finished differently, but not allow them to be deleted (or have fin-on-pod or pod-on-pod edits). Not fully flexible. Maybe easier to implement and at least partly useful to an advanced kit-simmer like yourself?

Different decals is one of the least important reasons to need single pods. There are hundreds of designs that require it, which generally fall into two categories:
1) Designs that simply have only one pod. Example: the Estes Orbital Interceptor. The T fin on top requires a single pod to create the fins-on-fins.
2) Designs that have multiple pods not symmetrically placed around the rocket, or have fins that are arranged asymmetrically. Example: the wing tanks on the original Interceptor.

As far as I can understand, the existing requirement for at least two pods, symmetrically arranged, is to handle the case when motors are placed in the pods (to keep thrust centered). However, pods have vastly more usage than just for outboard motors. Unfortunately the whole implementation is really geared for outboard motors, but with a few small accommodations it should be able to handle a pretty wide variety of designs.

 

[Charles_McG]

As far as I can understand, the existing requirement for at least two pods, symmetrically arranged, is to handle the case when motors are placed in the pods (to keep thrust centered). However, pods have vastly more usage than just for outboard motors. Unfortunately the whole implementation is really geared for outboard motors, but with a few small accommodations it should be able to handle a pretty wide variety of designs.

I understand how pods can be creatively used. I guess I was thinking back to Jim's first venting about obligate pod plurality. A year or so ago, I think.

If the implementation is outboard motor focused, it seems like a (relatively) simple accommodation would be to disable the mounting of motors in pod groups when n<2. [Not having seen the code ]

 

[neil_w]

obligate pod plurality

That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).

If the implementation is outboard motor focused, it seems like a (relatively) simple accommodation would be to disable the mounting of motors in pod groups when n<2. [Not having seen the code ]

I suggested that as well. It's probably a bit easier said than done. We'll see where it all ends up.

 

[Charles_McG]

That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).

You're welcome. I'll look for the Half-Baked post. And I will expect it to be asymmetrical.

 

[neil_w]

Challenge accepted.

 

[snrkl]

Is there an actual beta program or is it just a GitHub sync that needs to be done?

 

[K'Tesh]

I don't think OR has ever been exclusively about flight simulation. It handles lots of interior tubes, disks and parts that yes, contribute to Cg - but don't have to be rendered in semi-transparent views, like OR does. And can be faked with a master weight/Cg override. Nor is decal handling necessary. Or the in-flight photo generation.

My wish would be the ability to exclude parts for the purpose of flight simming. So I could take one of Jim's really accurate kit-sims and uncheck the parts that aren't flight-sim critical without having to delete them entirely.

Jim, if I understand your 'one pod only, sir' request, it's [partly] so you can split pods and put different decals on them. Full single-pod function might be most flexible, but if that's too much of a challenge for the developers (handling lopsided rockets), then maybe there's a middle ground. Split the pods, so they can be finished differently, but not allow them to be deleted (or have fin-on-pod or pod-on-pod edits). Not fully flexible. Maybe easier to implement and at least partly useful to an advanced kit-simmer like yourself?

Part of the one pod only was for the decals, as well as asymmetrical pod arrangement, and fin on fin placements like Neil explained. The big reason is that OR 15.03dev doesn't handle fins on pods properly... Lets say you have an odd number of pods (3, like the Estes Trident). Let's position the LL between two of the pods, and place that side down so the rocket is horizontal. You have one fin on each pod... Problem is that OR will orient the fins on all 3 pods in the same direction as the fin on the "top" pod. In other words, all three fins will be parallel to each other pointing straight up, instead of at 120 degrees. Basically the code needs to be fixed to make the pods "mirror" each other, relative to to their orientation.

 

[K'Tesh]

Is there an actual beta program or is it just a GitHub sync that needs to be done?

Cabernut informed me of the developer's version of OR back in Feb... I don't know if I can/or should share it... You might want to toss him a PM.

 

[K'Tesh]

I understand how pods can be creatively used. I guess I was thinking back to Jim's first venting about obligate pod plurality. A year or so ago, I think.

That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).

If the implementation is outboard motor focused, it seems like a (relatively) simple accommodation would be to disable the mounting of motors in pod groups when n<2. [Not having seen the code ]

I suggested that as well. It's probably a bit easier said than done. We'll see where it all ends up.

What about boost gliders? There's a number of gliders that have number of pods equal to 1 (I'm working on a sim for one right now). Right now, I really don't care if you can or cannot get flight info out of those sims. In some cases, I'm trying to preserve old designs by creating a file that can be used to clone them, in others I'm trying to figure our how their flight characteristics would change using modern motors (or redshifting a design)(in those cases, flight info is desired).

Mind you, I don't advocate cloning designs that are currently in production (unless you began the cloning process before the design was re-released). In my book, upscales and downscales are not clones.

 

[Cabernut]

Release candidate zero, (RC0) has been put together for bug finding. Some bugs are obvious and some are not so it would be good if a checklist could be compiled. I'll have to look up the link for the rc0 .jar file and post it here.

As for the reasoning behind pods >=2 was that certain simulation shortcuts are possible if the forces are symmetrical. Having one pod would throw things off a bit. I personally don't see why there couldn't be a warning like the ones for thick fins, too many parallel, or jagged edge fins, etc.

 

[Cabernut]

Try this link from one of the chief devs:

https://drive.google.com/open?id=0B--d1_8sQP5HdzAweFJ6LW1lRDg

 

[boatgeek]

That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).

If you do build a rocket with that name, it needs to have about 8 pods. Just sayin'.

Also, everyone is talking about pods, but I'm not seeing how to get pods at all (let alone pods with motors) in release 15.03. I want two, so am safe from obligate pod plurality rules. Can anyone point the way? Thanks!

 

[markkoelsch]

Then this exercise is meaningless for a rocket simulation software. For fancy renderings only, I would turn to Autodesk, or for the OpenSource crowd, Blender. Seem easier that way.

I completely agree. It can make a pretty picture- neat, but so can a variety of graphics programs. Can it tell me if the rocket will fly correctly or not- seriously doubt it can. If it cannot do that it is useless.


Sent from my iPhone using Rocketry Forum

 

[Cabernut]

If you do build a rocket with that name, it needs to have about 8 pods. Just sayin'.

Also, everyone is talking about pods, but I'm not seeing how to get pods at all (let alone pods with motors) in release 15.03. I want two, so am safe from obligate pod plurality rules. Can anyone point the way? Thanks!

Pods will be in the next release. See my post above for the work-in-progress "15.03dev"

 

[K'Tesh]

Just downloaded OR again from Cabernut's link... Here's the reason we need individual pods, until they can fix this... Every 3 finned rocket reminds you of the Shuttlecraft Tydirium.

 

[neil_w]

That's not why you need single pods... that's why you need that bug fixed.

 

[K'Tesh]

That's not why you need single pods... that's why you need that bug fixed.

Unless that is the desired fin arrangement.