[KSP 1.0.X] Kerbal Mechanics: Part Failures and Repairs v0.6.4.1

[Vladthemad]

Ha! Well, you could say it was excitement, or laziness. I read through some of the posts on the first page of the thread and then clicked the reply button. I didn't realize there were only three pages to the thread though! XD

Couldn't you make that work with module manager? It's been awhile since I monkeyed with MM, but isn't that what it's for?

Edited August 1, 2014 by Vladthemad

[IRnifty]

Couldn't you make that work with module manager? It's been awhile since I monkeyed with MM, but isn't that what it's for?

Due to the delicate way I had to handle failure functionality, my mod requires a little more than what MM can offer, so I wrote my own custom module injector that works in a similar fashion, but more specific to my mod. But with a list of mods to work with, I can easily set the mod to automatically add failures to mod parts with stock modules. To add failures to custom modules, I'd need to write brand new failure modules, which is fine, but that's not my current focus.

[soranno]

Hello again, I`ve come upon another issue I`d like to check with you.

Incidentally, I`ve had very positive experiences with engine failurs (what an odd thought) since moving away from using lv-t45s, with apparently nice balance in the ignitor failures of mainsale, skippers and the smallers 48s and such.

But anyway, having some issues with the thrust gauges becoming stuck in pods. This has occured several times now upon the act of undocking. Is there a specific trigger making that failure prone to occur on undock?

Be that the case or not, the failure is not repairable! Upon evaing a kerbal over there with spare parts all options appear in the right click menu except for the one to repair the broken gauge.

My Kerbals will soldier on to their Mun landing without a functioning gauge anyway, brave guys, but I assume this is unintended and should be repairable. If there is any further information I can supply to assist in correcting this issue, please let me know

Also, while I think of it, this mod`s `Bash decoupler` functionality just saved my very expensive science ship from an unrelated docking port clipping error! With a spent stage clinging to my ship, and unable to control the decoupler anymore, it was without doubt that ability that saved the day Unexpected bonus

[IRnifty]

Thanks, soranno, for your continued feedback. I think it's hilarious that you have so many problems with the T45's and claim good balance on all other engines. Fun fact: they all use the same numbers, so I still find this very strange. I've gone over it and have found nothing changed out of the default.

Now about that thrust gauge issue. I think the issue is that undocking might produce a short lived, yet extremely drastic, spike in g forces, but that will have to be tested. So does this happen with both vessels being undocked, or just the one you control immediately after the undock? Does it happen rarely, commonly, or every time? Lastly, how many command parts do you have on the docked vessel combined, and how many on the undocked vessel afterwards?

Last thing. You say the bash saved your ship. When you used that option, had you already used the decoupler? Because if it's been used, you're not supposed to be able to bash it to produce any explosion.

[soranno]

It is bizarre, but perhaps I was just a victim of chance using 45s, but I was getting failures every flight on a second or third ignition. Comparing that with other engines, I`ve still never seen a 909 failure (other than the odd one after I had already dropped the engine) and using multiple 24-77s on one ship, and over dozens of restarts have seen only one or two failures of single engines.

I will test some 45s into the ground and get some answers

The thrust gauge, each occasion was similar in ciscumstance, and 75% of undocks have seen the failure. On all occasions there was one command pod on each vessel, thus two combined separating into one each. The failure occurs in the pod of the ship I have undocked from. That is to say, I`ve undocked, and receive the failure popup regarding the pod on the other vessel.

Each time I have been undocking with a mk1-2 3 man pod, however the failing pods have been both mk1-2 and mk1 lander cans.

Looking at the ship in the VAB, I can also see that there is an advanced inline stabilizer between the pod and docking port. Perhaps that has been playing a part.

