[WIP] [Dev thread] Dang it! A random failures mod

[Ippo]

oops... forgive me for that, I had read the previous pages fast and though that the inspection would provide a reliability bonus. :/

Actually that was (and still is) my idea: a pre-emptive maintenance sort of thing. However, the idea of this inspection as in "just looking how it is" has been tossed around, and it might be actually quite useful. This second type of inspection would provide only information; the maintenance would also give the reliability bonus and consume resource.

The maintenance one will likely be the next feature I'll work on

Also, I found a bug(a real one this time ).

searching for bugs is funnier than I though

You know the little button you can use to lock a resource from being used(the one in the GUI that appear when you click on a part)?

Well, if you use that button to lock a resource when there is a leak, the fuel stop leaking.

This might actually be a problem, but I think I know what the game is doing. I'm guessing that the game sets the flow mode to none: if this is the case, I will just re-force it open every time I drain the resource

EDIT Another bug: the RSC tank of the tree kerbal capsule(MK1-2 command pod) don't lose fuel even though it should be leaking.

Well, this is actually really strange. What version are you using? I posted the Alpha 2 a couple hours ago: if it is what I think it is, it was fixed in the alpha 2. Please check that you have the updated version.

Tomorrow I'll try to replicate the bug myself... but now it's almost 2 am, so no

And thank you very much for your bug searching, it's really helpful

[goldenpeach]

You're welcome

Yes, I have the Alpha 2, I found out that deliberately causing failures to see how the rocket manage to fly is interesting...

Unfortunately, my apollo style mün rocket manage them very badly: if ANY failure occur at launch, I would have to abort the mission(except one: the shut down of the engine that get me on a free return trajectory).

EDIT: Actually, I had some idea to fix some failures(those about leaking fuel). However, they all need to be in the core of the rocket: if anything happen to the side booster(except gimbal locking and generator stopping electric production) there is an abort.

[Ippo]

I wanted to sleep but I was curious about the RCS, so I tested it now

It's working on my pc using the same build I uploaded. Would you be so kind to send me the log? Or actually, just open it and look for "TC" (use the find function of your editor).

You should find a line that says something like this:

 [DangIt]: DangItTank[-134956][Ship: Untitled Space Craft]: Chosen TC = 125.916 (min = 60, max = 240) 

In the release I upped the maximum TC to 300: my only guess at this moment is that it chose a very high TC => extremely slow leak that can be easily overlook.

(TC is the time constant of the exponential describing the leak: if TC is 300, it takes ~1500 seconds to empty the tank)

[goldenpeach]

I wanted to sleep but I was curious about the RCS, so I tested it now

[...]

haha!

Yeah, I understand that feeling when there is a bug in your code ^^

I just sent you the log; the RCS fuel did get removed of the tank when I time warped.

[Ippo]

Well, then there's your problem: the leak was too small to notice

The failure module chooses a random time constant between the limits given in the cfg, and then the resource decays exponentially. When the tank is full, a TC of 233 means a leak of (1/233) * 30 = 0.13 per second, which is really small. Time warping of course makes the problem more noticeable: at 10x timewarp, you are consuming 1.3 per (real life) second, which is basically the rate of a liquid engine.

Maybe a TC of 300 is way too high: I tried that value because with the introduction of silent failures I figured that slower leaks would have been more manageable (although no failure is silent by default)

[goldenpeach]

I have redone the testing, and found out that the problem isn't that the leak is too slow but that there seem to be a delay between the failure and the leak: I time warped at a slower pace and found out that, at the beginning, the fuel wasn't draining but that after a while, the fuel was draining properly.

Forget what I just said: the pod was just draining the RCS fuel of another tank (probably that I put a fuel cross fuel enabled part between them)!

