- Joined
- Mar 27, 2013
- Messages
- 14,849
- Reaction score
- 1,257
And I think we have a winner!Pretty sure I know this. I'm guessing it didn't save and reopen properly.![]()
Yup!!! I've put it to them again... Hopefully this will break down the opposition to the requested support.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.
Almost certainly not.Does the Cd and CP get calculated correctly?
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.Almost certainly not.
Appearance is a thing you can simulateThen 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.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 have asked for this in the past, but I don't think it's something we'll be likely to get soon, if ever.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.
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: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?
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.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.
That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).obligate pod plurality
I suggested that as well. It's probably a bit easier said than done. We'll see where it all ends up.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]
You're welcome. I'll look for the Half-Baked post. And I will expect it to be asymmetrical.That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).![]()
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.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?
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.Is there an actual beta program or is it just a GitHub sync that needs to be done?
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.
If you do build a rocket with that name, it needs to have about 8 pods. Just sayin'.That is an awesome turn of phrase, gotta use that somewhere (maybe a future rocket name).![]()
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.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.
Pods will be in the next release. See my post above for the work-in-progress "15.03dev"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!
Unless that is the desired fin arrangement.That's not why you need single pods... that's why you need that bug fixed.![]()