EDIT, after extensive testing at the launchpad, under hacked gravity conditions I must revise the estimate of failure rate to 40%, noting that in a sample of about 100 tests there was one occasion of 22 consecutive successful undocks. Testing also essentially confirmed the role of the advanced inline stabilizer in the failure, the ship design altered to remove that part could not replicate the failure in testing. The failure rate therefore doesn`t seem to be too much of an issue, however the condition persist that the failure is not repairable

As to the bashing decoupler episode, on this occasion the decoupler had not been activated, but was part of a vessel that had no command parts at the time, and rather than exploding, the bash triggered a standard separation. However, I have since tested a bit on the launchpad, and following both successful decouplings, and part failures, the bash decoupler option is still available, and spamming it causes an explosion.

Edited August 5, 2014 by soranno
updated information

[IRnifty]

Wow, soranno. Can I hire you as QA for my game? You give very good answers. I'll check these things out later today and come back with news.

[IRnifty]

Updated! Version 0.4.1 Alpha:

Changelog:

- Fixed the inability to fix the Altimeter and the Thrust Gauge.

- Fixed the Alternator fix action saying "Fix Altimeter" instead of "Fix Alternator".

- Fixed being able to perform additional actions on a spent decoupler.

- Changed Maintenance context action to read "Maintain <Module>" instead of the generic "Perform Maintenance".

- Changed the ship color map such that a part with a failed module will always appear red, regardless of the average reliability.

[soranno]

Well done on the update, and thank you for continuing support of this great mod.

I have managed to recreate the failures in question in test conditions and could successfully repair them, however it seems that either because the ships were launched before the update, or the failures occurred before the update, but those ships affected by the failures in service remain unrepairable ~ perhaps unavoidable. Anyway, new ships are unaffected.

I might just edit the persistence file to remove the failure from them this time, and let them naturally fail again

Edit: My attempt to edit the persistence file was successful, I was able to activate the repair altimeter button in the gui, and then make the repair in game

I`m reminded of another issue, albeit one that I think is unavoidable. When you board a pod while carrying rocket parts, those parts are lost forever, as naturally enough there is no place in the pod for those parts to go. Maybe the simplest option is a warning upon trying to board the pod that carried parts will be lost?

Not really sure how helpful or otherwise my answers are being just hoping to support as best I can without being a pest, hah! But by all means if there was anything else you could use my input on

Edited August 6, 2014 by soranno

[IRnifty]

No, don't worry! You're being extremely helpful. Indeed, old ships have a problem with new module functionality. They just don't pick up new actions well, and tend to hold on to changes or removals. Quite unavoidable.

And the rocket parts deal, also a problem. I would display a warning, if I knew how to. It's not easy intercepting default functions, but I'll give it a look some time.

[Sigmar]

Hi, love the idea, since that makes the whole space exploration a bit more risky. Just two questions:

1. Where do I get the rocket parts for repairs? Is there a container or something like that for them? Or do I have to install Interplanetary Launchpads?

2. Could you make the decoupler a bit more reliable? Feeled 99% of the time they don't work.

And last, another thought: Would it be possible to get technology and the times you build a part as a factor into the reliability? When stuff is new and experimental it tends to break somewhat regular, but as technology moves on and you build it more often it becomes kinda more solid. That would emphase the difference between a prototype and a mass produced, established production series.

[thrandisher]

Hmm, did my first flight with this and i swear the rocket was a broken toy from jebs childhood, lol. Makes for a interesting time.

@sigmar i looked in the resrouces directory and theres a cfg named, RocketPartsFromExLaunchpad.cfg so im guessing from that.

[IRnifty]

Sigmar, I've included the rocket parts resource from Extraplanetary Launchpads into my mod, such that you don't need Ex Launchpads, but you can have it, and my repairs will work with it. In the Utilities category, there is a container that looks like it came from Kerbal Attachment System. That's because it did. It's a placeholder part until I've completed the core of the mod and can move onto making the containers.

And about the failures, I honestly don't understand how everyone is encountering failures so much. I put some really low random chances in there and haven't encountered many failures myself without cheating them in. Are they genuinely too common, or are you guys going on the cheap with your parts? Oh well, they can't be too rare...

Thanks, both of you, for your interest and feedback. It really helps.

Edited August 7, 2014 by IRnifty

[thrandisher]

When i have more time in a few day's ill get some play time in and see how it goes. I only did the 1 flight and had 2 different part failures. 1 was a tank during launch, then a leak on a tank just before i hit Mun. I thought it was great since i had to jump out and toss on some duct tape real fast, lol.

[soranno]

