IRnifty

This is exactly why I am not writing classes for each type of failure. If an engine's circuitry were to malfunction in the real world, the worst case is erratic firing until it finally explodes. One class handling all computer failures simply cannot correctly model varying behavior on all applicable parts without writing spacialized code anyway. At this point, this specialized code is simply organized in a different way, one that IMO is less readable than simply separating by affected module. And besides, I don't personally mind writing specialized code for other mod's parts. It's really not that hard to extend what I already have, anyway. Simply define the new class, inherit "ModuleReliabilityBase" and you already have basic functionality, such as quality, reliability, part highlighting. All the extending code needs to do is specify the behavior the part will take on once it does fail.

No problem! Although, I'm going to change it later to be more centralized, such that the "Reliability Stats" on a part only shows what the failure chances are, and the central monitor will show current states, but still be subject to failure itself, as was discussed in your thread.

Ladies and gents, Alpha v0.2 is now available! A summary of the changes: - The entire system has been rewritten, such that failure modules no longer inherit the module they cause to fail. - Parts can now have multiple modules with failure capabilities. - The mod no longer replaces stock parts, but instead injects its modules once the game starts. - The engine's failure module has been split into three: Gimbal, Ignition, and Cooling - The information on all failure modules on a given part can be viewed by right clicking the part and selecting "Reliability Stats" - The quality of a part can be modified in the editor through the same window. - A part with a broken module will now glow red until fixed.

Actually, I have a different way of handling it. Let's take the engine for example. Usually, an engine part will have multiple components at work. For the typical engine, these are: - The engine, - The gimbal, - The alternator Simply put, I decided that every different component should have its own failure class, with the exception of ModuleEngines and ModuleEnginesFX, and ModuleDecouple and ModuleAnchoredDecoupler. These two groups will have combined classes. So the above mentioned typical engine would have 3 failure classes, one for the engine, one for the gimbal, and one for the alternator. BUT, I decided the engine module is too complex for just one failure class, so I broke it down to two, the ignitor, and the cooling system. Thus the engine part would now have failure classes for the ignitor, the cooling system, the gimbal, and the alternator. The last thing I decided to do was to add a final module which would hold these together and manage them. This last module would provide the ability to edit the "quality" of each individual module, allowing players to balance what is important on the parts. In other words, what can safely fail and what can't. At this time, I'm working figuring out how to go about allowing the player to edit the quality, be it through the right-click menu, or a separate GUI, considering parts should have no more than three failure modules. Once that's done, I'll be releasing version 2 of the alpha.

I don't think the player would get annoyed with it so much as simply care less about what exactly it says. But as it is right now, I have a repair option, which will in the future cost parts, and a kick option, which skips parts, but runs the risk of destroying the engine. How's that for an idea?

Calm down, don't get your panties in a bunch. I asked because I was in a hurry. But that doesn't matter now. I wrote my own code which injects my modules the way I need them to be injected. Problem solved. So as it stands, I should have an update soon to the alpha build I have on the OP. To anyone that want's to help me balance it, let me know so we can talk a bit.

We were previously discussing a "detailed status report" which would provide the reliabilities of the various parts, but could be subject to failure itself.

These are great ideas, and it may be simpler than you think. Take a rocket with an age of x. Make the effect of an inspection, or what I'd simply call maintenance, produce a reduction that is proportional to the age and also proportional to the time since the last inspection. Such that the lower the age, the lower the benefit; the lower the time since the last maintenance, the lower the benefit.

It isn't the hardest thing to do, but it would take some work... I'm sure I could achieve something decent given time. I'm actually trying to start talks with Ippo. I'm going to see if we can't share our ideas and make our mods better, or even merge them.

You know what? That's an interesting idea, but I'd call it a detailed systems report more so than a scan. And how about this: If the report contains false info, the report could also "glitch" in random characters, replacing others within the false entry containing the bad part, every second or few, such that with vigilance, the false report could be spotted and something done about it.

