DStaal

As another corner case to look at: My (old, as I'm stuck on 1.1.3 for hardware reasons) version had an unpleasant interaction with some air-augmented solid boosters recently: When they auto-switched from air-augmented to standard rocket mode, GravityTurn autostaged them away - despite them still running and having fuel. The effects were slightly less catastrophic than expected, as the payload did survive, and was in a position to safely abort... Either way, it's worth looking at whether this is also an issue with the current version, and whether something can/should done about it. I believe the boosters I was using are from the BDB pack.

Literally the post above yours. (Mods: Might it be an idea to lock this thread? Unless it's original author comes back, there's no reason for further posts here.)

Awesomeness is being documented above.

Heh. It uses the skycrane from USI - the engine is directly above the decoupler. It's retracted at the moment, as in this ship the engines and the ladders can't be deployed at the same time.

Actually, 1.2 doesn't work on my computer... That's in 1.1.3. (And here I thought people were going to wonder about where the engines are. )

Because NecroBones might like action shots of his mod, and because I'm proud of this little guy: Just landed, still in transport configuration: Autonomic science rover deployed, and ready for final field test before setting out. (And before the Mun exploration crew does their local set of experiments and heads back to Kerbin): The rover is a mix of Buffalo, BDB, Coatl Areospace, and DMagic Science parts. Mostly.

Go to the original GravityTurn thread for a 1.1.3 version. But I don't think it will work all that well if you can't throttle down - changing the throttle is it's main method of control.

I believe Indicator Lights would be able to help with that. You might even be able to write an MM config file that does it.

@RoverDude - Given the currently common 'Habitation isn't the same as it was in VAB! Help!' requests, I've added a GitHub feature request: Have a column in the VAB LS window that shows the habitation+bonuses separately from the habitation without the activatable bonuses. The idea here is to increase discoverablity: Currently, people see that the habitation in the VAB is different then on the launchpad, figure something is wrong, and come ask for help. With an extra column, they are more likely to notice that 'wait, it matches *this* column, but not that one', and figure that there is some way to get it to match the other - which leads to 'doing things with parts': pulling up right-click menus and looking at options. Even if they don't make that connection, they'll likely come here and ask 'how to I 'activate habitation' or whatever you decide to call it, and get a quick answer. (And after a couple of times it's been answered, Google will be able to point them to it.) Related and optional - but would also increase discoverablity and planning - would be to add another section (or another column to the part breakdown) to the VAB LS window with the EC costs of activating the habitation bonuses. Then people will be able to see there's a trade-off, and that EC is being used for something. (I'm guessing this is technically redundant data to the standard part info, but I'm not sure.)

Stepping away from the shuttle parts for a moment: In the station parts pack, anyone else having issues with not being able to get science out of a KerbalLab? I can load it up with experimental data and process that data just fine - but clicking 'transmit science' runs through a transmission sequence without actually moving the science. I'm still in 1.1.3.

I'm actually liking KSO's station parts pack at the moment - although arguably they're a bit overpowered, and buggy in some cases.

I'm actually pretty much with you on the austere thing, actually. My point on the power for the DeepFreeze pod is that if you're getting in this pod it's because you don't expect the ship it's attached to to operate much longer (or even right now...) - and if that's the case, you shouldn't rely on it to make the pod's life-support systems work. In the DeepFreeze pod's case, the 'life support' comes in the way of cryosleep, so you should be able to enter cryosleep (but not necessarily exit) with just the resources of the pod - because those are the only resources you can count on working at the point where you need the pod. Otherwise your ship starts coming apart, you jump in the escape pod, and... Quickly starve to death, because the pod doesn't work. (Actually, you'd probably run out of air first, I think.) It's a deep-space pod, so going someplace isn't likely to be helpful (if you're likely to be near habitation, use a mk1A, a mk1N, or a mk1D as appropriate. Two of those can land, because getting someone out of orbit and to a base/habitable planet is much more likely to keep them alive than hoping there's a rescue ship capable of the run nearby. The other waits for pickup.), at least not without bolting on another whole ship. But you should be able to do the primary function of the pod. Now, again, what I'd expect them to have in real life is some sort of one-off solid state fuel cell - something that's stable for long-term storage, but can provide the power needed to run the freezer. Once. And yeah, there's no real need for escape pods in KSP. I like to mount them anyway. (Though there is a mod that brings in orbital decay, if you want it.) Though actually I can see the DeepFreeze pods being the most useful in some ways: If you're running a life-support mod, and you've miscalculated how much supplies you needed, freezing yourself and waiting for rescue sounds good. (Actually, it might be worth looking into MKS's wear mechanic as well as it relates to these... It can cause a ship to fail, if you don't take care of it.)

Note that it's not so much about craft - it's about leaving the scene and going to a new one. You can EVA, and switch between local craft all you like without triggering the redraw which fixes it. I haven't tried a F5/F9 cycle - that should fix it.

As a note: ARP can delete the stock resources button and replace it on it's own. I find that it usually only works on the second craft I load per session (that is: I need to switch scenes, not go back to the tracking center), but it is an option.

I would argue that if you can rely on your parent ship for power, why are you getting into an escape pod? Though realistically they'd probably have some sort of specialized power solution for this: capacitors come to mind, but I'm thinking more likely is some sort of one-off fuel cell that can supply just enough for the freezing process. Then yeah, an RTG to maintain power to the freeze systems and to run the beeper.

Testing continues - A rack of mk1N pods was sent to Minmus (where bases are set up) for non-atmospheric testing. Monoprop usage was minimal for these, although testing was done from low orbit. Battery life was a limiting factor, as expected - even with an extra battery attached it took careful management to maintain power availability until landing. On the other hand, the idea of attaching a DERP monoprop fuel cell to one worked flawlessly, and supplied more than sufficient power all the way to landing. Reaction-wheel control was sub-standard, however. It appears the mk1N has issues being able to hold a position in space - this is awkward, as it is the sole pod that *requires* holding a specific orientation. The wobbling under SAS was a significant part of the drain on EC - it's recommended therefore that users not turn on SAS until within ~1km of the surface or less, to reduce power usage. As a side-note, the optional Landertron software pack works fairly well - but users of the pods should be aware that the software only appears to consider *vertical* velocity to the surface. It is advised to reduce horizontal velocity as much as possible during the initial de-orbit burn. As a final note: While the mk1A gets set neatly on it's bottom by the parachute, the mk1N is much more likely to tip over during landing. As these tests were unmanned it is uncertain whether the extended landing rockets provided enough clearance to exit safely, but it is worth bearing in mind for future rescue operations: The pod may need to be rolled over before the occupant can be retrieved. Also, Bob's idea of hacking a parachute casing to store extra monoprop appears functional, although more work is needed on the paint scheme. Testing has been authorized for the battery and fuel cell variants. (I’m hacking at these - though I'm trying to figure out how the texturing works in KSP and not having much luck so far.)

