New Horizons

How do you deal with crew duration contracts? When I dock a manned craft to a litte station, then its mission time is added to that one of the crewed ship. This makes racing for new duration records too easy. Especially the later record steps cannot be fullfilled without docking to a station with life support. While building your ship you can find a white placeholder symbol (as it is seen in my game) in the button bar below, which opens a new window, where you you can click on "Avionics". It appears to me that there is no automated warning anymore when passing avionic limits. Sometimes I do not see any window at all - maybe due to broken modded parts or mass limits.

Today I had a walking dead Kerbal on my station. When I took a look at that station nitrogen and oxygen showed "perpetual" an my inhabitant was still alive, even could go on eva with the warning of an lack of oxygen. So I suddenly started a already prepared resupply capsule - minutes went I by and I saved the game to catch some sleep. Next day, I got an Oxygen warning and some minutes later he really was dead. Very strange! Supplys arrived 40 minutes later ... At least the smell on the station was low due to no nitrogen left and pressure at 40 kpa. Another question: Why is the ECLSS quality that expansive? It doobles or almost triples the cost. Is this sane?

I wish we had support for Kronometer here :-)

I learned so much tonight. Thank you all! Now I can begin to reduce those warnings and then focus on real improvements of my heavily moded game folder.

With other words: Things as this with two ":" are not allowed anymore? @PART[jx2LDA]:FOR[Kerbalism]:AFTER[JX2Antenna]

Did it!

Whish I could. Here one cannot upload files. Maybe this works magically, without makiing all my files readable. https://www.dropbox.com/s/r0gytw9z7la8o36/KSP.log?dl=0

Even with the latest SXt version I get an error with MM 3.01. CLS_Aviation.cfg seems to produce a problem. It seems that "NEEDS" in MM patches causes a lot of problems me using MM 3.01. SXT related errors reduced a lot after downloading the latest version.

With the latest MM 3.01 Kerbalism produces several errors on the loading screen. Anyone saw them, too?

Hey everyone, just upgraded from MM 2.8.1 to 3.01 on KSP 1.3.1. MM now throws new errors on the loading screen. Is there any way to see a log about all these errors, at best with hints to the individual sources of errors, too?

I have a suggestion to make. Playing with a rescaled mod and thus other day lenght than on Kerbin profits from using the mod Kronometer, which adjusts the ingame clock, when the rotation period of your home world is not 6 or even 24 h. If Kerbal Alarm Clock detects Kronometer this could help a lot.

I am looking forward to.

Procedural tanks don't get a failure module - in VAB and in flight they do not have a failure rate. I suspect that their resources are too deep within modules. Supplemental: I figured it out ;-) Now even my procedural real fuels fueled tanks can suffer a leackage For this here is the extension for "TankFailureModule.cfg" //Procedural Parts only - actually not needed, when using Real Fuels @PART[*]:HAS[@MODULE[TankContentSwitcher]] { MODULE { name = TankFailureModule baseChanceOfFailure = 0.008 expectedLifetime = 50 } } //Using Real Fuels and Procedural Parts @PART[*]:HAS[@MODULE[ModuleFuelTanks]] { MODULE { name = TankFailureModule baseChanceOfFailure = 0.008 expectedLifetime = 50 } }

