Terwin

The reactor control panel is NFE, and your reactor is not doing anything because, as it says in the paw: 'output cap 95%' MKS reactors do not run unless they are needed, and that is determined by having available EC below 95% of max EC. Try adding something that drains EC and you should see the rector kick-in when the available EC goes below 95% (this is one of the parts of MKS reactors that I much prefer over NFE reactors: no wasting fuel when it is not needed)

You probably want to download USI-LS from github so you can get the right version for your version of the game. MKS and LS both install into UmbraSpaceIndustries so you should have both UmbraSpaceIndustries\MKS and UmbraSpaceIndustries\LifeSupport if you have installed both.

There is a time-span beyond which homesickness and habitation time stops counting. I believe that it is 5 years.(not counting any extensions from using colony supplies) So any base that can provide 5+ years of habitation will allow an indefinite stay without habitation or Home timers causing a problem. For pilots(and explorers) that time-span is 1 year.

To start with USI-MKS may have supplies and recyclers, but USI-LS is the life-support mod which makes kerbals actually consume supplies(and EC). The little green button is also part of USI-LS. If you hae USI-LS installed and it is not working, please seek help in the USI-LS thread. If you do not use the community tech tree, you will not see a change in the tech tree. USI-MKS can be used with either the stock tech tree, or the community tech tree(recommended), but does not change the tech tree itself other than adding parts. note: I responded to your previous copy of this message with information about the community tech tree mod, do you not even read responses to your own messages? I don't use detonators, but it seems probable that you would activate it from the right-click menu.

I started with MKS before detached logistics was a thing(also before ground anchor was a thing), and after some issues with flexible attachments I started making all of my mks bases rigidly attached, usually with a single major axis (like an I) giving a minor axis to larger bases (like a +) and often building up from enough places to support all of my rotating habitats well off the ground. On these bases I produced machinery locally for any major bases and generally automated maintenance from a workshop was good at keeping everything topped off. Before ground anchors I occasionally had jumping bases that I had to deal with, but generally so long as I used level ground for the entire base, I was good(I have not dared to try building on hills or slopes since the advent of ground anchors and improved stock physics may have made doing so more feasible) KAS is a good way to attach freshly constructed or delivered components(When moving large pieces for a base with a sizeable existing population, I will often adjust the maximum per-kerbal weight and range in the config file to allow arranging things without spending a lot of time moving groups of kerbals around on the surface) I believe that GC may allow transferring machinery during the finalization phase of building a module if you have machinery available on the constructing craft, but I have not tried to transfer machinery using the MKS disconnected logistics.

The 1.8 version works fine for 1.8.1 and 1.9, and it mostly works for 1.10, you just need to delete a few parts. A new version with additional functionality is in the works, but I believe it is still in the test phase(and with a mod as complex as this one, that can take a while, especially with new toys)

MKS does not modify the the tree(aside from adding parts). The Community Tech Tree mod is both recommended and supported if you would like a more in-depth tech tree. I believe HEavy rocketry has jarge fuel tanks, so it makes sense to put other storage there, as the stock tech tree does not have many good options for non-stock parts.

I am fairly sure you can, but asteroids have limited resources, so it will quickly run out of raw materials if you try to do things like build ships with them. (even just turning them into fuel tends to empty them out pretty quick in my experience)

The medical bay is the only way to reverse the timers after a kerbal has become a tourist. It runs the tourist clock backwards at an accelerated rate(perhaps as much as 20x total across all treated kerbals if I remember correctly?) consuming colonization supplies to do so. The longer the kerbal has been a tourist, the longer it takes for them to recover. It is most useful for when you ship kerbals to an established base on a too-small vessel or send a resupply ship to a vessel that ran out of resources. It is much more space and cost efficient to just keep kerbals supplied and happy instead of trying to bring them back from being a tourist.

You could use a rover to transfer them as one option. Be aware that if you do not fix the underlying issue(supplies or homesickness) then they will quickly become tourists again after leaving the medical bay.

Other than adding parts, MKS does not change the tech tree, The Community Tech tree mod is recommended for this purpose. To the best of my knowledge the RSS mod primarily changes the planetary size and layout, possibly with tweaks for other mods like community resources. So long as the background processes are not modified(ie changes to offline production), MKS should still be good. You my or may not need to manually tweak the few engine parts in MKS to match the RSS changes if you intend to use them however.

My insistence on individual seat-belts reduces vehicle capacity from 7+ to 5, so more-or-less, yes. The biggest difference between a space-suit and a dry-suit is the hook-ups. A dry-suit only needs an air-tank and some weights(otherwise you float), a space suit generally also has cooling capacity and you do not usually carry air tanks around on your back(you hook into the vessel for that). The only things they need for underwater operation are a mobile pressurized air tank(very heavy) and a bunch of (usually lead) weights to cancel buoyancy(very very heavy). On the other hand, US manned spacecraft make a controlled reentry, and either land at an airport(shuttle) or at sea(capsules). So long as they avoid the ice-caps, getting frozen in place is not a realistic threat. Mechanical failures on the other hand, are a viable potential threat and some of those failure modes can b mitigated with a space suit. Unless you want to argue that large chunks of low-latitude ocean are prone to icing up suddenly and unexpectedly... Not really no. Orbital space craft spend so little time at speeds and altitudes where an ejection seat could be useful, that a large net near the launch site could probably cover just about the same set of contingencies as ejection seats. (and launching over the ocean with recovery boats in-place works almost as well as a large net) Furthermore LES cover the entire ejection seat regime and then some.

