Gotmachine

Thanks for bringing this up Pthigrivi. Everyone seems to be ignoring this want from the devs in this discussion. If anything LS related is added to the game, don't expect Kerbals to actually die or become nonfunctional. So you're just debating the next LS mod at this point. Exactly, that's why any kind of LS system is very unlikely. The central point of a LS mechanism is to introduce a new constraint in the form of max crewed mission time, and gameplay loops revolving around mission planning, manned vs unmanned choices, supply and ISRU. Those can be interesting gameplay elements, but they are in direct opposition with the core intended gameplay loop which is to freely and goofily assembling vastly overpowered rocket components to play with the rocket equation, playing around with orbital mechanics, and landing on unreachable worlds. I'm quite confident that people expecting KSP 2 to have more in depth simulation/gameplay mechanisms than KSP 1 are going to be utterly disappointed. If anything, they will be vastly simplified. It has been clearly stated that KSP 2 is about making a more accessible game but with vastly more content. Said otherwise, the stock game is all about exploring gorgeous planets, flying shiny interstellar engines and building humongous bases and stations. They will certainly put a lot of effort into making a smooth progression system to back that, but it's pretty certain that the "simulation gameplay" part will be simplified as far as they can without betraying too much the "grounded in real world/physics" premise. Not only because such systems are getting in the way of the core gameplay loop, but also because they are very difficult to design, program and balance, especially if you want to satisfy the whole player base. No matter what the stock system is, there will be a bunch of mods proposing their own take on it, providing a much better fit for the various player demographics.

I fully agree with that, but the fundamental problem with LS is that any miscalculation on the player side results in a bricked mission, there is no real "counterplay", everything is happening at planning time. On a larger level, such a system is restricting player freedom to do whatever they want and it doesn't meaningfully contribute to the core gameplay loop, which is building creative spacecrafts from various bits using real (to the extent that the average player can understand) orbital and rocket physics to explore and colonize the stars with goofy green humanoids That "planning must be done right" aspect is already a major weakness in KSP, and a major complaint made by most people trying the game. The "build-launch-crash-try again" loop is a entertaining for the first hours when you discover the game, but it quickly become a source of frustration for the average player. We have heard a lot from the team about how it was crucial for KSP2 to get around that issue. "Non-hardcore" players are those that will make the game a financial success or not, and the difference between the game being supported for years or shelved a few months after launch. Not the people having poured thousands of hours in KSP 1 and posting on this forum. Despite what the public facing people are trying to convey, this is no passionate independent game, KSP2 is a financial investment controlled by a huge game publisher that bought a relatively successful independent brand to primarily make money out of it, you can be sure that every single feature that will or won't be present at launch is carefully weighted in terms of player demographics and impact on potential sales. It is common knowledge that the majority of people having bought KSP are abandoning before even reaching orbit. It's not what I want to hear, but the main point driving game design decisions is very likely : how to ensure the average player is able to progress steadily toward the mid-end game without too much frustration ? Especially since this mid-end game content is the selling point they are desperately trying to push forward. That doesn't rule out a very basic system existing as basic time progression limit mechanism, but I really don't expect anything beyond that. The fact that Nate Simpson refused to comment on the subject two/three years ago show that they at least were considering their options. And if the game is successful and kept alive after launch, a middle-complexity LS system and associated mechanisms (habitat, radiation, repairs, kerbal specialization, ISRU...) could be an opportunity for a DLC, even though I doubt such "complexity adding" systems will ever be the focus.

It has been strongly hinted in various interviews that life support on vessels won't be a thing at all. The only thing that was confirmed was that "colony growth (but not survival) requires producing/importing life-support-alike stuff". I highly doubt it will be a thing on vessels if it's not even a requirement on colonies, and in any case I wouldn't expect anything past a very basic system, probably even more basic than the simplest KSP1 LS mods. In the context of the "interstellar exploration" gameplay they are pushing forward for stock KSP 2, I can see why life support gameplay elements at the vessel level won't be a thing. It adds a relatively tedious supply and mission time planning requirement for every single launch, introducing a whole new "micro" gameplay loop conflicting with the "macro" scope of the game, which is clearly large scale interstellar exploration and colonization. I always comes back to the same point : the intended large scale and speculative future scope of KSP 2 is in conflict with it being a game that takes the actual physics and challenges of spaceflight and transform them in gameplay elements. Now, I'm sure there will be plenty of mods trying to implement said gameplay elements. As mentioned in this thread, the main purpose of LS as a gameplay loop is to make mission duration a constraint. Another one is to give value back to unmanned missions. From there, there are various levels of detail and complexity possible. But the issue remains that this will always be a "micro" gameplay level, where you have to manage things on a per kerbal, per vessel, per stage, per mission phase basis, doing careful planning, resource input, output and transfer management. This can go quite far in terms of complexity or realism and make a good gameplay loop, but if the overall game scope is managing hundreds of kerbals, vessels, colonies and stations all around the galaxy, it suddenly becomes completely out of place.

