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

[erbmur]

INCOMPATIBLE with FAR

waa!

It's only incompatible to the point where there will be no failures to any of the ailerons as far as i am aware. Apart from that everything else will fail fantastically!

[Bit Fiddler]

is there a way to scale back the failure rate? I want the random failures but I also want to be able to expect to fly an Aircraft to the pole and back for instance without it failing. I would like it such that the failure happen just not so frequently.

[Daishi]

My god that's pretty.

Can say the same about your rockets! Thanks for the praise, and the rep - I've got three bars now thanks to you

How gorgeous! Are you planning on making an Universal Storage version?

Cheers!

Probably not, sorry. The future direction of the mod is going to make non-wedge parts easier to store anyway under a unified shroud structure; so a dedicated wedge is going to be a redundant part to make now that we have this. But it's early days yet, who knows

Edited June 8, 2015 by Daishi

[Coga19000]

Got my first failure yesterday, yay!

Well, it was not much. It was a motor failure on an... already open antenna... in a comms module with four more antennas... launched in Creative... just to check the launch vehicle.

I DON'T CARE, IT WAS STILL A FAILURE OKAY

Anyways, thank you for your mod. It's awesome

Edited June 10, 2015 by Coga19000

[Coffeeman]

I apologize if this has been asked before, but is this mod compatible with TestFlight?

Theoretically they should, but they do the same thing, so no guarantees. DangIt also works on RO/RSS last I checked

INCOMPATIBLE with FAR

waa!

This just means no control surface failures. Everything else works fine.

- - - Updated - - -

is there a way to scale back the failure rate? I want the random failures but I also want to be able to expect to fly an Aircraft to the pole and back for instance without it failing. I would like it such that the failure happen just not so frequently.

Not currently, but it is a greatly asked for feature, so something for this should come soonish

[Miipe]

Hi!

I start playing with this awesome mod and really enjoy.

After some time in career mode with only 50 essential mods =), the frame rate became really really bad.

When i pressed alt+f2 the log is going crazy with the message '[Error]: Input is null', and won't stop. When I EVA the message stops, change to a vessel and start again.

So I finally trace down, and appear to be from this mod. I removed all mods and start a new carrer with just Dang It (CKAN install).

To reproduce do they follow:

New Carrer -> normal

VAB, place the command module and a parachute. After that place the Flea booster, the message [Error]: input is null will appear

If you save the ship or change stages, the log show the error again.

Exit VAB and enter again, click save, now the message spam twice.

Launch and the error will show twice. Land this vessel do not recover and launch another, the message will show 4 times.

I don't know exactly when, maybe because the number ships and satellites not active, but the error gets exponential, taking down the frame rate.

Here's the screenshot, and the log in this repro test

Log: http://1drv.ms/1dwUsaY

Tks and sorry for my english!!!

[Daishi]

Does it happen just with that booster, or every engine? Sounds like the mod isn't integrating with the game properly :\

[Miipe]

Does it happen just with that booster, or every engine? Sounds like the mod isn't integrating with the game properly :\

I tested with liquid booster, and happens too.

[Mitchz95]

I think I'm experiencing a bug. Spares don't seem to appear as a resource, and I can't take any from my pods to repair failed parts.

[madraven]

Hi,

I am getting the same error as Miipe.

playing in sandbox and when i add the stock LV-N "Nerv" Atomic Rocket Motor to my Shuttle made of MK3 parts in the SPH I get the error [ERROR]: Input is null.

Once the motor(s) are attached to the shuttle the error(s) pop up (in the Alt-F2 log) every time a part is added to or removed from the shuttle. If i take off the motors the error stops appearing. I can add bits with out issue. However as soon as the motors are put back on the error returns..

I also get this message when adding the following motors ( if i add 4 engines i get 4 errors, If i add 10 i get 10 errors)

BACC "Thumper"

GNR-2500 Nuclear Engine (USI Freight Transport Technologies)

