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

[Geschosskopf]

21 hours ago, Angel-125 said:

Glad you're having fun. And good to see you back!

Good to be back, and glad to see you're still in the mod business.

I have a noob question, though.  I can't find a way to change BARIS settings in an on-going game like you can with Pathfinder.  I set the BARIS options before I knew what they all did and now want to go back and change some of them.  Is there an in-game way of doing this, or do I have to uninstall/reinstall the mod?

Also, I don't see command pods listed as a type of part that can fail, but I've seen it happen.  First, the pod sprung a leak on launch, then the pod itself exploded shortly after I staged the chutes at the end of the flight.  Also, when looking at pods in the VAB/SPH parts lists, it shows them having MTBFs of 600 hours.  So I'm thinking that pods are being treated as fuel tanks due to their built-in mono (or other types of fuel in some mod parts).  So I'm thinking you might want to add a check for MODULECommand and/or Kerbal capacity > 0 , so as not to blow up pods when folks aren't expecting it.

Personally, I kinda like having potentially explosive pods.  So if you do something that makes pods failure-proof, maybe you could add them to the list part types you can optionally have break/explode anyway

Finally, is it intended or usual for there to be some delay between a staging event and the part failures happening?  I'm seeing a few seconds delay in there.  For example, engines failing 100-200m up instead of on the pad, pods exploding after the chutes are fully deployed, etc.  I just want to know that these delayed failures are actually the result of staging or some other cause, to help me understand better what's going on.

If there IS an intentional delay between staging and failure, I like it because it creates false hopes   .  You hit the space bar, all looks well, and just as you're breathing a sigh of relief, BOOM!  Hehehe!  Only problem is, this makes it hard to capture the explosions in screeenshots because you never quite know when they'll happen.  But such is life

 

[Hotaru]

29 minutes ago, Geschosskopf said:

Also, I don't see command pods listed as a type of part that can fail, but I've seen it happen.  First, the pod sprung a leak on launch, then the pod itself exploded shortly after I staged the chutes at the end of the flight.  Also, when looking at pods in the VAB/SPH parts lists, it shows them having MTBFs of 600 hours.  So I'm thinking that pods are being treated as fuel tanks due to their built-in mono (or other types of fuel in some mod parts).  So I'm thinking you might want to add a check for MODULECommand and/or Kerbal capacity > 0 , so as not to blow up pods when folks aren't expecting it.

 

OK, I know I said you wouldn't hear from me again but seeing as this is actually kind of my fault: you're right, the MM patches check for any part with liquid fuel, monoprop or xenon resource containers, including pods. The relevant patch is this one:

 

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank]]:FOR[BARIS]
{
	MODULE
	{
		name = ModuleBreakableFuelTank
	}
}

 

To exclude command pods, I believe this version should work instead (I'm in the wrong OS right now to actually check):

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank],!MODULE[ModuleCommand]]:FOR[BARIS]
{
	MODULE
	{
		name = ModuleBreakableFuelTank
	}
}

 

PS. The patch in question is found in GameData\WildBlueIndustries\000BARIS\ModuleManagerPatches\MM_BARIS.cfg. 

Edited September 8, 2017 by Hotaru

[panarchist]

23 hours ago, Geschosskopf said:

I think you meant ROTFLMAO!    Seriously, this is hilarious.  I checked the "parts can explode" box and even leaving that at 1%, something seems to have blown up every launch so far.  I LOVE IT!!!  I managed to kill Jeb on my very 1st crewed launch when his Mk 1 pod exploded while floating down beneath his parachutes   Definitely Kerbal rockets are made of explodium.

I'm loving it too. In my case, I didn't do integration on anything. Which, when sending up rockets with 7-8 engines on the 1st stage creates some REALLY FUN ascents. My Saturn-V clone recovered from disaster but was only able to make it to LKO. I had to send a rescue mission with extra fuel and equipment to repair and refuel to get to the Mun.  It was awesome!

[JadeOfMaar]

I had a good deal of fun myself today. General KSP frustrations (for whatever reason) aside, here's my highlight. One of four upper stage SRBs + the lifter core engine suddenly failing... Even after waiting out an integration.

Edited September 8, 2017 by JadeOfMaar

[Pand5461]

@Hotaru is it possible to make any tank with non-zero-density resource breakable through MM patch?

And maybe add this to your last patch to allow tank failures on unmanned control parts

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank],@MODULE[ModuleCommand],#CrewCapacity[0]]:FOR[BARIS]
{
	MODULE
	{
		name = ModuleBreakableFuelTank
	}
}

 

