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

[SaSquatch]

Asteroid Cities V0.5 adds the resources to the asteroids.

http://forum.kerbalspaceprogram.com/threads/79675-June-10-Asteroid-Cities-V0-5-Improved-grabbers?highlight=asteroid+bunker

might just not worth making compatible... eh

Edited June 28, 2014 by SaSquatch

[Ippo]

Oh, thanks. So are you using asteroid cities? Because if that's the case I'll close the bug on github

[SaSquatch]

Yea... that must be where it's from then.

hmm... if there were particle effect for leaks, this could be the start of a comet.

[Ippo]

Yea... that must be where it's from then.

hmm... if there were particle effect for leaks, this could be the start of a comet.

Gentlement, we have just promoted a bug to a feature!

[Ippo]

Hi everyone, I am working on the inspection now.

Basically, I decided to go for a somewhat cryptic message that is returned when you inspect a part that will give you only a ballpark idea of how bad the part is faring.

This is the code that produces the message:

        public virtual string InspectionMessage()
        {
            float ratio = this.Age / this.LifeTimeSecs;


            if (ratio < 0.10)
                return "This part seems to be as good as new";
            else if (ratio < 0.50)
                return "This part is still in good conditions";
            else if (ratio < 0.75)
                return "This part is starting to show its age";
            else if (ratio < 1.25)
                return "It looks like it's time to get a new one";
            else if (ratio < 2.00)
                return "It really isn't a good idea to keep using this part";
            else if (ratio < 3)
                return "This part needs replacing soon";
            else
                return "This part appears to be in terrible conditions";
        }

I would like to hear your feedback on this, and also I would really appreciate a quick grammar check by native english speakers

[Daishi]

Looking good, just trim off the "s" at the end of your "conditions"

[Ippo]

Looking good, just trim off the "s" at the end of your "conditions"