GNR-3750 Nuclear Engine (USI Freight Transport Technologies)

HoneyBadger Vtol Atmo Engine (USI)

J-33 "Wheesley" Basic Jet Engine

J-X4 "Whiplash Turo Ramjet Engine

Kerbodyne KR-2L+ "Rhino"

Large Ducted Fan (USI) is get a lot of these when adding 1 [Log]: Look rotation viewing vector is zero and i get the same number of the [Error]: Input is null just after.

LV-T30 "Reliant"

LV-T45 "Swivel"

RT-5 "Flea"

Medium Ducted Fan (USI)

Micro Ducted Fan (USI)

RE-I5 "Skipper"

RE-L10 "Poodle"

RE-M3 "Mainsail"

RT-10 "Hammer"

S1 SRB-KD25k "Kickback"

S3 KS-25x4 "mammoth"

Sepratron I

If i uninstall DangIT the error goes away.

I hope thats of some help.

Cheers

[Ippo]

Did you install community resource pack?

[Mitchz95]

Did you install community resource pack?

Is that required? I don't see it listed in the OP.

[rabidninjawombat]

Is that required? I don't see it listed in the OP.

Its included in the download, generally mod developers include files in the download cause they are required (unless specifically labeled as optional)

[Ippo]

Is that required? I don't see it listed in the OP.

Yes, it's required. It's stated in the manual installation instructions, and it's also bundled in the zip file.

By the way, you should really use CKAN

[jazztoken]

Is there an easy way to verify that DangIt!/Entropy are working as normal? I've launched a number of ships with DangIt! installed and haven't seen a failure since .24.

I can see some log messages related to DangIt! and I can trigger manual failures, but it's spooky how long I've gone without an unexpected one.

[Ippo]

I can see some log messages related to DangIt! and I can trigger manual failures

Then they are working. Enjoy the suspense

[autumnalequinox]

Been enjoying the failure rate. It feels puuuurfect (I may have said this before). Just rare enough for my anxious brain.

I know heat now degrades parts. I had a probe heading to Moho and in an attempt to perform a braking burn and get into orbit, my cryo engine fails, boom! Then I have a backup, four small monoprop engines, which immediately fail as well. I'm assuming this is due to solar heating (my parts were showing about 450+). In addition, I did accidently burn the transfer engine really hard earlier in the mission.

My question is, if I use a mod like heat control (bleeds heat away using radiators and heat pipes) could this save my engines? Or if I build a protective thermal shell around them and keep engines shadowed? I'm using 1.02 still so I know the heat system is weird but cool = more reliable, correct?

I just want to make sure I can fix this problem through creative engineering.

[Z3R0_0NL1N3]

When an engine has multiple engine nozzles (like in Tantares parts or the stock Mammoth), is there a way for your mod to make one engine burn out (perhaps using a Module) and make the rest continue firing? This would replicate something like the Falcon 9's Octaweb that can still make it to orbit even if it has two engine failures, if you happen to be using a part that is, like that, an engine cluster.

Edited July 7, 2015 by Z3R0_0NL1N3

[majo339]

Greetings,

First of all let me congratulate you for a very nice and challenging mod. A few days ago I have started to use it an I like the idea very much, however I have some doubts regarding the failure probability calculations. Maybe you could help me or give me some hints.

In the wiki of your plugin we can read that "MTBF follows an exponential decay function", then there is a reference to the wikipage of the distribution itself, where MTBF, lifetime, tau, mean lifetime, exponential time constant, 1/lambda, are used as synonyms of the same value. If so, why do you specify two values for each of the elements in the *.cfg files in the ModuleManager folder: MTBF and LifeTime? Does the "LifeTime" in the cfg file mean something different than "LifeTime" on the wikipage of the plugin/exp distribution? Obviously they play different roles in your module (especially when you set the LifeTime value to a very low value for the engines), but I seem to be somewhat confused by the notation.