Edited September 8, 2017 by Pand5461

[Hotaru]

@Pand5461 I don't know, I'm inclined to doubt it--since that would require checking in both the resource definitions and the part config at the same time, which I don't think MM can do--but I'm no expert. And I believe that patch would require ModuleCommand, and therefore would only work for probe cores. To make it work for both regular fuel tanks and probe cores, but still exclude kermanned pods and passenger cabins, I believe you'd want this:

@PART[*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleBreakableFuelTank],#CrewCapacity[0]]:FOR[BARIS]
{
	MODULE
	{
		name = ModuleBreakableFuelTank
	}
}

Although I'm not completely sure if that would work for parts where crew capacity is not specified. (Easy enough to find out, though.)

 

Again, I'm no MM expert. Do bear in mind those patches I wrote were little more than a quick-and-dirty fix to the problem of "category=FuelTank" failing to cover some of the stock parts. I suspect a more elegant solution than mine is possible.

[Pand5461]

@Hotaru I think there is no CrewCapacity field in plain tanks, so my idea is that your patch (which excludes anything with ModuleCommand) includes ModuleBreakableFuelTank for regular tanks, and my patch adds it to probe cores only.

And actually there are things like hitchhiker's containers that have no ModuleCommand but have CrewCapacity and can have resources.

Being no MM expert, I'm suggesting anyone concerned to deal with it

[Hotaru]

@Pand5461 Yes, as separate patches working together they should cover all cases. I don't think there are any stock parts that have both crew and fuel but no command, but there are undoubtedly mod parts, so a check for crew capacity is certainly a good idea.

Edited September 8, 2017 by Hotaru

[Geschosskopf]

3 hours ago, Hotaru said:

@Pand5461 Yes, as separate patches working together they should cover all cases. I don't think there are any stock parts that have both crew and fuel but no command, but there are undoubtedly mod parts, so a check for crew capacity is certainly a good idea.

Thanks for the info.

It seems to me that if folks don't want pods, probe cores, or passenger cans to fail, they'd need checks for both ModuleCommand and crew capacity > 0.  And that these checks would need to be added to patches for every type of resource to cover all mod parts and the user's own MM tweaks adding fuel to stock pods and cans.

That seems to be more trouble than it's worth.  What I recommend instead is putting a warning label on the set-up screen that says fuel tanks includes pods.  That way, folks would know that if they set fuel tanks to fail, pods might explode.  If that's too harsh for them, they can disable fuel tank failure.

[Norcalplanner]

For what it's worth, I've had a Mk 1 pod have the radio fail, start leaking electrical charge, and spontaneously explode at various times. I'm thinking of downshifting to an easier setting or two - even after I figured out integration, it still took me a long time to actually get out of the atmosphere successfully. RL play time is a consideration, so I don't want this to become too big of a time sink. Loving the music and cards, though.

Does anyone else have a really laggy mouse and clicker in the difficulty settings menu with this installed?

[JadeOfMaar]

1 hour ago, Norcalplanner said:

For what it's worth, I've had a Mk 1 pod have the radio fail, start leaking electrical charge, and spontaneously explode at various times. I'm thinking of downshifting to an easier setting or two - even after I figured out integration, it still took me a long time to actually get out of the atmosphere successfully. RL play time is a consideration, so I don't want this to become too big of a time sink. Loving the music and cards, though.

Does anyone else have a really laggy mouse and clicker in the difficulty settings menu with this installed?

Spot on. I'm considering unticking a few things too to spare more IRL play time for getting around. And I'm also getting overall input lag and lag when changing scenes and activating experiments. Furthermore a few parts occur several times in their given tech tree node. I suspect BARIS may still be doing a little too much.  That and I have Ven's.

[Geschosskopf]

7 hours ago, Norcalplanner said:

For what it's worth, I've had a Mk 1 pod have the radio fail, start leaking electrical charge, and spontaneously explode at various times. I'm thinking of downshifting to an easier setting or two - even after I figured out integration, it still took me a long time to actually get out of the atmosphere successfully. RL play time is a consideration, so I don't want this to become too big of a time sink. Loving the music and cards, though.

Does anyone else have a really laggy mouse and clicker in the difficulty settings menu with this installed?

