Skystorm

@FritzsFleas Yes. Quite a few times actually, and I've posted a patch to fix it until the next patch.

Last time I looked the default is 2 hours.

@papuchalk I've seen that happen before. Was the rover physically attached inside the cargo bay at launch? It probably was which makes it part of the vessel. However, when you put it back inside the service bay it wasn't attached to anything which means it was now a separate vessel. I kinda of thought they had fixed that, for cargo bays at least, so that it auto-strutted stuff inside the bay. I could be wrong though. I generally use KIS to attach it to something inside using a pipe, or you could use a docking port. Once it is part of the lander again that shouldn't happen.

@steve_v Actually, you aren't sacrificing anything. Believe me they can still explode if you land hard, but they should behave more like normal until they can be fixed permanently. The 10x number I came up with wasn't arbitrary. It was because the logs were showing an impact speed that was about 10 times the actually vertical speed. In my particular case, a little over 2.1 m/s touch down speed was registering as a 21+ m/s impact. That is what is causing the landing legs to explode because all it takes for a 14 m/s crash tolerance is to land at 1.4 m/s or higher which is why they seem so sensitive. In fact, I'm starting to think the notion that docking has become more difficult may not just be perception but rather related to the same bug. If it is applying the same effect to all impacts, then a 1 m/s docking approach would seem like 10 m/s and would certainly explain bouncing off and flying away at a relatively high speed with respect to the approach speed.

Do you mean this? To turn that on/off, click on the round radio button just to the left of the crew portraits. You need to move the mouse over the crew portraits area to see the additional controls. This is a stock feature though not all parts necessarily support it.

@steve_v Here is the module manager patch I used to fix some of the landing legs. Haven't had a single problem with them since. @PART[landingLeg1] // LT-1 Landing Struts { @crashTolerance *= 10 } @PART[landingLeg1-2] // LT-2 Landing Strut { @crashTolerance *= 10 } @PART[miniLandingLeg] // LT-5 Micro Landing Strut { @crashTolerance *= 10 } Paste that into a file with a *.cfg extension and put it in your gamedata directory. And I'll go ahead and re-post the module manager patch for the 5m fairing sizing issues here as well. @PART[fairingSize4] { @MODEL,1 { @scale = 4,4,4 } %rescaleFactor = 1 @node_stack_interstage01a = 0.0, 2.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage01b = 0.0, 2.27, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_interstage02a = 0.0, 4.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage02b = 0.0, 4.27, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_interstage03a = 0.0, 6.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage03b = 0.0, 6.27, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_interstage04a = 0.0, 8.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage04b = 0.0, 8.27, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_interstage05a = 0.0, 10.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage05b = 0.0, 10.27, 0.0, 0.0, 1.0, 0.0, 2 @node_stack_interstage06a = 0.0, 12.17, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_interstage06b = 0.0, 12.27, 0.0, 0.0, 1.0, 0.0, 2 } Paste that into a file with a *.cfg extension and put it in your gamedata directory.

@MAV3RICK Your engines require some form of ullage. Some form of forward thrust should stabilize it such as from an ullage motor or RCS until it says the propellant is "Stable", then ignite the engine(s). Engines that do not require ullage will say so in their descriptions. https://en.wikipedia.org/wiki/Ullage#Rocketry

Also, if your engines are too powerful you can adjust their Thrust Limiters to reduce thrust for landing and give you more fine control over them.

@Nataris @HebaruSan hit the nail on the head. The game is perfectly stable but it is not without bugs, and yes it does have exploding landing legs. However, the 5m fairing sizing issue is one I've been posting module manager patches to fix, and I have a patch for the landing legs as well though I haven't posted it on the forums. I'm playing 6.4x scale and the fairing drag seems close enough to normal to not make a noticeable difference to me. Frankly, if someone hadn't mentioned the fairing drag issue I wouldn't have even realized there was a problem. I'm not excusing the bugs but frankly I think in many cases people are making much ado about nothing. This was a major update, both in terms of the unity upgrade and Making History, and I think in part because it was a paid release they felt they couldn't really do their usual prerelease phase. I do however think that is why Squad released 1.4 a week before Making History as a quasi-prerelease and then 1.4.1 to fix those when Making History went live. That being said, it has not gone unnoticed that several of those bugs should have been easily detected with some simple regression tests.

The logic behind the max grab mass and pickup distance make perfect sense, but in practice I think it can be a bit more of a detriment to game play on the surface and a real nightmare trying to keep multiple kerbals stationary while floating in space. Fortunately, you can alter the KIS settings with a simple module manager patch. @KISConfig:NEEDS[KIS]:FINAL { @EvaPickup { @maxDistance = 3 @grabMaxMass = 1 } } The maxDistance is how far you can reach in meters and the grabMaxMass is the maximum weight of the part in tons. The numbers above are the current default values as of KIS verson 1.10. Feel free to adjust the numbers to your liking. Place the above text into a file with a *.cfg extension and save it somewhere in your Gamedata directory. You must have Module Manager for this to work.