The second question is more directly bound to the gameplay. I have performed some small scale scientific mission to the moon. The ship includes 14 tanks (where 9 of them are dropped before reaching the kerbal orbit), and also four wheels on the final stage which is my scientific rover/hopper. The thing is: when I launched the mission for the first time, after several minutes of flight (yet before the orbit) one of the tanks got broken. When I restarted the game and tried it again, I made it to the mun, but after several kerbal days (maybe 20 hours) of exploration, one of the wheel tire got broken. This is where I thought to myself: what the hell, am I so unlucky or are the brake-down probabilities too high? Then I went into some literature reading, and well, there I am with my post.

I even went to some reference calculation website http://reliabilityanalyticstoolkit.appspot.com/exponential_distribution where I tried to put the MTBF of a wheel tire, of a tank, and estimate the failure probabilities of these two cases. As I expected, the probability of them (with the MTBF taken from the cfg files) during the first several tens of hours of the mission, is practically an absolute zero. So why did it happen to me?

Apparently I have a problem with understanding the LifeTime value from your cfg files. If you could put me some light on that, I would be grateful.

Best regards,

Majo339

PS. I did not travel at high temperatures, I keep the speed within the atmosphere at <=250m/s.

[Ippo]

Hello everyone! Sorry for not replying sooner, life's been pretty hectic and weird lately. For a variety of reasons, I just cannot stay at home, so even when I have some some spare time I'm not around a PC.

My question is, if I use a mod like heat control (bleeds heat away using radiators and heat pipes) could this save my engines? Or if I build a protective thermal shell around them and keep engines shadowed? I'm using 1.02 still so I know the heat system is weird but cool = more reliable, correct?

The failure rate is influenced by the temperature: reducing the temperature by any means will be beneficial

When an engine has multiple engine nozzles (like in Tantares parts or the stock Mammoth), is there a way for your mod to make one engine burn out (perhaps using a Module) and make the rest continue firing? This would replicate something like the Falcon 9's Octaweb that can still make it to orbit even if it has two engine failures, if you happen to be using a part that is, like that, an engine cluster.

Unfortunately not, not at the moment.

...

The LifeTime is the constant of the exponential decay (with all the implications that your read about already).

MTBF is the initial value, at time zero.

So for example, if you have two parts with the same LifeTime but different MTBF, the one with the higher MTBF will always be strictly more reliable than the other. I hope it's clearer now

[Svm420]

Any chance of progress with procedural parts failures? I enjoy the mod, but end up missing out n any tank failures because I use Pparts. Same with entropy actually now that I think never had an srb fail and that must be why.

[majo339]

The LifeTime is the constant of the exponential decay (with all the implications that your read about already). MTBF is the initial value, at time zero. So for example, if you have two parts with the same LifeTime but different MTBF, the one with the higher MTBF will always be strictly more reliable than the other. I hope it's clearer now

Yes it is, thank you. So to make it 100% sure: MTBF(t) = MTBF(0)*e^(-t/LifeTime). Correct?

A second question relates to my hitherto experience with the mod:

• 1st launch: one of the 15 fuel tanks (MTBF=350400h, LifeTime=131400h) breakes within the first 5 minutes of flight
  
• 2nd launch: one of the four wheel tires (MTBF=350400h, LifeTime=131400h) breakes within first 10 hours of flight
  
• just a minute ago: one of the two batteries (MTBF=175200h, LifeTime=87600h) has gone short-circuited after 12h of mission
  

According to your intuition and your intentions while programming this mod: would you say this a normal behaviour of the process at these parameters? I have a feeling that these failures happen way too early and too often.

I have looked into my savegame file and I see that all the parts have the "Age" parameter values set to quite high values. For example, a fuel tank has Age of 60467.11, and the wheel tires Age is 1345.39. Maybe here is something not right.

Regards,

Majo339

Edited July 8, 2015 by majo339

[Ippo]

Any chance of progress with procedural parts failures? I enjoy the mod, but end up missing out n any tank failures because I use Pparts. Same with entropy actually now that I think never had an srb fail and that must be why.

