Ippo

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

In the first release they were much higher. I felt it was a little OP... so now I erred on the opposite side. 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. 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. 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).

However, it only works when the engines are off: if you are consuming fuel and re-assign the amount, the consumption is actually reduced, and not increased. Re-assigning the amount is only correct if the leak is the only flow in the tank.

Hello chris, I am doing that very specific type of thing and there is no other solution. Just wandering if anybody has any answer to ThermalShark's question, because otherwise I'm just going to go and lock all teh things. (I'm simulating a leak in a tank, so of course I want to drain only from that tank bypassing flow. If no one knows of a more elegant solution, I'm just going to set the flow mode of the resource in the tank and call it a day)

I should start paying you

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. 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. 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

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)

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)

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 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 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

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.

So basically, discount = a*age + b*inspection? I like this

Hey, sorry, I forgot to answer to you Of course you are absolutely right, any kerbal doing anything is definitely a little OP. There is one problem with parts only functioning partially: I have no idea how to do that, because the KSP objects were not really meant for this. Some of them are even very hard to disable at all: for reaction wheels, you only need to set one flag; for lights, you need to completely rip the light module from the part so that it technically isn't a light anymore. What you posted is something that I'd like to do further down along the road... but it might get pushed up if you tell us more about diagnosing ships at sea, this looks like one hell of a job

These ideas are very good for an interface, and I'll consider them. However, I'm more interested in how to model the effects on reliability My idea now would be twofold (I really hope it is an actual word): - temporary, partial immunity to failure: as I describe above, for a short time after the inspection the failure chance will be reduced, increasing linearly back to its normal value; - permanent discount on the age: for the maintenance to have any actual effect on the part, we need to reduce its age. In fact, in the current model, the failure chance is only a function of the age. I was thinking that I could subtract from the age a percentage of the time that has passed since the last inspection. Let's say that you have a tank that is 1 year old and was last inspected 6 months ago: for example, inspecting it now would remove 2 months from the part's age (or another fraction of those 6 months) thus making it more reliable from this point on. If I perform a new inspection 3 weeks from now, I only discount 1 week. On the other hand, we might discount a percentage of the total age of the part. This model is simpler, but has 2 BIG problems: - because of the non-linearity in the aging function (well, actually in the failure chance function) inspecting earlier is a lot more profitable than inspecting later; - also, I might just start spamming the inspection and effectively force the part's age to (almost) 0. This can actually be mitigated by having the inspection require the use of spare parts, so that spamming inspections actually becomes more dangerous than just risking it. Any thoughts? Because otherwise, I'm rooting for the second option. (as you might be guessing from my obsession with exponentials and formulaes, I'm an engineer IRL)

Thanks, I hadn't thought of wastes. Very good point Well, the pillar of this community is "Don't tell anyone how to enjoy the game", so play the way you like it, no need to justify On the other hand, maybe I could interest you in the pre-emptive maintenance feature that is on future features list The mod is still in its very early stages (it's barely even *functioning* at all right now) and there's a lot more to come. The main problem with pre-emptive maintenance is to find a way to make it useful but not OP. If you like, I'd like to discuss it in depth in the dev thread

Sure, PM me any time

Thank you, this list will surely come in handy, especially since I don't use most of those mods myself

Right now, I am handling my persistence using the OnLoad and OnSave of my part modules. However, I'm only doing part modules, so I don't know if it applies to your mod too. I followed the explanation they gave me here, and it's working without a flaw at the moment. I don't know if this is different for scenario modules and mono behaviours, though.

OH. MY. GOD. Like, seriously!? This really confuses me a lot, but it works Well, of course now I get a huge stream of NRE because I have to initialize stuff, but as soon as I launch and they get set, it all starts working like a charm. I'm a little confused on why this works (I guess that Unity actually checks via reflection if I defined a FixedUpdate() ), but nontheless, it does, and that's all I care about right now You, sir, just saved my mod. Here, have some rep

The problem is that PartModules don't have a FixedUpdate method, so of course I can't use it.

Hello everyone, I am noticing something very weird on my PartModule From my logs, it appears that the OnFixedUpdate method is only called when the part it is attached to is in the active stage. Is it by design? Or am I doing something wrong?

Ok cool. I suspected it was like this, I just wanted confirmation. Also thanks for the tip on setting it

Added a poll: I want to know what you think about timewarp handling. Also, on the brink of a nervous collapse. Oxider leaks, LiquidFuel doesn't. And Reaction wheel for some reason don't get loaded, but I find no error in the logs. Updated update: using computer science's most advanced tools and theorems, I was able to track both problems and solve them.

How can I know if the ship is in physical timewarp or not? I found TimeWarp.WarpMode, but I can only get high or low, which isn't very informative.

AWESOME! I really like the textures on the first one! Thank you for working on this About the repair drone: that's definitely a cool idea. I'll think about it and see if it's implementable, basically the only problem I see with it is finding a way to give it access to the repair event even though it's not an EVA (well, actually the real problem is to make sure that only drones are allowed to see it, and no other vessel). I'll think about it P.S: and don't worry too much about timing, because development is slower on my end any way.

Just a quick devnote to keep you guys up to date. Right now my code is going through a deep rewrite / inspection, because I had been handling the plugin's lifecycle wrong regarding the persistence. The persistence layer, by the way, is really getting on my nerves: for some reason, it has now decided that it doesn't feel like writing some fields to the persistence file, so of course when I reload it everything falls apart. -.- (Specifically, it is refusing to write a bool and a string. A bool, I could believe it, but the string!? EVERYTHING gets written as a string in there!) Update: moving forwards! In addition to the huge pile of bugs, now also the parts aren't aging anymore for some reason. .-.