Gotmachine

Inflatable and pressure mechanics are a bit bugged currently. They will usually finish inflating if you unload the vessel and timewarp for a bit. And yes, you need nitrogen to inflate them. No. As for ISRU, yes, ISRU in Kerbalism is hard, slow, and balanced to be relatively realistic regarding what you can make, and where. Meaning that your options are quite limited. The first thing you need to understand is that we consider LiquidFuel as an abstraction of methane, which effectively require an abundant carbon source to be produced. Our numbers are an estimation based on various sources, but producing large amount of methane (or hydrogen, for that matter) from the moon regolith (or any regolith) is highly equipment and energy intensive. It's doable, but the scale of the infrastructure and operations to make enough propellant for anything more than a small payload rocket are simply huge. Our numbers are certainly questionable, but all things equal, the possibilities are in the ballpark of reality. Also note that we don't control what resources are available and where, those are defined in the CRP mod. For example, there is no extra water abundance at the mun poles, which can be questionable. The main viable options for large scale propellant production with Kerbalism are : - Hydrogen from "crustal" (ie, mined with a drill) water : can be found everywhere, albeit in concentrations that are usually too low. A few places have higher concentrations, like Laythe and Duna poles. - Methane/LiquidFuel from atmospheric CO2 sources (+ a water source for hydrogen) : available on Eve, Laythe, Duna This is the same deal with greenhouses, which are a niche option and not really practical in general. Also, reading your posts, you should tone down your expectations about what is achievable in Kerbalism (but to be fair, that is a very common mistake for newcomers). If your goal in KSP is to make large scale interplanetary manned missions, bases, stations and ISRU, you should seriously consider switching to a mod or combination of mods that are more geared toward that, like USI LS + MKS, TAC-LS, Snacks, KerbalHealth, etc... Kerbalism makes the difficulty/possibilities in line with real world, current technologies limitations. You can also check the Kerbalism Simplex profile : Which retains most of Kerbalism features but is much more forgiving and in line with the stock difficulty balance. All this being said, for the in-dev next major version, we are rewriting a lot of the current features, with the general intent to make things a bit more relaxed in terms of difficulty for long term manned operations. This mainly mean easier and more reliable management of resource chains and ISRU operations, more forgiving mechanics concerning stress and radiation, and more late game / high tech options.

Note that following 1.11, this isn't true anymore since the EVA jetpack inventory item has it's own EVA propellant (in stock) or MonoPropellant (with Kerbalism) storage (5 units). There is also a "fuel cylinders" inventory item that carry 3 extra units of MP. Also note that : - On going on EVA, those inventory items will be (re)filled with the MP stored on the vessel (if any). - On boarding, the MP stored in the EVA kerbal inventory items will be transferred to the vessel MP storage, if there is some storage available.

While we wait for @Sir Mortimer to update the OP, here is the KSP 1.11 compatibility release : https://github.com/Kerbalism/Kerbalism/releases/tag/3.12 Should be available on CKAN already. Updated for KSP 1.11 Monopropellant support for KSP 1.11 EVA jetpack and "eva fuel cylinders" (@gotmachine) Removed ability to disable habitats, to mitigate the (unfixed) bugs with pressurization (@gotmachine) Added radiation fields configs for GPP and GEP (@SirMortimer) Enable water recycler process on US2 Water Purifier wedge (@ccaviness) #690 : Handle B9PS switching of solar panel rates (NFSolar...) (@gotmachine) #654 : Comet samples support (@gotmachine) * Improvements to engine reliability patches (@hemeac) * Support for KiwiTechTree in EngineIgnitor support patch (@Clamp-o-Tron) * Fix to radial LS containers mass (@Murtnowski)

I will push an update as soon as I sort the issues related to the new things in this update. Shouldn't take too long. Related issue : https://github.com/Kerbalism/Kerbalism/issues/707

Mentioning it here for awareness : https://bugs.kerbalspaceprogram.com/issues/26860 Doing the following : In the editor, grab a part from the part list, or grab an already placed part Put it into a stock inventory Put it back in the editor Results in KSP to forget to enable all partmodules on the part (it doesn't set MonoBehaviour.enabled = true), causing any Start()/Update()/FixedUpdate() code to not run.

The standard procedure with a modded game is to not update KSP until all you mods are updated. Mods will break when KSP updates. If you're using Steam, the usual way of doing that is to have your modded install separate from your steam install. Revert your KSP to 1.10.1 (on steam, go to your game properties > beta tab > select KSP 1.10.1 in the dropdown) Then go to where you KSP isntall is on your hard disk (on steam, game properties > local files > browse) and copy paste the whole "Kerbal Space Program" folder somewhere else.

