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

[Ippo]

I was thinking more thematically then technically how to do it. "No Connection" state equivalent to unmanned, while a "Connection" equals a "manned" vehicle. Thematically... establish a connection to a probe for the first time in months or years to discover all of the issues that have popped up since it went silent.

Well, using the connection would grant the unmanned boost to manned pods.

Also, for the sake of simplicity/accessibility I decided that failures are not going to happen on unloaded vehicles.

[Tiberius]

Since we are bringing up RemoteTech: I'd love to use it to check if we have a com link to the KSC and having the worst failures, like engines, require the com link. Unfortunately I see that remote tech is on hiatus, so I'm not in love with the idea of an outdated dependency.

Thanks for the reply. You might be glad to hear RemoteTech is officially [Development Resumed]. Cilph has handed the open source project over to a number of community contributors to continue development. They have just released a 0.23.5 compatibly binary and plan on releasing another update soon.

I also love your idea of Kerbals needing help from the KSC engineers on the ground. In a real emergency that's a huge advantage. "Have a com link to the KSC and have the worst failures, like engines, require the com link." Its perfect. I wouldn't make it a dependency, just an optional level of difficulty for players who have RemoteTech installed. RemoteTech players are masochist and will enjoy it. It gives them another use for their communication relays and maybe even stock antennas

Edited June 20, 2014 by Tiberius

[AndersW]

Maintenance:

Maintenance is like an inspection in the sense that it can be carried out only on parts that haven't failed yet. It does, however, cost some spare parts (I was thinking 1 spare part for everything and let's call it a day) and have a permanent effect on the part's age, thus a permanent increase in reliability*.

For example, each module could have a coefficient between 0 and 1 and when you do the pre-emptive maintenance on it you subtract this fraction of the part's age. So if a module has a coefficient of 0.3, at each maintenance the part gets its age reduced by 30%.

The cost also has the function to discourage spamming the maintenance: however, it might be best to add a minimum time between maintenance to prevent the player from completely restoring the part to factory conditions, if they are willing to shell out enough resources.

For maintenance I would recommend something like the science lab. A maintenance bay that needs to be manned, and consumes spare parts at a set rate. This effectively slows the aging of parts, but you can set the rate of consumption so that the parts still age. It also takes the maintenance out of the hands of the players so they can't abuse it. And the repair bay idea could be added to manually done maintenance instead of replacing it entirely. Like a maintenance bay jr that allows you to run maintenance manually, and the manned maintenance bay that runs maintenance automatically and might be more efficient.

[MissionController3134]

FAR remove the Control Surface module and replaces it with its own version, which in turn causes a NullReferenceException in my control surface code.

I need to specify that actually it's the only problem: removing the control surface cfg makes it work (without control surface problems, ofc)

Oh... that makes sense...

[mic_e]

On the topic of unmanned probes: I think when budget is implemented (somehow, e.g. with a 'reliability slider'), this problem will solve itself; you simply can make critical components redundant and/or spend more cash on reliability. Of course, spending less cash on manned mission reliability because 'we can fix it anyway' might not be the most realistic thing...

One problem I see: It will be rewarding, but incredibly boring and time-consuming to get out and inspect every single part when still on the launchpad. Marking all parts as inspected before lift-off would solve this problem, but I kind of don't like that solution (come on, no failures during launch?). What about adding a small chance that an unskilled Kerbal will break things (make failures more probable) during inspection?

I agree that it would be far too tedious to only provide reliability monitoring when a Kerbal is on inspection-EVA.

The G-Force thing I suggested would have the benefit of making failures (much?) more likely during launch (or those 'special' landings where you smash into the atmosphere at 90 degrees). IMHO, it would add so much to the realism that it would simply be worth it.

Edited June 20, 2014 by mic_e

[Ippo]

On the topic of unmanned probes: I think when budget is implemented (somehow, e.g. with a 'reliability slider'), this problem will solve itself; you simply can make critical components redundant and/or spend more cash on reliability. Of course, spending less cash on manned mission reliability because 'we can fix it anyway' might not be the most realistic thing...

You know, probably in the end it's just easier to silently buff the reliability of unmanned vessels, as in "doubling the MTBF without telling the user".

One problem I see: It will be rewarding, but incredibly boring and time-consuming to get out and inspect every single part when still on the launchpad.

If one is willing to take the time, it's his call. Parts won't be marked as inspected at launch because yes, that would be OP.

Also, one (far away) day there might be integration with Launch Count Down by Athlonic (awesome mod, you should check it out) and it would likely rely on an INCREASE in the chance of failure at launch. I'm just posting this minutes after they cancelled yet another SpaceX flight because there was a problem ON THE PAD.

I agree that it would be far too tedious to only provide reliability monitoring when a Kerbal is on inspection-EVA.

Why don't we choose both? Inspection only until you unlock a "reliability computer" or some other woo like that, that gives you the ability to get the full-ship report.

