DStaal

Time to atmosphere sounds fun - and is often something that I wish I could check easier. It's rarely something that I need to know exactly - but it's often something I need to have general knowledge of, and there's not a good way to do that at the moment. Time to apoapsis and time to periapsis I don't see a need for here. There are several other mods that can provide that with convenient and fairly minimal UI (I have it in an KER HUD, for instance - though I know MechJeb has something as well, and I think VOID has something, and there are probably others). The 'burn to circularize' vs. 'burn to capture' is also one where to me the obvious solution is 'put in a maneuver node for what you want' - and then BBT already handles it for you. The time to apoapsis in a launch (that is, while on a suborbital trajectory) could be a good special case however. (Though I'll admit I use GravityTurn, which handles it for you - including putting a maneuver node in to circularize.)

How would you indicate it was an estimation?

The moderators liked it. Every month they pick a few, and pin them for the month. This month this thread was one - and it was up to date at the time it was pinned.

On EL: The sliders to transfer resources don't apply to survey builds (where you're using the survey stakes). Resources are only auto-transferred to the new vessel if it's built attached to a launchpad. (I recommend Keridian Dynamics for some better launchpad parts.) Some resources can be built into new vessels (solid fuel, ablator), but that depends on whether there's a recipe for it. (This is OT for this thread though - if you have more questions on EL, I'd suggest you take it over to that thread, as it's not really supported in MKS any longer. The MKS way to build things is with GC, and it can transfer resources to newly built vessels remotely.)

Honestly, I don't actually see #1 as a problem, per se. This design is obviously more for maneuverability and terrain-handling than speed - It's not efficient or desirable to fly long distances using rotors in that manor, so this is for delivery to moderately nearby (a couple hundred kilometers, max, really) - but hard-to-reach - locations. As such size, weight, and maintainability would be primary concerns, not top speed. So what if the design limits the speed? It makes it easy to reach the parts, and keeps it out of the way in use.

Never had that problem when using those versions in my game. I'm guessing it's someplace else.

Those are useful. They're normal as the game loads all the parts you have - so the *next* one after the final entry is the part that's causing an issue. Parts are loaded in filename-alphabetic order, so the next file in the same mod or the first file in the next mod is where you should be looking.

The underscores to periods thing I believe is normal - check other parts with underscores in their names. (I know there are a couple of places where KSP won't use underscores in names - so periods get subbed in.)

What @KerbMav said. You'd have to check each converter for the rest, but in general if there's no more place to put the 'main' output then the converter will shut down.

I’d make the argument that MaterialKits in any extensive game are essentially free - Once you get a small ISRU setup in place, you can make the rest. (Less than that with MKS, as you can turn spent landing stages into MaterialKits...) I'd balance on the mass, making sure the total mass of the vessel/parts is the same no matter how it's built. In fact, for a full balance what makes sense to me is to basically price/mass the DIY kit as if it were made entirely of SpecializedParts. (Basically the old OSE recipe.) That would be a bit more complex a calculation - trying to balance both mass and cost at the same time - but is arguably the most realistic.

There's been some back and forth on what should be displayed there. After all, a lot of players will want to see what the hab time will be quickly, and use launching to test. Some of these I'm not sure exactly how they're shown at the moment unless I take a look. (Is Kerbin special cased? Is the launchpad special cased to show more than Kerbin? etc.) Showing on the launchpad isn't a problem. (It might even count down...) Just note that hitting zero on the launchpad - or on the surface of Kerbin - doesn't actually trigger any issues, even if it does count down. You have to be above the surface for it to matter. (Default height is 20km - though that's configurable. This means you can run out of hab on an areobrake and they'll return to work just in time to fire the parachutes - assuming you've got your capsule oriented correctly to survive reentry, of course...)

The recent version of Janitor's Closet will hover up a tooltip saying which mod is from when you mouse over a part in the VAB. It's not 100% accurate in some edge cases, but should do most of the time.

It does change from dev to dev - but in this case it appears to have changed from the last revision. I haven't checked, but I believe it's also different from the behavior of the rest of the CLS text buttons. I'm fairly confident this was unintentional.