We already have that : https://github.com/Kerbalism/Kerbalism/wiki/PlayGuide-~-Resources The stock ISRU options don't exists in Kerbalism. And stress. And LS resources supplies. And reliability. Of course I'm talking about default Kerbalism difficulty, and without mods that make make things too easy (hypothetical overpowerful engines or deepfreeze for example). Even at the easiest settings, manned missions that take more than a few years are almost impossible in practice.

This is a stock bug. This said, it seems indeed to be occurring more often when Kerbalism is installed because Kerbalism add some overhead on scene loads, and that bug is somehow dependent on that. Not sure what is happening, you're indeed supposed to get the bonus. No The active shield is the only thing that can protect you from high radiation levels. But in general, yes, the Jool neighborhood isn't Kerbal friendly. First, to put things in perspective, remember that a Kerbin year is ~100 earth days, and that Kerbals have 1/4 the physiological needs of humans. But yes, as a general rule, unless you're establishing a permanent base somewhere with some ISRU to sustain it partially, greenhouses aren't worth it. If your goal is to make self-sustainable bases, yep, it is hopeless. In fact, even doing "basic" manned missions outside of the Kerbin SOI is quite hard. Kerbalism difficulty balance make what is achievable in KSP roughly in the realm of reality. I've yet to see proof of a successful manned mission to Jool with Kerbalism. And I believe that there are only a handful of people that can claim a successful mission to Duna.

RemoteTech is unsupported in current (3.x) releases, and my advice is to not try to use both mods together. There are many bugs, and even that put aside, the balance is all over the place We have fixed the RemoteTech support code in the in-development next major Kerbalism version (4.0), but there is currently no playable release of that version, and we have no ETA on a release. If you want a realism oriented comms mod, I would suggest looking at RealAntennas which is available for stock and fully compatible with Kerbalism.

You are installing all your mods wrong. When you download a mod, the zip file will usually contain a "GameData" folder. You need to copy the contents of that folder inside your own GameData folder. What you are doing is extracting the whole zip into GameData, wich won't work because mods expect a specific folder path. If you want hassle free mod installation, I suggest you to delete all installed mods and use CKAN instead :

This is semi-intended, as in we talked about it at some point and concluded, "nah, good enough". Due to a bunch of complicated reasons, the stock "can't collect more than X% of the science value" thing is incompatible with what we are doing (collecting science over time). We could probably code a workaround for the scanner arms, but this is quite a bit of work for not much added value.

We already do a lot of prunning, but some conditions can be very hard to evaluate analytically, and once you factor in what other mods might be doing (ex : DMOS) this becomes an impossible task. So no, it isn't worth the effort. In the case of asteroids, those situations are allowed because of stock contracts and various asteroid-related experiments/contracts from DMOS.

This is stock silliness and we don't touch it because that would break too many things. And also, like in stock, those samples are unique for every asteroid/comet (you can re-do the same situation with every different asteroid/comet) Anyway, it isn't because some situation exists in the science archive that you have to do it (or even that it is possible to do it) For reference, the count of every existing subject in a stock, non-dlc 1.10 game sum up to 3543582 science points, more than enough to complete any tech tree dozens of times, even accounting for the occasional undoable subject.

As one of the Kerbalism maintainers, and after a quick look at the implementation, my only suggestion is : do not use that Kopernicus release on any non-test savegame. We are perfectly fine with R-T-B reusing our code, but this should never have been done this way and will cause many issues (or at least it should never had been publicly released in that state).

Yeah, this is an annoying bug. The problem is that we can't easily disable pressurization as a whole because of various reasons, one of them being that the Kerbalism 3.x branch development is in minimum effort mode. In the meantime, you should be relatively fine if you don't ever touch the enable/disable habitat button. We should probably remove the ability to disable habitat as a temporary workaround.

Depends on you MM skills. Not trivial. Otherwise, you can take the easy route and just ignore it.

@eberkain A quick github search show that this "Atmospheric Pressure Differential Scan" is coming from the "PEBKAC Launch Escape" mod. And as to why a launch escape part mod has decided to add a brand new experiment that is basically a duplicate of the stock one, I have no answer. The "because we can" syndrome, probably.

Kerbalism works (relatively reliably) at any timewarp speed. Unsupported other mods modules don't. And if they are unsupported, they won't work correctly regardless of the timewarp speed. If you get the "a producer of XXX has incoherent behavior at high warp speeds" message, that's because you have a mod that produce resources in a way that is incompatible with Kerbalism and for which we don't have dedicated support (or if support is broken following an update to that mod). If you can't find which mod is causing it, post your KSP.log, I will try to find the culprit. Note that NF solar support is currently broken and can be the cause of that. We have a fixed dev build here : https://github.com/Kerbalism/DevBuilds/releases/tag/DevBuild-7621

