RoverDude

Sure, on my list

Sure, you're free to adjust your own configs any way you see fit. Me, I am comfortable with the amount of supplies Kerbals use, and the canisters have appropriate mass ratios and storage capacities, so I don't anticipate this changing.

That is because that model has no IVA. KIS does very weird things in my experience (including making Kerbals debris) when there is no IVA.

That works, or if you use MKS, in the next version you just need to drop a supply container somewhere near your base. tbh unless you're diving right into an interplanetary aerobrake that lands with a capture and descent, you will be fine. And if in doubt, adjust the chute pressure and pop them before you run out of food. Done it more than once Yup

tbh I'm pretty happy with the existing mechanic. Allowing them to be revived at will (even for an hour) completely removes the need for life support. The fact that you got a Kerbal stuck in orbit and had to (eventually) mount a rescue pretty much shows the mod working as intended You must be playing with a very tiny Kerbol system then - 100 days is pretty slim pickings once you're outside of the Kerbin system

Karbonite has converters to LH2

Actually, most of the time we respect licenses

I'm Curious which mod started this thought experiment

Yes, it's used for some of the RCS bits.

Tbh I will very likely add a mechanic to prevent spamming sample canisters in the future

Artefact of the persistence file when stuff gets moved around after a save is started - CTT is just a config, not code. You could always tweak your persistence file to resolve this. Ahh - log a github issue please, I assume Kerbin time Not really given a real astronaut only uses about 2.5kg or so and Kerbals are pretty small (We assume there is some built in recycling for water/oxygen in the capsules).

And that's why the fuel is a pain to get

@Wetapunga - VERY nice! Sorry, FAR is not supported, just stock aero. That being said, it should not be an issue building out a balanced ship. Probably due to the K+ parts. There will be some updated engine clusters coming in the next refresh

That's a bit exaggerated as noted I'm pretty busy but will be circling back and doing a ton of node fixes as time allows.

Good deal - I'll do a run through on prices, temps, etc. and put them on par with stock.

Hey Snjo! Quick heads up - the initial balance pass on the engines (due to how ISP changed) was a very rough cut - you probably want to re-look at the curves. Also the control surface FS tweaks are temporarily off since that was causing Kraken goodness - I also moved all of the control surface bits to the new stock control surface module, which fixed all of the wings as that was just a syntax change. The collider on the bomber wing extender is acting a bit odd, but beyond that we're in pretty good shape (I am happily barnstorming away with my biplane). I'll move some bits around to the correct categories once I have a chance as well

I'm reviewing all of the conversion numbers - both in light on some research I am doing as well as balancing against the MKS Mk II/IV/V modules. Saw some answers here, but best to hop to the MKS thread with details On my list tbh I am not looking at adding blizzy toolbar stuff to any of my mods, sorry lol thanks!

That is a question for the NF thread

If you spent ten hours staring at the narrow band, you may want to review the use of the different scanners. I'm sorry you do not trust the orbital, that's your call. But it does serve it's purpose in providing a reasonable subset of areas in which to further investigate. To reiterate the gameplay flow, since that may be missed in the noise (and add a bit more detail while I am at it). - Use the orbital surveyor to get a general layout and identify potential areas to investigate. - Investigate by dropping a Rover on the ground to unlock the biome, or use the NBS over an interesting area to get a clearer idea of the level of resources in that biome That large red splotch you saw does in fact indicate that there is stuff at the poles (in a specific biome)... but given the edges of the various biomes (some are actually pretty even concentric areas, some are not), it may not have been on the precise spot you landed on. No different than a stray hit on, say, a shores biome or one of the minmus slopes can cause a splotch to appear, when the actual area with resources is extremely small. The biome bit is important - resources always follow biome edges. So if you see a hit inside of, say, one of the Mun craters.. rest assured, that crater has Ore. Regarding some of the other suggestions regarding map projection, etc. - you have three things that influence the default settings. First - the textures are VERY small. Most of the interpolation you see is being handled by Unity. There simply is not enough pixel space to do many of the usual map stretching techniques one would use, and the objects are uv spheres not icospheres. This does make a significant difference in the way trilinear interpolation makes the texture look. Second. Nothing is stored. Everything is procedural. So performance is absolutely critical (again, an alternate projection is a completely moot point anyway due to pixel density and interpolation, unless one makes a sacrifice in performance. Trust me - this was looked into). Third. The biomes themselves have some interesting angular artefacts and very sharp edges (this is not just a case of slapping some simplex noise on a sphere), so additional interpolation, simplex noise, etc. are used to give the overlay a more organic look, and to avoid smearing/tearing artefacts, weird edges, etc. The intent, as noted below, is that this scanner is used to provide a 'hint' of where to look - other scanners cover the rest based on those hints. That being said, there is something odd about that specific picture - if I could get a seed value from the persistence file, I'd like to peek and see precisely what caused the hit that gave you that splotch. (Edit) Did some of my own poking around, found the edge case that's giving you a false splotch.

Two choices really. 1. If you're using CRP, then bundle CRP. This is what ensures compatibility. Then for anything not in CRP you just add a separate config file (MKS does this). 2. If you do not wish to use CRP, then do your own thing. If you wish to be neighborly and happen to use the same resources, just copy and paste the specific values (cost, density, flow mode, etc.) from CRP into your own config file. This is kinda the reverse of what we do with TAC-LS for water/oxygen/food/etc.

That will be more MKS stuff that is not yet released.

Correct

That's actually by design. The stock drill is a dual-mode drill. Any asteroid drill will do the same thing.

In general surface is better but there's a specific penalty for doing science on Kerbin's surface (you would learn more about space in orbit or on another planet than at the local park)

We both know that 1/3 of the surface area is a bit of an exaggeration. As noted, if you are dissatisfied with the default settings you're welcome to change them (these were left exposed precisely to give people more options), or log an issue on the public tracker. But given this is the Gameplay/Tutorial forum not the Suggestions/Feedback forum, I expect at this point this horse has been sufficiently beaten.