Terwin

So long as it does not trespass and does not exceed the posted speed limits on any roads it happens to be on, it can go as fast as they want. You hardly have police officers waiting at the end of a race track after all...

I believe that requires an engineer on EVA, and some specialized parts/material kits are consumed by the switch.

While a wear and tear mechanic is a good option to have, would it not be much easier to just add a 'spare capacity' to things that use machinery so that they can run for a while before the decreasing machinery levels actually have an impact? (perhaps +5-10% for things that are expected to be manned, vs the +100% currently present in MPUs) That gives you consistent functionality over short periods(a few days) before the lack of maintenance starts to have a negative effect without any additional resources to track. Not sure of a good way to balance this to USI-LS though, unless installing MKS reduces the weight and adds a Machinery bin for LS components so they can start tracking wear.

So crew compartments are supposed to be secure against lithobreaking? I may need to speak to my manufacturers as mine tend to explode, even when well below orbital speeds... Then again, my only 'lost' kerbal did eventually come back, so perhaps he just had to wait for the 'jaws of life'...

Clearly side-arms are powerful enough to leave either scuffs or chunks of hot lead on a decal on the hull, but I do not see any escaping atmosphere, so clearly they did not fully penetrate if they penetrated at all.(unless the copula was evacuated, then it may or may not have penetrated)

Seems like the hardest part would be to determine when and how much power the solar satellite could supply and to which base(s). If you try to use something like the planetary warehouse you suddenly have infinite battery storage with no cost or weight requirements. Using anything other than catch-up mechanics requires some sort of real-time estimation/simulation(otherwise you get power when the satellite is in shadow or after the fuel cell should have run out of fuel for example). Then you get to worry about what other base(s) should also be pulling power from a given satellite and then recording how long and how much power each of those bases should have power that was already calculated for this particular satellite. Then what if some of those other bases have solar panels go into shadow, or otherwise have changed power requirements, better simulate those too. Eventually you may need to end up simulating in nearly real-time everything that is in range of your microwave power transmission. This is why wireless power couplers are so much easier than long range beamed power: it only works for things already in the physics bubble. Unfortunately, that limitation makes a solar satellite just about useless. There are of course some workarounds, such as evenly dividing available power among all receivers so that you only need to simulate everything that has a power transmitter(of course having a series of surface solar plants and orbital relay stations would still require a great deal of simulation overhead) Unless the developer is willing to ignore potential transmitter status changes or has some seriously clever ideas, microwave power transmission outside the physics bubble sounds like a major headache.

I'd probably go with 'General Construction' once it is no longer ground specific. Hmm, it seems that the image of the recently released package is corrupted or missing, but congratulations anyway.

mooring!? xD DOCKING! USI construction has 'Construction' docking ports that can be 'collapsed' to remove the docking ports and directly connect the two pieces. There is no reason you could not do this with shipping crates. Sure you would have a docking port during transit, but when you get it to it's final destination, just collapse the ports and you will have a direct connection with no docking ports to disturb the aesthetics. Admittedly I have never used them(I use KIS/KAS instead), but they seem like a good option for assembling bases without excess part-count or resorting to KAS for on-site assembly. Note: I think construction docking ports can only be put on nodes, so that may limit your assembly options. (I think shipping crates mostly have 3 nodes, one on each end, and one on a side for surface attaching) Another option is to use Ground Construction for on-site construction, then use a construction docking port to connect a node on your new vessel to a node on the old vessel. This would let you have lots of surface-attached shipping crates pre-assembled, then attached to your base with a node.

Actually, I find it worthwhile to hire Kolonists. They have no skills relating to colony operation, but they do count as pilot+engineer+scientist when it comes to the colony bonuses. Especially for the temporary habitation bases(something RoverDude suggested for the early game as an alternative funding source to missions). Aside form any operational needs(like engineers for drills), I have been filling up those bases with as many Kolonists as are supported by the life support production facilities. In addition to letting me bump my Mun Kolonization bonuses, temporary bases let me stockpile ore, LFO, Gypsum, and Fertilizer for future use.

When you hit a rich vein the first time you go looking for gold, you can be forgiven for thinking that prospecting is easy. Squad was lucky with KSP, and in their naivete, chose FTE. In hind-sight it was a bad decision, but bad decisions are how you gain experience, and experience is how you make good decisions. This is the sort of growing-pains you should expect with any indie developer. Of course if T2E made that kind of novice mistake, then we should rightly take them to task for it as an experienced insider. Compare it to a new player forgetting parachutes on the return portion of their first Mun mission, as opposed to Scott Manley making the same mistake.

I think this is due to the dependency on GC Core which I have not yet seen on CKAN, but if you install manually, it includes a working GC core for 1.3.1.

