Hotaru

Not everyone considers hunting down dozens of asteroids until they happen to find a magic boulder, possibly only to find out that the "special properties" aren't all that interesting, fun. The fact that they asked the question suggests they'd like an answer, and we have "spoiler" tags for exactly this situation. I'd like an answer too, if it comes to that: I've caught a couple of magic boulders and have noticed no unusual properties (they were weirdly light for their dimensions but I think this is an oddity of KSP asteroids in general). It's possible such properties are related to getting resources from them, which I haven't tried.

What I'd do is build the rocket with a launch tower allowing access to it on the pad, then if something goes wrong during fueling-up or engine startup, send some engineers out in a rover car to go fix it. Or skip the tower and build a sort of fire truck type thing, that works too.

I suspect you're right that this was the intent, but I think it had the opposite effect to what was intended. I'd have been horrified by that trailer when I was a kid. Even today, it makes me kind of ill. The thing about Wile E. Coyote was he never actually died--he was always back for the next cartoon. The implied permadeath in the KSP 1.0 trailer gives it a very different, and much darker, feel, and one that I really don't think belongs in the cartoony kerbal world. An extra couple of shots at the end showing Gene hitting a big "Reset Flight" button and Jeb, Val, and their rocket materializing back on the launch pad could've achieved a different effect, but they chose not to do that.

For a brand-new game on BARIS default settings, yes. New, untested parts are expected to fail often. The more flights you do, the more reliable the parts will become. If you want that to happen faster, either do lots of tests (static tests on the pad work as well as actual flights) or decrease the "Flights Per Part Quality Bonus" slider in the BARIS difficulty options.

Squad is already fine with us moving planets around, giving ourselves infinite fuel, and "cheating" in dozens of other ways even just with persistence editing and the debug menu, to say nothing of mods. Spawning magic boulders for cinematic purposes doesn't seem like an unreasonable request deserving of a straight answer. @panzer1b I think asteroids' properties (including their magic boulderness or otherwise) are generated randomly based on a seed, and can't be changed selectively. Your best bet might be to copy the seed of a "real" magic boulder of roughly the correct size and color and paste it in the "seed" line of the one you want to magic boulderify. I haven't actually tried this procedure so it might be a bust, but I'd be curious to hear if it works or not. Also, make sure to undock anything docked to the one you're changing first or strange things might happen. PS. The above is incorrect, at least as far as magic boulder properties go. See @OHara's spoiler for the correct way to do it.

I think that's Walt Kerman you're thinking of, the hazmat suit guy. I'm pretty sure Gus was a reference to Grissom. They handled it well in the end though.

You aren't the first to think of that, or the first to comment on it. I also thought that video was in poor taste, as did a fair number of others when it first came out. It's worth mentioning that Squad isn't completely oblivious to this. There used to be a somewhat tasteless joke about things catching fire around Gus Kerman (the head of operations in the Admin building), which was changed after a lot of people pointed it out. Given that this is a promotional video already released, though, and not something in-game that can be changed any time, I think it's unlikely Squad will do anything about it. (Although an apology would be appreciated.)

Sorry, just trying to help. I can stop any time.

Sure, no problem. I don't guarantee that's anything like a comprehensive list of leakable resources though. All those things sound excellent! If anything I wonder if the resource locking on tanks will make things too easy, given that as long as the resources aren't in use you can just lock the tank and prevent any possibility of failures. Maybe give it a large bonus to quality checks in this case, but not ignore it completely? (I've been experimenting with a patch that multiplies the MTBF of any tank smaller than an FLT-200, but I think your way's better.) So am I!

In that case it's just another highest part count/fastest computer contest, so that's me out. PS. Fastest Eve flyby under 100 parts might be interesting, though. PPS. This is fastest game time, right? Not fastest real-life time? Although that might also be interesting, in a completely different way.

To Eve... what? Flyby? Orbit? Surface? From where? LKO-LKO? KSC launch pad to landing back on Kerbin?