I think one's attitude towards BARIS depends entirely on one's attitude toward the game.  Personally speaking, used to be I could NEVER imagine introducing malfunctions into my game.  I spent hours and hours carefully designing and testing ships for very ambitious missions and, after all that, the last thing I wanted was for anything to trip me up.  There was concern for all the invested effort, plus not wanting to fail in front of an audience if I'd been doing a mission reports thread.  But eventually, I decided this was boring.  By then I'd been there twice, done that backwards, and my projects simply marched to their inevitably successful conclusions because I had totally mastered building and flying rockets.  No drama at all, which makes for boring reading of reports.  So, taking cues from members with actual writing talent, I started introducing problems of my own devising, or rolling with bugs instead of reverting.  Drama requires uncertainty.  So I even sabotaged a huge expedition to Sarnus, despite pouring countless hours into making all the ships absolutely perfect.  I found I enjoyed this more, but thinking up my own disasters was as much work as designing the planned missions themselves, thanks to me having zero writing talent.  Thus, I appreciate BARIS for taking that load off my shoulders.  Now I can build yet another routine major expedition somewhere and can rely on BARIS to screw it up with no effort on my part.  Yay

Of course, I care nothing for Kerbal lives.  In my universe, astronauts are pressganged vagrants and convicts, essentially galley slaves.  Totally expendable.  Maybe that helps.  But even for folks with more conventional views, having the chance of having things go catastrophically wrong for no reason can be alluring.  I don't recommend it for beginners, or your 1st time to go anywhere, but once you've decided you need something more amusing, BARIS whill definitely do it.

[Just Jim]

10 minutes ago, Geschosskopf said:

But eventually, I decided this was boring.  By then I'd been there twice, done that backwards, and my projects simply marched to their inevitably successful conclusions because I had totally mastered building and flying rockets.  No drama at all, which makes for boring reading of reports.  So, taking cues from members with actual writing talent, I started introducing problems of my own devising, or rolling with bugs instead of reverting. 

This is also where I am.... I've gotten to the point I LOVE when a random glitch or bug throws a curve-ball into the mission. And I've gotten where I'll exploit one of these curve-balls any chance I can.

So yeah, BARIS sounds like all sorts of frustrating fun for my heroes. The only reason I still haven't turned it on is (minor Emiko spoiler) I've already staged the upcoming... situations... for the next couple chapters. After that I'll fire up BARIS and let the chips roll where they may.

[Geschosskopf]

8 minutes ago, Just Jim said:

This is also where I am.... I've gotten to the point I LOVE when a random glitch or bug throws a curve-ball into the mission. And I've gotten where I'll exploit one of these curve-balls any chance I can.

So yeah, BARIS sounds like all sorts of frustrating fun for my heroes. The only reason I still haven't turned it on is (minor Emiko spoiler) I've already staged the upcoming... situations... for the next couple chapters. After that I'll fire up BARIS and let the chips roll where they may.

See, one of the great writers even likes this

 

[Just Jim]

1 hour ago, Geschosskopf said:

See, one of the great writers even likes this

Oh, please... don't inflate my ego any more than already necessary... lmao....

But seriously, yeah, I love the idea of something potentially breaking at the worst possible time.

 

 

[Angelo Kerman]

BARIS is definitely meant for those who've been there, done that, read the book, watched the movie, played the video game...

Got to enjoy some downtime today in San Francisco- 40 degrees cooler than last weekend for the win. Anyway, the MM patches for fuel tanks need some work. Not sure of the coding, but maybe something to the effect of:

@PART[*]:HAS[@RESOURCE[*],![CrewCapacity > 0]]:FOR[BARIS]

Basically, all parts that have a resource in them that don have a crew capacity > 0. That might work...

I also have a pre-release up for a potential fix for an issue with KCT where, if you create a design and then launch it, the design won't benefit from flight experience or the Test Bench.

[drhay53]

2 minutes ago, Angel-125 said:

BARIS is definitely meant for those who've been there, done that, read the book, watched the movie, played the video game...

Got to enjoy some downtime today in San Francisco- 40 degrees cooler than last weekend for the win. Anyway, the MM patches for fuel tanks need some work. Not sure of the coding, but maybe something to the effect of:

@PART[*]:HAS[@RESOURCE[*],![CrewCapacity > 0]]:FOR[BARIS]

Basically, all parts that have a resource in them that don have a crew capacity > 0. That might work...

I also have a pre-release up for a potential fix for an issue with KCT where, if you create a design and then launch it, the design won't benefit from flight experience or the Test Bench.