@LadyAthenaWhat is likely happening is that the contract requested a "Kerbin landed water" result and what you have is a "Kerbin splashed water". And yes, contract completion only happen when you recover or transmit the science, not when you collect it. Also, to answer your previous question : yes, some contracts can generate with "undoable" experiments result requirements due to the contract system being unaware of Kerbalism custom restrictions. We try to limit those cases as much as possible, but this can't be fixed without huge hacks, especially for the kerbalism specific, non stock experiments. Just be careful when accepting science contracts.

The planner show 0.536/m , not /s The planner simulate the whole resource chain, and processes (like the fuel cell) output scale according to needs. Here the fuel cell is running at a small fraction of its 2.043 EC/s capacity, because you are only consuming 0.034 EC/s, that's why it consume less hydrogen/oxygen.

That's much less relevant than what people usually think. No matter if you use 32 or 64 bit floating point precision, the distances in KSP are so huge that you have to adopt a floating origin system, and potentially even more complex implementations. It's a typical case of "if you're doing something special, you can't expect the simple generic solution to work".

Yes. My main worries comes from the whole interstellar scope of the game. KSP 2 will have to deal with interstellar travel time scales. Meaning they will need to run the simulation at even higher timewarp factors than what is used in KSP 1. Timewarp is a huge technical constraint. In KSP1, almost every feature is either disabled, or doesn't work consistently when you timewarp and even more for inactive (unloaded) vessels. The few system that are actually somewhat handled in timewarp, like the resource system, the thermal system or commnet have a special, barebone or inconsistent (to not say broken) behaviour. Simulation algorithms that work consistently at varying, arbitrary time steps are orders of magnitude more complex. They require more processing, and they severely constraint what you can do. And no matter how smart that code is, there is the issue that the simulation entry variables aren't constant. The whole point of a discrete simulation is that you evaluate every external variable continuously, at an interval that is faster than a significant change in those variables. If you have, for example, an algorithm that depend on whether the vessel is in sunlight or in the shadow of body, you need to have at least a couple sampling points for each situations. At 100 000x and 50 ups, it mean a simulation step is done every ~30 min of real time. It's already a quite low "resolution", a lot of things can change wildly during 30 minutes. From my experience, the maximum time step that still work reasonably accurately is on the order of 1-2 minutes, which at 50 ups, correspond to a timewarp speed in the order of 5 000x And you can see that in KSP. Going from 1000x to 10000x is the threshold at which everything start working weirdly. Now, in stock KSP1, it doesn't matter much. First because almost every gameplay feature is only enabled in the physics, real time (4x timewarp max) bubble. Second because the few features that are actually enabled in non-physics warp (main example is the drills/ISRU/core heat system) are quite shallow, and simplistic enough so the inconsistencies don't matter much. But KSP2 apparently intend to have several core features for which that issue is applicable. They have mentioned the ability to run engines during timewarp/in the background. And there is the whole colony building thing with supply chains, ISRU, etc. Those are great ideas on paper. But by enlarging the scope of the game to interstellar timescales, and consequently to even higher timewarp speeds than KSP 1, IMO, they shoot themselves in the foot if they intended to make any non ultra simplistic and more or less physically accurate subsystem, like resource chains, thermals, comms, radiation, life support, or any time based game mechanism (science, scanners...) In KSP1 (or in KSP 1 mods), those features have tons of issues with timewarp, but the 100 000x limit still is more or less manageable. And on top of that, there is multiplayer, which add another huge range of constraints, although it will all depend on what is actually KSP 2 multiplayer. Since we've got zero information on that, I won't go into technical details about what those constraints could be, but they are potentially non-trivial as well. And finally, on a more conceptual level, and it is more my personal opinion than a technical issue, I have a problem with the whole interstellar aspect they are introducing. IMO, the core concept of KSP, what make it an unique game compared to all other "space" games is that it is a relatively accurate, and realistic physics sandbox. It is exactly in the sweet spot between a pure simulation (like Orbiter or MS Flight Simulator) and a "enjoyment focused" game. It has a few simplifications, like 2 bodies orbital physics, abstracted fuel types, less constraints on engine usage (throttle, ignitions...) for the sake of gameplay, but not much. By going into the realm of pure hypothetical, science fiction technologies, it breaks that fundamental contract. On a surface level it doesn't change much, but it make all the dimension of attempting to model the actual, known, physical challenges of space travel and exploration almost pointless. What's the point of a physically accurate thermal simulation if you introduce engines and energy sources of such magnitudes that they don't have an actual realistic solution in that regard ? What's the point of a communication network with a range system when you work on distances for which there is no realistic solution ? What's the point of a somewhat realistic ISRU/colony system when it is producing structures and technologies that are so enormous and advanced that all the current industrial capacity on earth couldn't do it ? What's the point of representing any current space technology or goals if we are put in the realm of science fiction after a few hours of gameplay ? Something that made me realize that is the interview with Nate Simpson and Scott Manley, where Scott Manley made the remark that SRBs can gimbal. Why would they care ? They are focused on the color of science fiction engines exhaust plumes that make SRBs an irrelevant and obsolete technology. That interstellar scope clashes fundamentally with anything we can relate in the current age of space exploration. They could have done everything they are doing but with staying in a single planetary system. There are tons of "near future" technologies they could have implemented, with actual real science and physics to back that. So yes, I'm not thrilled. I fear a lot of things will be very shallow, both because of the unrealistic interstellar scope, and because of the technical constraints. I fear they are trying to much to have "exciting" features, and that in the process they will both fail at making a good game and a good space exploration simulation that is appealing to people that have an interest in relatable, current space technologies, programs and prospects. It might be a better "wide audience" commercial strategy, and maybe they expect the modding scene to provide what they won't on that aspect. But on the other hand, all the (speculative) technical issues I talked about might get in the way of that. Modding is hard, it's time consuming and the difficulty increase exponentially when the features you're trying to implement have no solid ground in the base game. Future will tell.

