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

[CaribeanSoul]

Perhaps the ability to flag a craft as interplanetary or interstellar (perhaps by the inclusion of some small part in the design) could cause the integration time to become considerably longer (and perhaps cost?) and then increase the MTBF for all parts to much higher values.

[Jacke]

4 hours ago, Hotaru said:

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.

Trying to get BARIS to be anything like reality (to get verisimilitude) for the long flight times of interplanetary missions by just relating the total mission elapsed time with respect to MTBF values is going to see missions be rather fateful, hard to make them have some chance of failure without ending up almost certain to fail.  That's going to be frustrating.

A dynamic MTBF as @Hotaru suggested is one way to deal with this.  Comparing those MTBF to something besides just raw MET would help too.  Both would be better.

I'll be interested in seeing how many attempts it takes @Hotaru to get to Duna.  Now, imagine a Jool probe mission.  How will it have any chance of succeeding by just comparing a MTBF values of under 10,000 hours to the MET?

[CaribeanSoul]

So ... the "Manage Operations" button has disappeared from my MOLE parts.

I haven't had a lot of time to play lately and when I have I've been doing "mod stuff" rather than launching any rockets.  So I decided to just disable BARIS and continue with my bigby orbital workshop (sKylab) station.  I went to do a final check of the craft before telling KCT to build it and noticed the "Manage Operations" option was gone from the menu.  I confimed it was also happening in a sandbox save.  I reinstalled the latest versions of MOLE and BARIS to make sure I hadn't messed something up.  No dice.  I did notice that I could get the manage operations option on my Blue Dog parts and the gui worked fine.

I rolled back Pathfinder, MOLE, and Buffalo to pre-BARIS release and Manage Operations button reappeared.  I'm an idiot though and didn't grab the logs before I rolled back to the old release.  If I have some time tomorrow I'll put the latest release back and grab the logs ... 

[Shnyrik]

On 26.08.2017 at 1:24 AM, Hotaru said:

I always leave SAS on when switching focus, with Persistent Rotation that's necessary

Does it work well in 1.3? Or is there some dev or community version?

[Hotaru]

8 minutes ago, Shnyrik said:

Does it work well in 1.3? Or is there some dev or community version?

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.

[Hotaru]

16 hours ago, Jacke said:

I'll be interested in seeing how many attempts it takes @Hotaru to get to Duna.  Now, imagine a Jool probe mission.  How will it have any chance of succeeding by just comparing a MTBF values of under 10,000 hours to the MET?

 

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?

Edited August 28, 2017 by Hotaru

[Angelo Kerman]

1 hour ago, Hotaru said:

PPS. Question @Angel-125: Does an engine classify as operating for MTBF purposes whenever it's activated or only when it's producing thrust?

Engine MTBF examines its total burn time, not total activated time.

BARIS 1.2.7 (KSP 1.3 only, 1.2.2 support was dropped a few releases ago) is now available:

Event Cards
- Vehicle integration completed event result won't be available when KCT is installed.

MTBF
- Part condition is now based on MTBF instead of part quality.
- New Condition summary: Maintenance Required - When MTBF runs out, this summary will indicate that the part needs periodic maintenance in order to maintain its quality.
- As parts gain flight experience, they'll gain MTBF in addition to their flight experience bonus.
- MTBF capped at 5,112 hours (2 kerbal-years).
- ModuleQualityControl now allows part-based MTBF caps just like it does with quality rating caps. These caps override the global settings.
- Fixed issue where MTBF improvements gained through part upgrades wasn't being applied.
- Fixed issue where MTBF improvements gained through facility upgrades wasn't being applied.

Configuration
- Added new Constants.cfg file; many of BARIS's constant values can be configured with this file, including the MTBF cap...

Other Fixes
- Fixed issue where the odds of a part exploding during launch and/or post-launch weren't honoring a 0% chance.

[Angelo Kerman]

Known issue: In the flight dialog, Condition also shows your quality rating. It can be misleading as condition is tied to MTBF instead of quality, so you could see "Maintenance Required" right along with, say 45/45 quality. I have to devise a better way to show the quality rating separate from part condition.

[Bottle Rocketeer 500]

48 minutes ago, Angel-125 said:

Part condition is now based on MTBF instead of part quality.

Yay! Now less OMS engine failures for my shuttle while trying to do STS-1a for the shuttle challenge!

[Antik]

One silly question: does crew's stupidity actually affect reliability checks, especially during launch?

 

[Angelo Kerman]

2 minutes ago, Antik said:

One silly question: does crew's stupidity actually affect reliability checks, especially during launch?

 

No. Only skill does.

14 minutes ago, Bottle Rocketeer 500 said:

Yay! Now less OMS engine failures for my shuttle while trying to do STS-1a for the shuttle challenge!

Note that this refers to the condition summary, not the likeliness that a part will fail. That's still done via part Quality and vessel Reliability.

[Antik]

Hm, okay. It still does not explain, why failures with smarter kerbals are less harsh, compared to that with smarter. 

Jeb: 4 launches, 3 sviwel shutdowns, 4 srb partial thrust losses

Val: 4 launches, same vehicle, one sviwel shutdown, two stuck throttles, no srb fails.

All buildings at 1lvl, exept MC- at second.

Also, capsule radio and gyros break all the times, sometimes even twice.

Edited August 28, 2017 by Antik

[Angelo Kerman]

1 minute ago, Antik said:

Hm, okay. It still does not explain, why failures with smarter kerbals are less harsh, compared to that with smarter. 

Jeb: 4 launches, 3 sviwel shutdowns, 4 srb partial thrust losses

Val: 4 launches, same vehicle, one sviwel shutdown, two stuck throttles, no srb fails.