Driving my car to and from work ~250 times a year for ~20 years I have had 0 instances of accidents where my life was saved by my seat-belt. I have also had 0 instances where the 'windshield breaker' I keep in the center console has allowed me to escape a vehicle when otherwise trapped. I strongly expect I have spent more time driving my car than there have been maned launches/landings(the times when those suits are worn) Yet, I always put on my seat-belt every time I get in the car. Am I expecting to get int an accident? No, but I know that it is a plausible outcome of getting into my car, so I put on my safety gear, just in case. I know for a fact that there have been accidents in the past where a seat-belt/pressure suit would have saved lives. The arguments by the original poster sound to me a lot like the arguments from people saying that they should not be required to wear seat-belts, except coming from car manufacturers who don't want to install the seat-belts in the first place. 329 manned missions (https://en.wikipedia.org/wiki/List_of_human_spaceflights) 8.5 min to orbit, 20 min to reenter 329*(8.5+20)=9376.5 minutes 9400 minutes /40 minutes(20 min each way to/from work) = 235 days of driving to work... So yes, every year for the last ~8 years I have spent more time on the road than manned missions have spent launching and landing in total. Yet I still wear my seat-belt every day.

This is covered in the last few pages. The mod is not yet updated for 1.10, and some parts need to be removed for it to work in the interim.

You can calculate this before hand. I was not expecting AI, just a pre-planned program that follows certain steps at the appropriate(subjective) time. That is politics, I am just addressing technical challenges.

IT has a non-ore mass that is still around. I forget if they get smaller as you harvest them or not.

You also get ore from planetary bodies. They do not run out, but can have varying density/rate of production based on the biome(randomly determined each game).

This is still assuming a miss. options to mitigate that change include: A) double-check your math. Planets and black-holes don't dodge, if you are careful, the odds of missing can be very low. B) relativistic 'gravel' in a net that you release just after jumping into the system. Even if each rock is a couple hundred kg, you only need a few at 99% of ls to take out a planetary biosphere(possibly just one) C) plant a bomb in the middle of your asteroid and blow it up just after the jump into the system so that you have a large and growing cloud of relativistic debris heading towards your target. D) walk your shots: have a hand-full of colliders start to accelerate one after the other, and if the first one misses, adjust the destination coordinates of the second and try again.(left-overs can jump to the far side of the black-hole to slow down for future use)

Physical time-warp for the burns and lots more time-warp for travel time. It helped that I grabbed the closest class E and just had to shift the orbit slightly to meet up with the cluster. For the class B asteroid I landed at KSC, I had to harvest and burn a lot of the ore for the dv I needed. I have found that large ore tanks and regular trips to the Mun are a much easier orbital refueling solution than captured asteroids...

I used the stock claw to link up 6 asteroids in Dres orbit, five of them were Class E with a total mass of over 11,000 tons, the largest was 3155 tons. This gallery shows the process My thrust was 180kn from 3 Nerv. No, I did not go fast, but with a single claw aimed at the center of mass, I was able to maneuver them quite well. The hard part was getting the asteroid to line up the double-sided claw apparatus I had on the far side with the linked rocks. Fortunately, I am well accustomed to docking with the klaw using just reaction wheels and main engines as that is my usual approach to docking.

This collider was specifically large and with a jump drive(even if it had little else). I'm sure you can afford to sacrifice a jump drive to take out a planet. If it missed the target planet with it's first attempt, it can always pop-out to a different planet, then pop back to the target planet, if it still has the 60 minute jump drive cool-down, it might even jump to a different planet and then just travel at near C to the target again. Using something with lots of energy to blow things up is easy, making something with lots of energy 'safe' is much harder.

I have had good success with a single claw. The most important thing is to line up with the COM of the asteroid, so that you can move the thing without spinning into a death spiral. You can fine-tune a little bit with adjusting the angle of the claw, but you want to start as close as feasible. I have had some success with asteroids in the past

You were referencing the 1LS minimum range to engage the FTL drive, just jump backwards 2-3 light seconds and over enough to try and hit again. No need to change your inertia, just use your FTL to move back far enough for a second attempt to hit. This 'missile' may not even have a proper STL engine as it was accelerated by dropping it towards a black hole, it just needs enough accuracy in its FTL to line up it's projected trajectory with that of the target.

umm, if you are at 99% of light speed, then it takes all of 1.01 seconds to travel 1 light second away from your target, so you might just get to make a second try before the observation station has a chance to send out the alert... Also, if you have access to a sizeable black hole(such as a galactic core), it might only take a few hours(and some very precise timing) to accelerate a vessel to relativistic speeds. For this, larger is better as it not only gives higher acceleration further out, but also lets you get much closer(thus higher acceleration) before tidal forces rip you apart(possibly even inside the event horizon if you find one big enough). Note: a 200 ton nickle/iron asteroid with a steel wrapper to keep it from breaking up and a remote controlled/pre-programmed jump engine is going to be far cheaper than any method of manufacturing a ton of antimatter, and when it hits something big enough(like a planet or moon), the energy released will be orders of magnitude larger. As an added bonus, blowing up the asteroid just turns it into relativistic shrapnel and thus it will be even more devastating.

I generally go with the Mun for reduced transit time, no orbital tilt, and usually fewer biomes needed to cover all required resources. Although it is not uncommon for me to just have a refueling base in orbit of Kerbin with a mining drone that refills with ore from the mun.