Thanks (it's plural in italian :/ )

[Ippo]

RFC (Request For Comment):

Regarding impacts and temperature, I feel that they should both increase the rate at which the part ages. Specifically, the temperature should increase the aging rate, while an impact should bump the age up. Of course, the more violent the events, the stronger the effect. I'm planning to model them like this:

- The temperature will increase the rate at which the age is accumulated. So for every second, the part gains (1 + t) seconds, where

t = ( T / maxT ) ^ n (maxT is the part's max temperature)

The exponent n allows me to control how much higher temperatures should be penalized: I'm thinking n = 3 right now, but n = 4 is a possibility.

- A crash will cause an instantaneous "bump" of the age, of the amount:

B = (v / maxV) * age (maxV is the part's crash tolerance)

however, with a threshold: if v < (maxV / 4) there is no penalty.

Thoughts about this? It is mainly due to reduce the randomness by linking the state of the part to your flying skills.

[Daishi]

RFC (Request For Comment)...

No complaints - this keeps getting better and better! Maybe you could tap into KSP's heat damage model somehow to save yourself some work (assuming this isn't built off it)? Scalable impact damage sounds fantastic - DangIt seems to be turning into one of those mods that should really be in stock

Also sent you an PM, reply when you can.

[NathanKell]

The temperature one is problematic: it's unduly generous to parts in cold environments, which might actually make them brittle.

I would suggest having some penalty for t < 20C, say, increasing rapidly as t approaches -273.15 (absolute 0).

That said, I *really* like this. It's worth remembering that one reason arguing against making reusable rockets is that a single (or maybe 2) launch-length burns of an engine make it unsuitable for reuse in terms of (questionable) reliability.

Daishi: KSP doesn't *have* a heat damage model. What it has is a crappy heat dissipation/addition model (each tick, some constant times the difference between the part's temperature and the environment is added to the part, or subtracted if hotter than the environment) and crappy heat transference model (if a part is connected to me and less than ~5m away, do the same thing as above replacing "environment" with "other part"), and then the part explodes if part.temp > part.maxTemp. That's it, aside from the few things (like engines) that "produce" temperature.

Edited July 11, 2014 by NathanKell

[Ippo]

...

Thanks Answered.

The temperature one is problematic: it's unduly generous to parts in cold environments, which might actually make them brittle.

I would suggest having some penalty for t < 20C, say, increasing rapidly as t approaches -273.15 (absolute 0).

I understand your point, and it's absolutely valid: however, if you check the temperature you spend most of the time in space around -200°, so it needs to be balanced more carefully or it becomes insane.

Right now, in the latest commit I am using this formula:

3 * ( T / maxT ) ^ 5 

that seemed good to me for high temperatures. Maybe I can use a similar function for the negative range, like:

k * ( |T| / 273.15 ) ^ n 

with k and n to decide. What do you think about that? (Also, you are basically the unofficial scientific advisor of this project)

EDIT: Nathan, you are going to love this one when I get to implement it

EDIT 2: I have been thinking about it, and I think that penalizing negative temperatures is not fair because they are outside your control. You can limit positive temperatures by flying better or using heatshields. However, once you are in space there is nothing you can do to control the temperature: so you are not penalizing low temperatures, but you are basically changing the base aging rate. However, I could see this feature working only if I also implemented some sort of heating mechanism, like a generator that consumes electric power to keep your parts warm.

Edited July 12, 2014 by Ippo

[Ippo]

Also, I'm thinking about postponing the perk system to alpha 4. With .24 nearing release I will have to recompile / redistribute again, and I'm going slower than I expected.

Well now they posted the gameplay video, so 0.24 must be *really* close -> perks are moved to alpha 4 so that I don't have to rush the biggest feature.

Edited July 12, 2014 by Ippo

[NathanKell]

Hmm. Good point about not having control.

Might be worth ignoring it until someone rewrites (writes? ) a decent heating model, especially a decent one *in space*.

And yes, LOCA sounds great

[zengei]

Secondly how about adjusting part reliability based on how many times it's been used (mostly for career mode I think) so that newly unlocked parts would be less reliable, becoming more so as the part is ether used more or time passes since it was unlocked. This would model ironing out the kinks of a new part and give the older parts a small advantage over newly unlocked but more advanced parts.

I really like this idea. In fact, I came here to post this after watching Scott Manley's Interstellar Quest Episode 10, where he basically

.

It would encourage reusing existing designs and testing new designs before using them "for real".

[IsamuHigashi]

I really like this idea. In fact, I came here to post this after watching Scott Manley's Interstellar Quest Episode 10, where he basically

.

It would encourage reusing existing designs and testing new designs before using them "for real".

I thinks so too but how about also add Contracts where you have to test a Part [like the ones that wil be in 0.24 already] and if completet gife that part a Reliability bost or somthing

[Ippo]

I really like this idea. In fact, I came here to post this after watching Scott Manley's Interstellar Quest Episode 10, where he basically

.

It would encourage reusing existing designs and testing new designs before using them "for real".

However, it's really really easy to cheat around it: launch and recover from the pad enough times and you are good.

A better system would be to track the total use time for a part and increase the reliability to the nominal value as time goes by, but it might get complicated code-wise.

I thinks so too but how about also add Contracts where you have to test a Part [like the ones that wil be in 0.24 already] and if completet gife that part a Reliability bost or somthing

This, instead, is more sensible imho: drastically reduce the reliability during test flights, and then when you buy a part off the shelf it has the nominal failure rate (which would be also more realistic lore-wise, since apparently now all the parts are built by contractors and therefore if you can buy it it's out of development).

[goldenpeach]

A cool feature would be to pay for the reliability of a part: the more you pay, the more reliable the part is; it would permit for short mission to be less expensive(because you don't need as much as reliability) while a interplanetary mission will cost you more.

Also, it will make you choose between having less failures with a higher price or a lot of failures but more spare parts.

[Ippo]

You won't believe the coincidence, I was just reflecting on how this mechanism could be implemented

I want to add this, one day. I'm not really sure how to fit it in the code, but I'll figure something out.

P.S: I hadn't seen you in a while... I was getting worried

[goldenpeach]

Well, as you said it, I was busy IRL

Oh,(just for the sake of humour), my absence can be considerate a good new: it mean that I haven't found bugs!

[Stage]

Hey Ippo!

I really like your mod, I've been missing this function since the beginning of KSP

Could you add support for MKS/OKS, maybe Karbonite to your mod?

Would be great!

Regards,

Stage

[Ippo]

Hey Ippo!

I really like your mod, I've been missing this function since the beginning of KSP

Could you add support for MKS/OKS, maybe Karbonite to your mod?

Would be great!

Regards,

Stage

Can you please elaborate? What features would you want, specifically?

[Stage]

Yeah, probably should have been more clear

I thought about adding some of the MKS ressources to your blacklist.

I think those should be on it:

PunchCards

MEP-Computing

MEP-Environmental

MEP-Mining

MEP-Laboratory

MEP-Manufacturing

MEP-Refining

I just started a new game with DangIt and MKS, so I'm not quite sure if that's all.

[Ippo]

I'll take a look and see what resources are added by MKS. In the meantime, you can add them yourself to the blacklist, just follow the format I used for the others.

[Aknar]

Don't know if you've seen the graphs I posted and if you found them useful: #26,#27,#33

As I explain in this post: #1, I'd like to see a tech tree based on part upgrades, not obtaining the parts themselves. Having all the parts from the start but having to upgrade them with modules to be able to do bigger more complex missions seems more logical to me. Upgrading them to make them less prone to failure would fit perfectly into this idea (more modules means more types of failures). Any plan on making an optional tech tree patch?

Edited August 4, 2014 by Aknar

[Ippo]

Don't know if you've seen the graphs I posted and if you found them useful: #26,#27,#33

As I explain in this post: #1, I'd like to see a tech tree based on part upgrades, not obtaining the parts themselves. Having all the parts from the start but having to upgrade them with modules to be able to do bigger more complex missions seems more logical to me. Upgrading them to make them less prone to failure would fit perfectly into this idea (more modules means more types of failures). Any plan on making an optional tech tree patch?

I had a quick glance at your charts (I am a bit tied up atm): I see someone has studied HAZOP Thanks for the input, I'll scavenge utilize your tables to design some more failures down the line.

As for the tech tree, I'd like to do it MechJeb style: unlocking a placeholder part that enables more behaviours. It will probably come in two "lines" of upgrades: one line for reliability out of the box, and one for better inspections / repairability. It's all very theoretical atm, since 1) I need to to some heavy code changes before I can go on and 2) I honestly have no idea how to deal with the tech tree.

(Also, back from vacation, development resumed)