pander59

Granted, these humorous items were actually meant for real spacecraft design, but I don't see why the comments do not cater to even our own machinations in such a simulated environment. I know I immediately thought of the community the minute these came back into my vision. Enjoy. Akin's Laws of Spacecraft Design* 1. Engineering is done with numbers. Analysis without numbers is only an opinion. 2. To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong . 3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. 4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. 5. (Miller's Law) Three points determine a curve. 6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker. 7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it. 8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point. 9. Not having all the information you need is never a satisfactory excuse for not starting the analysis. 10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along. 11. Sometimes, the fastest way to get to the end is to throw everything out and start over. 12. There is never a single right solution. There are always multiple wrong ones, though. 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. 14. (Edison's Law) "Better" is the enemy of "good". 15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. 16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours. 17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct. 18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though. 19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up. 20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately. 21. (Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which. 22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.) 23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. 24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it. 25. (Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along. 26. (Montemerlo's Law) Don't do nuthin' dumb. 27. (Varsi's Law) Schedules only move in one direction. 28. (Ranger's Law) There ain't no such thing as a free launch. 29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right. 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept. 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees. 32. (Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up. 33. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...) *I've been involved in spacecraft and space systems design and development for my entire career, including teaching the senior-level capstone spacecraft design course, for ten years at MIT and now at the University of Maryland for more than a decade. These are some bits of wisdom that I have gleaned during that time, some by picking up on the experience of others, but mostly by screwing up myself. I originally wrote these up and handed them out to my senior design class, as a strong hint on how best to survive my design experience. Months later, I get a phone call from a friend in California complimenting me on the Laws, which he saw on a "joke-of-the-day" listserve. Since then, I'm aware of half a dozen sites around the world that present various editions of the Laws, and even one site which has converted them to the Laws of Certified Public Accounting. (Don't ask...) Anyone is welcome to link to these, use them, post them, send me suggestions of additional laws, but I do maintain that this is the canonical set of Akin's Laws...

Which solved the problem. Proper detachment when the SRBs are attached to the decouplers while the mouse is over where the decoupler is actually located. Silly little problem and I might have never found the answer without the assistance of the community. Thank you all very much for your help. I will use this info in the future if other issues come up... Don't always look for the obvious answer. Many times it isn't always the correct path to the solution. Grr. I hate answers like this. They seem to arbitrary. Nonetheless, I am grateful for your assistance.

So the secret is revealed on the attachment phase. Thank you. It sure looked like I was doing it properly but then again, the mystery is in the details. I will try this again with this bit of information. and will report the results.

I considered that as well and have changed the decouplers from one version to the other. Also considering the SRBs were permanently attached and moving things around for mounting points. The decouplers blow, they just don't release. Now after re-reading your post, I will try this one again... making absolutely sure that they are physically attached to the decoupler rather than the ship itself. I have attempted this before but it would seem it is the only reason why the SRBs remain after firing the decouplers. Still, if it is obvious that I am attempting to attach to a decoupler, when the alignment during assembly changes color and allows the attachment, it should just be right... correct?

Now that has some things I can deal with. The craft file is here : http://wikisend.com/download/938664/Let's make this work.craft Thank you for your concern. This is a prototype, I know it has issues that need to be addressed. I will work on them once this detach issue is resolved. The short SRBs detach properly. When I command the longer ones to detach they just remain as they were. You will see that as soon as you run it. I am sure it is something stupid, but this isn't the first time I have had issues with decouplers.

Okay, I am trying to attach an image. This apparently isn't going to work out too well. I don't do cell phones. I used to, but I don't like them. I have never done personal media, so facebook and the like are just completely bogus items. I cannot attach an image to a post because I have no place to send it to provide a proper IRL. Yes, for crying out loud, I have other options to pull this off. I shouldn't have to do this much work to send a pic into etherspace. When I settle down just a little I'll try again. I really do want an answer to this particular problem.

And before I go down the very quick replies, I have way over-enjineered my potential screw ups... thankyuverymuch. To answer one just a tad down, rather than use multiple decouplers, I decided to go with singles, despite the issues with SRB rocking. I can balance the load and prevent that, but I still don't get clean separation on every item attached radially. The problem does seem to be with the longer SRBs. As for another lower respondent, I will make an attempt to give you a visual in the Assembly area and during launch. I know for sure that staging has been properly taken care of. Now what I need is some multimedia assistance. I am a geek, a dweeb. I do networks as if I had bits in my brain. I don't do videos. I will learn. You guys seem to know all about it. Sigh. I'm an fscking 55 year old unix guy. I solved my problems with doom and the rest of the FPS scenario. I am back to geekdom and alpha-testing software. But for that tweaking little piece of crap that should just work I am bewildered.

I've had this problem since 0.18.0 and still have it in 0.25.0. I have yet to see it properly discussed or even worked around. People routinely have radial decouplers properly operating on their spacecraft. When I use them to remove SRBs from mine, most often only one set actually operates and another set fails to eject. I have a nice rocket that I want to get into orbit now. The primary stage SRBs eject as commanded. The secondary (longer burn) SRBs remain attached and drag my "third stage" liquid rocket down due to the weight. I have tried various decoupler versions, various decoupler configurations, and various decoupler strategies. To no avail. There is obviously some secret that I have yet to behold. Radial decouplers should just work, correct? This isn't secret physics. Blow a bolt and the whole thing should just drop off. For crying out loud, this is driving me insane. I need some help. It shouldn't be this tough.