I am thinking about procedural parts support. As I can understand now resources in there a set a little bit deeper in modules. Maybe there is a way to modify MODULE { name = TankContentSwitcher TANK_TYPE_OPTION { name = Mixed | LiquidFuel | Oxidizer | RCS //all 4 possible RESOURCE { name = Oxidizer | LiquidFuel //all 2 possible } } } With Real Fuels it becomes even more interesting. This happens: @PART[proceduralTankLiquid]:AFTER[modularFuelTanks] { !MODULE[TankContentSwitcher] { } MODULE { name = ModuleFuelTanks type = Default volume = 211 tankVolumeConversion = 200 } } @PART[proceduralTankRCS]:AFTER[modularFuelTanks] { !MODULE[TankContentSwitcher] { } MODULE { name = ModuleFuelTanks type = RCS volume = 106 tankVolumeConversion = 200 } } @PART[proceduralTankXenon]:AFTER[modularFuelTanks] { !MODULE[TankContentSwitcher] { } MODULE { name = ModuleFuelTanks type = Xenon volume = 792 tankVolumeConversion = 10000 } } @PART[proceduralConeLiquid]:AFTER[modularFuelTanks] { !MODULE[TankContentSwitcher] { } MODULE { name = ModuleFuelTanks type = Default volume = 77 tankVolumeConversion = 200 } } What do you think about this thoughts?

Hey super. Now I experienced my first RCS engine failing. Thank you very much. May I suggest an improvement of the GUI statements for already happened failures? When a part already malfunctioned, it still shows "Chance of xx Failure: yy %" (a little correction here: units should be seperated from numbers by a blank) Shouldn't that place used for something like: "Failed due to kind of failure"? In the UPFM window it would be nice to see, what failure occured. Especially for solar panels with different kind of malfunctions this would give more information, experienced sun tracking and retracting error already ;-) Can these failure hit the same part? Up to now, I did not see a failed RCS thruster glowing red :-(

Even with V0.13 RCS thrusters do not show a Failure Rate, other engines and parts do work. How can I suppoprt you to find my issue?

I am testing the new version. What are the consequences of an RCS failure? don't see failure rates at RCS parts so far.

With 11.0.23 i get much better results: I lost one battery of 8 after the same time I lost all of them and all solar panels before. I have an Idea to distinguish retractable, sun tracking and simple fixed solar panels. A) Simple fixed panels should only get short circuit like batteries do. As taken from part solarPanels5 (as far as I know this is the only very simple one: MODULE { name = ModuleDeployableSolarPanel isTracking = false // <-- have a look here secondaryTransformName = suncatcher pivotName = suncatcher isBreakable = false resourceName = ElectricCharge chargeRate = 0.35 extendActionName = #autoLOC_6001805 //#autoLOC_6001805 = Extend <<1>> retractActionName = #autoLOC_6001806 //#autoLOC_6001806 = Retract <<1>> extendpanelsActionName = #autoLOC_6001807 //#autoLOC_6001807 = Toggle <<1>> } Enhance this modes cfg: SolarPanelFailureModule.cfg @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel[isTracking = false]]] --> insert some kind of electrical break down like on batteries Not sure about MM patch - testing now B) Disable sun tracking Taken from solarPanels3 MODULE { name = ModuleDeployableSolarPanel isTracking = false // add this if possible without reloading the entire game resourceName = ElectricCharge chargeRate = 1.64 retractable = false animationName = altsolarpanelbase secondaryTransformName = panel1 extendActionName = #autoLOC_6001805 //#autoLOC_6001805 = Extend <<1>> retractActionName = #autoLOC_6001806 //#autoLOC_6001806 = Retract <<1>> extendpanelsActionName = #autoLOC_6001807 //#autoLOC_6001807 = Toggle <<1>> } C) Disable retracting capability For retracting panels use already implemented retraction error for parts, which have no "retractable = false" and set "retractable = false"

I will test this now. Thanks a lot. Two more questions: Why do suffer solar panels without moveability from retraction errors? It would feel more convenient to have to different failure types for solar panels: A) Some kind of short cut like batteries are affected from B) Retraction error, which only permitts further movement in suns direction, bit keeps the ability to harvest energy, when point to the sun In my career play I did not use capules or probes with reactions wheels so far. As in real world it would be interesting to see different intense failures, too. A) drop of control authority like engines suffer from underthrust B) total break down The thing I didn't understand yet is, when is a failure rate evaluated? Ok, it does after launch (engines might break after a certain burn time and as I red other parts might fail within houres after lift off), but does anything happen at transitions between situations/SOI or even between physics mode and time warp? All this leads to the ultimate question: Can parts break after a long time, e. g. firing a thruster while landing on Duna and such adventures? In principle, of not I see a good chance of a conbined play of this mod and Kerbalisms mean time between failures feature.

Ok, understood. The failure report didn't tell about a ever so decreasing thrust - interesting. I thougt it was a one time thing. Should parts get more reliable with each building generation? I have a ship with 12 small solar panels - build it severel times now (no recovery) und failure rates are still around 15-17 %. After severel days in flight all solar panels and batteries are broken. Is it reasonable, that everything breaks that fast, especially when I build for redundancy?

I found that RCS thrusters are excluded so far. Is there a particular reason for that? I added this file here "EngineFailureModule.cfg" by @PART[*]:HAS[@MODULE[ModuleEngines*|ModuleRCS*]] Testing now - seems to be not working in game :-( Additionally: Over the time I'd like to see more modules open to failures, thinking about avionics from RP-0 or Antenna from Kerbalism Recently I had a interesting effect on an upper stage engine in orbit. There was a drop off in thrust. The thrust limiter decreased a little, but I was able to reset it to 100 % again, but after reignition it droped again - so far, almost reasonable. But why was the thrust limiter on different values after an reignition? The more often I tried, the worse thrust got - from 90 % initially down to around 50 % - very interesting.

This latest Contract Configurator seems to collide with the way upgrade levels and Strategia mix up. On level 1 Administration permits 2 strategies at a time. Without installing this mod here and entering Administration of course you see no contracts but in the lower half of the window there are 2 strategies permitted. Installing that required mod Contract Configurator here, leads to only one permitted strategy, although the upgrade level still suggests 2 strategies. Is this known to anyone? Unfortunately I can not say, how this works with KSP 1.3.0. Earlier with KSP 1.2.2 it worked as expected.

Did anyone managed to use this mod in a KSP 1.3.1 install? Are there any experimental recompiled versions out there? I am asking because activities on the front of RO and RP-0 seem to be non-existant for a very long time, which makes me sad. Testing RP-0 0.54 with KSP 1.3.1 leads to a crash while loading.

Is there a way too use real fuels with this mod?

I want to learn more about the active shielding. Is its effect limited in direction or distance from that part? Is the reduction effect of more than one active shielding part per ship cumulative?