Don't forget that some people either prefer to play stock (for a variety of reasons, such as the extra challenge or the consistency of experience with other players) or can't use mods (most notably consoles)--and therefore it would still be nice to figure out a way of doing this in an unmodded game. Unfortunately I don't think there is a way to get perfect zero inclination around an arbitrary body without mods on any platform (since consoles unfortunately don't have access to the debug menu). Any 3 of those 4 conditions are easy to achieve, but I can't think of a way to get all 4: eyeballing it gets you everything except a perfect inclination, using the Mun doesn't work anywhere but Kerbin, using mods requires using mods (funnily enough), and the debug menu isn't available on console. I guess which option is the best depends on which kind of purist you are.

Well, it looks like I was half-wrong. A kermanned round-trip to Duna is possible with a 600-hour MTBF, but unkermanned missions lasting longer than about a year are not. Here's what I've done so far: Note that this was all in BARIS 1.2.5, which is no longer the current version. The next thing I'm going to do is repeat some of these tests in BARIS 1.2.7, which has, among other things, a dynamic MTBF with a much higher cap. First I launched four "Angela" flyby probes--basically just a probe core, antenna, and a couple science instruments, with no propulsion. All four completed their missions with no failures. Then I launched four "Bluebell" orbiters with the goal of using Scansat radar to map the surface of Duna. Bluebell I failed when its rocket second stage exploded. Bluebell II and III both suffered engine failures en route, although III was able to return limited data during the flyby. Bluebell IV also suffered an engine failure but it was a thrust control failure (engine always on), and I was able to work around it by locking and unlocking the fuel tank. It achieved orbit and completed its mission. It's worth mentioning that on all four Bluebell missions the engines were left in the activated state during the transit, and the three that made it out of LKO all suffered failures within the first 40 days of flight--which suggests that engine MTBF is not working as intended and any time the engine is activated--even if it's not producing thrust--is being counted towards its MTBF. Finally I launched "Caroline I," a three-kerman mission to the surface of Duna. It experienced no trouble through liftoff, departure, outbound transit, arrival, landing, and return to orbit (as expected--all this happened within the first 250 days of the mission). During the year-and-a-half wait for the launch window home and the 220-day transit back to Kerbin it suffered a number of failures, but the crew were able to keep the ship in working order without too much trouble. Unlike the Bluebell series, I deactivated Caroline I's engines during idle periods and neither the single transfer stage engine nor the four lander engines experienced any failures during the flight. However, I did discover a problem: Caroline I's transfer stage (which was used for both the outbound and return trips, being left in Duna orbit for the landing) used three Kerbodyne tanks, one of each size--and BARIS didn't recognize them as fallible. Given the rate at which the ship's six glykerol tanks needed to be repaired, fuel leaks would've been a serious problem if not for this bug. It seems likely the crew could've fixed them, but not without losing a substantial amount of fuel--and of course such a failure would've ended an unkermanned mission. I poked around in the config files of both BARIS and the stock parts and I'm pretty sure I've found the problem (which still exists in 1.2.7): BARIS checks for items with category FuelTank when looking for fallible fuel tanks, but for some bizarre reason the Kerbodyne tanks (and some other stock tanks, such as the Mark 3 ones) are classified as category Propulsion instead. This is also the case for a fair number of modded tanks. It's also worth mentioning that this method misses any part that is primarily something else but has fuel tanks--for instance, the radial glykerol tanks from DeepFreeze are fallible but the glykerol tanks integrated into the freezer pods are not. My suggestion would be rather than going by category, to check for resource containers. It'll be a lot more cumbersome, especially if you want to accommodate modded resources like glykerol, but definitely more reliable. I'm going to launch a few more Caroline missions in BARIS 1.2.7 and see what happens. I want to try one at 100/100 reliability--the best that BARIS allows--and another at the default maximum 80/80 reliability and see how they compare. I might also try experimenting with the main difficulty slider and seeing how big a difference that makes. PS. This MM patch should add the BARIS ModuleBreakableFuelTank to any part that contains stock fuels and a few modded ones (NF propellants and DeepFreeze glykerol). It seems to be working (the QualityControl module shows up on parts where it was missing before, at least) but I haven't tested it thoroughly: use at your own risk. //baris tank fix @PART[*]:HAS[@RESOURCE[LiquidFuel],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[Hydrogen],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[Oxygen],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[ArgonGas],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[LqdHydrogen],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } } @PART[*]:HAS[@RESOURCE[Glykerol],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS] { MODULE { name = ModuleBreakableFuelTank } }

