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

[panarchist]

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

I ran into #2 with one of my designs, and totally thought I was doing integration incorrectly. I gave up trying to rescue that design and just flew it as-is and called it "cursed".

Is there any way to exempt certain designs from BARIS? Perhaps the stock ships? My thought on this is that many space programs "inherit" legacy vehicles from other places, like the Air Force or possibly civilian aircraft designs. It would be cool to be able to do something like that, to simulate getting a mature design from somewhere else. Or possibly that could be an event card, I don't know.

BTW, the Tiger Team idea was really cool - haven't used one yet since I am playing a career game and haven't earned enough Funds yet. (not willing to give up my science until I can build my first airship)

[darloth]

I had a bug where all my VAB workers vanished into nothing.

 

I couldn't reproduce it, but I think the start of the problem was doing a Revert To VAB on an integrated craft.

Edit: Further details, think I've reproduced this now - Using version 3.0b, if I set all workers working to integrate a craft in the VAB, then exit the VAB, wait until integration is complete, go back into the VAB, get the message that the craft has changed (it hasn't) so I need to reload, do NOT reload, go to the pad, check that the vessel is not integrated, but then revert to VAB - THEN, all my workers will have vanished and the integration will have reset to 0.

 

Unrelated, as a feature request can I launch from the space center instead of the VAB please? There's already an integrations list, and the transition loading time is quite significant.   Even if the launch bay showed me somehow (probably via name) which version was the integrated one as a poster mentioned above, that would be a big help.

 

While I like the idea of the vehicle integration in this mod, it's still slightly finnicky.  I might end up using KCT just to see if that results in more reliable integrations that don't get lost if I do things in the wrong order.

Edit: Seems to work better with KCT, and that also allows me to launch from the space center.  Of course, things still break a lot, but that's working as intended

Edited September 11, 2017 by darloth

[Angelo Kerman]

9 hours ago, darloth said:

I had a bug where all my VAB workers vanished into nothing.

 

I couldn't reproduce it, but I think the start of the problem was doing a Revert To VAB on an integrated craft.

Edit: Further details, think I've reproduced this now - Using version 3.0b, if I set all workers working to integrate a craft in the VAB, then exit the VAB, wait until integration is complete, go back into the VAB, get the message that the craft has changed (it hasn't) so I need to reload, do NOT reload, go to the pad, check that the vessel is not integrated, but then revert to VAB - THEN, all my workers will have vanished and the integration will have reset to 0.

 

Unrelated, as a feature request can I launch from the space center instead of the VAB please? There's already an integrations list, and the transition loading time is quite significant.   Even if the launch bay showed me somehow (probably via name) which version was the integrated one as a poster mentioned above, that would be a big help.

 

While I like the idea of the vehicle integration in this mod, it's still slightly finnicky.  I might end up using KCT just to see if that results in more reliable integrations that don't get lost if I do things in the wrong order.

Edit: Seems to work better with KCT, and that also allows me to launch from the space center.  Of course, things still break a lot, but that's working as intended

As I've mentioned before, loading and launching from anywhere except the VAB/SPH would prevent the ability to fill your vessels with crew. I currently don't have a solution for this. KCT has its own way of getting around this problem, but it's extensive and will take time to do something similar in BARIS.

1.3.9.2 PRE-RELEASE is now available:

- Removed overall vessel reliability check that was set up during launch; it wasn't doing much except causing people to complain that their launches failed near the end of their flight to orbit.
- Fixed vessel modified spam that occurs when you attempt to modify a vessel after it has been integrated.
- Vessel integration completed dialog no longer shows integration bays that are empty.
- Edited vehicle integration status messages to improve clarity.
- Fixed missing title in "Has suffered another component failure" message.

[plausse]

I will start playing ksp again when I'm done with being busy. When I do BARIS is the thing that excites me the most. 

Thanks 

[darloth]

Sorry, didn't see the previous post about needing the VAB/SPH for crew - but I didn't read all the middle pages of the thread either, so that's on me.  Okay then, fair enough on the loading and launching from there.  Hopefully one day it'll be easier to set up somehow, but this is fine for now, it's mostly only a big issue early in career when you want to launch a lot of small things and are really just waiting for one craft at a time.

