DStaal

I'm not sure. It was brought in to solve a severe problem for MKS users that many people couldn't get needed pilots and scientists early-game. You'd have to talk to RoverDude.

Do you have MKS installed? Recent versions contain a derivative of this mod as well. (So you can hire all the different types of Kerbals without waiting for months to get the profession you need.)

No problem with the mod. The forum lost a bunch of threads earlier this year though, and Karbonite was one.

The Flight Engineer is a window from Kerbal Engineering Redux: The one on the left... I think I've seen it in Kobattos review, but I'm not sure.

The configs at the moment aren't exactly easy to test: You need to remove, edit, and replace files from KPBS if you want things to be clean.

Just wanted to let people know that Merkov and I (mostly Merkov...) have been doing a lot of discussion and work on this over on GitHub as well. I'd count most of the parts as done for stage 2 - pending a bit of play-testing and poking around. There are still three parts whose configs I think may need some tweaking: The Central Hub, the MK1 habitat, and the Greenhouse. The latter needs the most work, as we're still discussing how we want to deal with it: I think we should have the full multi-mode greenhouse like MKS has, but which modes should be available with USI-LS is an open question.

A little bug I've seen for a while, but haven't gotten around to localizing the behavior: For burns of over about 5 minutes, the automatic alarms don't appear to correctly calculate the 1/2burntime+margin for inserting the alarm: The alarm gets set to close to the burn, meaning you should have already started the burn by the time the alarm goes off.

Very mass-efficient EC storage, with drawbacks in how you can use it. Really good for things like powering Xenon engines - you trickle-charge the capacitors between burns, and then discharge during the burn. Saves you quite a bit of mass over either batteries or a reactor that can power the engine for the same burn.

It still has an EL survey station in it.

I tend to do a three-stage to orbit, with the last stage emptying out just at insertion, so I notice it more. I find you want at the very minimum a TWR of ~1.2 through around 40k off of Kerbin. Past that you can often get by with less, depending on the exact launch profile you've achieved. But underpowering the third stage is my biggest cause of launch failures: Just a bit to low, and GT can't keep the apoapsis up, and I burn through all the fuel that was supposed to get me to orbit, leaving me with only my vacuum engines trying to get through the last 15k of atmosphere. This can even be triggered by an extreme differences between the TWR of the lower launch stages and the upper launch stages: GT will aim a more shallow trajectory if it notices you have the power to do so, and if you then shed that engine for something with a significantly lower TWR, that shallow trajectory may no longer be workable.

Another source of vector and aerodynamic losses are underpowered upper stages: The rocket will have to pitch up to maintain it's climb rate, resulting in a less efficient profile.

Heh. RoverDude is *not* a good example here. He's willing to work with CKAN now - after there were some policy change that meant that mod authors have more control over things. Before that he was one of the stronger anti-CKAN people around. And Streetwind has given a perfectly good reason not to support CKAN - because it's a lot of work for him. There are some that find that work useful, and some that don't. I'm working on a mod at the moment, and I'm not planning on directly supporting CKAN because CKAN hasn't been useful to me, so I don't use it. Therefore I don't have a good way of testing it, and don't feel I can offer any useful support. I'll be open to others uploading it onto CKAN - and I'll point people having trouble with CKAN installs to them.

I think part of it is residual - for a long time CKAN would list mods whether the author wanted them to or not, and you'd get a lot of users that would say 'of course I've installed it correctly: I used CKAN', when using CKAN is *not* a guarantee of a correct install. And then those users would argue with the mod makers saying that they need to fix something, when the entire problem was out of their hands and may well have been something the mod maker was against in the first place. Now, CKAN has fixed up their policies some, but it still isn't completely smooth - and users have to know that, and be willing to see if their problem is on their end before reporting problems. Which often isn't the case.

I think aggressively stating that a mod maker needs to do something that they've very clearly said they don't want to do is fairly hostile to start with. (And I run ~200 mods, without CKAN - because it's not very well supported on my platform, to the point that until I upgraded my computer it wouldn't run at all.)

Just so people know, there are actually very extensive guidelines - with instructions on how to use them:

There's also Experiment Tracker, which I find a bit cleaner to use:

0.0005 is correct. You should be able to see and change this in the Life Support settings window. (Open the LS window in KSC view.)

True, but monoprop's largest real-world advantage in many cases is not needing an ignition source - something which doesn't apply in KSP. So it gets harder to justify tradeoffs against performance.

I get the feeling the fix for that will be as soon as he knows what the fix is. So, he can't give future plans on when it would be out - when he knows enough to make a plan, he'll be done.

Quite possibly related: I saw similar behavior in a ship last night. Launching with docking ports coupled worked fine, and I could decouple - but once I re-docked I couldn't undock again.

That could be stated a bit nicer, but I've been seeing similar behavior with the Buffalo chassis segments for a while now. I hadn't reported because I haven't had a chance to do more than notice it was happening - I wanted to check for interactions a bit first.

Already working on tweaking that - I'm moving the resource cost into a separate patch that's only applied with MKS. Initial version was just to make sure things worked. Given that nothing else really has anything comparable, deviating from the balance guidelines shouldn't be too big of an issue here. I can see RoverDude's point in that it should take a certain amount of machinery (not Machinery) to be able to handle larger volumes of materials, but in this case I think we can pretend it's mostly 'feed in the raw materials straight from the drills.' Anyway, changes put in.

You would need a logistics module at both ends, and to make sure you visit them in the correct order after long periods. (As the one you visit first will do it's production first.) They are far enough away that the only logistics that can connect them is Planetary Logistics.

Quick comment: The '.version' file should probably be inside the 'DeepSky' folder, so it actually gets installed by users.

If so, I apologize - but if I read it right, that could very well be his problem.