PS. Not my video, to be clear. Just showing that it'd been done.

Alt-F5 is a shortcut to make a hard save. Regular F5 just makes a quicksave.

So far my impression is that a vehicle can generally be expected to last at least twice (and possibly three or four times) its MTBF if its parts start at 100/100 condition. Building in more redundancy will help as well. Obviously early-game relays with lower reliability will fail long before then but those would've ended up being replaced eventually anyway. 4-8 years is definitely a shorter replacement cycle than we're used to but I think it'll be manageable. Plus the cap is easily configurable in the new constants.cfg file.

Good idea though!

I'm still working on it, I've done a series of flybys and orbiters, getting ready to send some Kerbals. The flybys were 4 out of 4 (they were basically just a probe core and an antenna); the orbiters were 1 out of 4--one rocket explosion and three engine failures, with one ending up salvageable. Apart from the engine problems it's looking like unkermanned Duna missions are, in fact, possible. However, these missions have all lasted only about 200 days. Continuing to keep track of the probes after the end of their missions, I've noticed that by T+1 year, they've suffered several failures each, and by T+2 years, every part has failed on both the probes and their spent rocket stages--which does not bode well for missions to more distant destinations, or kermanned round-trips. We'll see how the kermanned missions go. My guess is it'll be easy to get to Duna and nearly impossible to get back, but we'll see how good my kerbals are at fixing things. PS. The results I'm getting now suggest the actual useful life of a part starting at 100/100 reliability is actually several times its MTBF. Parts with a 100-day (600-hour) MTBF are starting to fail after 300 days, and likely to have failed after 600 days. My current test series is on default difficulty, by the way. I haven't experimented with adjusting that slider, it's possible setting it to easy or super-easy will make interplanetary trips doable, although I suspect that would have the side effect of making Kerbin system ops a little boring. PPS. Question @Angel-125: Does an engine classify as operating for MTBF purposes whenever it's activated or only when it's producing thrust?

Link to original forum post.

The version I'm using is 1.8.4 for KSP 1.2.2; however, I have yet to have any problem with it in 1.3.

The trick is going to be having failures infrequent enough to make interplanetary travel possible while still having them frequent enough to make Kerbin system ops interesting. This is why I'm in favor of a dynamic MTBF that increases along with part reliability. It's OK for interplanetary travel to be impossible in the early game, but as long as improving technology makes it become possible later on.

@CaribeanSoul I think it makes quality checks easier, which is to say on any given check parts are a bit more or less likely to fail, so the failure rate overall will be higher or lower. @Angel-125 can correct me if I'm wrong though. Yes, that's what I'm seeing as well. I do notice that (even in stock KSP, nothing to do with BARIS) I sometimes have to hit the spacebar twice to fire my next stage--as though I have to sort of re-fire the current stage before the next one will go--and I wonder if this is being counted as an additional staging event by BARIS? I just meant that the card reports the Kerbal in question suffered a harrowing experience even though they've never even been on a mission. I think this is as intended, just making sure. I know about the loss of a vessel under construction; I just wondered if the VAB was meant to be damaged in addition to that, given that the card shows a picture of it destroyed. Sounds like it's working as intended so no problem, again just checking. That's a bit dark... and from a gameplay point of view I don't think serves much of a purpose. Not a huge deal, but all it really means is I have to go into the menu and hold down the + button for a while again to get 50 more. (Unless they get more expensive the more of them you lose, but since it's outside the player's control that'd seem a little harsh.) Which logs? Which debugging, KSP's, BARIS's, or both? (Sorry to be difficult, but I'm used to solving problems myself rather than asking for help on the forums, and I've never actually had to submit logs before.) Fair enough. Maybe make it an option? The point I'm trying to make about MTBF is this: right now, at default settings, BARIS makes interplanetary travel virtually impossible. Even on easy settings it's prohibitively difficult. But we don't have to argue about this--we can test it. I'll try debugging the part qualities and reliability up to maximum and see how many tries it takes to get to Duna, with and without kerbals, and let you know what happens. My guess is I won't be able to do it at all, or it will take dozens of attempts--but maybe I'll be wrong. And again, I'm really sorry if I'm coming off as difficult. I know I keep saying it but I'm really looking forward to this mod so I'm excited about working on trying to get it balanced. Let me know if I'm giving you too much grief about all this though and I'll shut up about it. It is, after all, your mod.

