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?

@linuxgurugamer: I just had the time to try this again on a clean 1.3.1 game. Only Engine Ignitor (standalone) 1.3.3, Toolbar controller and ModuleManager are installed. I started a new game and disabled Ullage simulation and set the ignition chance to 100%. Still the ullage simulation is activated when in flight. Log entries are: (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) EngineIgnitor: minPotential: 0.2, chance: 0.4549751 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) EngineIgnitor: minPotential: 0.2, chance: 0.9290937 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) EngineIgnitor: minPotential: 0.2, chance: 0.1608593 Here i staged until the engine fired while in flight. Still in the settings menu ullage simulation is disabled and ignition chance is set to 100%. Also in the VAB when selecting an engine it sais "Ullage simulation disabled". Am i missing something or does the settings have no effect?

@linuxgurugamer : I am using a KSP 1.3.1 install with EngineIgnitor 1.3.3. Because of the ullage simulation not working correctly for me i tried to disable the ullage simulation in the persistent.sfs file. I also changed the ChanceWhenUnstable to 100 as the deactivation of the ullage simulation did not work on a first try in a Krash simulation. EI { ChanceWhenUnstable = 100 allowTestMode = False useBlizzy = False useUllage = False } This did not work in a KRASH simulation either (chance was still 20%, fuel flow was unstable and ignition failed often) I then started a new sandbox game with the same settings configured in the settings options when creating the save. There it was also not working and showing the same symptoms as in the KRASH simulation. Am i missing something? Is this a confirmed bug? EDIT: 5 years of playing KSP and i just found out, that i can look at the settings of the current save game ingame..... nevertheless ullage simulation is shown to be turned off there, too.

Hi, it seems that this mod increased my loading time from a few minutes to about 90 minutes. Is such a behaviour already known or worth a closer investigation by me? Noticed it on a heavy modded game (100+ mods). But also in nearly stock it takes about a second for every file (audio, model texture) to load with this mod installed instead of a few milliseconds without it. KSPVersion was 1.3.1. Edit: I just noticed that the version with only a few mods was 1.4.2. in fact (installed through ckan). But the one with many mods was 1.3.1.

Thank you very much:-)

No Problem, if you can't do anything, perhaps you could add it as a known issue? I thought there might be a chance, that this is just a minor change, when i realized, that you have to launch the capsules crewed, too, in order to take the inventory with you. Also in the capsules the inventory is labled as "[Kerbal]'s inventory" (after launch, when you right-click the capsule), so it seems to be a personal inventory, as it would be with the seats.

Is this incorporated in any scrapyard build that is working in ksp 1.3.1 together with upfm? (i remember that for some time upfm should only be used with build 72 of scrapyard)

I think i found a minor ... not a real conflict, more like a "not working as expected" ... between KCT, KAS/KIS and TakeCommandContinued (allowing you to launch kerbals in external command seats) When adding a item to the inventory of an external command seat in the vab, you get a message on top of the inventory that says: "The seat must be crewed at launch to acquire items" (you also get this message with the mk1 command pod for example) This works in a KRASH simulation without problem - The item is in the inventory of the kerbal. But when i launch the vessel with KCT (regardles if i do it from the main screen or VAB), the inventory is empty. I also tested it with the "Cardboard Box" and the "MK1 Command Pod" - Here everything is working as expected and they are taking their inventory to launch. It seems, that the external command seat is not treated the same way as the mk1 pod - understandable, as it can normally not be launched with a kerbal. Is this fixable? If not, could you add a little note a the first post about this behaviour? KSP Version: 1.3.1; KCT Version: 1.3.9.0 Thanks i advance :-)

Sorry for my late reply. At first, thanks for your description and updates :-) If i understand you correctly, i can avoid this problem by switching auto-apply of and only applying the inventory before i start the build, with your new sollution? Also this sounds more like AGX would need some optimization while saving.

Well i think your optimizations are doing a pretty good job. Without AGX, my game is pretty lag free in the VAB even with auto apply on, in a game with about 160 mods. I included 4 videos in the Bug report: Only Scrapyard installed (auto-apply on) Scrapyard and AGX installed (auto-apply on) All 160 Mods including Scrapyard without AGX All 160 Mods including Scrapyard and AGX You can see there is little difference between 1 and 3 but including AGX is creating a massive impact in performance. Therefore i think this is a specific conflict between these 2 mods. As you see in 3 your optimizations are doing a pretty good job i think Here is the Link to my Dropbox: https://www.dropbox.com/s/01jpds5p3czyslj/BugReport.7z?dl=0 Ps: I left the timer unchanged for now

Hi Magico, i seem to have found a conflict between ScrapYard and ActionGroups Extended These mods together cause a stutter in the VAB for me every 1-2 seconds - only when i am moving parts around. This becomes really game-disturbing when having a havy modded game because the stutters take 0.5 to 1 second then. Ich used MemGraph and with it i can see, that every time a stutter occurd, a cleanup is performed. This is not happening when one of the two mods is removed or i am not moving any part in the VAB. I don't know if this is allready reported. If not and i can help you with further information, i will be glad to provide them. What do you need and which way do you prefer? I have the output_log.txt, the ksp.log and a screenshot as well as a video of the scenario with scrapyard and AGX as well as only ScrapYard. Unfortunatelly i am not able - or to stupid to find the option - to insert the screenshots in this post. Installed Mods are: ScrapYard Build 82 MagiCore Action Groups Extended ClickThroughBlocker ExceptionDetector MemGraph ModuleManager.3.0.4 Thanks for your great mods - the game is not the same without them! Ps.: I don't know if this is the right place to report it, or if i should report it on the AGX thread. So sorry if this is the wrong place.