I don't want a wacky system parsing the settings file comments and writing an external MM patch, this is a terrible way to handle this. I will eventually look into making a better in-game UI and to extend the patch system to generalize user-facing settings. Meanwhile I think that for the few people that need to customize things, copypasting the patch example available in the extras folder is more than enough.

The premise of KSPCF is to be "drop-and-forget" mod, the ability to enable or disable patches through MM is mainly here for mod compatibility purposes, not for the end users to tinker with. There are currently more than 50 individual patches in KSPCF (and this is growing quickly), most of them are just obscure techno-babble to anyone that isn't familiar with technical aspects of the KSP internals. Said otherwise, the only users that should be enabling or disabling patches are the users that know how to write a MM patch. This being said, I agree some patches (mainly the QoL ones) could use some additional in-game configuration options, including the option to disable them. I also agree that the current solution of adding such options as entries in the KSP main settings isn't very scalable. Creating a separate settings interface available both from the main menu and the pause menu would be nice. At some point I wanted to implement a standard "settings API" that could also be reused by other mods (I hate that mods have to resort to cluttering the mod toolbar for this), but I have no such project currently.

V1.20.0 is finally out (sorry all contributors for the delay !) Available from GitHub and CKAN. Changes in that release : New KSP bugfix : UpgradeBugs [KSP 1.8.0 - 1.12.3] Fix various bugs with upgrades, like the part stats upgrade module breaking, upgrades not properly applying in the editor, upgrade cost not being applied to part cost, and various issues int the public API. (contributed by @NathanKell) New KSP bugfix : DoubleCurvePreserveTangents [KSP 1.8.0 - 1.12.3] Fix DoubleCurve flattening the tangents of the first keyframe regardless of whether tangents are supplied. (contributed by @NathanKell) New KSP bugfix : StrategyDuration [KSP 1.8.0 - 1.12.3] Fix Strategies not using Duration settings. (contributed by @NathanKell) New KSP bugfix : CometMiningNotRemovingMass [KSP 1.12.2 - 1.12.3] Fix mass of comets not actually reducing when mining them, despite the PAW saying so. New performance patch : AsteroidAndCometDrillCache [KSP 1.12.3] Reduce constant overhead of ModuleAsteroidDrill and ModuleCometDrill by using the cached asteroid/comet part lookup results from ModuleResourceHarvester. Improves performance with large part count vessels having at least one drill part. (contributed by @JonnyOThan) New stock configs tweak : ManufacturerFixes Fix a bunch of stock parts not having manufacturers, add icons for the stock "Stratus Corporation" and "LightYear Tire Company" and two new agents, "FreeFall Parachutes" and "Clamp-O-Tron". (contributed by @sunnypunny) PersistentIConfigNode patch : fixed incorrect serialization in some corner cases(contributed by @NathanKell) OnSymmetryFieldChanged : fixed mistakenly inverted "changed" condition resulting in the patch not actually preventing symmetry events to be fired when the value hasn't changed. Added russian localization (contributed by @sunnypunny) For mass, my rationale was that inventory mass is an information that isn't available anywhere else, as most inventories don't have the mass limit slider. I initially made the patch with full information about slots/mass/volume but removed it because that made the text way too long on kerbal inventories. But those cases could be differentiated and the non-kerbal inventory info made more useful, I implemented this quick-and-dirty, so feel free to submit a PR to improve this. I think someone else reported that on Discord (@Rodger maybe ?), I will try to take a look. Not sure this is desirable. When you approach 0 m/s, this mean your prograde vector is about to turn around 180°, and when this starts happening you usually don't want SAS to stay engaged toward that vector. I'm pretty sure I occasionally found myself in situations where I would have preferred a larger than stock threshold. Maybe the threshold could be lowered a bit, but the stock threshold is something most experienced players have a "muscle reflex" for, so in any case a KSPCF patch for this would be an option to change it, not a lower default threshold.

