[KSP 1.0.X] Kerbal Mechanics: Part Failures and Repairs v0.6.4.1

[IRnifty]

Updated! v0.5:

- KSP 0.9 compatibility update. Fixed IPartCostModifier bug and part highlighting bug resulting from changes between 0.25 and 0.9.

- All proper repairs require a Kerbal with the Engineer skill, with varying degrees of experience. Improper repairs remain accessible by any Kerbal.

- All proper repairs can be done by any Kerbal of any experience if not in Career Mode.

- Reduced Decoupler chance of silent failure from 20% to 10%.

- Module Injector now searches all config files for injections, allowing separated injection files.

- Modified reliability drain logic to properly reflect the Kerbin 6 hour day.

[Phenakist]

I have a couple questions about this mod, in theory I feel like this is a great addition to making KSP more immersive, however in it's current implementation I find it way too intrusive on the game.

As it stands, things such as leaks can go hugely unnoticed, there's no possible way of telling I am leaking anything when I have several ships in the sky, no popup that alerts me to a possible mission catastrophe like loosing all my oxidizer whilst time dilating. I am well aware there is a colour coder to show potential issues, but I feel a time dilation reducer to x1 and a pop up warning me would be a more reliable system, accompanied by the nice colour coding overlay (much like how it works in the life support mod that does all this to make it 100% clear something bad has happened)

Another question I have is regarding fixing decouplers. Is it possible? I did an EVA to try and manually pop the decoupler myself and I could see no possible way of doing this. Am I missing an option?

I hope this is taken as positive feedback because this mod is great, and I am aware it's in alpha so I thought my input would be appreciated, but until some of these are addressed I manually edit the config so leaks // decouple fails cannot happen.

Carry on the great work!

[superkurbol2014]

I wanted to try this mod but I am using the idskillful weapons and damage mod. Would this two mods conflict with eachother?

[Invader Myk]

IMO the coupler failure is a bit high. 10% silent + ~6% explosive x2 couplers for a basic surface to orbit rocket means that there is about a 1 in 3 chance of failure in a part at a vital point in the flight.

If that failure rate were what NASA accepted, then every launch would be a Challenger.

[IRnifty]

Phenakist, I appreciate your feedback. That is strange, as I have a function designed to stop time warp along with alerting the player should a failure occur. I had thought I forgot to add that function to tanks, but it seems I didn't. Testing will be required, so I'll get back on that. However, there is already an overlay option, found in every command part. Right click, "Get Ship Status", which will open a small dialog which allows you to view the state of every part affected by my mod. As for decouplers, yes you can fix them, but you must use an Engineer or be in Sandbox or Science Mode to use the proper fix option. I think I want to redesign how and when decouples fail anyway. As it is, it's impossible to determine if a decoupler will fail or not until you need to use it, since that isn't determined by the mod until then.

superkurbol2014, I'll have a look at the mod and do some testing. My mod operates by placing additional modules onto parts which override the original modules, so there may be a possibility. I'll have to check and get back on that.

Invader Myk, still too high, huh? I'll reduce it yet some more in the coming update.

Again, thanks all of you for the feedback. It is deeply appreciated.

[Invader Myk]

A bit of backwards planning might be useful for setting individual part failure rates.

How often do you want a flight to suffer a mechanical failure?

How many of each failable part are on a typical (read not made under the "enough thrust and fuel will get anything done" school of rocketry)?

Divide the desired overall failure rate by the number of failable parts.

So, if 1 in 10 flights suffer a failure, then each flight has a 10% failure rate.

If an average flight has 3 engines, 3 tanks, 2 decouplers, and a command module then each individual part has (dividing fail rates evenly) just over a 1% failure rate.

This could be further refined by separating failures into catastrophic and non-catastrophic. Such as a higher fail rate for an orbital transfer engine, that isn't vital to atmospheric flight and can be repaired before it is needed again, than the main sequence engine, that will cause the flight to fall out of the sky with no hope of repair.

[IRnifty]

Yes of course. It would make sense to make landings easier in order to provide an entry level of challenge, but those who install the mod want the challenge of realism. Therefore, it is best to leave it just as possible to fail while landing/taking off as it is for a 10 minute orbital transfer.

And the stranger thing, in my career play, provided I've only been to the Mun so far, I've had a total of 3 failures excluding decoupler failures. One was an altimeter failure on a muli-pod jet, so no real harm. Another was a glitched engine failure, and the third was a tank failure on my SCANsat probe, which I thus was forced to leave in orbit for future return. This is at around a total of over 50 flights. That's a 6% failure rate.

Now if I were to include the decoupler failures, over half of those were within "simulations" made possible with a mod that causes build times, which also provides paid simulations (basically a test run of the craft which costs around 5% of the original craft). The other half of the decoupler failures I right clicked on the part during flight and spammed decouple until it exploded. I'd say those failures increased the actual flight failure rate to about 10%-12% in total. By my books, even with their high rate of failure, decouplers so far have been a very minor setback, usually only causing a small loss in efficiency due to carrying around dead weight.