The G-Force thing I suggested would have the benefit of making failures (much?) more likely during launch (or those 'special' landings where you smash into the atmosphere at 90 degrees). IMHO, it would add so much to the realism that it would simply be worth it.

To be honest, I'm not a huge fan of this idea. However, it's very simple for me to add... so if anyone has anything against it, speak now, otherwise it's in.

[BudgetHedgehog]

so if anyone has anything against it, speak now, otherwise it's in.

Would not want.

[Ippo]

Would not want.

That's not much... care to elaborate?

Also, I was thinking that it can already be accomodated into my framework on a per-module basis.

For example, right now engines have a failure chance that depends on the throttle (... I did mention that, did I?): the same thing can easily be done for tanks. However, I don't see any other part for which it would make much sense except engines and tanks... and engines already have the throttle effect.

[mic_e]

Throttle-based tank failures make only a moderate amount of sense to me... even at full throttle, tanks are not neccesarily being drained (different stage, no engine actually firing, ...)

<propaganda>think of g-based failures not as 'more failures', but as 'failures at more appropriate times, and less when safely in zero g'</propaganda>

[BudgetHedgehog]

That's not much... care to elaborate?

Would not want:

The G-Force thing I suggested would have the benefit of making failures (much?) more likely during launch (or those 'special' landings where you smash into the atmosphere at 90 degrees).

EDIT: to expand even further: I don't want failures to happen much more often during launch - with the amount of mods I'm running/if it's a high part count ship, for things to go SNAFUBAR right at launch is basically either a 'Revert to Launch' which means minutes of pointless waiting for loading to happen or an emergency abort sequence which means waiting to land safely, recovering and THEN waiting for loading to happen. My play time is limited, I don't want to have to keep on reverting/aborting launch simply because failures happen most often at that time - one thing that should be always at the front of your mind is "gameplay will always ALWAYS beat realism in an enjoyable and fun game". I wouldn't have installed your mod if I wanted to lower my enjoyment of this game.

EDIT 2: that said, I guess that while running FAR, that would make an interesting combination if my plane manages to not fall apart.. if it doesn't there'll be high-Gs involved which under that suggestion would mean a part failure.. but then again, that would also mean pointless waiting until I either land safely or crash unsafely.. If things go wrong, I want to be able to fix them and in atmo/during launch, I am unable to do so.

Edited June 21, 2014 by ObsessedWithKSP

[Ippo]

Throttle-based tank failures make only a moderate amount of sense to me

I actually meant that, just like engines are effected by throttling, tanks might be affected by Gs using the same system.

Also, just like engines are the only part affected by throttle, tanks might be the only (or one of the few) parts affected by Gs.

EDIT: to expand even further: I don't want failures to happen much more often during launch - with the amount of mods I'm running/if it's a high part count ship, for things to go SNAFUBAR right at launch is basically either a 'Revert to Launch'

On the other hand, having the G meter influence the failure chance would also affect other parts of gameplay other than launch: as mic_e said, there's also reentry and other manouvres.

Basically, what I need to do is replacing the current poll with a new one: how can I do that? I can't find the option anywhere

[BudgetHedgehog]

On the other hand, having the G meter influence the failure chance would also affect other parts of gameplay other than launch: as mic_e said, there's also reentry and other manouvres.

And as I said, if things go wrong, I want to be able to fix them and in atmo/during launch[/during re-entry], I am unable to do so. High-Gs may occur with a particularly sharp turn with a plane but again, I'm in atmo and I can't easily EVA and repair things. I'm not suggesting a complete blacklist on failures in atmo (some aren't important such as the engine alternator/throttle or fuel tank leak.. It's entirely possibly that I could still make orbit even with those failures), but just that I don't think tying high-G to failures is a good idea.

[Athlonic]

I actually meant that, just like engines are effected by throttling, tanks might be affected by Gs using the same system.

Also, just like engines are the only part affected by throttle, tanks might be the only (or one of the few) parts affected by Gs.

On the other hand, having the G meter influence the failure chance would also affect other parts of gameplay other than launch: as mic_e said, there's also reentry and other manouvres.

Basically, what I need to do is replacing the current poll with a new one: how can I do that? I can't find the option anywhere

Regarding, launch failures (even is this feature is far far away and beyond from now ^^) we definitely should boost failure chance only on a limited bunch of parts (main sail engine/main tanks or first stage parts only).

Because I can see a problem when using fairings if an enclosed part fail or like ObsessedWithKSP said, on a 400 parts vessel.

Every suggestions are welcome, of course

[VaporTrail]

Had a "ah ha... HA ha..." sort of moment when reading the release thread.

Failure event for Universal Storage bays: If open and failed, or failed and subsequently opened, Bay will not close without being fixed.

Minor annoyance for anyone using standard aero... but I think it'd be a pretty big problem for anyone using FAR and DRE.