Edit: There was a potential issue here, but it seems to have solved itself in the latest version, so I've removed it.  If you're still interested, the text can be found here: https://pastebin.com/VmM1Lqec

Additional failure modes for engines (primarily limited thrust or gimbal lock) would be lovely, since currently they mostly just shut down completely which isn't much fun.  I wonder whether individual engines from a single-part-multi-engine cluster suffer failures individually?

 

Another suggestion, if you ever get the time, perhaps it's worthwhile making an integration with KRASH and any other simulation mods where, if it's possible for you to do so, you can choose to not suffer (or just flat out never suffer) part failures in simulations?  They don't add much in my opinion to a feasibility sim, and seem to be constant across simulation reruns though I didn't do enough testing to confirm that.  Either way not a big priority, but a nice to have.

Edited September 11, 2017 by darloth

[Benjamin Kerman]

For the MM patches on the last page: 

I belive you might be able to do something checking if it has a RESOURCE node, and then maybe do something checking against engine propellents to make sure it is a propellant. 

[Geschosskopf]

22 hours ago, Benjamin Kerman said:

For the MM patches on the last page: 

I belive you might be able to do something checking if it has a RESOURCE node, and then maybe do something checking against engine propellents to make sure it is a propellant. 

I dunno.  Non-propellants should cause problems.  EC isn't a propellant but batteries should explode sometimes.  After all, the Kerbals no doubt got all their batteries from hoverboards and Galaxy Note 7s  

Also, ablator.  I've recently seen heat shields spring leaks and/or explode.  But that's cool.  We all remember tiles falling off the shuttle, which accounts for leaks, and if the heat shield explodes, that's the same result as if the jettison mechanism fired prematurely.  And hey, what's more Kerbal than making a heat shield out of an explosive material  

Then there are, of course, all the other non-propellant resources for crafting, life support, etc.  However, why shouldn't all those tanks spring leaks?  Plumbing is plumbing.  And things only explode if you check that box in settings.  Since we're not discussing realism in a game with little green men, there's no problem with tanks of dirt, slag, and such exploding if you have them set to   However, I can understand some folks not being able to deal with that conceptually, so perhaps in the future catastrophic failure could be selected for specific resources instead of being blanket.

[Angelo Kerman]

On 9/12/2017 at 7:03 AM, Benjamin Kerman said:

For the MM patches on the last page: 

I belive you might be able to do something checking if it has a RESOURCE node, and then maybe do something checking against engine propellents to make sure it is a propellant. 

 

5 hours ago, Geschosskopf said:

I dunno.  Non-propellants should cause problems.  EC isn't a propellant but batteries should explode sometimes.  After all, the Kerbals no doubt got all their batteries from hoverboards and Galaxy Note 7s  

Also, ablator.  I've recently seen heat shields spring leaks and/or explode.  But that's cool.  We all remember tiles falling off the shuttle, which accounts for leaks, and if the heat shield explodes, that's the same result as if the jettison mechanism fired prematurely.  And hey, what's more Kerbal than making a heat shield out of an explosive material  

Then there are, of course, all the other non-propellant resources for crafting, life support, etc.  However, why shouldn't all those tanks spring leaks?  Plumbing is plumbing.  And things only explode if you check that box in settings.  Since we're not discussing realism in a game with little green men, there's no problem with tanks of dirt, slag, and such exploding if you have them set to   However, I can understand some folks not being able to deal with that conceptually, so perhaps in the future catastrophic failure could be selected for specific resources instead of being blanket.

I probably need to exclude Ablator from the breakable fuel tank patch, it already excludes ElectricCharge. The breakable fuel tank module is designed to cover all kinds of resources, but unless you want to add a MM patch for every conceivable resource, "Fuel tank" has to cover anything that stores a resource. Adding a MM patch for every resource is definitely impractical, so I'll likely change the wording on Fuel Tank to Resource Container.