I live in the Bay area and last saturday night at 1 AM it was still 89 degrees in my apartment....

[Norcalplanner]

3 hours ago, Geschosskopf said:

I think one's attitude towards BARIS depends entirely on one's attitude toward the game.  Personally speaking, used to be I could NEVER imagine introducing malfunctions into my game.  I spent hours and hours carefully designing and testing ships for very ambitious missions and, after all that, the last thing I wanted was for anything to trip me up.  There was concern for all the invested effort, plus not wanting to fail in front of an audience if I'd been doing a mission reports thread.  But eventually, I decided this was boring.  By then I'd been there twice, done that backwards, and my projects simply marched to their inevitably successful conclusions because I had totally mastered building and flying rockets.  No drama at all, which makes for boring reading of reports.  So, taking cues from members with actual writing talent, I started introducing problems of my own devising, or rolling with bugs instead of reverting.  Drama requires uncertainty.  So I even sabotaged a huge expedition to Sarnus, despite pouring countless hours into making all the ships absolutely perfect.  I found I enjoyed this more, but thinking up my own disasters was as much work as designing the planned missions themselves, thanks to me having zero writing talent.  Thus, I appreciate BARIS for taking that load off my shoulders.  Now I can build yet another routine major expedition somewhere and can rely on BARIS to screw it up with no effort on my part.  Yay

Of course, I care nothing for Kerbal lives.  In my universe, astronauts are pressganged vagrants and convicts, essentially galley slaves.  Totally expendable.  Maybe that helps.  But even for folks with more conventional views, having the chance of having things go catastrophically wrong for no reason can be alluring.  I don't recommend it for beginners, or your 1st time to go anywhere, but once you've decided you need something more amusing, BARIS whill definitely do it.

Oh, I like the mod plenty.  Just need to turn it down a little bit to suit my taste, which Angel-125 has so graciously made accommodation for.

Like you, I've been there and done that.  That's why my current career involves MKS colonization efforts in an upscaled version of GPP with stock parts... which introduces plenty of setbacks on its own, beyond what BARIS is dishing out.  Tellumo is a harsh mistress. :-)

[Geschosskopf]

1 hour ago, Angel-125 said:

...

@PART[*]:HAS[@RESOURCE[*],![CrewCapacity > 0]]:FOR[BARIS]

Basically, all parts that have a resource in them that don have a crew capacity > 0. That might work...

I also have a pre-release up for a potential fix for an issue with KCT where, if you create a design and then launch it, the design won't benefit from flight experience or the Test Bench.

The above MM line would still allow probe cores to explode, which I'm finding happens at least as often as pods (which seem to happen exactly as often as tanks and batteries).  So you might want to add having ModuleCommand, too.  I think you need both ModuleCommand (covers cores and pods) and crew capacity (covers passenger cans) to really prevent Kerbals from being mercifully killed instantly, instead of dying slowly and painfully from gradual life support depletion due to failures elsewhere .  But OTOH, if you blow the Kerbals to bits, then there's really no point in having them be able to repair malfunctions.

I've noticed some annoying glitches with BARIS as a whole.

#1.  Integrating a ship causes it to be saved with the same name it had before you put it into integration.  Thus, if you've saved your design before integration, you end up with 2 copies of it, both with the same name, one integrated and the other not.  I suggest having the save made by integration add a suffix to the craft name, such as "-INT" to show it's been integrated.

#2.  Changing a design AFTER you've integrated it totally spams you with "integration has failed" messages.  Each time you click on a part, or right-click on a part, or move a part, you get that same "Houston, we have a problem" sound and the "integration failed" message pops up.  This happens even if you rename the craft before you start editing it, which is very annoying.  The constant barrage of both sound and visual reminders that you're changing a previously integrated design causes mondo lag and eventually leads to game instability.  And the most annoying thing is, frequently need to make minor tweaks and improvements to existing designs, so you run into this problem all the time.

#3.  Sometimes you get a message "Has suffered another component failure" without telling you what part it's talking about.  Such as this:

--------------------

And please clarify something for me.....   On the pic above, you can see there were only 2 staging events, launch and dropping the 1st stage.  The malfunctions started 1:11 AFTER the 2nd staging event, then just chained from then on every few seconds.  I have normal malfunction checks only 1 time per day.  So what's causing all these problems?  The staging or the "normal" checks?  I really have no idea what's going on here, or whether this amount and frequency of malfunctions is intended.  This rocket had been integrated had 35/25 reliability.  All the parts on it had flown (and usually exploded) 4 or 5 times before at least, the probe core most of all.

 