That reminds me, although I had intended to mention it many times and forgot, the rocket parts container doesn`t have any entry in the tech tree. Easy enough to put it in somewhere, but maybe that being added at source might clear up that point with a few users.

So, I experienced my first ever tank failures (was there any change made to those in the recent update?)

It was quite an interesting failure.. on an unmanned com satellite (naturally) with 4 round monoprop tanks, and one 50 unit stack monoprop tank. I was in time warp, moving between 100x and 1000x, when suddenly the warp was terminated and all 5 tanks failed at exactly the same moment I was quite taken aback, as you might imagine. One of my stream viewers saw fit to suggest the `ruskies` were testing their space rifles.

However, shutting off the fuel flow stopped the leaks. After that I throttled up the engines and used the fuel flow control for the stack tank like a throttle control. You can see the moment of failure at the start of this video clip ( and how I used the tank flow control to stop the leaks)

http://www.twitch.tv/hoshizora/c/4844042 (language warning, sorry just a bit at the start)

About the decouplers. I think it`s fair to say I see 50% failure on stack decouplers of all kinds. That said, they have the failsafe of just spamming decouple until they explode so it doesn`t really bother me. I just live in fear of engine failure on landing but the engines I use for landings have proven very reliable (24s and 48s, also 909)

Just stay away from me with those 45s. I don`t care if it`s buy one get one free, or double points Tuesday, nothing doing!

[Sigmar]

Thank you, but I really can't find that container. That's strange, but maybe I just don't see it an that chaos that is my utility page^^

Anyway, regarding the decoupler...

Yeah, I wanted to know how often they would fail. That are 95 TR-18A Stack Decouplers. Kerbal Mechanics version is 0.4.1, just to make sure that I used the actual one.

After some right-click -> Decouple madness I can say that 50 of those decouplers failed, 45 worked, so let's say roughly 50% failed, which is pretty much the failure rate it shows. But that's a bit to much, at that point I would change my supplier, especially since that is the standard quality ^^

With every second decoupler failing, chances are that you encounter problems with the decouplers at least once, but probably even more often, per mission. That is especially annoying with a part that:

1. Can't be repaired (single use item)

2. Is absolutely vital not only for the rocket staging, but also for the escape system some people build (or at least I build)

That's why I feel like encountering those damn decouplers way to often *lol*

[IRnifty]

I see your concern. I'll hotfix the decouplers and reduce their chances. And soranno, all tanks at once? As in they all glowed red? Or was it one tank leaking and cross feeding from the others? Can you test if its possible to stop a single tank's leak by stopping its crossfeed?

[soranno]

aHA! Nice catch! It is just the one tank, and the leak is draining all tanks.

Disabling the crossfeed of the one tank does not stop the leaking, all the other healthy tanks continue to drain fuel into (and out of) the leaking tank (thus creating the illusion they were all leaking). In order to stop the leak all the vessel`s monoprop tanks must have their fuel flow disabled

[IRnifty]

Ok, cool. Originally, both I and Ippo (the developer of DanIt! Random Failures) had this issue, but we decided it would be more realistic to let it leak from all, and would provide more than enough incentive to just go out and fix it, instead of blocking it off and not sparing the parts (or duct tape).

[soranno]

I assume that`s an issue limited to monoprop, and not other rocket fuel?

Any ideas what caused the tank failure while in time warp? I had been quickly going back and forth between 100x and 1000x, seemingly generated some forces on the ship somehow

[Ippo]

It actually depends on the resource flow rule. Monopropellant flow across all stages, liquid fuel only through connected tanks.

[IRnifty]

Welcome back, Ippo! ('-')/

He's right. MonoProp leaks will attempt to drain until completely gone, because the flow mode allows it to flow anywhere on the ship without connection. Liquid fuel and oxidizer will only flow between connected tanks, so leaks usually stay localized. There is no way to fix this, but it's not quite that big a problem.

EDIT: It seems Ippo has found a clever solution that I think is worth implementing, so I'll reveal what it is on the next patch notes, which won't be long.

Well why would you want to cheat the system by disallowing failures during time warp? It's bad enough you can skip them by time warping while the craft isn't loaded. Yes, parts can fail during time warp, just as if the checks were happening real time. Every in-game 10 seconds, the system checks, which can be affected by time warp. I've recently noticed, though, that some failures will happen early in the lifetime of a part, given the average is a year, and the failures usually happen after a few days...

Edited August 8, 2014 by IRnifty

[soranno]

I wasn`t aware it could even happen in time warp when on rails, but I certainly don`t support disallowing the failures under any conditions.

My space agency engineers have indeed come to the conclusion that automated vessels should not be interacted with unless absolutely necessary for fear of failures... also my engineers suffer nightmares of the day you figure out how to kill a part on an unfocussed ship.

It had not escaped me that the majority of failures occur very early in part life, most of the failures I have experienced within the first 10 minutes of flight. However, it is reasonable to suggest the first 10 minutes of flight are potentially among the most severe and damaging of the journey (unless you plan to land on eve or something)

[soranno]

Hi again, another interesting observed behaviour for your attention, if you please

Another decoupler one, and I would imagine given the circumstances of this, limited to decouplers

I had a couple of contracts to test stack separators on sub orbital trajectories, so I put them on the nose of my rocket in order to stage them as I ascended. They all failed, and just exploded (not a complaint ) but more crucial is that the activation, while all contract conditions were green, was seemingly cancelled by the failure, and the contract went incomplete. It would seem that the part failing is just as valid a test result as anything else, haha, so it`s an unfortunate behaviour that the two systems are conflicting in this manner.

[IRnifty]

Thanks for that. I think I might have a fix, but I'll have to test. Do you still have that contract? If you do, please make a copy of that save for testing if you plan to continue it.

Edited August 9, 2014 by IRnifty

[soranno]

Yes, on my next flight up I forgot about the tests and carried the damn separators with me to my station.

I`ll take a copy to test if/when you have something.