For catastrophic failures, I may need to make a change so that the quality control module can query the breakable modules to see if they can explode. Then I can make a blacklist for breakable fuel tanks; if all of the resources they hold are on the blacklist, then they can't explode.

I can see it now...

Breakable fuel tank: Sir! Permission to explode, Sir!

Quality Control Module: What resources do you carry?

Breakable fuel tank: Sir! EnrichedUranium, Sir!

Quality Control Module: Oh hell yes, permission granted!

Edited September 13, 2017 by Angel-125

[Benjamin Kerman]

With things like electricity, i think it would be a good idea to have faliure modes for the batteries and heat sheilds too. 

With batteries, the charge they can hold can decrease, or they can loose charge randomly due to "shorts" in the system. If there is a short, maybe pick a random part and add some heat to it. 

For heat shields, maybe give them a "crack" where the heatsheild gets more heat or is less resistant to it. There might also be badly manufactured ones, where the ablator isnt the same thickness or something like that. 

EDIT: I might be able to try my hand at this, if you are willing to help me out a little!

Edited September 13, 2017 by Benjamin Kerman

[Angelo Kerman]

51 minutes ago, Benjamin Kerman said:

With things like electricity, i think it would be a good idea to have faliure modes for the batteries and heat sheilds too. 

With batteries, the charge they can hold can decrease, or they can loose charge randomly due to "shorts" in the system. If there is a short, maybe pick a random part and add some heat to it. 

For heat shields, maybe give them a "crack" where the heatsheild gets more heat or is less resistant to it. There might also be badly manufactured ones, where the ablator isnt the same thickness or something like that. 

EDIT: I might be able to try my hand at this, if you are willing to help me out a little!

The more breakable modules you add to the game, the slower the game will get. The recent change to the fuel tanks MM patch now adds a breakable fuel tank module to every part that holds a resource, which is why I'm trying to limit it. Originally I only added the module to parts in the Fuel Tank category, but thanks to how Squad created some tanks, they aren't defined in the fuel tank category. For example, the stock Kerbodyne S3-7200 Tank is defined under Propulsion, not Fuel Tank. That's what created this whole mess in the first place.

Also, for batteries, there are many parts that contain ElectricCharge and aren't batteries- the Buffalo Command Cab, for instance, or the stock Mk1 pod, both have ElectricCharge and thus could be considered as a battery. And you can bet that if you have a command pod that has a battery in it, people will wonder why their pods start exploding.

BARIS isn't designed to be the ultimate part failures mod. It is there to have enough parts that make a difference in missions to fail, but not every possible item. Yes, you could add all kinds of things- wing surfaces, control surfaces, and the like- and mods like DangIt do that- but you're just asking for your game to slow to a crawl at that point. If you're looking for something more detailed, you'll probably want to look elsewhere.

Edited September 13, 2017 by Angel-125

[Benjamin Kerman]

Yeah, I see what you mean. There could be a MM patch to limit the command pods, but it just gets long and nasty, with all the different exeptions. I mean, there are some generalizations, but people start complaining "why isnt this blowing up", or "why is this not wehn it should". You just get more and more patches. 

The game slowing issue could be big, but i dont know how much of a difference it really makes. Would 2 or 3 more part modules really make a difference? For that matter, do MM patches make a big difference either? (Asking out of ignorance, not to try to get you do do anything differently). 

Thank you for humoring me on this suggestion, and feel free to ask me if you would like my help implementing it (if you decide to).  

[linuxgurugamer]

Module manager patches slow down the startup of the game, but they don't slow down the game running itself. The Only Exception would be if a patch ads a expensive module to every part. Expensive in terms of CPU time.

[Angelo Kerman]

I've minimized the CPU usage as much as I can, including using coroutines to help with the appearance of responsiveness, but I can only do so much...

[Geschosskopf]

4 hours ago, Angel-125 said:

I probably need to exclude Ablator from the breakable fuel tank patch, it already excludes ElectricCharge. .....