@Zxy44 Not sure what is going on for you, but I can tell you that I'm running Windows 10 with KSP 1.4.2 + MH with 84 mods and the game is perfectly stable.

Anyone have any experience running the 1.3.1 version of Real Fuels on KSP 1.4.x? Does it work ok?

I'm a bit amazed that these are still popping up when I already posted a fix for this back on March 15th and again on March 28th.

@Ahres That is a snippet from my current persistent.sfs file. Jeb and the other veterans are all heroes in my current game, and I suspect they are by default at least in sandbox mode. It appears that it was added in 1.4 and I suspect that it is related to Making History somehow.

@Ahres Are you referring to the badS, veteran or hero flags? I think badS and veteran have been around a while but hero may be relatively new. KERBAL { name = Jebediah Kerman badS = True veteran = True hero = True } Most of the other attributes were omitted for clarity.

Why do I get the feeling we're about to see someone create the Kerbal version of the "Titanic" at harbor with an anchor chain made from a bunch of linked toroidal fuel tanks just to make them "useful"?

@Nataris Paste the contents into a text file with a *.cfg extension and place it in your Gamedata folder. I usually create a folder under Gamedata for all of my custom patch files and store it in there.

@Nataris The missing drills are a known issue. You can use the following module manager patch to work around the problem until it is fixed.

I would tend to go with release them as they are ready. However, the current versions seem to work without issue, and I'm using pretty much all of them.

@Tewa I created the following module manager patch to address the missing drills and my heating issues with them. It know things are working for the MEU-500-A, but I haven't tested the other 3 drills. I can see all 6 drills now instead of just the two MEU-100's.

@juanml82 The problem is that running 3 drills each with only 1 separator active is essentially the same thing as running 1 drill with all 3 separators active. Each generates the same amount of core heat: 100Kw per drill per separator for a total of 300Kw of core heat, except that the 3 separate drills never overheat while the single drill with 3 separators always overheats every time. Further, I tried adding two additional MKS 'Ranger' Thermal Control Systems for a total of 9,000 Kw of cooling, 3 times as much as before with the same two drills, and the results are exactly the same as my previous post. Any drill running more than one separator always overheats while all other components, including other drills and the reactor, on the vessel are running at their ideal core temperature. It behaves as though the required cooling is per separator but the max coolant is global to the core itself. Meaning that a drill with 3 separators each requiring 100Kw will produce 300Kw of core heat while the core only allows a max of 100Kw of cooling. This makes it impossible to ever cool a drill with multiple separators running even if there is plenty of cooling to be had. To test this I made a simple module manager patch which raises the max cooling for the MEU-500-A from 100Kw to 300Kw in order to allow enough core heat to be pulled away by the radiator when all 3 separators are active. Running the same tests as in my previous post showed that no overheating occurs even with all 3 separators running on both drills. @PART[MKS_Drill_02A] { @MODULE[ModuleCoreHeat] { @MaxCoolant = 300 } } Incidentally, I wasn't using any other radiators, folding or otherwise, but rather only the single MKS 'Ranger' Thermal Control System. Also, the reactor itself never overheated even when the drill did.

Perhaps you can help me understand an overheating problem with an automated mining vessel I'm testing. Here is the relevant information: Cooling is handled by a single MKS 'Ranger' Thermal Control System with 3,000Kw of core heat transfer. Power is provided by a 1.25m Nuclear Reactor providing 200 EC/s and requiring 450Kw of cooling. There are 2x MEU-500-A Pulse Drills w/3 separators each. Each requires a max cooling of 100Kw. If my math is correct, a total of 3,000Kw of cooling - 450Kw - 6x * 100Kw leaves 1,950Kw of excess cooling, so here is the problem: 1. If I run both drills with only a single separator on each, cooling works fine. No overheating problems. 2. If I run a single drill with two separators, the drill's core temperature rises rapidly while the thermal control system is still only at 61% load. The reactor is steady with no overheating. 3. If I run one drill with a single separator and one drill with two separators, cooling works fine on the drill with only one separator active. However, core temperature on the drill with two separators active rises rapidly. The reactor again has no overheating. If on the drill with two separators active which is overheating I then turn one of the separators off, leaving only one separator running, the temperature returns to nominal. It almost seems as though it is not possible to pull enough heat away to run multiple separators on the MEU-500-A. KSP 1.4.1.2089 USI Core 0.7.0.0 USI Kolonization Systems 0.55.0.0 USI Life Support 0.9.0.0 USI Tools 0.12.0.0

Ahh. Didn't realize I needed to be outside. Thanks.

Is there a way to change the drill's (MEU-100), active separator to a different resource in the field, and if so, what is required to do so? I have 5-start engineers and scientists on site.

@Black-Two- We are aware of it, and I posted a patch to fix it if you use Module Manager.