Sorry bro, not happening. Not from me, anyway.

Yes it is, thank you. So to make it 100% sure: MTBF(t) = MTBF(0)*e^(-t/LifeTime). Correct?

A second question relates to my hitherto experience with the mod:

• 1st launch: one of the 15 fuel tanks (MTBF=350400h, LifeTime=131400h) breakes within the first 5 minutes of flight
  
• 2nd launch: one of the four wheel tires (MTBF=350400h, LifeTime=131400h) breakes within first 10 hours of flight
  
• just a minute ago: one of the two batteries (MTBF=175200h, LifeTime=87600h) has gone short-circuited after 12h of mission
  

According to your intuition and your intentions while programming this mod: would you say this a normal behaviour of the process at these parameters? I have a feeling that these failures happen way too early and too often.

I have looked into my savegame file and I see that all the parts have the "Age" parameter values set to quite high values. For example, a fuel tank has Age of 60467.11, and the wheel tires Age is 1345.39. Maybe here is something not right.

Regards,

Majo339

Well, it certainly sounds suspicious. I don't know what to say, sorry.

[Z3R0_0NL1N3]

I see in the wiki that heat causes parts to age faster. What about having excessive G-forces cause a part to have a very high chance of failure?

[Magitek]

While trying to get several mods to work without generating errors I noticed DangIt was throwing Error - Input is null for every part with electrical charge on it.

For whatever reason one of KSP's functions does not like being passed null so I changed the tank leak system to use to empty strings instead of null.

modified source:

using System;

using System.IO;

using System.Collections;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using UnityEngine;

namespace ippo

