BlueTiger12

With @PART[ExternalReEntryPack]:NEEDS[KOOSE]:AFTER[KOOSE] { MODULE { name = ModuleCargoPart packedVolume = 15 } } within a .cfg file in the GameData folder, i am at least able to put the lifeboat in the inventory of a capsule in the VAB again. Didn't test, if everything else works though. Tested a little bit, but either i am too stupid for it, or it doesn't work correctly. I was not able to deploy it, as i don't get any options in the context menu, when i have it on a kerbal.

I seem to be unable to place the lifeboat into the inventory of a capsule though (1.12.2)

One question regarding the 1.25 meter utility module from StockalikeSpaceStationRedux ('Star'): It had a big nerf 3 years ago, because it contains a radiation shield and was moved at the end of the tech tree. (https://github.com/Kerbalism/Kerbalism/pull/182) I would like to have it more in the front and use the radiation shield as an upgrade, like with the radiation shield in the destiny module from HabTech2, or the TV in Sickbays. I tried it with the following code within KerbalismConfig/Support/SSPX.cfg, but i see the shield in the right click menu, as soon, as i use the module in the VAB, without the upgrade being researched. Does anybody have any Idea here? // ============================================================================ // region Recyclers // ============================================================================ PARTUPGRADE:NEEDS[FeatureRadiation] { name = Upgrade-StarActiveShield partIcon = crewCabin techRequired = experimentalScience cost = 65000 title = Add active shield to the PAS-6 'Star' Utility Module manufacturer = Kerbalmax Industries description = Adds a active radiation shield to the PAS-6 'Star' Utility Module. } @PART[sspx-utility-125-1]:NEEDS[StationPartsExpansionRedux,ProfileDefault,FeatureRadiation]:AFTER[zzzKerbalismDefault] { // since this part contains an active shield, it needs a big NERF: // available only together with kerbalisms active shield // pricing adjusted, the part was way too cheap // @TechRequired = experimentalScience // @entryCost = 65000 // @cost = 15000 MODULE { name = Emitter radiation = -0.0000005555 // -0.002 rad/h toggle = true ec_rate = 1.25 active = e10 cost = 12000 slots = 0 UPGRADES { UPGRADE { name__ = Upgrade-StarActiveShield techRequired__ = experimentalScience slots = 1 } } } } @PART[sspx-utility-125-1]:NEEDS[StationPartsExpansionRedux,ProfileDefault,FeatureReliability]:AFTER[zzzKerbalismDefault] { MODULE { name = Reliability type = Emitter title = Shield repair = Engineer mtbf = 72576000 extra_cost = 2.5 extra_mass = 0.1 } } // end

Hi all, i have a question regarding the nerf of the SSPX PDT-6 "Star" Utility Module. https://github.com/Kerbalism/Kerbalism/commit/6d99aa6db7a515e0fa00a2771dc38d93ce275318 Instead of moving it far back into the tech tree and therefore rendering it unavailable for your early space stations, would it be possible to implement the offending active shield module as a upgrade, like it is done with several modules?

I had tested antivirus already, but i never thought of my pihole blocking my request to codeload.github.com. Especiallyas pings to github.com went through..... Thank you very much, that solved it for me :-)

Can someone help me with that error? I get it since the auto update to 1.26.2, but downgrading to 1.26.0 didn't help. It affects all KSP instances for me (old saves going back til 1.3.1)

One page 134, this problem is also mentioned I had this problem too, and using this older version as well as starting a new save fixed it for me (but i then stayed on the old version)

I really like this idea. The thing about BARIS i don't like, is that this mechanic is disabled when using KCT. Maybe this Pre-Flight test could cost money and take time, and based on the amount of both you spend, your reliability for this flight is increased (perhaps Part-based?) and maybe also there is a slight influence on further builds. Though i think it shouldn't increase a generation for all time. With the combination of money and time, also for non KCT Users, there would be a tradeoff, but i personally think the additional time would have more impact then money.

Which currently seems not to be working, at least for me