Oh, and Phenakist, failures currently cannot happen if the vessel is unloaded. This means you must be near or controlling a vessel in order to receive a failure.

Edited February 2, 2015 by IRnifty

[IRnifty]

Updated!

v0.6:

- Added settings option to stop time warp when a failure occurs. Default on.

- Added settings option to display an alert dialog when a failure occurs. Default on.

- Added settings option to highlight in red the failing part while the alert is open. Default on.

- Added icon to the KSP toolbar (A.K.A the "App Launcher") which handles the new settings and the ship status highlighing.

- Removed "Highlight Failed Parts" ship status option. Failed parts now automatically display as red when ship status highlighting is active.

[Phenakist]

this update sounds amazing will download tomorrow!!

[Dres]

*Sees Logo, clicks, reads Thread, INSTANT DOWNLOAD*

[Papa_Joe]

Hey IRnifty,

I'm the author of Ship Manifest, and I've found a conflict in your mod with other mods during highlighting.

I also highlight parts when selecting resources and your method is turning off my highlighting, as it is firing every frame. This was confirmed by a user that isolated the issue to your mod.

Specifically, in your Update method, you test for "highlightcolor != kerbalgreen" to see if you need to turn off highlighting. During my update of Ship Manifest's highlighting in the last version, I attempted to do exactly the same thing. What I found is that you cannot match the color specified. So, your logic as written will always return true and you are actively turning off highlighting every frame.

I had to use a different method. I tested for the presence of the colors I use for highlighting and then turned it off if they were present. Not as elegant as I would like, but it limits the call to only my own highlighting, and prevents me from "stepping on other mods".

Alternatively, you can overload the part class and add a highlighted flag to your new class, keeping track of what you have highlighted... then use that class to build your part list Instead of the part class. This works as well, and is a method used by Connected Living Space.

Let me know if you would like me to do a pull request with a proposed solution.

Also, with the addition of Hatches in CLS, and its new third party hatch support, I'd love to see a failure mode for Life Support Leaks. This would then allow for the "need" to close hatches, and limit your atmosphere life support losses... It would then render the part(s) not habitable and necessitate repairs... SM now allows you to close hatches centrally, so it adds a level of immersion. This would also add a new layer to design, as you would want to "limit" exposure due to potential leaks and may wish to redesign with airlocks in mind....

Thoughts?

Edited February 10, 2015 by Papa_Joe

[IRnifty]

Papa_Joe, hmm... Interesting. Ok. I'll have a bit of a look at how I implement my highlighting system. Likely, what I can do is, when a player turns on highlight, set an internal bool to true, and when they turn it off, only reset highlighting only once if that bool is still true and then set it to false. Shouldn't be too hard. Perhaps this could work well with other mods that highlight.

Or... Perhaps... Maybe a highlighting manager mod should be created and thus used by any mods wishing to highlight, since the currently implemented highlighting system allows for too much conflict. I'm going to implement the first of my ideas and then message you about possibilities for that highlighting manager. Thanks for letting me know about the conflict.

EDIT: So I've tested my implementation, and it works well, but it currently overrides your coloring only while mine is active. I personally consider this fine. But other than that, it works well, because when the user turns my highlighting, yours is reinstated properly following one frame.

Edited February 10, 2015 by IRnifty

[Papa_Joe]

Papa_Joe, hmm... Interesting. Ok. I'll have a bit of a look at how I implement my highlighting system. Likely, what I can do is, when a player turns on highlight, set an internal bool to true, and when they turn it off, only reset highlighting only once if that bool is still true and then set it to false. Shouldn't be too hard. Perhaps this could work well with other mods that highlight.

Or... Perhaps... Maybe a highlighting manager mod should be created and thus used by any mods wishing to highlight, since the currently implemented highlighting system allows for too much conflict. I'm going to implement the first of my ideas and then message you about possibilities for that highlighting manager. Thanks for letting me know about the conflict.

EDIT: So I've tested my implementation, and it works well, but it currently overrides your coloring only while mine is active. I personally consider this fine. But other than that, it works well, because when the user turns my highlighting, yours is reinstated properly following one frame.

Agreed, the plugin with focus should have the priority imho. I'll take a look at what Farrem is doing and see if we can come up with a standard pattern for highlightng

Thanks for taking a look at this!

Edited February 10, 2015 by Papa_Joe

[IRnifty]

Updated!

v0.6.1:

- Fixed part highlighting compatibility issue with Ship Manifest (and any other mod that highlights parts).

[Papa_Joe]

Updated!

v0.6.1:

- Fixed part highlighting compatibility issue with Ship Manifest (and any other mod that highlights parts).

Sweet! Thanks so much!

[IRnifty]

Updated!

v0.6.2:

- Fixed KSP App Launcher bug when switching to the main menu and back.

- Fixed bug with App window not showing when an alert is showing.

[IRnifty]

Updated!

v0.6.3:

- Fixed App window bug on resolutions other than 1080p.

[Malah]

Updated!

v0.6.3:

