[0.90] Kerbal Mechanics: Part failures

[IRnifty]

Honestly, you should read the Instruction at MM's thread yourself. It is not that complicated, and it should not take you more than 5 minutes to master it.

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.

[Camacha]

I think "Fix Engine" should really be changed to "Kick Engine" =P

I would actually much prefer the context menus to be as neutral as possible. No bashing and kicking, just repairing. More imaginative terms are funny the first time, but that wears off quickly.

[IRnifty]

I would actually much prefer the context menus to be as neutral as possible. No bashing and kicking, just repairing. More imaginative terms are funny the first time, but that wears off quickly.

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?

[8749236]

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?

I like that...

Whos here to play properly anyway? xD

We are all here to mess things up >=D

I will look this up someday, perhaps I can give some idea...

*** Ideas incoming! ***

I checked your code..

Perhaps you can do a class of failures (i'm not sure how C# works... yet..)

Such as:

failure
- explode
- short-circuit
- burnt-out-circuit
- fuel_leak
- fuel_on_fire
- pump_failure

Or even complicated:

several abstract failure:

- explosion

- leak

- inoperable

Then derive childs out of them...

You can do the same thing for the probability of failing parts, too..

So you can re-use them for different modules...

Or use multiple of them simultaneously in one module..

Edited June 11, 2014 by 8749236

[IRnifty]

Perhaps you can do a class of failures...

Then derive childs out of them...

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.

[IRnifty]

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.

[Ippo]

- The information on all failure modules on a given part can be viewed by right clicking the part and selecting

"Reliability Stats"

I'm so gonna steal this from you

[IRnifty]

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.

[8749236]

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.

Well... it is better to mention in topic title which says: "Hey guys! I just updated it! come and check it out!"

Instead of keeping it the same..

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.

Well, my point is, find some similarities between failure.

Such as engine failure can be caused by mechanical failure (e.g. Turbo Fan disk blew up), electrical failure (e.g. short circuits), collision (e.g. hard docked with space station caused docking mechanisim inoperative) or random failure (e.g. engine misfire due to software error; structural failure due to bad parts) (extremely rare)

Then you can extend them easily... or define new failing behaviour when necessary...

Especially when you want to support other mods... are you going to make a failure module for every single potential component?

What about warp drive from KSPI?

- Warp field generator

- Energy Conversion Regulator

- Energy buffer

okay, 3 module, hard coded...

What about piston engine?

- Radiator

- ignitor (spark plug)

- Propellor

3 More! And theres more parts than you can think of...

Although most of them are pretty much in the same category, but there definitely will be some unique parts that has some unique components that requires to fail...

So, the idea is here: Why tries to have specialized class for each component? Why dont just create abstract class for each type of failures and pretends that they are the components? (Just display a message and no one will notice this dirty trick)

Furthermore, when you want to expand your mod to support other mod, you dont need to write a new class for that anymore.

All you have to do is just add some existing failures (mechanical, electrical and so on...), modify the outcome of failure when necessary (I recommend make this can be done in cfg file) or the trigger of such failure...

No need to write excessive and possibly repeating codes... just maintenance...

And no, there should be more than 3 failure modules (assume each module represents one possible case of failure, only).

There are various way that a device can fail.

For example, you computer can be electrocuted, burnt into ash, firmware error, battery explosion (if you're using laptop), virus invasion, hardware malfunction, etc.

All sorts of possiblity... Perhaps they will fall into same category, but different cases will yield different outcome. Perhaps you just need to reboot or format your computer. Or you just need to tear it apart and replace some RAM stick; or it is totally dead... Each requires different amount of efforts and different tools to fix it.. and yeah... time!.

Imagine your lander landed on the moon and noticed your heater is broken, all fuel are frozen solid...

And realized repairing your heater with available tools requires 3 hours and you only have 4 hours of supply on your lander (no mother ship in orbit) (TAC Life support)...

Then, challenge accepted:

- Return to Kerbin from Mun with 1 hour of supply!

Or when your lander is blasting off and suddenly software gone wrong, and it shutdown the main thrusters, and your falling back to ground like in Europa Report (that one is caused by icy fuel)...

Time for Rescue mission! (Assuming poor kerbal survived...)

[Ippo]

All you have to do is just add some existing failures (mechanical, electrical and so on...), modify the outcome of failure when necessary (I recommend make this can be done in cfg file) or the trigger of such failure...

No need to write excessive and possibly repeating codes... just maintenance...

And no, there should be more than 3 failure modules (assume each module represents one possible case of failure, only).

There are various way that a device can fail.

Hi, sorry to break into someone else's thread. I'm Ippo, I'm developing a mod with the same scope of this one.

Sorry but it just won't work that way: when a failure happens, you want to render the part unusable, and I can tell you that this is never an easy task in KSP.

One way or the other, you will always need dedicated code for every specific failure you want to implement, and yes, it's very likely that you will also need a dedicated module for new parts introduced by other mods.

This is because disabling a part is different for each of them. For instance, if you want to disable the reaction wheel all you need to do is set a flag and you are done; on the other hand, engines require that you also call another method to deactivate the particle fx, or you get an engine that is not running but still produces flames and sounds; my personal favourites are the light bulbs, you need to completely remove the ModuleLights from the part (effectively making it a part that can never produce a light) if you want it to stop responding correctly.

tl;dr: it's way, way more complicated than how you imagined it under the hood because there is no standardized way to disable / enable a part.

P.S: liking Europa Report?

Edited June 14, 2014 by Ippo

[IRnifty]

tl;dr: it's way, way more complicated than how you imagined it under the hood because there is no standardized way to disable / enable a part.

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.

Edited June 15, 2014 by IRnifty

[8749236]

Hi, sorry to break into someone else's thread. I'm Ippo, I'm developing a mod with the same scope of this one.

Sorry but it just won't work that way: when a failure happens, you want to render the part unusable, and I can tell you that this is never an easy task in KSP.

One way or the other, you will always need dedicated code for every specific failure you want to implement, and yes, it's very likely that you will also need a dedicated module for new parts introduced by other mods.

This is because disabling a part is different for each of them. For instance, if you want to disable the reaction wheel all you need to do is set a flag and you are done; on the other hand, engines require that you also call another method to deactivate the particle fx, or you get an engine that is not running but still produces flames and sounds; my personal favourites are the light bulbs, you need to completely remove the ModuleLights from the part (effectively making it a part that can never produce a light) if you want it to stop responding correctly.

tl;dr: it's way, way more complicated than how you imagined it under the hood because there is no standardized way to disable / enable a part.

P.S: liking Europa Report?

I think I need learn some C# before getting more into details..

Havent finshed my beginner's tutorial yet...

Perhaps it is way too different to C++ and Java?

[IRnifty]

I think I need learn some C# before getting more into details..

Havent finshed my beginner's tutorial yet...

Perhaps it is way too different to C++ and Java?

The problem isn't with the language. It's how Unity and KSP use it. First, I have to ask, do you know the basics on how KSP's ship engine runs? About the relationship between a vessel, its parts, and their modules? If you don't feel free to watch

. It provides plenty of useful info for beginners and advanced modders alike. Shoot, I find myself referring to a part of it from time to time, and I wrote it.

If you do know how KSP works, then you should automatically know that every single module in the base game is vastly different from the next. A single class for a type of failure happening across multiple different modules is just going to get too messy, because of those vast differences. At the point of finishing a single class, I guarantee you that you'll have done less work designing multiple classes for individual modules. Heck, a single engine was so complex, I decided to split it into 4 different failure classes. And one isn't even in my mod yet! You have to understand that I'm building my mod from the ground up to be easily extended by anyone wanting to add more failures for more modules. If Majiir want's his Kethane drills to dull, he should have little to no problem creating a single class indicating the failure behavior his drills should take on.

Bar-none, the simplest and most effective method of doing this is what Ippo and I are already doing.

Believe me when I say that both Ippo and I know exactly what you mean, and it would definitely make sense, if only all modules had a standardized method of controlling its behavior, but they don't.

[8749236]

The problem isn't with the language. It's how Unity and KSP use it. First, I have to ask, do you know the basics on how KSP's ship engine runs? About the relationship between a vessel, its parts, and their modules? If you don't feel free to watch

. It provides plenty of useful info for beginners and advanced modders alike. Shoot, I find myself referring to a part of it from time to time, and I wrote it.

If you do know how KSP works, then you should automatically know that every single module in the base game is vastly different from the next. A single class for a type of failure happening across multiple different modules is just going to get too messy, because of those vast differences. At the point of finishing a single class, I guarantee you that you'll have done less work designing multiple classes for individual modules. Heck, a single engine was so complex, I decided to split it into 4 different failure classes. And one isn't even in my mod yet! You have to understand that I'm building my mod from the ground up to be easily extended by anyone wanting to add more failures for more modules. If Majiir want's his Kethane drills to dull, he should have little to no problem creating a single class indicating the failure behavior his drills should take on.

Bar-none, the simplest and most effective method of doing this is what Ippo and I are already doing.

Believe me when I say that both Ippo and I know exactly what you mean, and it would definitely make sense, if only all modules had a standardized method of controlling its behavior, but they don't.

After my University =(

Thanks.. but perhaps that will be too late...

[IRnifty]

Ladies and gents, Kerbal Mechanics ALPHA v0.3 is now out! Take a look at the original post, or go to the new site, Kerbal Stuff, to see it there, and even get notified when I update again!

Also, shameless advertising: Check out my modding tutorial series, with up-to-date information compiled in one place, right here!

Edited July 12, 2014 by IRnifty

[Ippo]

Great! Can I suggest you to move the download link in the OP?

Also, I absolutely approve your decision to use kerbalstuff

[IRnifty]

Woops... I guess I deleted the link when I updated the description. Thanks for watching out!

[IRnifty]

Updated!

v0.3.1:

- Updated mod to KSP version 0.24.

- Fixed instant and automatic altimeter failures on all but one pod.

- IMPORTANT NOTE: Due to a fault in how part costs work, this mod currently DOES NOT support funds. An urgent email to Squad support has already been sent.

Edited July 18, 2014 by IRnifty

[IRnifty]

Updated!

Welcome to Funds support in version 0.4!

Changes:

- Updated mod to KSP version 0.24.1. (Compatible with 0.24.2)

- Added Funds support. Terrible quality parts (all modules 0%) cost 50% of the part's default cost. Default quality parts (all modules 75%) cost 100% of the default.

- Added thrust gauge failures. Excessively high g forces will cause the thrust gauge to display incorrect data. If multiple parts with gauge capabilities are present, all must fail to cause true failure.

- Added Reliability Monitor to all command parts. Has both quality and reliability, but no true failure. Low reliability results in inaccurate reliability data across the ship.

- Added a control panel to the Reliability Monitor that allows highlighting of parts with failed modules. Also allows the player to map the status of the ship's parts on the ship. (Green is good, red is bad.)

- Added option for quality changes in the editor to also affect parts in symetry with original part.

Edited July 25, 2014 by IRnifty

[IRnifty]

This mod is compatible with 0.24.2 with no issues.

[IRnifty]

Updated! Version 0.4.1 Alpha:

Changelog:

- Fixed the inability to fix the Altimeter and the Thrust Gauge.

- Fixed the Alternator fix action saying "Fix Altimeter" instead of "Fix Alternator".

- Fixed being able to perform additional actions on a spent decoupler.

- Changed Maintenance context action to read "Maintain <Module>" instead of the generic "Perform Maintenance".

- Changed the ship color map such that a part with a failed module will always appear red, regardless of the average reliability.

[IRnifty]

Updated! v0.4.2:

- Fixed Decouplers not completing contract tests when either exploding or silently failing.

- Lowered decoupler default chance to explode from 12.5% to 6.25%.

- Lowered decoupler default chance to silently fail from 50% to 20%.

- Fixed fuel tanks with more than one resource initially leaking one resource, and occasionally reloading with a different one leaking.

- Fixed more variables not loading properly.

- Changed "reliabilityDrain" variable names to "lifeTime" to coincide with the fact that they hold the number of days a part will take to hit 0% reliability.

- Added Small Spare Parts Container to tech tree under "General Construction" and fixed the base price to 100 FUNds.

- Set RocketParts resource unit cost to 1 FUNd per unit of RocketParts, making a full Small Spare Parts Container cost 600 FUNds.

[DKlarations]

Hello!

Firstly, I would like to say that of all the random failures mods, I prefer this one.

Secondly... I can't seem to find rocket parts anywhere? I have 0.4.2 can't seem to find them...

Slightly embarrassing when you have 100 people watching you stream :-P

[IRnifty]

Sorry about that! There was a tiny little build problem that overwrote the config files for my rocket parts container and removed it from the tech tree. Try re-downloading from the forums here and that should get the container into the "General Construction" node. Remember that you must go into the tech tree to unlock recently added parts if you've already unlocked that node.

Happy failing! ('-')/

[jandcando]

I had this idea a while ago, but I never really got to it .

Well since you are already on top of it, I would like to share with you the plan I had for my take on this. I really don't mind giving it to you, I don't even know how to make plugins for KSP yet. You can do whatever you want with it, I figured it might give you some ideas: https://www.dropbox.com/s/stw5bnmnhfjhghb/Goals.txt?dl=0