25 minutes ago, Norcalplanner said:

Like you, I've been there and done that.  That's why my current career involves MKS colonization efforts in an upscaled version of GPP with stock parts... which introduces plenty of setbacks on its own, beyond what BARIS is dishing out.  Tellumo is a harsh mistress. :-)

Well, it's been about a year since I've messed with MKS but last time I touched it, it had a bad case of feature bloat.  Originally advertised as a fairly simple and abstract system, it by then had become so complex, with so many variables interacting in so many ways, and so little documentation, that it was impossible to figure out why nothing ever worked the way you thought it would.  And you spent your entire playtime tweaking settings on the various base modules trying to get something vaguely resembling stability out of the base.  Hopefully things have changed there in all this time, but if not, you for sure don't need to throw even more monkey wrenches into that with BARIS

[panarchist]

3 hours ago, Just Jim said:

This is also where I am.... I've gotten to the point I LOVE when a random glitch or bug throws a curve-ball into the mission. And I've gotten where I'll exploit one of these curve-balls any chance I can.

So yeah, BARIS sounds like all sorts of frustrating fun for my heroes. The only reason I still haven't turned it on is (minor Emiko spoiler) I've already staged the upcoming... situations... for the next couple chapters. After that I'll fire up BARIS and let the chips roll where they may.

