[1.12.2] BARIS - Building A Rocket Isn't Simple

[Angelo Kerman]

10 minutes ago, Hotaru said:

I'm a little worried about parts like fuel tanks that are in operation all the time--600 hours isn't very long compared to even a short interplanetary transfer. I'm also a little confused when a reaction wheel classifies as in operation, since they have very short MTBFs (similar to engines--on the order of 20 hours) and in 1.2 they seemed to be failing a lot more than other parts.

I'll play with 1.2.5 for a while though and see what happens--so far all I've done has been send up satellites, I haven't tried any kermanned missions yet. Thanks for the quick update, I'm impressed you implemented so many of our suggestions so fast! (Especially looking forward to the explosion thing. That'll be fun.)

Check out MM_BARIS, it sets up the MTBF values by type of part. I believe the RCS and SAS are set to 12 hours. You can play with those values and find something that works well for you- but they'll only apply to new vessel construction. If you leave SAS and RCS on when you focus on another vessel, then they'll be considered as potential candidates to break during the vessel reliability check. Fuel tanks are always considered as potential candidates to break due to micrometeorites and such.

[Hotaru]

1 minute ago, Angel-125 said:

If you leave SAS and RCS on when you focus on another vessel, then they'll be considered as potential candidates to break during the vessel reliability check.

That'll be the problem then: I always leave SAS on when switching focus, with Persistent Rotation that's necessary to maintain the vessel's orientation while unloaded. For my own purposes I'll just adjust the MTBF on reaction wheels to compensate; I do think it'd be a good idea for them to have a higher default MTBF though, more like what fuel tanks have, as I'm sure I'm not the only one who always leaves SAS on.

[Angelo Kerman]

Just now, Hotaru said:

That'll be the problem then: I always leave SAS on when switching focus, with Persistent Rotation that's necessary to maintain the vessel's orientation while unloaded. For my own purposes I'll just adjust the MTBF on reaction wheels to compensate; I do think it'd be a good idea for them to have a higher default MTBF though, more like what fuel tanks have, as I'm sure I'm not the only one who always leaves SAS on.

Well if you wouldn't mind doing some MTFB tuning and posting your results...

One thing to consider: the values in that MM_BARIS file assume no knowledge of the part, such as tech tree and such. If a part already has setup the breakable part modules and quality control module, then those default values won't be used. Ideally, MM_StockParts would be applied first, then MM_BARIS (probably renamed Z_MM_BARIS so that it appears last in the file list). That way, you could specify MTBF values based upon where a part falls in the tech tree- but there are a lot of parts out there, hence the default values.

[Hotaru]

2 minutes ago, Angel-125 said:

Well if you wouldn't mind doing some MTFB tuning and posting your results...

I will do that and get back to you (although for obvious reasons it'll take a day or two).

The problem with the reaction wheel thing is what their MTBF should be depends on how you think about SAS--is it a system to be used only for stability during maneuvers (and should only be used very occasionally) or is it a system that maintains the vessel's orientation at all times (and should virtually always be operating)? I use Persistent Rotation so I'm kind of stuck with the second option (which requires long MTBFs)--but in stock, where vessels always keep their orientation when unloaded, the former (the way you have it set up now, with a short MTBF) arguably makes more sense.

 

6 minutes ago, Angel-125 said:

One thing to consider: the values in that MM_BARIS file assume no knowledge of the part, such as tech tree and such. If a part already has setup the breakable part modules and quality control module, then those default values won't be used. Ideally, MM_StockParts would be applied first, then MM_BARIS (probably renamed Z_MM_BARIS so that it appears last in the file list). That way, you could specify MTBF values based upon where a part falls in the tech tree- but there are a lot of parts out there, hence the default values.

So, like, an Aerospike could be more reliable than an LV-T30? Makes sense. Also opens up some interesting possibilities: for instance, some engines could be intended for single uses as lifter engines (cheaper but shorter MTBF), while others could be meant for reuse or long-term use on deep-space missions (more expensive but longer MTBF). Real world analog being RS-68 compared to RS-25. Not sure if there's really enough variation in the current set of stock parts to do this, but in combination with the part upgrade system it could be very cool.

[Angelo Kerman]

53 minutes ago, Hotaru said:

I will do that and get back to you (although for obvious reasons it'll take a day or two).

The problem with the reaction wheel thing is what their MTBF should be depends on how you think about SAS--is it a system to be used only for stability during maneuvers (and should only be used very occasionally) or is it a system that maintains the vessel's orientation at all times (and should virtually always be operating)? I use Persistent Rotation so I'm kind of stuck with the second option (which requires long MTBFs)--but in stock, where vessels always keep their orientation when unloaded, the former (the way you have it set up now, with a short MTBF) arguably makes more sense.

 

So, like, an Aerospike could be more reliable than an LV-T30? Makes sense. Also opens up some interesting possibilities: for instance, some engines could be intended for single uses as lifter engines (cheaper but shorter MTBF), while others could be meant for reuse or long-term use on deep-space missions (more expensive but longer MTBF). Real world analog being RS-68 compared to RS-25. Not sure if there's really enough variation in the current set of stock parts to do this, but in combination with the part upgrade system it could be very cool.

Frankly, I leave my SAS (and sometimes RCS) on all the time too...

Yup! BARIS was designed with the idea that some parts would have longer lifespans than others. MOLE parts last 30 days, for instance, Pathfinder parts last 150 days, and DSEV parts last a full year. Fuel tanks are rated for 100 kerbal days (600 hours), and should fail about 4 times per year as currently implemented.

Edited August 25, 2017 by Angel-125

[Jacke]

2 hours ago, Angel-125 said:

Check out MM_BARIS, it sets up the MTBF values by type of part. I believe the RCS and SAS are set to 12 hours. You can play with those values and find something that works well for you- but they'll only apply to new vessel construction. If you leave SAS and RCS on when you focus on another vessel, then they'll be considered as potential candidates to break during the vessel reliability check. Fuel tanks are always considered as potential candidates to break due to micrometeorites and such.

Hmmm, from my knowledge of spaceflight history, I have some suggestions, some partly descriptive, some that point to changes.

I think those MTBF values are rather low, even for 1st generation equipment, especially for RCS just being enabled.  RCS systems are rarely designed to shut down once enabled and having running times (as opposed to burn times) in days or longer.  And SAS based on nav platforms are always running even if currently not enabled to give corrective actions.  Micrometeorites, even in Kessler Syndrome besotted LEO, are very rare and easily defended with a high chance of success with one or two bumper layers.

Most systems are like electronics.  It's rarely the lines that the source of failure unless exposed to vibration or wear and tear (like the early J2 engine high-altitude propellant line failures).  It's more often the nodes those lines connect that fail.  For fuel, engines, and RCS, that's going to be valves and pumps.  The failure of systems should be related to the operation of those nodes.  I don't know if it's possible to track RCS pulses or burn time, but it should be possible to do that for tanks and engines, based upon pumping time and burn time.

[Angelo Kerman]

As people check in about realism and such, remember that KSP has ion engines that deliver 4kn of thrust. I'm not above putting fun above realism- if you want things to be pretty reliable, then don't install BARIS- parts are meant to fail, and should fail enough to be something you have to think about but not so much that it gets too frustrating and not fun to play.

[Jacke]

3 minutes ago, Angel-125 said:

...parts are meant to fail, and should fail enough to be something you have to think about but not so much that it gets too frustrating and not fun to play.

Agreed.  But parts should fail in a realistic way and with realistic rates if those allow the right balance between being challenging and not too frustrating.

[Just Jim]

Hmmm... so krap can break... I like it... lol.

I just updated to 1.3, and found this in the latest MOLE update... and I may enable and use it in Emiko. I have to read over the WIKI stuff more closely tomorrow, but I like the idea of having parts wear down, etc...

Question, as far as lifespans:

2 hours ago, Angel-125 said:

Yup! BARIS was designed with the idea that some parts would have longer lifespans than others. MOLE parts last 30 days, for instance, Pathfinder parts last 150 days, and DSEV parts last a full year. Fuel tanks are rated for 100 kerbal days (600 hours), and should fail about 4 times per year as currently implemented.

Emiko is a very old career game, and several of my bases and ships are already several years old. If I enable Baris, will parts start breaking from age right off on an older ship, or will it start counting days from when I enable it?

Edited August 26, 2017 by Just Jim

[Angelo Kerman]

Just now, Just Jim said:

Hmmm... so krap can break... I like it... lol.

I just updated to 1.3, and found this in the latest MOLE update... and I may use enable and use it in Emiko. I have to read over the WIKI stuff more closely tomorrow, but I like the idea of having parts wear down, etc...

Question, as far as lifespans:

Emiko is a very old career game, and several of my bases and ships are already several years old. If I enable Baris, will parts start breaking from age right off on an older ship, or will it start counting days from when I enable it?

You have several options available. For existing saves, BARIS ignores any vessel that you haven't visited after installing the mod. When you do load a vessel, you'll receive some default values for part quality and vessel reliability. You can also enable the debug option and set your vessels to the maximum quality cap (which defaults to 80, but can be adjusted all the way to 100)- I did that for my K.E.E.P. save so that the Akron would be unlikely to break. I didn't have that option at first and let me tell you, the Akron was in sorry shape!

You also have the option to decide exactly what parts will break, such as fuel tanks, engines, and the like. So you can do all of the above, and decide how much you want to break to start. You can also disable launch failures and just contend with parts wearing out. You can also disable the need for the repair resources.

So, definitely lots of options to match your play style. My suggestion would be to make a copy of your save and try BARIS there first to get a feel for it, then enable/disable features that suit your needs.

[Just Jim]

20 minutes ago, Angel-125 said:

You have several options available. For existing saves, BARIS ignores any vessel that you haven't visited after installing the mod. When you do load a vessel, you'll receive some default values for part quality and vessel reliability. You can also enable the debug option and set your vessels to the maximum quality cap (which defaults to 80, but can be adjusted all the way to 100)- I did that for my K.E.E.P. save so that the Akron would be unlikely to break. I didn't have that option at first and let me tell you, the Akron was in sorry shape!

You also have the option to decide exactly what parts will break, such as fuel tanks, engines, and the like. So you can do all of the above, and decide how much you want to break to start. You can also disable launch failures and just contend with parts wearing out. You can also disable the need for the repair resources.

So, definitely lots of options to match your play style. My suggestion would be to make a copy of your save and try BARIS there first to get a feel for it, then enable/disable features that suit your needs.

OK, I'll keep these in mind... thanks!

Might be fun to go somewhere like my polar base, which has been empty for quite some time, and find stuff all busted up... make the engineers earn their credits... lol... 

Edited August 26, 2017 by Just Jim

[Hotaru]

2 hours ago, Angel-125 said:

You have several options available. For existing saves, BARIS ignores any vessel that you haven't visited after installing the mod. When you do load a vessel, you'll receive some default values for part quality and vessel reliability. You can also enable the debug option and set your vessels to the maximum quality cap (which defaults to 80, but can be adjusted all the way to 100)- I did that for my K.E.E.P. save so that the Akron would be unlikely to break. I didn't have that option at first and let me tell you, the Akron was in sorry shape!

Very cool, I've been wondering about how it handles existing saves (thinking about whether to try it on my HSP save or not).

 

4 hours ago, Angel-125 said:

Yup! BARIS was designed with the idea that some parts would have longer lifespans than others. MOLE parts last 30 days, for instance, Pathfinder parts last 150 days, and DSEV parts last a full year. Fuel tanks are rated for 100 kerbal days (600 hours), and should fail about 4 times per year as currently implemented.

4 times per year is way too much, I think. Even on the shortest interplanetary transfers that means I should expect to have several fuel leaks develop... bad enough if I have kerbals along to repair them, but it makes unkermanned probes to other planets basically impossible.

I mean, I'm thinking about my current career, which is in year 27 at the moment. The longest kermanned mission so far is Daring 4, my Eeloo mission, which lasted about 6 years, 2 out and 4 back--at 4 failures per tank per year (plus other failures as well) they'd have been struggling to keep that ship running by the time they arrived at Eeloo, and by the time they made it back to Kerbin they'd be lucky to still have a ship under them at all.

On the other hand, my oldest operating space station, Persistence in Munar orbit, is nearly twenty years old. If I'd been using BARIS or a similar mod, I'd have expected to have to worry mostly about routine maintenance for the first few years of operation--around year 5 I'd expect to start having to replace a part here and there--by year 20 I'd figure it'll have enough wrong with it to be approaching the end of its useful life.

Consider also the lifespan of engines--their default MTBF is 16 hours, I think, which suggests that they're intended to have lifespans on the order of years rather than months, since an engine will only be ever used for a few minutes at a time. I doubt even the engines on my low-TWR, nuclear-powered interplanetary missions would've come anywhere near 16 hours of burn time during their operational lives despite being used on years-long missions.

The only time I'd be expecting these kinds of high failure rates would be the early game--having to throw five probes at Duna before one of them works sounds about right for the early days of interplanetary exploration. But if things are still going that way in the late game, it'll be frustrating rather than fun.

I'll do some testing in my BARIS sandbox save and let you know what I come up with, but I suspect I'm going to end up suggesting increasing MTBF by at least a factor of ten.

One other possibility would be to make MTBF configurable, or dynamic somehow--the more experience you gain with a part, the longer its useful life becomes. A completely untested tank might have an MTBF of only 100 hours, but once it's been used a few dozen times it might be expected to last several years without developing a problem. Alternatively, maybe we could pay extra (either in funds, science points, or mass--although I expect the mass option would conflict with other mods) for increased reliability.

 

2 hours ago, Angel-125 said:

As people check in about realism and such, remember that KSP has ion engines that deliver 4kn of thrust. I'm not above putting fun above realism- if you want things to be pretty reliable, then don't install BARIS- parts are meant to fail, and should fail enough to be something you have to think about but not so much that it gets too frustrating and not fun to play.

This I think is the most important point, and why I've not been bringing up the "it's not realistic" point in arguing for longer MTBFs. I think having parts fail as often as they seem to do now (except perhaps in the very early game) is well over that line between challenging and frustrating. On the one hand I want stuff to go wrong, parts to break, rockets to blow up--on the other hand I still want to be able to complete missions successfully at least some of the time. Having to succeed in the face of system failures will be all the more satisfying, but that'll only happen if failures are infrequent enough that success is actually possible.

[CaribeanSoul]

I'm sorry if I missed it but did you ever explain how the difficulty slider changes the failure chances?  (I looked for it in the wiki but didn't find anything.)

Edited August 26, 2017 by CaribeanSoul

[Pand5461]

7 hours ago, Hotaru said:

The only time I'd be expecting these kinds of high failure rates would be the early game--having to throw five probes at Duna before one of them works sounds about right for the early days of interplanetary exploration. But if things are still going that way in the late game, it'll be frustrating rather than fun.

I'll do some testing in my BARIS sandbox save and let you know what I come up with, but I suspect I'm going to end up suggesting increasing MTBF by at least a factor of ten.

One other possibility would be to make MTBF configurable, or dynamic somehow--the more experience you gain with a part, the longer its useful life becomes. A completely untested tank might have an MTBF of only 100 hours, but once it's been used a few dozen times it might be expected to last several years without developing a problem. Alternatively, maybe we could pay extra (either in funds, science points, or mass--although I expect the mass option would conflict with other mods) for increased reliability.

Can't agree more.

The problem with "realism" is of course that real-life missions do not use the same equipment for long-term and short-term flights. Any sane person will try to develop reliable equipment for deep space missions rather than use failure-prone one and pray to Kraken it will last few dosen times its MTBF (OK, USSR in the years of the Space Race did exactly the latter but we're not in a hurry here).  So, there must be an option to increase the reliability for a specific vessel for extra fee or time if that vessel is supposed to go for a long mission.

As for tanks specifically, their reliability may be based on the volume - a micrometeoroid is arguably less likely to hit a small tank than a huge one. First, this encourages players to not overdesign. Second, the further a spacecraft goes, the smaller tanks are usually left on it, so large MTBFs are naturally important mostly for small tanks.

[Hotaru]

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)

 

Edited August 26, 2017 by Hotaru

[Jacke]

2 hours ago, Hotaru said:

...random tank explosions are more plausible (cf. Apollo 13)

Failures like the explosion of the LOX tank in Apollo 13 are anything but random.  BARIS doesn't need to go into the back story, but the key thing here is the tank had multiple faults and failed after sufficient use while being used, both delivering resource and undergoing maintenance.  Failure should mostly happen to systems in use after sufficient use.

[Hotaru]

12 minutes ago, Jacke said:

Failures like the explosion of the LOX tank in Apollo 13 are anything but random.  BARIS doesn't need to go into the back story, but the key thing here is the tank had multiple faults and failed after sufficient use while being used, both delivering resource and undergoing maintenance.  Failure should mostly happen to systems in use after sufficient use.

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.

Edited August 27, 2017 by Hotaru

[Jacke]

2 hours ago, Hotaru said:

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.

That's the point I'm trying to make.  Random simple gameplay determination replaces the myriad hidden details of reality.  And for that Apollo 13 LOX tank, that was a stressful period of use, being heated and stirred.

Parts should mostly fail when they are used and only rarely when they are idle, perhaps with an increased chance of failure striking when they are first used and when they are restarted in use.  Additional events should be possible under general periods of stress like ascent, reentry, or otherwise under thrust, as a broad generalization of the whole spacecraft being in some sort of use.

 

[Hotaru]

@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.

[Angelo Kerman]

20 hours ago, Hotaru said:

*SNIP*

Bugs

Very frequent (more than half the time) failures near end of ascent: Depends upon the staging timer. If you perform another staging event before the timer expires, the timer will be applied to the current stage. In my test craft, launch failures happen soon after launch and near achieving orbit.

Engine reports "shutdown to prevent catastrophic failure" and then explodes anyway: If an engine can't be shut down then it will explode. Probably something to do with the message displayed.

"Intestinal Fortitude" card comes up even though nothing actually happened (intended?): One of your kerbals became a badass, unless all of them already are.

"Speed Challenge" card comes up even though the only vehicle under construction was completed weeks ago: Will get disabled when KCT is installed.

"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 building does not get damaged; card says that one of your vehicle integration projects is lost if you have any in progress.

VAB workforce occasionally reduced by half (related to "High Bay Collapse?"): Well, vehicle integration isn't done by robots...

Antennas and fuel tanks don't seem to be gaining quality/flight experience: Turn on debugging and please provide logs.

Answers

Does staging-independent launch failure check happen at a set time, or a random time within a set window? Staging independent launch failure check happens independently of staging events anywhere between 2 and 6 minutes after launch.

How is likelihood of launch failure determined? Is it related to vessel reliability? Staging/launch events are based on vessel Reliability. Interacting with a part through the PAW bases its quality checks on the part's Quality rating.

Part Explosions

I don't agree that only engines and fuel tanks should explode- RCS fuel valves might cause an improper mix, or pogo oscillations might shake the thruster apart. Flywheels might crack or bearings seize up and cause the assembly to fly apart. Fuel tanks might be over pressurized and burst. Drill shafts might get over stressed and shatter. Batteries might overheat and explode. Capacitors might get overcharged and explode. That's why the part exploding feature is an option- and you can independently decide if they explode during launch or explode during post-launch activities. Those sliders go all the way down to zero (though there's a bug at the moment).

MTBF

MTBF assumes that it's unlikely for a part to fail within the allotted MTBF hours, not impossible. With a 10,000-hour MTBF rating, that's nearly 4 kerbal years- you might as well disable part failures on that type of part- but hey, it's your game. That's why I made BARIS highly configurable Remember, you can also affect how often checks are made, between 1 and 6 times per day as well.

I do like the idea of adding MTBF to parts with more flight experience, but will likely cap MTBF at 2,556 hours (1 kerbal year). With the addition of a Constants.cfg file, which will let you set certain constants used by BARIS, you can change that cap to your liking.

For unkermanned spacecraft, you could always disable the skill check requirement and the EVA requirement in order to effect repairs. Or, if you feel that a particular type of part, such as a fuel tank, is too mission critical to fail, then disable part failures for that part type. I am toying with the idea of a Robonaut type of part that would let you create small probes to take the place of astronauts when fixing things, but that will definitely be advanced technology.

Edited August 27, 2017 by Angel-125

[CaribeanSoul]

I think the addition of a config file is a great idea.  Putting as many configurable values in there as possible would allow advanced users to tweak and test things without you going crazy adding all of that to various guis.

 

Could someone, anyone, please tell me what the difficulty slider really does?  The suspense is killing me...

[Hotaru]

@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.

 

 

Quote

Depends upon the staging timer. If you perform another staging event before the timer expires, the timer will be applied to the current stage. In my test craft, launch failures happen soon after launch and near achieving orbit.

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?

 

48 minutes ago, Angel-125 said:

One of your kerbals became a badass, unless all of them already are.

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.

 

49 minutes ago, Angel-125 said:

VAB building does not get damaged; card says that one of your vehicle integration projects is lost if you have any in progress.

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.

 

50 minutes ago, Angel-125 said:

Well, vehicle integration isn't done by robots...

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.)

 

51 minutes ago, Angel-125 said:

Antennas and fuel tanks don't seem to be gaining quality/flight experience: Turn on debugging and please provide logs.

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.)

 

52 minutes ago, Angel-125 said:

I don't agree that only engines and fuel tanks should explode

Fair enough. Maybe make it an option?

 

52 minutes ago, Angel-125 said:

With a 10,000-hour MTBF rating, that's nearly 4 kerbal years- you might as well disable part failures on that type of part-

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.

[CaribeanSoul]

2 minutes ago, Hotaru said:

@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.

 

Well ... that part seems likely.  I was hoping for an explanation of the math/mechanics behind that.  Does it add a flat bonus to all quality check rolls?  Does it check quality less often?  Does it affect the max quality on parts? etc...

[panarchist]

On 8/25/2017 at 7:02 PM, Angel-125 said:

You also have the option to decide exactly what parts will break, such as fuel tanks, engines, and the like. So you can do all of the above, and decide how much you want to break to start. You can also disable launch failures and just contend with parts wearing out. You can also disable the need for the repair resources.

So, definitely lots of options to match your play style. My suggestion would be to make a copy of your save and try BARIS there first to get a feel for it, then enable/disable features that suit your needs.

One thing you might consider, and one which I haven't seen anyone do before, is to enable two sets of MTBF numbers - the other set being for launch/landing in an atmosphere (or alternatively, one set of MTBFs, but set higher, and a multiplier for breakage chance when launching/landing in atmo, or other high dynamic pressure environments (which is probably actually the better one to use)

A great example of why this would be awesome is fuel tanks.  MTBF on a fuel tank in space is ludicrously high.  Unless subjected to thrust, there's no real chance of it springing a leak.  Leaks and pressure failures only happen when there is thrust to pull on the tank's fittings, shaking from dynamic pressure of ship oscillation, on tank weld weakening due to repeated thermal expansion/contraction or long-term neutron embrittlement. Micrometeoroid puncture is almost unheard of in interplanetary space - the main dangers for puncture are in low planetary orbit, being within a planet's rings, or within a comet's tail. Cryogenic tanks are more susceptible, but with non-cryo tanks, MTBF in space is somewhere in the hundreds of thousands of hours. MTBF at launch is a far lower figure.

2 hours ago, Angel-125 said:

MTBF assumes that it's unlikely for a part to fail within the allotted MTBF hours, not impossible. With a 10,000-hour MTBF rating, that's nearly 4 kerbal years- you might as well disable part failures on that type of part

And this is my point - as @Hotaru stated, interplanetary (or interstellar) is going to take a LONG time, and the actual odds of a failure are non-trivial, but in the hundreds of thousands of hours - assuming there wasn't a launch failure.  During launches, the MTBF of a tank is <10 hours, and probably <2 hours.  It's the average 8 minute (on Earth) or less trip which allows us to beat the odds, as it were.

Edited August 27, 2017 by panarchist
spelling error

[Hotaru]

24 minutes ago, panarchist said:

interplanetary (or interstellar) is going to take a LONG time

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.