My thought was that satellites would die over time and therefore need to be replaced at some time, as i usually don't ever switch back to my comsats, failures would not happen and therefore they would not wear out. @severedsolo Thanks for your opinion on my suggestions :-) I am very much looking forward to testing your pre-release but unfortunatelly i don't have much spare time during the next days :-/

@severedsolo If you have the time and are up to it, may i ask you on your thoughts to the other ideas, too? I would be very interested in reading your opinion on them.

@severedsolo I have some suggestions, but i don't know if they go too far. But nevertheless i will suggest them, perhaps something of it is usefull to you. Generally i like your mod and the direction it is heading very much. There are only 2 things i would like to see changed. One of them is related to your rebalancing. 1. I would like the possibility of failures while it is not the active vessel. 2. I would love the concept of parts wearing out during flight - so that they have a mean expected liftime. For example that the batteries of my comsats are slowly dying and therefore i have to think about redundancy and replacing them at some time. It also would add a little bit to the KCT concept - where time is valuable - as you should think twice if you make missions one after another as your satellites wear out faster if you timewarp a lot, or do them in paralell. But with failures only on loaded vessels, for example my comsats would never wear out. I think they would also play nicely together, as you think about rerolling in intervals. I think of something like this: 1. Let failures happen on vessels, regardless if they are loaded or on rails 2. Dices for failures like engine ignitions, solar panel deploy mechanism, antenna deploy mechanisms or parachutes are rolled on activation, as these are instant failures. This is also the way it is currently implemented, i think. 3. Failures for things like batteries, fuel tanks and so on are rolled on launch. 4. Failures for engine overheating and so on are also rolled at engine ignition. 5. If a failure if point 3 or 4 is determined, it will occur somewhere between now and the part's expected lifetime. 6. If no failure is determined, the dices are then again rolled when the expected liftetime is reached. Then if a failure is determined, it will happen between now and a part of the original expected lifetim (1/3 for example) 7. At the end of the 2nd expected lifetime, dices are rolled again. The time is again 1/3 of the previous lifetime (which was already 1/3 of the original lifetime). 8. This goes on every time the lifetime ends. Obviously there should be a cap to prevent the dices from rolling to often and making a failure unavoidable. Maybe a minimum time of 30 ingame minutes. This way the possiblity of a failure would increase tue to roling dices more frequently, after the expected lifetime is reached. The lifetime concept would also give a more variable time when a failure will happen, opposing to your fixed 2 minutes for engines or 6 hours for other parts, after which no more failure will happen, as long as you don't switch back and forth. Also the expected lifetime should increase with the failure rate decreasing. So the more often a part is build, the longer it's expected lifetime will be. Maybe the lifetime could also be increased by paying additional money for that part. Lifetime for engines should be pretty short then, but the lifetime should only be counted while they are running (Failure described at point 4). Due to a failure roll when activating a part (Failure described at point 2), it would also mirrow the risk of moving parts and engines (solar panels getting stuck the more often they are retracted and extended, antennas getting stuck on extracting, engines failing with more frequent shut-down and activation) With this you would have a little risk at the start, where you activate engines and antennas and solar panels, then you would be pretty safe for the expected lifetime (though there is still a small chance for a failure) but after the expected lifetime, your vessel/satellite will slowly start to degrade, as it would in real life. But you could calculate with that. A part with an expected lifetime of 2 months will most likely not make it to Duna, but a part with an expected lifetime of about 3 years most likely will make it and also be able to operate in orbit for a long time. I also agree with @Gordon Dry that it would make sence that a part being build more often should have an impact on all other older parts of that category, i.e. a highly reliable Poodle should have made a LV-909 a little bit more reliable, too. But i don't know if that is just too dificult or complex to implement. I hope something of the above can help you in your decision in which direction you will go in balancing the failures. Thank you very much for your mod :-) It makes the game way more fun to play for me.

@Errol Good point, i just tried it with a clean 1.4.3 install. Unfortunatelly it shows the same results.

Thank you very much And also for enriching the game with so many great mods :-)

@linuxgurugamer I am sorry, i don't understand where you point me to. I understand, that the ullage simulation is not working correctly, but i thought therefore you implemented the option to disable it. Or does this also mean, that the option to disable the simulation, that you implemented in 1.3.3 is also known to be not working?