Just released v3.16 which should fix that issue : https://github.com/Kerbalism/Kerbalism/releases/tag/3.16 I personally haven't tested the RT support and I don't intent to maintain it. Not sure if the contributor that added that support back in is still around.

Not really no. I barely play KSP anymore, I've been mostly casually messing around since quite some time. That and the fact that KSP 2 is nearing the horizon slowly killed my motivation to work on large scale modding projects. Yes. It would need to be updated to reflect the comms related changes in the default config.

A "deinterstellarification" mod or mod suite that put back the focus of the game on being a contemporary space program simulator : - Remove the interstellar systems - Change the scale of the home system to a more realistic one than 1:10 (something between 1:3 and 1:4) - Expand the home system with more places to visit - Remove the speculative / scifi tech stuff Then expand on those core modifications to provide more in-depth gameplay elements that are rooted in contemporary and realistic space exploration realities. Aspects like life support, radiation, science/exploration, economics, ISRU, etc.

Kerbalism 3.15 is released Added italian localization (@leonardfactory) Backported Comms handling from Kerbalism 4 (@KooZ, @gotmachine) Backported RemoteTech support from Kerbalism 4 (@KooZ) Reworked antenna balance support configs for RemoteTech (@KooZ) Bodies are now sorted by SMA in planner UI (@al2me6) Made shielding efficiency difficulty presets configurable in Settings.cfg (@gotmachine) Resource names are now properly localized (@leonardfactory) Fixed issue #819 : Fatal error on science DB compilation when ROCManager isn't available (@gotmachine) Fixed issue #799 : Sample mass not being included in vessel mass in the editor (@gotmachine) Fixed issue #748 : Disabled ModuleAsteroidDrill background processing. Code isn't working anymore and needs a refactor (@gotmachine) Fixed issue #775 : Lab Experiments don't use the right scientist level requirements(@RoadWarrior9) Fixed issue #745 : Serenity deployed experiments take 10 times longer than stock (@Nistenf) Config tweak : Fix antenna EC calculation typo (@shult12) Config tweak : Adjusted drive capacities for Stock, Restock+ and RLA probes (@hypodronic) Mod support : Pebkac experiment fix (@Gordon-Dry) Mod support : Updated Near Future Spacecraft science support configs (@Vulpodrac) Mod support : Updated SSPX support configs (@sicario, @Vulpodrac, @AlexL) Thanks to all contributors. Moderators, if you see this and if you feel this is alright, here is an updated OP for this thread, would be nice if it was copypasted in place of the vastly outdated current one : Welcome to Kerbalism Hundreds of Kerbals were killed in the making of this mod. Kerbalism is a mod for Kerbal Space Program that alters the game to add life support, radiation, ISRU chains, part and engine failures and an entirely new way of doing science. Features summary : Life support : Kerbals consume food, water and oxygen and will die if they aren't provided. Various processes can be added to recycle or produce those resources in situ. Stress : Kerbals require adequate living space, atmospheric pressure and comforts. When those are lacking, they will get more and more stressed and start making mistakes. Radiation : Kerbalism simulate the space radiation environment and radiation from local sources. A vessel must be adequately shielded and mission planning must be adjusted to avoid the most deadly places like planetary radiation belts. Reliability : Components have a limited operational lifetime and will fail over time, and engines have a limited amount of ignitions and a limited burn time. ISRU : Instead of the easy "ore to everything" stock system, producing and processing resources in situ uses a semi-realistic set of extraction and conversion rules. Science over time : Experiments produce data over time. The data is also transmitted over time, making science collection an automated background mechanism instead of the stock click-spammy system. Kerbalism also removes the stock labs "infinite science" mechanism, rebalance the stock experiments and add many probe, satellite and late-game manned experiments. Background processing : All vessels are simulated continuously, not only the currently active one. Life support, resource processing, experiments and data transmission are simulated in the background, even during time warp. Vessels management : Kerbalism provide a centralized user interface to monitor and control all your vessels. Many actions can be performed without having to switch to a vessel. Mission planning : The editor user interface allow to evaluate your vessel design against the various environments and provide extended information about all aspects of the mod. For more detailed information, go to the Github wiki and the FAQ. Current version: 3.15 Download : Github releases - CKAN Docs & support : Github wiki - Discord - FAQ - Github issues - KSP forums thread License : Unlicense (public domain) KSP version : 1.8.x to 1.12.x Requires : Module Manager, CommunityResourcePack, HarmonyKSP, KSPCommunityFixes Mod compatibility - Changelog - Dev Builds Download and installation Download on Github releases or use CKAN Two packages are required : Kerbalism is the core plugin, always required. KerbalismConfig is the official configuration pack. It can be be replaced by other packs distributed elsewhere. Requirements Module Manager HarmonyKSP KSPCommunityFixes CommunityResourcePack (required by KerbalismConfig only, third-party config packs might not require it) Configuration packs The Kerbalism official configuration pack is a feature set maintained by the Kerbalism contributors. It tries to achieve a good balance between realism, difficulty and complexity, is primarily balanced against the stock game and has a "current space tech" scope. Mixing it with other mods that significantly change the stock scale, scope or gameplay isn't well supported and not recommended for a good experience. Several alternate configuration packs have been created by third party modders : ROKerbalism : Official config pack for RO and RP1, maintained by the RP1 team. SIMPLEX : Stockalike simplified life support and ISRU designed to work well with the SIMPLEX tech tree and other mods by theJesuit. SkyhawkKerbalism : A BDB focused profile with revamped LS, science and ISRU going alongside a custom tech tree by CessnaSkyhawk. LessRealThanReal(ism) : A config pack part of a larger mod based on RP1 but made to played at stock scales without RO. Make sure to install exactly one configuration pack only. Don't combine packs unless there is explicit instructions to do so. Mod compatibility and support Checking the mod compatibility page is mandatory before installing Kerbalism on a heavily modded game. Kerbalism does very custom stuff. This can break other mods. For a lot of mods that breaks or need balancing, we provide support code and configuration patches. However some mods are incompatible because there is too much feature overlap or support is too complex to implement. Documentation, help and bug-reporting Tutorials and documentation are available at the Github wiki Need help ? Ask on Discord or in the KSP forums thread Also see this short YouTube video about useful UI tips. You found a bug ? Maybe it's related to another mod ? Check the Mod Compatibility page. Maybe it's a known issue ? Check the GitHub issues and ask on Discord. You want to report a bug ? Install the KSPBugReport plugin and generate a bug report with it. Support requests that don't provide full logs and KSP database dumps are often ignored. Report it on Github issues (preferred) or in the KSP forums thread (we don't go there often). You want to contribute or add support for your mod ? Check the technical guide on the wiki Pull requests are welcome, especially for mod support configs. For code contributions, it is recommended to talk to us on Discord before engaging anything. Read the contributing documentation To build the plugin from the source code, read the BuildSystem documentation Disclaimer and license This mod is released under the Unlicense, which mean it's in the public domain.