Hey Ippo! ('-')/ I'm IRnifty, the developer of the Kerbal Mechanics mod, which went into an accidental coma. I see you've made some interesting progress on your mod that I haven't thought of before! Do you think we could talk a bit? I think we could make a great mod if we pulled our ideas together.

Sorry guys for not keeping up with updates. I promise I'm reading the feedback and taking it into account. I'm simply very busy with work and a bunch of other projects. @Fraz86, since you're familiar with MM, mind making an example config file that'd add a module to every part that has a given module?

curiousepic, I do plan on doing this at some point, but I seem to be too busy at the moment with a few other projects and work, so when I can, I will. Also, I like that battery idea, Justin Kerbice.

I did just realize, however, why I actually have to replace the decoupler module... There is no way to override the decoupling functionality without replacing it, unless someone else can come up with something... EDIT: Maaayy be able to circumvent this... testing now...

undercoveryankee, MeCripp, PringleMan, and regex, You all have a very valid point, and the suggestion you all have unanimously given will likely become reality. The only reason it is as it is now is because I had no prior experience making custom modules. (C# yes, but not how each module works.) Now that I've learned a bit by accomplishing what I have so far, I can make the suggested change much more easily than when I started. So I completely agree with you guys, it's just like this because I was newer to this when most of this was written. Oh, and a few final notes: 1: I know the current repair process is too simple, and that will change once I gain more experience in this. 2: KSP has no money yet, so quality can simply be cranked up with no penalty, but that will change... 3: I really do appreciate the feedback, guys. You are all helping to make something amazing, IMO.

Any time. And I wouldn't be too worried about compatibility. Both of our mods are early alpha. Anything can change. Maybe with discussion, a new, better method can be discovered. I'm going to try and PM you my email.

ModuleEngineReliability inherits ModuleEngines. If you look at the cfg's, you'll notice ModuleEngines has been replaced by ModuleEngineReliability. Have you tried clearing your cache, cookies, etc? A different browser, maybe? What do you use?

Actually, each part has and only will ever have one module, unless others are required for the parts other functions. Failures are handled in each module, such that only one module is needed for a large multitude of possible failures. My engine module, ModuleEngineReliability, as an example, simply overlays standard engine behavior with failure checks. If a failure occurs, the overlaid class performs the appropriate failure code. My engine module currently handles 3 different types of failure, all in one module. I'm at work now, otherwise I'd link my engine module class. Just curious: why can't you access GitHub? Just can't sign in?

Yea... Although I don't know if there's too much that can be done about that. Also, I have added my project to GitHub. Check the OP for the source.

JefferyCor, I do plan to do something like this, but I know it as the KAS method, where it injects the ModuleGrab into everything. PringleMan, I wouldn't at all mind if you helped in this regard! HoneyFox, you can "tweak" the "quality" of a part in the editor. This will affect the price once money is added. Also, I know I'm supposed to supply source, an I will soon, but I did upload this mod at 2 in the morning where I live expect to see it within the next 24 hrs.

Indeed. I'll try to contact them soon. As it is, I really should be in bed right now...

Oh wow... You've really done up that list! I think I will be using this, thanks! And I had no idea anyone else was working on similar mods! I wish them all luck, and may the best mod win EDIT: Cpt. Kipard, you can tweak the "quality" of the part by right-clicking it in the editor (default 75%), or modifying the cfg's... Basically, the quality affects how fast the reliability drains. The lower the reliability, the higher chance something will happen.

Hello all, Allow me to introduce what I have so far developed of my mod: Kerbal Mechanics: Part Failures View on Main Thread Here

YOU SAVED MY KETHANE BASE!!! Although I don't think it's legal to redistribute, so I'd take that link down so you don't get into trouble. Leave the zip there so I can finish though.

My internet is naturally slow, but I can still download things. Testing right now with a 30 MB song I mixed up a ways back, and it's going just fine. The Kethane zip will not finish.