- Fixed App window bug on resolutions other than 1080p.

Thanks I will try it tonight

[Papa_Joe]

The latest version of Ship Manifest (SM) now has Deployable Solar Panel management. It supports the "BROKEN" state, and prevents extending/retracting the panel when the panel is in this state. Since it is a dashboard, you can quickly see what panels may need repairs in your vessel or station.

If Kerbal Mechanics has this failure mode, you can now detect it. If it doesn't I recommend adding failures for solar panels...

Edited February 18, 2015 by Papa_Joe

[IRnifty]

I have not yet created a failure module for solar panels because it's difficult dealing with panels that are physically broken by impacts. As it is, once they're broken, you can't click on them anymore, and then in order to actually repair them, I'd have to destroy the old part in code and recreate it, which I'm sure is possible, but physically modifying ships is a bit out of my range at the moment.

[Papa_Joe]

I have not yet created a failure module for solar panels because it's difficult dealing with panels that are physically broken by impacts. As it is, once they're broken, you can't click on them anymore, and then in order to actually repair them, I'd have to destroy the old part in code and recreate it, which I'm sure is possible, but physically modifying ships is a bit out of my range at the moment.

Thanks for the response! I understand the issue, now that you have described it. I'll take a look at that and see if I can gain some insight myself. If so, I'll pass on what I learn.

[Papa_Joe]

Thanks for the response! I understand the issue, now that you have described it. I'll take a look at that and see if I can gain some insight myself. If so, I'll pass on what I learn.

I have followed up with this and discovered the following via a post by stupid_chris: http://forum.kerbalspaceprogram.com/threads/40434

You can simply change the panel state from broken to any other state, and this will "fix" the panel.

So, if you look at your solar panel code:

if (ipanel.panelState == ModuleDeployableSolarPanel.panelStates.BROKEN)
     ipanel.panelState = ModuleDeployableSolarPanel.panelStates.RETRACTED;

This will return the panel to pristine (retracted) condition. I have tested this and it works. So to simulate a broken panel you can simply set the panel state to BROKEN.

Hope that helps.

Edited February 24, 2015 by Papa_Joe
correct spelling of stupid_chris' name. Sorry!

[stevehead]

Hi, I'm trying to throw together a mod pack for a 64K install and I got a NullReferenceException when I tried quiting the game through the menu from the KSC scene (the stock toolbar disappeared and it throws the exception when I click Quit to Main Menu):

[EXC 20:25:18.482] NullReferenceException
    UnityEngine.Component.get_gameObject ()
    KerbalMechanics.KerbalMechanicsApp.<Awake>b__0 (GameScenes e)
    EventData`1[GameScenes].Fire (GameScenes data)
    HighLogic.LoadScene (GameScenes scene)
    KSCPauseMenu.draw (Int32 id)
    UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
    UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)

Here's a link to the full log file: https://www.dropbox.com/s/7lz4auy3363lgnh/KSP.log?dl=0

It's a pretty heavily modded install: 64K RSS, Alternate Resource Panel, Better Buoyancy, Distant Object Enhancement, DMagic Orbital Science, Docking Port Alignment Indicator, FAR, Filter Extensions, ForScience Continued!, KAC, Kerbal ConstructionTime, KJR, Kerbal Mechanics, MechJeb, Mod-Oriented Tech Tree, Module RCS FX, Near Future Tech., NovaPunch, NRAP, PlanetShine, Precise Node, Procedural Fairings / Parts / Wings, RCS Build Aid, RealChute, RemoteTech, RLA Stockalike, SCANsat, TACLS, Toolbar, Trajectories, Transfer Window Planner, Tweak Scale, USI Stuff (Alcubierre Warp Drive, Karbonite, K+, MKS/OKS), Universal Storage, and some random dependencies.

I wouldn't be surprised if it was a conflict with one of the above, but I provided the log for you just in case.

Edited March 7, 2015 by stevehead

[IRnifty]

Updated!

v0.6.4:

- KSP 1.0 "Kompatibility" update ;3

EDIT: Updated again!

v0.6.4.1:

- Fixed icon duplication bug.

Edited April 28, 2015 by IRnifty

[FreakyCheeseMan]

Neat mod! Few quick questions?

How does this work with timescale? This has been my question with all of the random failures stuff - how do you make a 5-day Mun mission and a 2-year Duna mission both have a reasonable chance of failure? It seems like either the short missions will never experience the faiulre mechanics, or the long missions will be completely impossible.

Can un-focused ships experience random failures? If not, does changing focus from interplanetary ships during transfer negate the risk? If so, will focusing on a ship for the first time in a long while cause it to suddenly have every part fail at once?

WHere are Rocket Parts stored? How much do they weigh? Am I going to get that thing where Mechjeb modules suddenly contain lots of heavy parts and all my ships fall over?

What do repairs do to reliablity? Will they restore it, allowing the same part (say, a core holding tank at the center of a major refueling station) to last indefinitely, with regular maintenance?

What happens to non-stock parts and containers (in particular, will life support containers also leak?)