For catastrophic failures, I may need to make a change so that the quality control module can query the breakable modules to see if they can explode. Then I can make a blacklist for breakable fuel tanks; if all of the resources they hold are on the blacklist, then they can't explode.

 

3 hours ago, Angel-125 said:

The more breakable modules you add to the game, the slower the game will get. The recent change to the fuel tanks MM patch now adds a breakable fuel tank module to every part that holds a resource, which is why I'm trying to limit it. .......

Also, for batteries, there are many parts that contain ElectricCharge and aren't batteries- the Buffalo Command Cab, for instance, or the stock Mk1 pod, both have ElectricCharge and thus could be considered as a battery. And you can bet that if you have a command pod that has a battery in it, people will wonder why their pods start exploding.

BARIS isn't designed to be the ultimate part failures mod. It is there to have enough parts that make a difference in missions to fail, but not every possible item. Yes, you could add all kinds of things- wing surfaces, control surfaces, and the like- and mods like DangIt do that- but you're just asking for your game to slow to a crawl at that point. If you're looking for something more detailed, you'll probably want to look elsewhere.

Well...........  My feeling is, if you install a malfunction mod at all, you're totally cool with it killing Kerbals, utterly ruining meticulously crafted missions, and even without such disasters still ramping up the grind level of your game.  If you don't want that, then don't install a malfunction mod.  Period, end of story.  I wouldn't be using BARIS if I was afraid of any of the above happening; thus, I'm not very enthusiastic about neutering it.  Bring on death and mayhem!  Kerbals are in "seemingly inexhaustible supply" by the game's own wiki pages, so if we don't cull the herd, they'll reach Malthusian overload and the species will go extinct.  None of us want that, so GO KILL SOME KERBALS to save the rest