Actually, there is no fuel crossfeed enabled parts between them: the RCS fuel is drained the same way as if I was using RSC thruster without any failures(from the bottom of the rocket to the upper part of the rocket.

Edited June 9, 2014 by goldenpeach

[Ippo]

I have redone the testing, and found out that the problem isn't that the leak is too slow but that there seem to be a delay between the failure and the leak: I time warped at a slower pace and found out that, at the beginning, the fuel wasn't draining but that after a while, the fuel was draining properly.

Forget what I just said: the pod was just draining the RCS fuel of another tank (probably that I put a fuel cross fuel enabled part between them)!

Actually, there is no fuel crossfeed enabled parts between them: the RCS fuel is drained the same way as if I was using RSC thruster without any failures(from the bottom of the rocket to the upper part of the rocket.

I should start paying you

[goldenpeach]

^^

Searching for bugs is really fun!

I wonder if someone could do a mod with a lot of bug so everyone can search for them(but can we call them "bugs" if there are intentionally put in the code?)

[Ippo]

They already did!

[goldenpeach]

XD

Well, remember the apple commercial saying

that there was an app for everything on the App store?

It seem that the same thing apply for the add-on in KSP!

Also, on an other not of humour, your plugin is a random failure mod which target any mod installed. who could have expected that it would include your own mod!

[Ippo]

Quick dev update for the interested:

Right now, development is essentially stopped because I have an exam soon. Anyway, this short pause will be very good: I have many cool stuff in mind right now, and I need to sort my thoughts out

Basically, I am trying to get a clear conceptual design of:

- inspections vs pre-emptive maintenance

- decaying performance (where applicable, like solar panels and RTGs)

- a new, huge feature that I'm quite not ready to announce yet because I need more infos and tests to be sure I can pull this off

So stay tuned, more goodies are coming (also, one of these nights I'll take the time to write the module for EngineFX, it's stupid that half of the engines are immune right now).

[Ippo]

Well, after two days of not studying I have some encouraging results, so I can say it officially now...

PERKS

Yep: I'm doing perks. Each kerbal will have his own random set of perks and it will affect his ability to do repairs.

Please understand that I have been knee-deep in Reflection code for two days and I haven't thought for a single moment to how to balance this.

I don't know what the effects will be or anything else: just know that I have now a system in place that allows me to give perks to the kerbals* and access them in flight, anything else is still completely not designed at this moment.

And now I'm off to bed, 'coz here in Italy it's night

* Actually, the system allows to keep a separate persistent file for each kerbal, plus it can automatically fill data in with user-defined classes. This is of course targeted to other modders and I will release it asap, as soon as I write a minimum of documentation for it.

[VaporTrail]

Post transfer:

Couple of thoughts, not sure if they've been mentioned:

First:

Perhaps a Minimum Time Before Failure stat. Call it a "Warranty Time Period" since MTBF is taken... Big problems usually take lots of time to get to the point where they're about to happen... then happen quickly. WTPs would range from several days to a week or so (generally lights and other "nonessentials") up to months (big fuel tanks and the like).

Basically the idea is to prevent huge problems on the pad for long missions, but still allow the occasional "quality control issue" through. This would probably be a good spot to tie the reliability in... better parts have a longer WTP than those 'built by the lowest bidder.'

Second:

Perhaps a modifier for systems that have had a failure. Basically, if you have a failure in one type of system (say a battery) then the failure generation system should have a built-in bias against generating the same type of failure immediately thereafter. The idea is to prevent someone having to repair a fault in every battery, on a vessel that mounts a dozen small battery packs because they need the power, and the redundancy, instead of getting a mixed bag of faults. The trick is to ensure that it doesn't prevent getting two of the same failures back to back... just makes it less likely.

[Ippo]

Big problems usually take lots of time to get to the point where they're about to happen... then happen quickly. [...] Basically the idea is to prevent huge problems on the pad for long missions.

Sadly,

doesn't always work like that...

However, on the pad you are literally as safe as it gets, because you have the lowest failure chance of the whole mission.

Basically, if you have a failure in one type of system (say a battery) then the failure generation system should have a built-in bias against generating the same type of failure immediately thereafter. The idea is to prevent someone having to repair a fault in every battery, on a vessel that mounts a dozen small battery packs because they need the power, and the redundancy, instead of getting a mixed bag of faults. The trick is to ensure that it doesn't prevent getting two of the same failures back to back... just makes it less likely.

I don't get the purpose of this, could you elaborate? If you have a lot of batteries then you will obviously see them fail more often than the other components.

(Also, thanks for the post transfer)

[goldenpeach]

Ok, I have three more bugs to report(yep, I'm back ).

The first one: the light of the landing gear stay on even if the light bulb should fail(you can't turn it off tough).

Oh, and it's the only light emitting part to do that.

The second one is interesting: the SRB leek fuel when I puncture the tank.

The third one is not really a bug: when a control surface is stuck, we can reenable the control with the GUI(the GUI hat enable to disable the control surface from controlling the yaw/roll1pitch of the ship).

Edited June 15, 2014 by goldenpeach

[Ippo]

The first one: the light of the landing gear stay on even if the light bulb should fail(you can't turn it off tough).

Oh, and it's the only light emitting part to do that.

I hadn't thought of them, good catch. I'll look into it.

The second one is interesting: the SRB leek fuel when I puncture the tank.

It's not interesting, it's annoying: SolidFuel is in the blacklist so it should ignore it

The third one is not really a bug: when a control surface is stuck, we can reenable the control with the GUI(the GUI hat enable to disable the control surface from controlling the yaw/roll1pitch of the ship).

... and this instead completely slipped through. I had solved it for the gimbal and then forgot to do it for control surfaces

Thank you dude, you are really helping me a lot I'll take care of them asap.

[goldenpeach]

I made a quick test and it definitely bring a good news (or something we can consider a good new for debugging): the result is the same if I "ignore" liquid fuel( I modified the plugin to make it ignore liquid fuel).

Why do I consider that a good news? Because, it would be far worst if the systems for ignoring resources worked for some resources but not for the others(I didn't make the plugin though, so it's up to you to take it as a good news or a bad one)

[Cleric2145]

One method of implementing "inspection" or maintenance (albeit a complicated way) might be to slowly lower the age of any part illuminated by EVA helmet lights, or within x meters of an EVA Kerbal. I'm sure this isn't very practical, but would be a nice way to differentiate actual preventative maintenance and simple visual/functional inspections.

[Ippo]

One method of implementing "inspection" or maintenance (albeit a complicated way) might be to slowly lower the age of any part illuminated by EVA helmet lights, or within x meters of an EVA Kerbal. I'm sure this isn't very practical, but would be a nice way to differentiate actual preventative maintenance and simple visual/functional inspections.

This is actually a very cool idea

I have no idea if it can even be done, but I'll try and see just out of curiosity.

[Ippo]

I made a quick test and it definitely bring a good news (or something we can consider a good new for debugging): the result is the same if I "ignore" liquid fuel( I modified the plugin to make it ignore liquid fuel).

Yes, that's definitely good news. I was checking just now and the blacklist is loaded right from the cfg, but then is not saved in the persistence and then basically disappears, because I'm dumb.

EDIT: or even dumber, since for some reason I can't get to fix it.

UPDATE: Well, the blacklist is now fixed through a sort-of hack. Unfortunately I realized that I'll never get this done properly without a run time controller, so this is what I'll do next.

Edited June 17, 2014 by Ippo

[Ippo]

The third one is not really a bug: when a control surface is stuck, we can reenable the control with the GUI(the GUI hat enable to disable the control surface from controlling the yaw/roll1pitch of the ship).

Hey dude, sorry to bother you: could you check again to confirm? I just tested and while it's true that the gui is still displayed, it doesn't allow me to "fix" the control surface. At least for me, it remains stuck until I do the EVA repair.

Also, I don't know if I can hide those controls because they are not events, they are KSPFields and I can't seem to be able to edit their guiActive property.

[peachoftree]

For implementing decoupler fail- I havent made any mods myself, but I have poked around some code. Maybe you could try using module manager to overwrite ModuleDecouple with your own module that implements key interception in case of a failure.

[Ippo]

For implementing decoupler fail- I havent made any mods myself, but I have poked around some code. Maybe you could try using module manager to overwrite ModuleDecouple with your own module that implements key interception in case of a failure.

Bad idea: not only it's pretty much guaranteed to be incompatible with other mods but it would likely break the stock game too.

[Ippo]

Quick dev-rant: I hate tanks. Seriously. Everything was going easy swell and logical... and then you have to refactor EVERYTHING to accomodate for tanks.

Darned tanks >.<

[Ippo]

ALPHA 2.2 IS OUT

Check it out in the release thread