Ditto - I haven't been everywhere yet, but I've done enough missions to be very experienced at rocket and station building, and once flew an Orion-powered explorer craft on an 11 year mission to Cercani (Other Worlds mod) - 7x10^12km away. (and yet I've never landed on Duna) Having things fail on the "perfect" rocket and needing to make do, or change plans, is pretty awesome. I started a new game with Pathfinder and the rest of that series of mods + Engineering Tech Tree.  First aircraft I built had the jet engine fail in a way it can't be shut off. Now the option is keep flying until I run out of fuel, or figure out some way to ditch/land slow enough to not die. I love it.

[smotheredrun]

4 hours ago, Just Jim said:

Oh, please... don't inflate my ego any more than already necessary... lmao....

But seriously, yeah, I love the idea of something potentially breaking at the worst possible time.

 

 

Angel needs to beg the Evil Empi... uh I mean merciful Disney for special permission to have (slightly Kerbalized) Lando yell that every time something breaks.

[Angelo Kerman]

@Geschosskopf Currently the mod checks for failures after each staging event and once per launch. So the first stage fires, the second stage fires, and one final check for the overall launch. I don't think the overall launch check is doing much for game play, and is leading to failures at the end of launch, so I will probably remove that check and stretch out the max time at which a staging check will occur. So what you see in the log is accurate, a failure check can occur a few seconds after the staging event and much later in the mission. With the new changes, it will be possible to complete a stage burn before the timer goes off, such as a separatron burn, but I think that's ok, because that check will roll into the current stage. It will look like the next staging event does a check sooner rather than later.

2 and 3 are bugs, but I also want to ensure that players don't mess with the design that they loaded from the bay. The intent is to just load the craft, stuff some victims into it, and launch. If you try to mess with the craft after integration it should warn you, though once should be sufficient.

1. Not sure what you're getting at, BARIS makes a separate file of the craft and works from that file when loading from the bay. You could then load a craft from the gam's load button and make further changes. Can you clarify?

[Geschosskopf]

3 hours ago, Angel-125 said:

@Geschosskopf Currently the mod checks for failures after each staging event and once per launch. So the first stage fires, the second stage fires, and one final check for the overall launch. I don't think the overall launch check is doing much for game play, and is leading to failures at the end of launch, so I will probably remove that check and stretch out the max time at which a staging check will occur. So what you see in the log is accurate, a failure check can occur a few seconds after the staging event and much later in the mission. With the new changes, it will be possible to complete a stage burn before the timer goes off, such as a separatron burn, but I think that's ok, because that check will roll into the current stage. It will look like the next staging event does a check sooner rather than later.

2 and 3 are bugs, but I also want to ensure that players don't mess with the design that they loaded from the bay. The intent is to just load the craft, stuff some victims into it, and launch. If you try to mess with the craft after integration it should warn you, though once should be sufficient.

1. Not sure what you're getting at, BARIS makes a separate file of the craft and works from that file when loading from the bay. You could then load a craft from the gam's load button and make further changes. Can you clarify?

Thanks for the info.

As to the craft file name issue.  Suppose you're building a ship.  It always has a name, even if it's just "Unnamed vessel", but for this example let's say I changed the name to "Basic Rocket", and that I saved the in-work design.  Thus, if KSP crashes or I have to go on a call, when I get back to the VAB, I can hit the VAB's "open" button and I'll see "Basic Rocket" on the craft file list.  OK so far?

Anyway, eventually I finish building "Basic Rocket", open the BARIS button, and put it in an integration bay. twiddle my thumbs for however long that takes, and go back to the VAB.  I hit the BARIS "Load" button, then the launch button, and off I go to death or glory.  But somewhere in the process of getting the rocket from integration to the pad, BARIS saves it, and it calls it the same name it already had.  This BARIS save of the integrated ship does NOT overwrite my previous pre-integration save.  Thus, at some future point, when I hit the VAB's "open" button, I'll see "Basic Rocket" listed twice.  In the VAB, BARIS treats both files the same---trying to edit either one results in the spam of "Integration failed" messages.  However, BARIS at the launch pad seems to be able to tell them apart.  One will launch no problem, the other will say"This vessel hasn't been integrated"  This is why I wish the save made by BARIS had a different file name, like with "-INT" added to the end, so EDIT I'd both myself and BARIS would know which was integrated and which wasn't.

So say in the future I want to tweak the design of "Basic Rocket".  I hit the VAB's "open" button and see "Basic Rocket" and "Basic Rocket-INT".  I leave "Basic Rocket-INT" alone, but I should be able to do whatever I want to plain "Basic Rocket" without BARIS noticing.  So I tweak it, name it "Basic Rocket Mk 2", integrate it, and get "Basic Rocket Mk 2-INT", and so on, all without BARIS complaining.

Edited September 9, 2017 by Geschosskopf
clarification

[RobertJPowell]

This was exactly what i was looking for in a failures mod - Difficult yet customisable on just how difficult. Thanks so much. - This is forcing me to really test everything, including unmanned tests of my major rockets... It's just brilliant. Love the fact that it is possible that sometimes you'll have such systemic failures that even the LES won't save you XD

[Angelo Kerman]

3 hours ago, Geschosskopf said:

Thanks for the info.

As to the craft file name issue.  Suppose you're building a ship.  It always has a name, even if it's just "Unnamed vessel", but for this example let's say I changed the name to "Basic Rocket", and that I saved the in-work design.  Thus, if KSP crashes or I have to go on a call, when I get back to the VAB, I can hit the VAB's "open" button and I'll see "Basic Rocket" on the craft file list.  OK so far?

Anyway, eventually I finish building "Basic Rocket", open the BARIS button, and put it in an integration bay. twiddle my thumbs for however long that takes, and go back to the VAB.  I hit the BARIS "Load" button, then the launch button, and off I go to death or glory.  But somewhere in the process of getting the rocket from integration to the pad, BARIS saves it, and it calls it the same name it already had.  This BARIS save of the integrated ship does NOT overwrite my previous pre-integration save.  Thus, at some future point, when I hit the VAB's "open" button, I'll see "Basic Rocket" listed twice.  In the VAB, BARIS treats both files the same---trying to edit either one results in the spam of "Integration failed" messages.  However, BARIS at the launch pad seems to be able to tell them apart.  One will launch no problem, the other will say"This vessel hasn't been integrated"  This is why I wish the save made by BARIS had a different file name, like with "-INT" added to the end, so EDIT I'd both myself and BARIS would know which was integrated and which wasn't.

So say in the future I want to tweak the design of "Basic Rocket".  I hit the VAB's "open" button and see "Basic Rocket" and "Basic Rocket-INT".  I leave "Basic Rocket-INT" alone, but I should be able to do whatever I want to plain "Basic Rocket" without BARIS noticing.  So I tweak it, name it "Basic Rocket Mk 2", integrate it, and get "Basic Rocket Mk 2-INT", and so on, all without BARIS complaining.

Ok, I can look into this and see what can be done. Vehicle Integration is pretty tricky...

Meanwhile, I have a pre-release that reworks the MM patches. I cleaned up all the patches for parts with individual resources- that's not practical for all possible resources- and replaced them with a generic one. I've also excluded parts that have ModuleCommand, so probe cores, command pods, and cockpits won't develop failures. I have to figure out how to set things up so that command pods/cores/cockpits can optionally fail, but for now, they're safe.

You can download the pre-release here.