However, I understand about widespread malfunction checks killing the game.  The easiest way to solve that problem, and to kill Kerbals, is to go for decapitation strikes.  Make pods, cockpits, and  probe cores the ONLY things that can fail (ModuleCommand) :  I mean, they all have lithium-ion batteries of dubious Khinese origin and the kerbaled parts also require various tanks of highly compressed and often flammable and/or oxidizing gases, too  What could go wrong there?   And make no bones (figuratively---you'll be making plenty literally) about this.  "If you install BARIS, Kerbals WILL die.  Don't whine about it when it happens.,  Nobody cares.  Suck it up and soldier on."  Have that in big red letters all over.

That said, if the purpose here is to make meaningful malfunctions, none of the crafty resources should be bothered.  There's more where they came from and drill/ISRU failures can cover that.  The things that kill missions are failures of ModuleCommand, failures of dV (whether due to fuel or engine failures), failures of communications, and failures of electricity.  Nearly everything else you can roll with, and arguably you can often roll with fuel failures as well. So IMHO parts with those functions should be the priority targets.  Given that there are countless mod-introduced fuels and most of them are available in the field via ISRU, maybe not worrying about any of those would be fine.  But EC storage should be way up on the failure list---catastrophic battery failure has caused airliners to crash, after all.  And antenna failure is the main reason for loss of communications.  Oh, and capsules have both, plus self-igniting, pyrophoric monopropellant, plus compressed cabin air, plus Kerbals playing with matches.  Then engines should fail in several ways, either less ISP intermittant thrust (as opposed to reduced) or not work at all.  Gimbal failures are harmless because nobody should use gimbals anyway.

Edited September 13, 2017 by Geschosskopf

[Angelo Kerman]

Coming soon:

I think I've got a way to let command pods and parts with crew capacity to fail. If those options are unchecked, they override other breakable components.

[Geschosskopf]

8 hours ago, Angel-125 said:

Coming soon:

.....I think I've got a way to let command pods and parts with crew capacity to fail. If those options are unchecked, they override other breakable components.

Yay!

Is there a way to access the settings screen from an on-going game, so you could change settings if you don't like what you picked initially?  I can't find a way to do this.

[Benjamin Kerman]

3 minutes ago, Geschosskopf said:

Yay!

Is there a way to access the settings screen from an on-going game, so you could change settings if you don't like what you picked initially?  I can't find a way to do this.

Yes there is. I belive it is in the escape menu. 

[Angelo Kerman]

BARIS 1.3.9.3 PRE-RELEASE is ready for testing:

- Removed quality checks that happened when a fuel tank was emptied or filled to capacity- it was causing spam upon vehicle load.
- Timers are now reset when you activate or deactivate BARIS to prevent reliability check spamming when you leave BARIS off in your save for long periods of in-game time.
- In the options screen, clarified that any part that stores resources, not just fuel tanks, can spring leaks and fail.
- Add ability to customize the ModuleBreakableFuelTank leak messages.
- Parts with the Ablator resource now have more appropriate resource leak messages.
- Added option to allow command pods, cockpits, and probe cores to fail. If unchecked, they will never fail (overriding other breakable components).
- Added option to allow parts to fail if they have crew capacity. If unchecked, a part with crew capacity will never fail (overriding other breakable components).
- Command pods, cockpits, and probe cores are no longer excluded from part failures- unless they're not allowed to fail.
- Experimental: Parts with ElectricCharge can now fail.

[RobertJPowell]

Gonna have to start a new space Program and give it a whirl

 

Edit: Sadly not got any logs but going to dig. Turned on Baris having over written my previous BARIS install with the indev version above. All the options are there BUT it doesn't seem to be functioning fully in game (no random events..) I'll get a log report once I've played around some more.

Edit 2: So updating WBT to 1.2.7 fixed my issues

Edited September 14, 2017 by RobertJPowell

[Pand5461]

@Angel-125 is it possible to control separately explosive potential and failures in .cfg?

E.g., I'd want tanks to never leak but have a chance to explode, and command parts to never explode but have a chance of reaction wheels malfunction.

[Angelo Kerman]

6 minutes ago, Pand5461 said:

@Angel-125 is it possible to control separately explosive potential and failures in .cfg?

E.g., I'd want tanks to never leak but have a chance to explode, and command parts to never explode but have a chance of reaction wheels malfunction.

At the present time, that's not possible. Explosions are tied to part failures as one possible outcome.

[ThatOneBritishGuy...]

Is integration with Kerbal Krash Systems possible? Seems like these two mods should go hand in hand.

[Angelo Kerman]

7 minutes ago, ThatOneBritishGuy... said:

Is integration with Kerbal Krash Systems possible? Seems like these two mods should go hand in hand.

Not planned at this time, sorry. Perhaps in a future update once my other projects are further along.

Saw this video today, very appropriate for BARIS:

 

[Geschosskopf]

9 hours ago, Angel-125 said:

BARIS 1.3.9.3 PRE-RELEASE is ready for testing:

- Removed quality checks that happened when a fuel tank was emptied or filled to capacity- it was causing spam upon vehicle load.
- Timers are now reset when you activate or deactivate BARIS to prevent reliability check spamming when you leave BARIS off in your save for long periods of in-game time.
- In the options screen, clarified that any part that stores resources, not just fuel tanks, can spring leaks and fail.
- Add ability to customize the ModuleBreakableFuelTank leak messages.
- Parts with the Ablator resource now have more appropriate resource leak messages.
- Added option to allow command pods, cockpits, and probe cores to fail. If unchecked, they will never fail (overriding other breakable components).
- Added option to allow parts to fail if they have crew capacity. If unchecked, a part with crew capacity will never fail (overriding other breakable components).
- Command pods, cockpits, and probe cores are no longer excluded from part failures- unless they're not allowed to fail.
- Experimental: Parts with ElectricCharge can now fail.

Sounds wonderful

[Tyko]

I installed 1.3.9.3 Pre-Release and found a couple of bugs in the vehicle integration screen of the VAB

1. I'm playing science mode so have 4 bays. The integration dialog box didn't resize to show all 4 bays. It's narrow enough that I can only see about 1.8 bays and the remaining require scrolling to the right.
2. I can't add workers. It says I have 0/50 workers but when I press the "+" button it doesn't increase the number of workers. It stays at 0

Thanks for working on this! It's really cool!