Bug report: In the right-click menu in the VAB (at the very least), for 'CLS Passable' 'No' means it's passable, and 'Yes' means it isn't passable. Took me a while to figure out what was going on there. (Note this could also be @Bit Fiddler's problem.)

Just to be clear - scavenging of Supplies is an LS feature, and doesn't require any modules: Kerbals will just scavenge if they need to, instead of staving when there's a box of food just outside the hatch. And: It recomputes given the updated information. Before any status effects are applied - so if you have a vessel that says it's been out of EC for three years - but you haven't visited it in that time, and it's got plenty of hab/supplies, and it's got EC generation, when you switch back you're Kerbals will be fine. Basically: Ignore EC except on your current vessel, and then only worry about it if it's actually going down. As long as you have enough generation to cover it whenever you decide to look at the vessel, you'll be fine. (And yes, there's a loophole you can abuse there: A station that has no EC storage, spends half it's time in shadow, and is only solar powered will never 'run out' of EC according to USI-LS if you make sure to never visit it in shadow.)

On the hab time being indefinite: Were you on Kerbin? Kerbals don't have habitation issues on their homeworld - they can just go outside. I believe the earliest part that has dedicated hab time increases is the Hitchhiker. Though for a 12 day orbit, you might be able to play with adding in something else - an empty lander can or inline cockpit might be able to give you enough extra hab time. (As every seat will give a bit more, assuming you don't fill them with Kerbals.) Or the Mk1 Crew Cabin, which I think is a bit earlier. Resource sharing is an MKS thing, and requires a dedicated module - except for Supplies, I believe, as starving Kerbals will pull from anywhere they can get to. So I don't think you actually need to add anything in your scenario. (But note they'll always use their current vessel's Supplies first.) On your second question: It doesn't. It simply says 'with the current amount of EC stored, at your current drain rate, you'll run out in ___.' (Or, in the VAB: 'Assuming no other drain than LS, you'd run out the storage in ___.') If you have generation you can pretty much ignore it - assuming the generation is always active. (It comes into play when trying to run early Mun trips on batteries, or when setting up solar powered stations that'll have long dark periods.)

Fair enough. I'll admit it took me a while to get the 4,000 units of fuel it wanted into place.

As another thought for the basic station - I noticed that whatever other contract pack I was on before I added this wanted a station with *fuel* as it's first thing.

I just want to put in a vote *against* doing that: It makes it harder to update in my opinion, as it takes more work to manually merge the sub-folder than just dropping in and overwriting the folder in Gamedata. Also, I tend to find it easier to find the the specific part/mod I want if it's in a well-named folder that has something to do with the mod, instead of having to dig into all kinds of unrelatedly-named top-level folders to figure out which one contains the mod that I'm looking for. I like USI and WildBlueIndustry's mods - but they take easily twice as much time and work to update as any other mod, and whenever I have to I always wish they were packaged more like Near Future Technologies...

Installing just the CTT should work fine - you'll have empty nodes, but they should all be there. Or there's some sort of online org-chart that's linked in the CTT thread someplace - I've looked at it once or twice, but it was faster to just open KSP...

Nice tutorial - but you completely missed his question. His question wasn't about *how* to do it, but about *what to do*: Which nodes in the tech tree do you think would be appropriate for these parts, and should it just be the same for both situations or should it be different? Personally, I'd have it be different - and have them be much further up the tech tree, not just one level up. I might even create a new tech tree node especially for them.

The notable line on that is probably the second one, which points to the field 'scienceMultiplier', and says it has a float instead of an integer value. So the obvious solution is to round it to the nearest integer. Of course, when I open up that part in my current install, that field has an integer value of '5' - so are you sure you're working with current versions? (Either that or you should double-check to make sure there aren't any MM patches changing the multiplier on that part for you.)

Honestly, from the sound of it you should just take over official maintenance. Though as a warning: 7z files aren't as well-known as .zip files, and some people may not have a way to open them.

I suspect the response will be 'sure, if you submit them'. I doubt anyone will want to write the patches unless they actually use FAR and DD.

MechJeb. (I say this as someone who almost never docks manually - but recently docked a ship without RCS by hand...)