@Jacke Please stop. I really don't want to get into a long and off-topic debate about the semantics of a three-word parenthetical aside. My only point with that aside was to illustrate that explosive failures (whether during liftoff or in-flight) make sense for fuel tanks but not for other part types.

True in real life, but in KSP we don't simulate things like manufacturing defects, shoddy maintenance procedures, or stirring of oxygen tanks--we use random die rolls for a gameplay approximation. That note just cited a real-world example of an explosion of a fuel tank during normal operations rather than during a particularly stressful period such as liftoff or reentry.

After playing with 1.2.5 for a bit, here's what I've come up with. Again, sorry to keep posting such long lists, I'm really trying to be helpful but I can't help but feel like I'm just badgering you. Thanks again for all your work on this mod, the more I play with it the more excited I'm getting about using it in a career. Bugs/issues: Very frequent (more than half the time) failures near end of ascent --launch failure check too aggressive? Engine reports "shutdown to prevent catastrophic failure" and then explodes anyway "Intestinal Fortitude" card comes up even though nothing actually happened (intended?) "Speed Challenge" card comes up even though the only vehicle under construction was completed weeks ago --differentiate between vessels under construction and completed vessels in storage? "One or more vessels has a problem" dialogue frequently reports a problem on currently active vessel even though there are no (new) malfunctions VAB not damaged by "High Bay Collapse" card (intended?) VAB workforce occasionally reduced by half (related to "High Bay Collapse?") Antennas and fuel tanks don't seem to be gaining quality/flight experience Questions: Does staging-independent launch failure check happen at a set time, or a random time within a set window? How is likelihood of launch failure determined? Is it related to vessel reliability? Suggestions: Limit explosive failures to fuel tanks only? --maybe also engines, but only if they're currently running? --it's a little strange to have antennas that spontaneously explode, but random tank explosions are more plausible (cf. Apollo 13) Make failures more likely during engine burn or high-G? --Maybe do this instead of a single random launch failure check: covers launch, engine burns, and entry/descent/landing rather than just launch --Would give an added incentive to use RCS, rather than low-throttle engines, for small corrections Proposed MTBF values: (Assuming parts will NEVER fail (except crit, launch, staging) before reaching MTBF After reaching MTBF their quality will degrade and they will eventually fail i. e. MTBF = part's useful lifespan If MTBF behaves more like real life MTBF--i. e. part should be expected to fail once within any given x hour period--different values might be needed) LFO engines, default 5 hours Nuclear/ion engines, default 15 hours Air-breathing engines, default 100 hours "Lifter" class engines, basic 1 hour T30, Mainsail, Twin-Boar, Mammoth (for single use as booster engines) "Lifter" class engines, advanced 5 hours Vector, Aerospike (for reusable launch vehicles, SSTOs, and heavy landing craft) "Orbital" class engines 10 hours Terrier, T45, Poodle, Skipper, Rhino, small engines (for repeated use on upper stages, small landing craft, etc.) "Interplanetary" class engines 15 hours Nerv, Dawn (for low-TWR interplanetary transfer stages) Jets, slow 100 hours Juno, Wheesly, Goliath, Panther (for long-term, low-speed use on suborbital airplanes) Jets, fast 30 hours Whiplash, Rapier (for short-term, high speed use on SSTOs and hypersonic airplanes) Antennas, default 5,000 hours Antennas, short-range 1,000 hours Comm. 16, 16S, HG-5 Antennas, medium-range 5,000 hours Comm. DTS-M1, RA-15 Antennas, long-range 10,000 hours Comm. 88-88, RA-100 Fuel tanks 10,000 hours Reaction wheels 100 hours RCS 100 hours Converters, drills, etc. ? (haven't had a chance to test these yet)