{

public class ModuleTankReliability : FailureModule

{

public override string DebugName { get { return "DangItTank"; } }

public override string ScreenName { get { return "Tank"; } }

public override string FailureMessage { get { return "A tank of " + leakName + " is leaking!"; } }

public override string RepairMessage { get { return "Duct tape applied."; } }

public override string FailGuiName { get { return "Puncture tank"; } }

public override string EvaRepairGuiName { get { return "Apply duct tape"; } }

public override string MaintenanceString { get { return "Repair the insulation"; } }

public override string ExtraEditorInfo

{

get

{

var temp = "This part can leak one of the following resources if it fails: ";

foreach (PartResource pr in part.Resources.list.FindAll(r => !DangIt.LeakBlackList.Contains(r.resourceName))) {

temp += pr.resourceName + ", ";

};

return temp.TrimEnd(' ').TrimEnd(',');

}

}

// The leak is modeled as an exponential function

// by approximating the differential equation

// dQ(t) = - pole * Q(t)

// where Q is the amount of fuel left in the tank

[KSPField(isPersistant = true, guiActive = false)]

protected float pole = 0.01f;

// Maximum and minimum values of the time constant

// The time constant is generated randomly between these two limits

// and pole = 1 / TC

[KSPField(isPersistant = true, guiActive = false)]

public float MaxTC = 60f;

[KSPField(isPersistant = true, guiActive = false)]

public float MinTC = 10f;

// Name of the leaking resource

[KSPField(isPersistant = true, guiActive = false)]

public string leakName = "";

// List of resources that the module will choose from when starting a new leak.

// This list is created when the module is started by taking all the resources

// in the part and excluding the ones that have been blacklisted in the configuration file

protected List<PartResource> leakables;

// This method is executed once at startup during a coroutine

// that waits for the runtime component to be available and then triggers

// this method.

protected override void DI_RuntimeFetch()

{

// At this point DangIt.Instance is not null: fetch the blacklist

this.leakables = part.Resources.list.FindAll(r => !DangIt.LeakBlackList.Contains(r.resourceName));

// If no leakables are found, just disable the module

if (leakables.Count == 0)

{

//this.Log("The part " + this.part.name + " does not contain any leakable resource.");

this.Events["Fail"].active = false;

this.leakName = "";

this.enabled = false; // disable the monobehaviour: this won't be updated

}

}

protected override void DI_Start(StartState state)

{

if (HighLogic.LoadedSceneIsFlight)

{

// The part was already failed when loaded:

// check if the resource is still in the tank

if (this.HasFailed)

{

if (leakName == "" || !part.Resources.Contains(leakName))

{

this.Log("ERROR: the part was started as failed but the leakName isn't valid!"); ;

this.SetFailureState(false);

}

}

}

}

protected override void DI_OnLoad(ConfigNode node)

{

this.pole = DangIt.Parse<float>("pole", 0.01f);

this.leakName = node.GetValue("leakName");

if (string.IsNullOrEmpty(leakName))

leakName = "";

this.Log("OnLoad: loaded leakName " + ((leakName == null) ? "null" : leakName));

}

protected override void DI_OnSave(ConfigNode node)

{

node.SetValue("leakName", (leakName == null) ? "" : leakName);

node.SetValue("pole", this.pole.ToString());

}

protected override void DI_Update()

{

try

{

if (this.HasFailed && (leakName != "" && (part.Resources[leakName].amount > 0))) // ignore empty tanks

{

double amount = pole * part.Resources[leakName].amount * TimeWarp.fixedDeltaTime;

// The user can disable the flow from tanks: if he does, RequestResource

// won't drain anything.

// In that case, we need to subtract directly the amount we want

if (part.Resources[leakName].flowState)

part.RequestResource(leakName, amount);

else

{

part.Resources[leakName].amount -= amount;

part.Resources[leakName].amount = Math.Max(part.Resources[leakName].amount, 0);

}

}

}

catch (Exception e)

{

OnError(e);

this.isEnabled = false;

this.SetFailureState(false);

}

}

protected override bool DI_FailBegin()

{

// Something has gone very wrong somewhere

if (leakables == null)

throw new Exception("The list of leakables is null!");

// Discard every resource that has already been emptied

leakables.RemoveAll(r => r.amount == 0);

if (leakables.Count > 0)

{

// Choose a random severity of the leak

// The lower TC, the faster the leak

float TC = UnityEngine.Random.Range(MinTC, MaxTC);

this.pole = 1 / TC;

this.Log(string.Format("Chosen TC = {0} (min = {1}, max = {2})", TC, MinTC, MaxTC));

// Pick a random index to leak.

// Random.Range excludes the upper bound,

// BUT because list.Count returns the length, not the max index, we DONT need a +1

// e.g. [1].Count == 1 but MyListWithOneItem[1] == IndexError

int idx = UnityEngine.Random.Range(0, leakables.Count);

print ("Selected IDX: " + idx.ToString ());

print ("Length of leakables: " + this.leakables.Count.ToString ());

print ("Leakables: " + this.leakables.ToString ());

this.leakName = leakables[idx].resourceName;

// Picked a resource, allow failing

return true;

}

else

{

leakName = "";

this.Log("Zero leakable resources found on part " + this.part.partName + ", aborting FailBegin()");

// Disallow failing

return false;

}

}

protected override void DI_Disable()

{

// nothing to do for tanks

return;

}

protected override void DI_EvaRepair()

{

this.leakName = "";

}

#if DEBUG

[KSPEvent(active = true, guiActive = true)]

public void PrintStatus()

{

this.Log("Printing flow modes");

foreach (PartResource res in this.part.Resources)

{

this.Log(res.resourceName + ": " + res.flowMode + ", " + res.flowState);

}

}

[KSPEvent(active = true, guiActive=true)]

public void PrintBlackList()

{

this.Log("Printing blacklist");

foreach (string item in DangIt.LeakBlackList)

{

this.Log("Blacklisted: " + item);

}

this.Log("Done");

}

#endif

public override bool DI_ShowInfoInEditor(){

return part.Resources.list.FindAll(r => !DangIt.LeakBlackList.Contains(r.resourceName)).Count>0; //Only show if has leakable rescoures

}

}

}