Starwaster

Parking lot??? Wow, that is ambitious

Thanks for this, sorry for the delay in replying but I wanted time to try this out first. It's a definite improvement though I do see the occasional odd moments where the autopilot should be satisfied with the ship's heading/attitude but is not. The last sentence in your reply makes me think that you're coming away with an interpretation of something I said that I didn't intend. I meant only this (situation with oversteering/countersteering) was one of these times where coding should mimic real life. Nothing more than that.

Note though that I did not actually change the existing parts. Rather I copied the cfg files (name them anything; I gave them *_decoupler.cfg names so that I know which is which) then added my desired change to my new part. If you do the approach that you're adding these as new parts then it's vital that you change the line that says 'name =' or it will look like it works in the VAB but then on the launch pad it will mysteriously not decouple because it ends up loading the originally named part.. Also beware of staging issues. The fairing mounts weren't meant to be decouplers so they weren't ever going to end up in the staging list. Apparently I neglected to add lines that tell KSP *HOW* to stage these parts. So they WILL end up in the wrong stages and you have to manually move them. I think they need the following lines but I have yet to try this on my end: stageOffset = 1 childStageOffset = 1 Other than that they work great. Not having to add separate decoupler rings makes these more stable. In fact they end up more stable than the equivalent KW Rocketry fairing/interstage parts. (especially the interstages)

I meant to have one up by now, at least for the first capsule, but then I got dragged into some L4D2...

yeah Voyager is a cool program, for how far they've gotten and for how they got there. I'd also like to bring up Curiousity. I didn't keep myself as well informed beforehand as I usually do so I didnt know about the landing system with its skycrane deployment until literally hours before and I remember understanding immediately that due to time lag that our little probe was really on its own for this descent. I mean, they always are, there's no remote controlling them at this range or even knowing their fate for minutes after they're down but it really struck home on Curiousity just what had to happen and how it all had to happen automatically... and I was wondering if we'd gotmjust a bit too bold on this one...

Ok, good point. I don't see the OP having posted anywhere since June 4th. Given copywrite restrictions enforced re: editing parts for re-release by third parties, let's put our minds together and make some ModuleManager patch files?

They don't NEED a 0.21 update. They're just parts, and the format for parts did not change transitioning from 0.20.x to 0.21.x

wow just had a waking nightmare reading this thread... a nightmare involving driving a rover on Gilly... (just had my first successful landing there... probably would have gone easier if I'd had more than 8kg of left in the tanks for rcs)

I'm tempted to use the rescale option on these maybe 30 times larger or so.... And build the Valley Forge! now someone needs to model three robotic helpers, different colors...

What are you putting in there? The following should do it: MODULE { name = MechJebCore } Or if you have ModuleManager installed, stick the following somewhere in your GameData folder as a *.cfg file. Really doesn't matter where in there it goes or what it's named as long as it has .cfg as an extension and it's located in GameData or a subfolder. @PART[cupola] { MODULE { name = MechJebCore } } @PART[landerCabinSmall] { MODULE { name = MechJebCore } } @PART[Mark1Cockpit] { MODULE { name = MechJebCore } } @PART[Mark2Cockpit] { MODULE { name = MechJebCore } } @PART[mark3Cockpit] { MODULE { name = MechJebCore } } @PART[Mark1-2Pod] { MODULE { name = MechJebCore } } @PART[mk1pod] { MODULE { name = MechJebCore } } @PART[mk2LanderCabin] { MODULE { name = MechJebCore } } @PART[probeCoreCube] { MODULE { name = MechJebCore } } @PART[probeCoreOcto] { MODULE { name = MechJebCore } } @PART[probeCoreOcto2] { MODULE { name = MechJebCore } } @PART[probeCoreSphere] { MODULE { name = MechJebCore } } @PART[probeStackLarge] { MODULE { name = MechJebCore } } @PART[probeStackSmall] { MODULE { name = MechJebCore } } @PART[seatExternalCmd] { MODULE { name = MechJebCore } }

Yes, except that as of 0.21 SAS is now better at those things than Mechjeb is. Mechjeb has some basic, fundamental issues with attitude control that just aren't being addressed, probably because nobody seems to actually talk about what the problems are. If you ever watch Mechjeb's inputs at work, ask yourself...is that how *I* would be flying my ship? If it is then you're going to wear out your WASD keys in short order.

I made copies of each of the part *.cfg files, added _decoupler at the end of the part's name property in the file (just for uniqueness so that KSP can tell them apart) then put this in each PART MODULE { name = ModuleDecouple ejectionForce = 250 explosiveNodeID = top } Now I have decoupler versions of each ring and fairing base...

boy this needs to be in the stock game...

Yeah, pretty much. There is a way to mitigate the issue, a bit. Cut thrust so forward acceleration ceases, then eject them. With KW fairings I've had slightly better results if I bind the fairing decouple to action groups instead of staging, but that might just be a placebo effect. (I mention KW because it's an issue with just about any decoupler sort of part but mostly with the fairing type objects)

I'm trying... I'm trying REALLY hard to derive some comfort from that but it's just not working...

That was my reply, let me compliment him the way I whats (sic). ok?

I have a similar situation with launches, but not (as near as I can tell) as bad a problem as you have. My problem is that if I do a launch with a viewpoint too close to the rocket I start imagining that I'm a technician who somehow got caught clinging to the spacecraft during launch because nobody noticed me there and I couldn't get to safety in time. If that happens.. what the HELL do you do??? I can only imagine that the only action that offers any hope of survival at all would be to leap from the rocket before it climbs high enough that death becomes 100% certain. But if you're leaping from something as tall as a multistory rocket, what are your chances of survival? Better than 100% I would hope but still pretty slim. But what if you were so petrified with fright that you couldn't even bring yourself to let go? To leap? Both scenarios scare the crap out of me...

QFT Me: "Jesus, MJ, what the hell are you DOING??? Do you see where our periapsis is going? Are you TRYING to get us killed??? MechJeb: "I'm sorry, Starwaster, I want you to know I still have the greatest enthusiasm for the mission."

omg are you crazy??? that looked perfect!

Like an interstage? Yes, I think that's what the inline fairings are...

procedural fairings!

missed this earlier but on the subject of gyros, it's not necessary to have them integral to each module. the ISS does indeed use these for attitude control but it's a single module with 4 gyros mounted to one of the trusses. we really already have what we need, stock, as of .21 IMO just saying. and glad you liked the pics, I'd love to see it make an appearance finally, does anyoune know if there's a modelling path possible using XSI for importing?

I read some interesting reasoning as to why certain spacecraft dispensed with airlocks in favor of cabin depressurization-EVA-repressurization airlocks are massive and weigh far more than just carrying surplus oxygen to repressurize with....

0.21 saves can be imported. You are given that option when KSP detects older saves.

How about: Without fairing With fairing (note the cool lighting strips along the frame...) Fairing (frontal) Looks cool with wheels mounted on it!