DStaal

Besides the options for the game, not really. You basically need a medium level of tech before you can build space-worthy living spaces. Kinda part of the point. Once you get the Hitchhiker and the Cupola you can start adding multipliers and high-hab parts.

From someplace around here on the forums I have Kolonist, which is a mix of the main three - designed to be someone who can pilot a rover, fix it's wheels, and reset it's experiments, without having any of the higher-level abilities. I've also been playing around with three of my own, which I may eventually make into a PR for MKS: Daredevils, Researchers, Repairmen. Which are basically the base three, *without* any MKS or other mechanics added in. (So no colonization bonuses, or hab time extensions, or anything like that. The intent is to have some cheaper early-game Kerbals for MKS, when you really need the skills from the base sets, but haven't gotten into colonizing other planets or anything.)

Does this go by a skill? (Can my other classes with the correct skill also work with it?)

A: Yes, they do that sometimes. B: Make sure you're actually attached, using the tool. Also note that anything you attach to the ground gets handled as a separate vessel in some places, and it's possible for KSP to detach them from the other vessels it's attached to. (Basically: Attaching something to the ground and then attaching it to your current ship via KIS attachments will work until it doesn't. Be ready to do the occasional repair.)

I regularly hand-land or use Mechjeb to land Karibou rovers. My hints: Balance the thrust around the center of mass. Obvious, but can be finicky. Remember both thrust and resources can be limited. Tweaking by putting a thin slice with SpecalizedParts or something at one and and adjusting how much it's holding can help get final balance. Balance the fuel around the center of mass. Again, semi-obvious but finicky. Balance the fuel *drain* around the center of mass. This one's a bit harder to spot - but remember the fuel flow rules and note where the fuel tanks are. If they won't balance equally as you drain them, you'll have an 'interesting' flight. Typically all of the above tends to mean 'fuel in the center, engines near the ends'. It's tempting to put the engines in the center, but you'll lose a lot of control authority that way. Orient the Karibou so that it points across the most important axis of rotation. With the engines at the ends, it's fairly stable and can maintain that orientation the easiest. Do *not* expect the engines to be able to help in any other axis of rotation. They'll flail around, but won't be much help. Give it lots of RCS, and don't be afraid to use it. (Note that the Karibou engines generate monoprop as they run...) Place the Karibou landing control core above the center of mass. It's possible to land using the command cab, but the radial control point makes it much easier - and it's best if it's over the center of mass/thrust. TCA is also good, but note that the Karibou engines are not enough then - they don't provide enough roll control under TCA to do much. RCS will help, but TCA doesn't tend to apply it. Also, the independent thrust vectors of the Karibou engines aren't something TCA works well with. I typically find that it's easier to build a good craft and land it under MechJeb then to rely on TCA for the Karibou, personally.

Hmm. If you're thinking about it, how about a straightforward multiplier, based on the mass of the ship? (Ideally without resources, if that's available...) Or, for a bit more complex: have the multipliers be at the part level, with the default being based on the mass of the part, with a possible override in the cfg. I'd probably start by thinking something like '(mass-10) * colonization'. Initial landers won't help much; you have to put significant resources into it to actually get a result...

Balance - He wants to keep the two sets of parts that do basically the same thing working basically the same way. Otherwise why would you use parts from MKS, as the USI-LS parts are better?

Yesss... Now separators are a valid option instead of a stupid waste of screen real estate...

MKS and Pathfinder both have resource paths to EU. (Depleted fuel is a byproduct of using the reactor - again, both allow you to reprocess to get some more EU.) I think KSP-I and NFE might have paths as well. The wireless transfer only works with resources, and doesn't apply to KIS. This sounds like an issue to be raised in the Workshop thread, as I don't think anything here has special handling for it. Though if it's attached via KIS-installed ports (which it sounds like), I've occasionally seen them 'drift off' and become disconnected.

BTW: I just noticed that the kso_usi_ls.cfg file has a lot of ':FOR[USILifeSupport]' blocks, which will not work as intended. You mean ':NEEDS[USILifeSupport]'. ('FOR' *defines* the mod, 'NEEDS' *requires* the mod. So, as written, this will always apply and make any other mod that has USI-LS support apply as well.)

Just deployed one of these again... Anyone else get massive drag from these? Inline octo-sat+nosecone took failed to launch with over 4,000 d/v. Drop the nosecone and put a fairing around the octo-sat, and with the same launch profile it managed to launch with fuel to spare.

I'm being a very bad mod author. The link at the start is to a complete and working version without the 'industrial' parts. One of these days I need to get around to balancing the industrial parts, but since I haven't been playing as much KSP it hasn't bugged me much, and I keep putting it off. You *can* grab the first pass of the industrial parts off of GitHub if you want, but I'm sure they're horribly unbalanced.

DSEV has some as well, as does KSO's station pack. That's what I can think of off the top of my head, at least in the smaller diameter sizes. (There are a couple of mods that have some in larger diameters as well...)

Thanks for even considering it. A standalone pack would be great - I wouldn't think they'd need to be much more than a thin slice/ring that you can put under the pod.

I like the general idea - but honestly, the fact that it's integrated into the command pods deters me. My action menu is long enough on them already, and I do regularly build ships which *shouldn't* have this functionality in the command pods. I'd rather it was a couple of parts that I could add as/when needed.

I wasn't aware that dirt is an OSE resource. I mostly know it from MKS. (And one of the things I need to work out for the next release of the MKS integration pack is to get the drills working for the MKS resources.)

Would an 'AFTER' or 'BEFORE' statement in the MM patch help? It seems like the type of thing those are for.

That's a low-level change to how the entire game is constructed, not something that should be expected by a simple add-on for switching fuels. (And yes, you have both a 'core' and a 'full release' - but the 'core' points to the full release when it gets updated, and players are likely to just drop it in.) You may have a point. *Here* isn't the place to demonstrate or argue for that point. KSP-I or a new mod would be the right place.

Build ship out of empty batteries and solar panels, launch, wait, recover, profit.

Honestly, I can never find good docs on this anywhere. I believe the variance is the difference between the max and min within a biome, while the dispersal is the 'clumpyness' of the deposits - how quickly it drops from the max. But that wasn't really relevant to what I was saying earlier: Orbital scanning isn't exact. It gives you a general idea of where there is likely to be any specific ore (one way it does this is by giving you the average for the biome instead of the local value), but without groundwork can't be relied on for more than a general overview. This is regardless of what the definitions are - as long as the resource isn't completely evenly distributed, orbital scans won't give you the exact picture of where the resource is on the ground on their own.

Scanning from orbit is always imprecise, typically averaging a bit over the biome. (The exact details vary a bit depending on whether you're using stock or ScanSat, and what ground-level work you may have done.)

Yes, well there is the known bug that's visible and affects even a pure-stock game that also affects this mod - but the mod itself is as compatible with the game as the stock science definitions are.

You know @RoverDude, you *can* set the default branch PRs get attached to on GitHub...

Here's the official docs: http://ksp.cybutek.net/kspavc/Documents/README.htm

I'm not sure it's actually easier to make a multi-surface amphibious craft that's not a hovercraft than it is to make one that is. Well, true multi-surface - if we limit it to 'roads' and 'water' or something like that then you can constrain the design choices. And I think a hovercraft would beat a fixed-wing plane in certain roles - short distance, larger loads, lower speed. (Though usually for a bit more infrastructure cost a car or train is more efficient yet in those roles. There has to be something prohibiting the infrastructure.) (BTW: Russia did experiment with some large fixed-wing ground effect craft...) But yeah, the hovering in Sci-Fi sense makes *no* sense. Put it on wheels or wings, people!