As Making history is not yet complete, I consider it safest to assume that something new will come up that will need support in the core game. While it is possible that Making History could over-write some core files, I would consider including those changes in a newer version of KSP to be a safer approach.(as in fewer confusing bugs for the players to run into)

I am expecting that 1.4.0 will have changes to the base game to make it compatible with Making History(or possibly 1.4.1), as such, I would expect Making History to have limited functionality at best for earlier versions(possibly no more than a parts pack)

I have never tried Kerbalism, I just heard that it re-works the on-load processing to be always-on background processing instead. As I like to run lots of concurrent missions, often with large bases on multiple bodies, always on background processing seems like a bad idea to me(seems like it would be similar to always having hundreds or thousands of extra parts in each scene, and I am not a fan of slide-shows). Yes, Permahab is 50 years by default, if your base/vessel has 50 years of hab for its occupants(or 1 year for pilots I believe), then they are considered comfortable enough to never get home-sick. Note: if the Kolonization rate gets to the Max of 500%, then all kerbals will be satisfied with 1 year of available hab, due to the body being considered fully colonized. (I guess if you have had that many pilots on the ground for that long, there must be an ample supply of entertainment available, even if it is just watching their make-shift pod races)

Stock KSP has a catch-up mechanic that it employs when returning to a vessel that has not been active for a while.(I believe this is switchable in the settings) If the vessel has been inactive for less than 6 hours of kerbin time, then it will just calculate what should have happened in that lapsed time in one chunk.(like mining ore or converting ore to fuel) If a vessel has been inactive for more than 6 hours, then KSP will process the down-time in 6 hour chunks(still using the current conditions, so if your base depends on solar panels, I don't recommend returning to when it cannot see the sun). The value in the 6 hour chunks is that this allows interdependent processes to work. (Example: you have been drilling and refining fuel for 18 hours, if it was done in one chunk, then all of your current ore would be refined, but you would then have 18 hours of unrefined ore, possibly losing some if you do not have enough storage, in 6 hour chunks, you get 3 smaller updates where it calculates how much of the current ore is converted, as well as how much new ore should be added over 6 hours, then updates all values at once, letting you process some of the ore you mined while away before it finishes processing.) Note: This means that if you have less than 6 hours of storage for something that you are both producing and consuming(such as ore), then you will not get as much effective production, as the production will stop during each 6 hour chunk due to the storage being full, and consumption will also stop due to storage being empty. In addition to the stock mechanic, RoverDude added a resource sharing mechanic that will allow local and planetary warehouses to share resources either with other local vessels, or with the planetary warehouse(depending on what sort of logistics support you have). This mechanic will try to transfer away resources when local storage is mostly full, and transfer in when local storage is mostly empty, but either way, it only tries to make local storage half-full, so 12 hours of local storage is a good idea when relying on these mechanics(so that you can have 6 hours worth transferred in or out for each batch) Other than the automatic resource transfers, USI mods(such as USI-LS and USI-MKS) use the stock background processing. (this is why USI and Kerbalism do not play well together, as Kerbalism re-writes stock background processing in a way that makes it inaccessible/non-functional for USI mods)

I am not too sure about the 'smarter to deal with other humans' at least not at first. I saw a something recently saying that the evidence suggests humans may not have killed other humans much until the late paleolithic, and that is very recent in an evolutionary scale... If you are an endurance hunter(as humans are theorized to be with our sparse fur, bipedal motion, sweating, etc), then every step towards intelligence that lets you out-smart your prey a little better, also saves calories from the hunt gives a competitive advantage(more calories available for procreation, even though more calories are also being spent on the bigger brain that lets you out-smart your prey better by planning further ahead for example). Chasing an animal off a bluff that breaks it's legs is a lot less calorie intensive than chasing it until it can no longer stand, and it takes a fair bit of planning to dig a ditch before hand when there are no bluffs near-by.

I do not think that intelligent life is as hard to come by as it might seem. Lots of species actively think about novel situations they encounter so as to classify them(food, threat, mate, etc). This means that the mechanisms of thought are well distributed, but not biologically advantageous for most species due to the energy costs. If the mechanisms are well distributed, you just need an environment where frequent/constant thought becomes advantageous(such as out-smarting prey when endurance hunting as a way to save calories as a potential source of our own ongoing thought) Once you are in a scenario where there is an evolutionary advantage for being smarter, intelligent thought is only a matter of time and evolutionary pressure.(so long as you are not in a dead-end niche or run out your food supply)

As JadeOfMaar said, without USI MKS, only the small ISRU will generate fertilizer(very slow and inefficient), but there are several ways to generate fertilizer and other resources using MKS(out of raw materials generally pulled out of planetary bodies, but also available from asteroids and 'Resource Nodes' which are a sort of landed asteroid that are a part of MKS that you can collect and process) I have found that unless you are spending at least as much time landed and resupplying as you do in transit, the fertilizer generated by the small ISRU is probably less useful than an extra can of fertilizer with the same weight. (I think it only makes 2.3 fertilizer per day while requiring > 1 ore per second, but I have not checked recently so I could be off by quite a bit)

I think it is more that they do not yet consider it complete. In any case, there is nothing preventing you from using the last version where all of your preferred mods are working(even with bugs). You just change your personal update schedule so that you only update after all of your preferred mods are available on a newer release. Admittedly I am not using very many mods(only about 30 so far in my 1.3.1 game), but a big part of that is trying different combinations.(my last major game I also had KR&D and atomic engines, but this time I thought I would try with primarily stock engines + Near future tech on top of my core USI, KER, KAC, Scansat et al) (I was actually planning to use Interstellar, but looking at it I got a bit intimidated and decided to start a little slower with NFT) I am also willing to play without mods as needed(such as early release and before my preferred mods are updated), which reminds me of the stock versions of my preferred mods already in the game(such as the burn count-downs in the tracking center which is a less intrusive/feature rich alternative to KAC). Admittedly that leads to scenarios where a LKO rescue mission swings past the Mun for an exploration contract because I misjudged the amount of dV I was loading into it, but that just helps me appreciate my favorite mods all the more once I have them again.

The mantis shrimp has 16 types of color receptive cones, including multiple polarization types and 5 bands of UV. Each independently movable eye has 3 regions, giving each eye trinocular vision and depth perception. Their claws can accelerate at 10,400g when attacking up to 23m/s from a standing start, causing cavitation bubbles and giving them a massive 1-2 punch that can kill their prey even if they miss. They have been known to break the glass in aquariums. Their eyes are being studies for developing new optical materials and their appendages are being studies for structural materials. They can see the world in colors we could never dream of, and they are highly efficient death-machines https://en.wikipedia.org/wiki/Mantis_shrimp

You know, even if you got the game through Steam, you can just copy your game directory elsewhere and you can keep playing it without further updates as long as you like. If you got it through any other avenue, nothing will auto-update without your say-so, so you can ignore future updates as long as you like.

It is normal for the passengers to wait, it is not normal for the airplanes to spend much time on the ground. Planes are expensive, and constant usage gives quicker return on investment.

I missed the part where the containment vessel was a different material, that makes keeping the entire liquid part as a liquid easier, but what happens if there are eddies in the liquid that bring 5800K material in contact with the containment vessel? Would that not etch the containment vessel? Is it possible that the etching could breach the containment vessel coolant lines? (the coolant is supposed to be ~4000K by the time it leaves the coolant lines, so a few eddie caused hot-spots could conceivably etch down far enough to breach those lines if the THC melts below 5800K(and if it did not, why not use that instead?) Controlling eddies in a fluid, especially an energetic(hot) and perturbed(bubbles) fluid where you cannot use anything for baffles because the baffles would melt, is a non-trivial task, and maintaining a steady heat gradient from 4000K to 5800K in such a fluid seems improbable at best.

How do you keep all of those little holes from plugging up with the liquid metal? If any parts of the heating chamber solidify after being a liquid, how do you make sure that the air tunnel is the same size or even still present? How do yo make sure that all of the air comes out of the metal instead of getting trapped in a bubble of solid metal? If you spin your centrifuge too fast, some of the liquid metal could press it's way down into the holes, clogging them up, but too slow and some of the air could get trapped, cool down, then cause bits of metal to be thrown off when it gets re-hated and 'pops' I do not even know if that 'too fast' is faster than the 'too slow' so you might even have both at the same time...

Some times I wonder if not including KAC is a tactical decision. There is often noticeable lag when visiting a vessel that has been unloaded for a long time but performing a function(like mining and refining fuel), and not having KAC encourages only a single mission in-progress at a time, reducing the frequency of the lag due to background processing. (it is not like there is a big down-side to only doing one mission at a time after all, and being able to time-warp all the way to Jool without worrying about other things in process could even be an advantage to sequential missions) On the other hand, when I updated to 1.3.1, I did make frequent use of the 'next node' timers in the tracking center for much the same purpose(it is just a lot easier to over-look than an on-screen pop-up, especially with large numbers of missions in-progress). Would have been nice if I could have sorted my vessels according to next burn node though. Also it has no way to set a non-node alarm, especially for checking-back on landed bases where you cannot add a 0dv burn as an alarm.