All buildings at 1lvl, exept MC- at second.

Experience counts, as does the Random Number Gods. Also, partial thrust losses are so obsolete now with 1.2.7...

Edited August 28, 2017 by Angel-125

[Antik]

Okay, thanks. And last one- define "expirience". It's simply the number of stars/expirience or it's actually number of flights and so on?

 

[Hotaru]

20 minutes ago, Antik said:

One silly question: does crew's stupidity actually affect reliability checks, especially during launch?

17 minutes ago, Angel-125 said:

No. Only skill does.

Good idea though!

 

[Angelo Kerman]

2 minutes ago, Antik said:

Okay, thanks. And last one- define "expirience". It's simply the number of stars/expirience or it's actually number of flights and so on?

 

Correct.

[larkvi]

I have a question about the intent of the cap: 2 years means that all my relay probes will fail constantly. Do you not use relay probes? I suppose I am curious how such dramatic failure rates actually work into your gameplay--do you only run manned missions?

[Hotaru]

12 minutes ago, larkvi said:

I have a question about the intent of the cap: 2 years means that all my relay probes will fail constantly. Do you not use relay probes? I suppose I am curious how such dramatic failure rates actually work into your gameplay--do you only run manned missions?

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.

[Angelo Kerman]

20 hours ago, larkvi said:

I have a question about the intent of the cap: 2 years means that all my relay probes will fail constantly. Do you not use relay probes? I suppose I am curious how such dramatic failure rates actually work into your gameplay--do you only run manned missions?

Have you actually tried running a mission, or is this just an intellectual exercise? I'm at the point where I would like to see quantifiable data before listening to people complain that missions are too hard.

Edited August 29, 2017 by Angel-125

[Hotaru]

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
	}
}

 

Edited August 30, 2017 by Hotaru

[Angelo Kerman]

13 hours ago, Hotaru said:

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
	}
}

 

Mind if I bring those into the next BARIS update? I knew the patches I wrote wouldn't cover everything, but those should help.

Some things planned for the next update- I'm waiting to see when 1.3.1 drops-

• If all the resources on a tank are locked then it won’t be considered active.

• Base chance to eject tied to highest stupidity level, overridden by constants file?

• Separate quality ratings from condition summary.

• Engine activated fix- appears to be listed as active even when just idling and not actually burning.

• Possibly some kind of Robonaut-like part for unkermanned repairs. It will be in Advanced Unmanned though.

Looking forward to seeing how 1.2.7 affects your results.

[Hotaru]

1 minute ago, Angel-125 said:

Mind if I bring those into the next BARIS update? I knew the patches I wrote wouldn't cover everything, but those should help.

Sure, no problem. I don't guarantee that's anything like a comprehensive list of leakable resources though.

 

1 minute ago, Angel-125 said:

Some things planned for the next update- I'm waiting to see when 1.3.1 drops-

• If all the resources on a tank are locked then it won’t be considered active.
• Base chance to eject tied to highest stupidity level, overridden by constants file?
• Separate quality ratings from condition summary.
• Engine activated fix- appears to be listed as active even when just idling and not actually burning.
• Possibly some kind of Robonaut-like part for unkermanned repairs. It will be in Advanced Unmanned 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.)

 

6 minutes ago, Angel-125 said:

Looking forward to seeing how 1.2.7 affects your results.

So am I!

[Angelo Kerman]

The more I think about this

1 hour ago, Hotaru said:

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!

*Sigh* We're just going around in circles now, so going forward:

• If you leave parts activated (engines ready to fire, RCS/SAS on, tanks unlocked), then they can wear down and break. If you want to survive interplanetary voyages, then deactivate your engines, turn off your SAS and RCS, lock your fuel tanks, etc. They won't be considered a failure candidate when checking to see what breaks. This is already in BARIS. It's the equivalent of what NASA does to put a deep space probe into a dormant state to conserve power, or putting a probe in the game into hibernation mode to reduce ElectricCharge use.
• De-activated parts will lose MTBF at a slower rate (1/10th normal) than activated parts- if they lost none at all, then the game would be too easy.
• There's a bug where parts are losing MTBF faster than they should; at default settings where checks are made 3 times per day, parts are losing 18 hours of MTBF per kerbal day instead of the intended 6.
• BARIS will watch for changes in fuel tank resources and make quality checks when resources are locked/unlocked.
• ModuleBreakableFueltank will gain an action group ability to lock/unlock all resources in the tank to make life a bit easier.
• Combine the above, and a locked tank, which normally lasts 600 hours, will last 6,000 hours- and that's not including the MTBF bonus you get from flight experience.

[Hotaru]

7 minutes ago, Angel-125 said:

*Sigh* We're just going around in circles now

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

[larkvi]

On 8/28/2017 at 11:18 PM, Angel-125 said:

Have you actually tried running a mission, or is this just an intellectual exercise? I'm at the point where I would like to see quantifiable data before listening to people complain that missions are too hard.

You will see a page or two above that I ran about ten missions (plus a number of test-bench launches with the same hardware), all with 100% failure rate to orbit (as well as the mod killing three of my kerbonauts in training, all in a short time span), so I am trying to understand what the actual play intent is. It seems that a critical component of quality is the manned bonus and the ability to repair, but for probes and other unmanned missions (I have an entirely unmanned program at the moment, with the first manned launches in the KCT build queue, but I currently have BARIS part failure off because it was making the game literally unplayable). So, that is why I want to know about intent and how your play style is informing your production. Do you only run manned missions, where there is a quality bonus and the ability to do repairs? Do you run hundreds of test fires before launching a single rocket? What is the intent?