RoverDude

There have certainly been cases in my most recent career save where eating a scientist would have saved the mission...

ILMs clip slightly by design - the collider is actually a bit further up so they appear to settle in the dirt.

Super easy, just reduce all habitation EC costs by a factor of 10. I did all of mine by hand in a few minutes. (Hab only not recyclers)

What part of the lower node or duna nodes are not matching? those should all be standard, and moving those nodes around can have some serious consequences.

Probably the sketchy RNG, but definitely would be good to know if other folks have seen this

@damerell - running a lot of converters for a lot of unloaded vessels is prohibitive. Running a bunch of them for what you have in physics range is fine. Batching has it's own issues/constraints. But there's a lot more going on than just doing a bit of math. You're also checking and consuming resources, dumping thermal heat, and other things that have to work with fuel flow, the resource graph, the thermal model, etc. (and a lot of stuff in MKS already does things in small-scale batches for perf reasons - i.e. logistics only checking every 5 seconds, for example). And sorry, running FixedUpdate every 0.02 seconds may be the same rate as a 50hz clock, but it is not the same thing.

@ShotgunNinja - With all due respect (and to be clear... this is the MKS thread not the Kerbalism thread). I warned you ages ago when I noticed just how much of core stock functionality was missing. And while Kerbalism may work to an acceptable degree for many mods (though not many would have gameplay changes where background activities were a fundamental part of the process), it has never worked with MKS (and probably some other USI mods based on what's missing)... this has been known since day one. It has nothing to do with fairness, it is simply the reality of things. As you say, there is no absolute 'right', merely 'right' for the job. And 100% compatibility with stock (and mods that leverage stock) is demonstrably something that Kerbalism does not do. For most people, the 99% case is fine (as I noted earlier). For MKS users (and again, this is the MKS thread), it is fundamentally breaking.

Yep, and in this case, (100%) mod/stock compatibility was not a job Kerbalism took on. Nothing wrong with that, just the reality of things.

Required resources, Efficiency Bonuses, and Specialty effects (which have a significant impact, whether the vessel is in the foreground or not)? What about ground contact and drill orientation detection for harvesters? To be clear. There are a lot of ways to skin a cat, based on your goals. And if Kerbalism works in the 99% case, and trades performance for that 1%, then all the more power to you. But it does make it fundamentally incompatible with MKS (or any mod that leverages missing features). Stock trades some sleight of hand for feature depth. The new (MKS) logistics system being worked has different tradeoffs. But regardless, there is no such a thing as a free lunch. And one of the prices you pay (to wrap a bow on the genesis of this topic) is performance. Maintaining the entire breadth of stock offerings without batching and with unloaded vessels would start causing hitches. And would amplify as your vessel count and bases (loaded/unloaded) got larger. So you either do sleight of hand and discount unloaded vessels (stock does this), or you cut features (Kerbalism does this). Which, as you have probably seen by now, is a pretty deep feature that includes a lot more than just inputs and outputs @voicey99 - fixed now. The sheet did not reflect the 90% EC cost reduction for habs. @DStaal you probably want to check that one too. It came as a result of feedback that not everyone has nuclear reactors and there were a lot of Kerbals freezing to death in USI-LS saves

It *should* be current, but I would need to double check it (or of someone beats it to me, run a Tundra hab through it as a test).

I can double check that (log an issue as a reminder). EC was changed recently and EC cost for hab reduced. I vaguely recall that the HH was a bit weird in that it's mass/volume was really out of whack

I am pretty sure that was sorted in a recent patch If anything... one would think you could disassemble a Kerbal into supplies.

And I am not referring to a 50hz clock. In KSP, FixedUpdate runs (by default) 50 times per second. And a lot of stuff happens in that timeframe. Putting a lot of stuff there kills performance. Last I checked, Kerbalism did not replicate all of the stock functions such as thermal (which affects thermal efficiency), depletion nodes, required resources, and probably a few others I brought up back in the day that MKS leverages. This is what causes a fundamental lack of compatibility.

A couple of thoughts as well. The overall system is pretty darn stable - i.e. there are no major changes to existing systems planned, only additions of parts/mechanics as needed (the exception being planetary logistics but that will be part of a larger feature set). So any assistance on wiki / documentation / vids / etc. is always appreciated. And there are tons of helpful folks here to answer questions.

Actually, no. Running anything in a tight loop (i.e. 50 times per second) stacks. It is simply NOT performant. This is kinda why we went through doing a ton of hard-core optimizations in 1.2, and why there's a ton of caching, etc. done - to squeeze everything we can in that 1/50th of a second before we hit noticable hitches in perf. And that includes converters. A few you will not notice. A bunch of them - when you couple in testing things like planetary resource densities (since depletion is supported), bonus calculations (which can be affected by resource presence hence you're hitting the resource graph), thermal (which updates every tick for obvious reasons), etc, etc, etc, makes processing lots of vessels in real-time a REALLY bad idea. (Source: I might know a thing or two about how stock converters work, the optimizations in place, and the compromises we made from a design standpoint to support massive vessel/part counts without slowing to a crawl because you tossed 80 drills on a single vessel...)

ATM can be deprecated given we do DDS now

Also - I agree with @DStaal - Karbonite capabilities on MKS drills should only be there if Karbonite is present, given that Karbonite (the mod) is separate from MKS. No different than you can see KSPI resources being harvestable, but there are no tools to harvest them included with MKS given that MKS does not use said resources. @N3N - would need to take a look, but see the note above. If they were to merge into the main mod, they should only light up if Karbonite is installed (pinging @TheRagingIrishman as well so we're on the same page).

Moving configs to patches, sure. Moving icons would be a code change (easy enough to see where). And always happy to get PR's for stuff that has changed over the years

They are not. (To add: The multipliers themselves are configurable)

@MaxwellsDemon - as @DStaal noted, hab multipliers are your friend. The optimum hab time tends to be a mix of both. I've had no issue ever getting bases past the 50+ year mark.

Non-Disclosure Agreement. It means we can't talk about stuff, nor can we confirm or deny stuff.

NDA

No difference RE the changelog, it was just a performance update

Reminder - there is a new pre-release for the constellation available (let me know if anyone gets lag with this version or not!) Thanks

@Grobluk (and anyone else interested in testing it out) new pre-release is up. Please let me know if anyone experiences any unusual lag, etc. Thanks!