As far as "fairing enclosed parts." I'd think that fuel leaks, and such shouldn't be considered... But perhaps things like Deployment Jams (landing gear, radio masts, and solar panels refusing to deploy...) might be good. Stuff you can EVA and fix after the fairing is removed... but that aren't going to be such a PITA that starting the flight over from scratch is the more attractive option.

[edit] Big freaking lightbulb... Has anyone suggested this before?

Might want to hook up with whoever's got control of Chatterer and see if there's any way you can set a trigger for Chatterer to play some of their excited Kerbalish whenever DangIt fires. Would be an awesome complement to DangIt's functionality.

Edited June 21, 2014 by VaporTrail

[Ippo]

Had a "ah ha... HA ha..." sort of moment when reading the release thread.

Failure event for Universal Storage bays: If open and failed, or failed and subsequently opened, Bay will not close without being fixed.

Minor annoyance for anyone using standard aero... but I think it'd be a pretty big problem for anyone using FAR and DRE.

I'm not sure I'm following. Might be the beer. Did I mention I brewed some beer? It's terrible. Anyway, back to the point: are you proposing a feature or did you find an incompatibility with universal storage?

As far as "fairing enclosed parts." I'd think that fuel leaks, and such shouldn't be considered... But perhaps things like Deployment Jams (landing gear, radio masts, and solar panels refusing to deploy...) might be good. Stuff you can EVA and fix after the fairing is removed... but that aren't going to be such a PITA that starting the flight over from scratch is the more attractive option.

That depends if I can get procedural fairings to tell me if it's inside a fairing or not.

[Paul Kingtiger]

You know, probably in the end it's just easier to silently buff the reliability of unmanned vessels, as in "doubling the MTBF without telling the user".

If you are going to take that approach would it be possible to have the multiplier in a settings.cfg file so that it could be adjusted by the user. That would some added flexibility for those who want to have a higher failure rate on unmanned craft.

[Ippo]

If you are going to take that approach would it be possible to have the multiplier in a settings.cfg file so that it could be adjusted by the user. That would some added flexibility for those who want to have a higher failure rate on unmanned craft.

People like me basically If I decide for that, I'll make sure to put it in a cfg. Personally, I still don't like that idea though.

[Ippo]

Also, quick progress report. I know I haven't been really active recently, but I have some RL things to handle, plus the release thread seems suspiciously quiet: this can't be good.

Anyway, I have been working on the persistence system that you might have seen in my signature. After a substantial help from codepoet, CrewFiles is really starting to look pretty much usable and stable! However, I haven't abandoned DangIt: in fact, CrewFiles has started like a part of it and then realized that it was better off as a separate API, but since DangIt will use it as soon as its ready, in a sense it's still part of the main mod

I haven't seen much feedback about the perks, though: what do you think about it? If you don't mind going back to my plans post, I'd like to hear your ideas about that, I'll have to start working on that soon.

[Daishi]

I'm all for your perk system, it always bugged me that the stock stupidity and courageousness traits did nothing useful. Adding more skills and unique (improvable?) traits would really help you get attached to your Kerbals and value their lives more - having a trained pilot wing suited for repairing\maintaining spaceplanes would be epic (If this kind of thing is covered in your Crewfiles mod, i apologize. Haven't really looked at it properly). Would be icing on the cake if 0.24 budgets made highly skilled crew painful to lose.

Dividing parts\ part failures into groups (say liquidfuel vs jet engine failures) and assigning skill tags to them would naturally go hand in hand. Of course if this is all part of your grand plan outlined in detail i can't find on my phone, ignore my musings

Failure event for Universal Storage bays: If open and failed, or failed and subsequently opened, Bay will not close without being fixed. Minor annoyance for anyone using standard aero... but I think it'd be a pretty big problem for anyone using FAR and DRE...

We don't have mesh colliders on our doors, mainly for performance issues (40% reduction in physics engine calcs), so having them open or closed during re-entry wouldn't actually make a difference to aerodynamics. Its only cosmetic geometry, so FAR would ignore it. Sorry

Edited June 25, 2014 by Daishi

[SaSquatch]

Has it been said that Asteroids need to be on the blacklist?

[Ippo]

Has it been said that Asteroids need to be on the blacklist?

... what. Asteroids hold resources!? (Strangely enough, I haven't even tried to grab one yet. For real)

[Daishi]

... what. Asteroids hold resources!? (Strangely enough, I haven't even tried to grab one yet. For real)

Join the club. Argh

[Ippo]

Update: I just checked and the Potatoroid (the actual name of the part: no, really) doesn't contain any resource definition, so by definition it can't leak anything.

[SaSquatch]

The two i just docked to had the "puncture tank" on them.... I wonder if the TAC resources that got added to them was what was targeted.

[Ippo]

The two i just docked to had the "puncture tank" on them.... I wonder if the TAC resources that got added to them was what was targeted.

wut

This doesn't make any sense to me, because I don't load the modules dynamically

I'll investigate as soon as I can.