Nothing I can do with that information. Either provide a download link to your KSP.log, or use the KSPBugReport plugin.

They aren't reduced. The overall amount of science points available is actually much higher than in stock. There are massive amounts of science you can get by sending simple unmanned interplanetary science missions. This being said, Kerbalism removes the silly "infinite science" mechanism of stock labs, so you're indeed forced to actually do new things to get science.

@ValiZockt Notifying in advance : I will be releasing Kerbalism 3.15 soon, and it contains a rewrite of the comms handling, which will almost certainly break KCC. Note that the changes are fully internal, the end user features are strictly identical, so this should just be a matter of re-linking to the stuff you're using in the Kerbalism assembly. You can safely use the latest dev build to develop against, it's very unlikely there will be more changes to the comms code before the 3.15 release.

Somehow managed to miss that. Hotfix available in 1.19.1

In theory it shouldn't, but untested. In any case, enabling that patch alongside Kerbalism is perfectly useless, as Kerbalism should disable the stock throttling mechanism. Also, this patch won't do much of a difference unless you have really silly amounts of both bodies and vessels.

V1.19.0 is out, with a bunch of hot stuff thanks to all contributors. Available from GitHub and CKAN. Changes in that release : New performance patch : CommNetThrottling [KSP 1.12.0 - 1.12.3] Disabled by default, you can enable it with a MM patch. Prevent full CommNet network updates from happening every frame, but instead to happen at a regular real-world time interval of 5 seconds while in flight. Enabling this can provide a decent performance uplift in games having an large amount of celestial bodies and/or vessels, but has a detrimental impact on the precision of the simulation and can potentially cause issues with mods relying on the stock behavior. (contributed by @JonnyOThan) New performance patch : DisableMapUpdateInFlight [KSP 1.8.0 - 1.12.3] Disable the update of orbit lines and markers in flight when the map view isn't shown. Provides decent performance gains in games having a large amount of celestial bodies and/or vessels. (contributed by @JonnyOThan) New performance patch : ProgressTrackingSpeedBoost [KSP 1.12.0 - 1.12.3] Remove unused ProgressTracking update handlers. Provides a very noticeable performance uplift in career games having a large amount of celestial bodies and/or vessels. (contributed by @JonnyOThan) New QoL patch : ToolbarShowHide [KSP 1.8.0 - 1.12.3] Add a button for hiding/showing the stock toolbar. Also allow accessing the toolbar while in the space center facilities windows (mission control, admin building, R&D...). (contributed by @NathanKell) New QoL patch : ResourceLockActions [KSP 1.8.0 - 1.12.3] Add part actions for locking/unlocking resources flow state. New KSP bugfix : EnginePlateAirstreamShieldedTopPart [KSP 1.11.0 - 1.12.3] Fix engine plates causing the part attached above them to be incorrectly shielded from airstream. (Thanks to @flart for reporting and to @Aelfhe1mfor coming up with a clever solution). New KSP bugfix : AsteroidInfiniteMining [KSP 1.10.0 - 1.12.3] Fix asteroid/comet mass being restored to 100% when reloading after having mined it down to 0%. (Thanks to @Rodger for reporting).