Glad to have this back - It's nice to have full three-axis control of my Kerbals on EVA.

One of the mods you've added is MKS. It changes the required resources for building.

The problem with retexturing is that someone was really clever - all the models share the same .dds, and just reference different parts of it for the icon somehow.

I should note that my idea of 'extra range as an upgrade' I really mean less range: You start with fairly close, and upgrade to full 2km.

If that's a goal, my thought would be to have upgrades to the parts that can be unlocked late. Extra range to the proximity sensor (or extra resolution, if that can be done) or being able to have proximity to things other than other ships are first thoughts.

Fuel sensors to me sound like they shouldn't require anything advanced - and are something you'd have a sensor on anyway. If it's not at the start, it should be very early. Basic or General rocketry make sense to me, as that's the first couple of LF rocket engines. (Maybe General Rocketry, if you want to put it a bit: Have the idea be that the first few LF rockets they just fired off, but they soon learned to put fuel gauges in.)

Looking forward to it. I'll admit I think the IVA for the DeepFreeze pod should be fairly basic: They really only need two buttons and a light. Hit the big button to detach the escape pod from the ship/station, wait for the light to turn green, hit the small button to freeze everything in the interior of the pod.

Ok, my Kerbals have been running this new addition to their fleet through it's paces, and have some after-action reports: (Note all of this is in 1.1.3 with pods slightly modified to work in that version of KSP. Testing focus so far has been on the mk1A, as it's quicker to deploy to test status, and lessons are expected to carry over. Testing has been with unmanned pods; The thought being you should be able to stuff a Tourist in an escape pod in an emergency. Also, I crashed ~6 pods before I landed one, so unmanned testing was warranted. ) Power is limited. This is not a major problem in the mk1A, as all maneuvers can be done immediately after separation. It is expected to be a major issue in the mk1N, where power is needed for touchdown as well. Monoprop deorbiters are plenty powerful, though a bit more fuel would be nice - mk1A can only be used in low Kerbin orbit; it would be useful for it to have enough to deorbit from a 250-350km or so Kerbin orbit, high enough for a mid-range Kerbin transfer station or a science station built to run high-Kerbin experiments. Control setup is surprising. You thrust towards prograde to deorbit. Parachute setup requires tweaking; my space agency is still iterating on this. The default opens way to high on my normal reentry profile; bringing the default deploy pressure to 0.5 (up from 0.05) atm appears to work, although mountains can cause issues. It's been a very nice pod to work with. From the above, what I'd like to see is the control scheme fixed, and possibly a battery in the same profile as the parachute - you can't afford to depend on solar for landing in the mk1N, in my opinion, and it needs a bit more power. A battery would also alleviate parachute setup: I normally fire my parachutes off manually, but that requires active control, and I usually run out of EC well before I enter the atmosphere. (Although I'm not sure that mountain landing would have been survivable in any case - the parachutes may not have had enough time to slow down the pod even if they'd deployed as soon as it was safe.) My Kerbals have always liked the idea of having escape pods handy, but the DERP pods have been awkward and ugly to install and to use, as they require an EVA. (Though their reentry characteristics are superb.) The REKT pods look to be much nicer both aesthetically and operationally, once the learning curve on their use is worked out.

To note: This is not a 1.2 issue, as I have the same problem, and I'm still on 1.1.3. Here's my modlist: