[1.0.5 - Alpha 6] Dang It! (12 september 2015)

[Ippo]

ALPHA 2 IS NOW AVAILABLE

I just uploaded the Alpha 2 release: if you have been using one of the previous alphas, please DO update. This new version corrects a lot of bugs: basically, the alpha 1 version only worked partially and the age tracking was never actually correct: this should fix it.

Please see the changelog in the OP, or on github, for the most relevant news.

P.S: I know that the lack of new features is disappointing, especially when compared to the titanic future features list. I wanted to include more new stuff, but eventually decided that the aging and other bug fixes were simply too important and needed to be release ASAP.

Let me be absolutely clear: all the alpha 1 versions work only partially and you should upgrade them immediately.

Edited June 8, 2014 by Ippo

[Itsdavyjones]

wow i'm waiting for .24 or whatever the next one is, and still brows the forums, and this is amazing, can't wait to try it out when i play again +1

[velusip]

I would like to provide some balance suggestions and rationale. Let me know what you think.

• I haven't managed to successfully do anything with this mod installed. This is because I run as many realism mods as will coexist, and the time stretch of realscale, the part counts, and the necessity of running at threshold performance puts a lot of stress on things. The odds for failing seem to be scaled too high for me. After having up to 8 redundant systems fail before leaving Kerbin (Earth) SoI I decided to post this. First: add a master balance coefficient for quickly configuring the chance to fail calculations. e.g. set difficulty from 1 to 0.2 for realism games where a vessel will be spending a lot of time doing stuff.
  
• Second: Increase failure chances while on the launchpad and reduce elsewhere -- even before any staging has been done. Just like a real launch, anomalies are observed during the countdown which delay the mission, at worst or at best.
  
• Building highly redundant probes might be more of a silly side-effect of using this mod rather than a good result. Third: something like an "attempt reboot" command or Yellow Dart's idea of a self repair system, or in the meantime; a much lower chance for failure when no kerbals are present (probes). I think that this mods biggest appeal is to provide a reason for a LES and more excuses to do spacewalks. So having failures when Kerbals are present=fun, but with no means to repair a probe=nuf.
  
• Fourth: Another minor suggestion is to indicate via right-click menu what could fail. This will at least help debug interaction with other mods. e.g. I had a probe core fail with no way to repair it.
  
• Fifth: More of a question, is flanking an engine increasing the odds of other modules to fail, or just the engine? It makes sense that other modules could break under gforce and vibration and whatnot. I think this increasing chance wth changing or high throttle should also be applied lightly to everything, and not so much to the engine itself.
  

Here's an example of the KSP.IO.PluginConfiguration. If you don't like using KSP.IO I can send you a serialization class I wrote for another mod.

Edited June 9, 2014 by velusip
formatting

[Ippo]

First: add a master balance coefficient for quickly configuring the chance to fail calculations. e.g. set difficulty from 1 to 0.2 for realism games where a vessel will be spending a lot of time doing stuff.

Right now no balancing whatsoever has been done. The cfg files themselves are absolutely unfinished: if you feel that the failures are too common, you can just open the cfg and increase the MTBF and LifeTime according to your taste.

• Fourth: Another minor suggestion is to indicate via right-click menu what could fail. This will at least help debug interaction with other mods. e.g. I had a probe core fail with no way to repair it.
  

That's very strange: did you enable any silent failure? Because otherwise it should be very clear what has broken down when the message appears on screen.

Also, in the VAB you can see all the reliability modules by right-clicking the part.

• Fifth: More of a question, is flanking an engine increasing the odds of other modules to fail, or just the engine? It makes sense that other modules could break under gforce and vibration and whatnot. I think this increasing chance wth changing or high throttle should also be applied lightly to everything, and not so much to the engine itself.
  

No(t yet?). At this moment every part is completely independent from the others.

Regarding the other points, let me redirect you to the dev thread so you can post your suggestion for anyone to discuss

[GalaxiesFinestToday]

Awesome idea! I always wanted something to happen to my ship and improvise to fix it, just like Apollo 13. Keep up the good work on this mod!

[J_Davis]

Right now no balancing whatsoever has been done. The cfg files themselves are absolutely unfinished: if you feel that the failures are too common, you can just open the cfg and increase the MTBF and LifeTime according to your taste.

Please do turn up the numbers, however. As low as it is unmanned missions are simply impossible with stock. Not everyone is comfortable hand-editing a MM .cfg file, or is going to know how to determine from lifetime and MTBF how likely a disaster is. XD

A multiplier for ships with no crew capacity would be very good, it can be assumed that probes are less likely to have failures.

Also, just curious, but did you implement ignoring the suggested resources? I'm especially worried my heat shields will fail on me by surprise, which would be one of those fatal and pretty much unrecoverable failure.

Edit: I did my own hand edit btw, I can put them on my KSP dropbox if your okay with it and others want it. Also, what are these options?

        MinTC = 60
        MaxTC = 300

Edited June 10, 2014 by J_Davis
added question

[Ippo]

Please do turn up the numbers, however.

In the first release they were much higher. I felt it was a little OP... so now I erred on the opposite side.

A multiplier for ships with no crew capacity would be very good, it can be assumed that probes are less likely to have failures.

Personally I don't think it's fair that the same component has two different behaviours according to the crew's presence. However, when I'll finally get around to a proper balancing, parts will be heavily differentiated and I'll see that small parts (aka: stuff you use on probes) gets a boost.

Also, just curious, but did you implement ignoring the suggested resources? I'm especially worried my heat shields will fail on me by surprise, which would be one of those fatal and pretty much unrecoverable failure.

Sorry, not yet. I have an exam next week and time is a bit tight at the moment. Also, as of now the list is also hardcoded which means you can't edit it. Moving the black list to run time is literally the next thing I'm going to work on... but again, exams.

Edit: I did my own hand edit btw, I can put them on my KSP dropbox if your okay with it and others want it. Also, what are these options?

        MinTC = 60
        MaxTC = 300

Sure thing, go ahead! Those values are the maximum and minimum time constants for the resource leak, that is computed as an exponential. Lower values are worse for you: I think that the minimum of 60 is pretty much ok, the max is a tad too high right now (on the dev thread I've been told that with a TC of 233 the leak is barely noticeable without timewarping).

Also please note that a bug has been found in the dev thread: the leak follow strictly the resource flow rules, so if you have more than one tank the resource is lost from the furthest available tank instead of the broken one. This doesn't affect gameplay, but it's still annoying. You should repair the broken one, even though it's not the one that is losing fuel (well, technically it is, but KSP automatically pumps in from the other tanks so it appears to remain full).

[VaporTrail]

Had an idea for a problem that I don't think is currently covered, but that could make life more interesting... Or maybe just annoying. It might take quite a bit of coding to get this one in though...

Example problem: A battery losing a cell, or partial failure of a battery.

Basically the battery (radial or stack) works as normal until the failure occurs. When the failure occurs, the battery experiencing the failure loses some percentage (50%?, 25%?, 10%?, Maybe base % on severity of failure?) of it's optimum maximum storage capacity. Basically, this means the battery will (quickly) lose any charge above the new "damaged" capacity, and any charge added to it will not increase the stored EC above this value.

For example, we have a stock Z-100 RCBP with a max capacity of 100 EC. This RCBP experiences a 1/10th severity failure and thus can not hold more than 90 EC until fixed. (possibly by adding a "failure" module that "quickly burns" electric charge to the battery in question, until the battery's capacity is 90 or less, then burns charge @ the charge rate of the battery, leaving the battery @ 90 EC. The charge rate is likely to be the total charge rate of the vessel, and in the case of large vessels or KSPI reactors, is likely to be huge.) This would be especially problematic for vessels using Balancer mods to keep their electric charge balanced (though I have yet to run into a scenario where that's relevant) as suddenly every battery has to drain to 90%.

Pros:

Another possible failure event, and possibly one that would be quite annoying in an unmanned long-duration vessel without sufficient redundancy.

Cons::

Not a very high priority failure for manned vessels, unless high %'s are used. If the choice is repairing the leaky fuel tank, or the slightly glitchy battery, the battery's gonna keep the glitch.

[Edit]

Just realized, the way KSPI Megajoules is structured (I think) a battery failure such as detailed above is going to completely hose power production... as the generators first fill all available EC before switching to MJ... if you have something burning huge amounts of EC (failure module...) then the reactor never gets to produce MJ.

Edited June 10, 2014 by VaporTrail

[Ippo]

...

I don't know about megajoules, but I could just reduce the MaxAmount of the battery.

[VaporTrail]

That would work... the only problem (well, I guess it's more an asthetic issue) is that the max capacity of the battery would change. Instead of being 90/100 when max charged and failed, it will be 90/90, as opposed to 100/100 unfailed and max charge.

[J_Davis]

Personally I don't think it's fair that the same component has two different behaviours according to the crew's presence. However, when I'll finally get around to a proper balancing, parts will be heavily differentiated and I'll see that small parts (aka: stuff you use on probes) gets a boost.

While I can understand it, if the alternative is making smaller parts more reliable, that will tend to push manned missions towards the smaller parts, and it becomes a punishment for those with weaker systems who need to save part count wherever possible.

[Ippo]

While I can understand it, if the alternative is making smaller parts more reliable, that will tend to push manned missions towards the smaller parts, and it becomes a punishment for those with weaker systems who need to save part count wherever possible.

However, keep in mind that the whole idea of redundancy will do that in any case.

[deepsheep]

I was wondering if it would be possible to factor in number of crew members in the aging calculation of the parts. It would be great to have a reason to send 3 Kerbals vs 1 Kerbals if it would slow down the failure rate.

[J_Davis]

However, keep in mind that the whole idea of redundancy will do that in any case.

Ah, I had a thought on this. It's an 'advanced' feature, but perhaps in the future some parts (esp. larger batteries and larger RCS tanks) could be setup with an automatic redundancy? Instead of leaking/loosing everything, a portion of the unit would fail and require work to fix, but in the meantime it would work at reduced capacity (any extra supplies pumped in would be lost, of course). Such parts, given their internal compartmentalization, could require more spare parts to repair, helping offset the inherent safety in them.

[Ippo]

UPDATE RELEASE

This (Alpha 2.1) is a very small update that brings a much needed feature: blacklisting resources from other mods. Right now it supports the following 4 mods:

• Deadly Reentry
  
• Extraplanetary Launchpads
  
• TAC life support
  
• Station Science
  

More will follow when I hear from some authors I contacted.

Anyway it's very easy to add a resource to the blacklist if you feel the need to do it now: just open the DangItTanks.cfg file and add the line:

ignore = ResourceName

You can also use this module manager file if you prefer to do it this way:

@PART:HAS[ModuleTanksReliability]:AFTER[DangIt]
{
    @MODULE[ModuleTanksReliability]
    {
        ignore = ResourceName
    }
}

[goldenpeach]

cool!

Also, I had my firsts failures!

It was a batterie failure on my manned craft during a crew changing mission with my space station.

(I had also spotted two failures on my space station when I docked, I don't know when they happened).

I am so happy(strange right? a failure shouldn't be a happy event)!

EDIT: while writing this, I just had another failure! Another batterie has short-curcuited on my pod I used for the above mission( I used the old one which remained docked to the station for a while)! The only problem is that the failure happened just when I was entering the atmosphere... I will try to fix it before the drag cause too much problems).

EDIT2: I tried and found out that I had transferred all the spares to my space station(I modified the resource file to allow that), I wasn't expecting a failure to happen so rapidly, next time I will keep a few spare with me ).

Edited June 11, 2014 by goldenpeach

[Ippo]

(I had also spotted two failures on my space station when I docked, I don't know when they happened).

To be totally honest: I am not quite sure either. As far as I know, they should only happen on active vessels: remember though that when you get within 2.5km they become active.

I need to run more tests on this. Sorry for the noobness, it's really my first mod ever and KSP has no documentation :/

I am so happy(strange right? a failure shouldn't be a happy event)!

... sorry, I guess?

I wasn't expecting a failure to happen so rapidly, next time I will keep a few spare with me ).

Are you still using the cgfs from the alpha 2? Because I realized that all those values were absurd, so I gave everything one hell of a buff in this new update.

If you did upgrade, though... then it's just bad luck This mod is inherently about a good dose of luck*

* that's actually not a joke: even if the MTBF is 10 thousand hours, it's not impossible that two failures happen one immediately after the other. Just very unlikely. By the way, this made me realize that this is a huge BS outcome of my model: I will need to give an age discount for repair, too.

[goldenpeach]

Actually, I like those failures, it give a bit of zest to my missions

Yes, I was using the alpha 2, I just downloaded the new update but I modified the values to match those from the alpha 2: I really like failures(yes, I'm kind of strange...)

EDIT:ok, I realized what you meant by "absurd": a have a small plane and it couldn't stand a full night without suffering failures!

Now I am just worried about failures during time warp but it just mean that I will keep the cursor on "abort" when I'm using the warp helper in mechjeb .

Edited June 12, 2014 by goldenpeach

[Cleric2145]

Using 2.1 I'm still getting some silly rates on failures. I sent a probe off to Eve, and less than 24 hours after leaving Kerbin SoI, it had already suffered a fuel tank leak, reaction wheel fail and a battery short circuit. Now, I was time-warping on the active vessel, so this could very easily be fixed by time-warping from the Tracking Station, but that's more work on the player's end. I can work around a fuel leak, the reaction wheels aren't an issue, and the battery loss sucks, but by the time I reach Eve I don't know if I'll have a functioning part on the probe. :|

[Ippo]

That's very strange, actually. Could you please open the cfg files and check the values for me? Tanks should have a MTBF of 24 thousand hours (~ 3 years) and batteries of 8000 (~ 1 year).

EDIT: I just checked the release on github and it has the updated values. I guess I'll have to buff them again, but that's seriously confusing. I'll check again the conversion from MTBF to failure chance, I guess.

I have to go through the base system again anyway, I found a couple more edge cases

Alpha 3 is going to take a while, but I promise it will be worth it

Edited June 14, 2014 by Ippo

[wased89]

I'm starting a space station and I'm getting failures (deadly ones, like monoprop and oxidizer leaks) every second launch if I'm lucky... i want some failures to happen but not this often... it's causing way too much grief for the program and kerbals (Excluding Jeb) have been rioting outside my space centre, please help me...

EDIT: All my modules that I send to my space station are unmanned... so that's even worse..

Edited June 14, 2014 by wased89

[mike9606]

I have launched 2 ships (1 orbital module and 1 station), and the only failure I have had is the failure of the reaction wheels in the probe core on the station, which has since been fixed after I docked the 2 crafts together.

[SaSquatch]

3hour mission saw 8 of 8 lights fail (just now). I packed 8 batteries onto a Mun probe, luckily only 2 failed enroute(the previous alpha).

I dig the mod. I actually faced the scenario of whether or not to launch with a stuck stabilizer and a shorted battery with the KSO (warping to my launch window on the pad usually sees a failure). Interesting challenge, but the one time when the main external tank was leaking, back to the VAB. In the very least, this is a nice alternative to maintenance flights compared to the repair missions from the Flight Controller mod, which uses special parts.

Also, any thought on having the failures reported in the Flight Events list? Might be handy for after mission reports or for anyone who uses Rasterprop monitor so failures show up in the Log, and with a time stamp.

[Ippo]

I'm starting a space station and I'm getting failures (deadly ones, like monoprop and oxidizer leaks) every second launch if I'm lucky...

...which has since been fixed after I docked the 2 crafts together.

3hour mission saw 8 of 8 lights fail (just now)....

I hate modding.

[mike9606]

I'm actually using mods for my space station. The probe core is a BOMP, and the crew capsules are the 1.25m hitchhikers Sam Hall made. I also have a mechjeb and Kerbal Engineer module on it. I feel bad because all those command parts adds up to a total of 150 spare parts max. I'm only at 100 on the station and 49 on the crew pod.