But the implementation is pretty terrible. Might try to take a look when I got some time.

It is effectively no longer under active maintenance since much more than a year. Kerbalism has been a community project since a long time, there is no need for "adoption", but so far nobody had been interested in picking up the not very fun role of active maintainer. I used to have that role, which consists in triaging issues and integrating contributions, doing some beta-testing, publishing releases, but I'm not interested in doing that anymore. This is a very big mod covering many features, and it is used in many different ways. There are multiple active config packs, as well as other mods relying on the codebase being stable. The project is getting minor contributions from time to time, but it needs someone to integrate them without breaking all that. This requires basic coding skills and being familiar with how the mod is structured and used, and while there are a few people around that could qualify, they aren't interested and/or don't have the time for that. I'm quite willing to help if someone motivated comes around, and I usually answer technical questions on the Kerbalism discord server.

This always has been my main concern about the choice to expand KSP scope to interstellar ranges (which I also don't like for other reasons, but whatever). The increased time scale of the game will fundamentally conflict with the "space program" aspect where you have multiple vessels, bases and missions ongoing concurrently, with a lot of actions that happen on a hours/days timescale. I expect the granularity of the simulation as a whole to be seriously dumbed down to very high level abstractions as a result.

This would only cover stock code and not mods, and that this wouldn't fix more fundamental consequences like incorrect drag. I'm here to fix bugs, not to create weirder ones. Mmmh... won't be 100% reliable, but feels like it would require a very weird part setup for this solution to fail. Might look at doing that, this is likely the only way to tackle this issue without requiring additional configs for each case.

Yeah... tricky one... What is happening is that "ModuleDecouple" on the engine plate is setting all attached parts as "shielded from airstream", excepted the part attached to the node defined in the "bottomNodeName" of the "ModuleJettison" module. Which make sense, but somehow they forgot that "all attached parts" also mean the part attached to the top node. In your example, this is the service bay, which then refuse to open because it is considered as in a fairing. But on the bright side, that part now doesn't cause any drag ! This is tricky to fix because this would require having an extra config field to specify additional nodes that shouldn't be shielded. Putting aside the fact that adding extra config fields to existing modules is difficult and messy, this would also mean that we need actual config patchs for every part using "ModuleDecouple" with "isEnginePlate = true". Alternatively, I could add an hardcoded exclusion for the usual top node id ("top") that might cover this issue for stock parts, but also might not work correctly in other cases (modded parts...).

Don't be sorry, thank you for testing and reporting There was indeed an additional bad interaction between CustomBarnKit and KSPCF (and turns out other mods as well). Hopefully, things should now work fine with KSPCF 1.18.3 !

@RussosDone, version 1.18.2 fixes that issue and should be available on CKAN in a while. Sorry to all for the inconvenience.

Yeah, this isn't even a bad interaction with CustomBarnKit, it's a bad interaction between the MemoryLeak patch and some stock code doing something unusual that I didn't anticipate. The issue happens in stock too. Will provide (another) fixed release ASAP.

Mkay. Well, there is definitely a performance impact in 1.11 / 1.12 due to the planets revamp (but arguably, they look much better). As for the "poorly made" comment, there are a few issues indeed but not any more or less than in previous versions. And this put aside, the 1.11 and 1.12 updates cycles definitely fixed a lot of bugs, and many active mods have also matured a lot in that timeframe.