https://forum.kerbalspaceprogram.com/index.php?/topic/194258-large-info-dump/&do=findComment&comment=3793267

Well, KSP isn't that bad. It just isn't programmed in an optimized way that scale well when there is a large amount of things in the game. And on the other hand, most of KSP systems try to be quite physically accurate, with varying degree of success, but that's one of the main reasons why they are so CPU intensive. A big issue in KSP is that almost everything is done in the main physics engine cycle, which has a fixed budget of 20ms (50 ups). KSP performance bottleneck mostly comes down from the fact a lot of things that aren't related, or needed, for physics are done in the physics cycle. It's like this because in Unity, it's the default, easy, fastest dev time way of doing it. But for a lot of the most CPU intensive simulation features of KSP, there is very little justification in having such a rapid 20 ms update cycle. KSP is not a game were there is a need for "instantaneous" interactions between everything, like in a FPS or a RTS. Introducing a separate custom loop that work on a larger timestep, lets say 100ms for example (and ideally on a separate thread) would allow to take out a good chunk of the CPU load from the physics loop. The resource system, the thermal system, the orbit solver, all that doesn't need to be on a tight update cycle. The only things that really require it are the aerodynamics and the control/thrust providing modules, because they directly interact with physics and need to react quickly to player inputs. It's indeed an area where Unity DOTS could provide a better infrastructure, as the "legacy" Unity gameobject system is firmly tied to the "standard" Unity update cycle. But it could be done without DOTS. Unity is a graphics engine that provide a "general purpose" game loop framework (and a ton of other features), but there is nothing preventing a developer to use it only partially and implement a more specialized system that better fit specific purposes. That's kinda what DOTS is about, to provide some less constrained tools for specific performance intensive applications that require a custom approach, without having to implement a completely from scratch custom solution. But a specialized game that require performance intensive computations has to implement custom solutions. You can't expect a general purpose framework made to fit any game from 2D platformers to 3D FPS to perform specialized tasks in an optimal fashion, and this is a valid point for every single game engine. An over the top example is Principia : it's a completely custom N-body engine written in C++ that interface with Unity and KSP, but implement a high performance, multithreaded chunk of code with it's own independent update cycle, made for a highly performance constrained specific feature. But don't underestimate the amount of work that is needed to make all those, and how complex those things are. One of my main worries for KSP2 is that instead of implementing high performance solutions, they dumb down some subsystems/features. Or worse, for the sake of their multiplayer or interstellar timescales ambitions, which add an order of magnitude of complexity for solving those issues.

The performance difference between aero and space situations 100% comes from KSP in-house implementation of aerodynamics and thermodynamics, which are incredibly CPU hungry. It has indeed absolutely nothing to do with the physics engine that handle joints and rigid bodies. I could go on for hours. For example, every partmodule in the game is an isolated system that does it's own thing and consume a lot of resources to do so, and in a lot of cases, all partmodules of the same type on your vessel are doing a computation that could have been done once for the whole vessel. It also mean that a lot of things that are vessel wide can only be analyzed by querying all individual partmodules. But it's a very specific example, and maybe not the best one, since the PartModule model is also great because it allow a lot of flexibility and is dead easy to work with. But that's the general problem of KSP. A lot of core systems are built in a kinda "brute force" way, using the simplest implementation, usually the one that require the less work. There is very little consideration for performance at the heart of all those systems. And it shows. KSP has received a lot of "after the fact" micro-optimization, but there is so much you can do without starting from scratch. I'm not saying the physics engine isn't a bottleneck, it is. But there are a lot of low hanging fruits in everything else in KSP.