RoverDude

Well unless I mess with the balance sheet again and make an exception for fuel products

That sounds right, but no need for a buff as MKS production is already balanced against USI.... stock was made cartoony-fast since it had to appeal to a much broader audience.

@voicey99 - on the low side would be best.

Sure, I am up to my armpits in Osprey stuff today so that would be helpful

Not completed yet

@voicey99 - please do! Can you confirm which MKS version you are on?

huh... that extra 100% is a bug, need to sort that Should have been just 183% in your case

Ramps are kinda a pain for larger rovers without sacrificing stability. One nice thing if you size it right is that after you drop out via undocking (and wheels deployed) to go back in you just stow the wheels which will raise your rover to lock onto the docking port

But such a small price to pay for not having to spam drills once your kolony is established

They do not. At that point. open the doors (assuming you're doing a drop bay), extend the wheels, undock and drop.

Nope, never

@DStaal - not sure if that TAC-LS config that was being worked in a separate thread ever made it in, nor am I quite sure what current TAC-LS integration looks like (as always, PRs are accepted).

Right. As I explained.... Kerbalism does a wholesale update of one of the core stock mechanics - converters. Which is about 90% of what MKS does. So when you override all of this behavior and cut bits out, it is going to break stuff that depends on those stock functions existing.

I would add - and more for the folks that do not watch me stream and chat about stuff like this... The intent was always to have native base construction (one way or the other) as part of MKS. I have a pretty hard and fast rule that I make no assumptions about installed mods - it's why that while MKS supports KAS/KIS, it works fine without it. So whenever there's a core bit I depend on, I either make it myself (USI-LS, CRP), help maintain it (CCK, Firespitter), or have access to the repo to help out with releases in case I need a day-zero compile (or someone gets hit by a bus (Ground Construction). This is important because there are a lot of things I want to do that explicitly depend on certain features existing - namely, reliable in-situ construction of large base components - that I needed in place before they could be released. So when I can operate on the assumption that stuff will always be there, it opens up options. I was originally going to roll my own (and was just about to...) when it turns out @allista made like... 90% of what I wanted. More importantly, we share the same philosophy regarding the importance of constraints, and there was a willingness to collaborate and make sure that the experience with Ground Construction was the same (or very similar) with or without MKS. This is the same approach I took with OSE workshop. In that case, I had no problem completely reworking MKS to work with MaterialKits (the resource @ObiVanDamme created with OSE Workshop), since it made for a seamless experience. The key takeaway being that both of these experiences (GC Integration and OSE Workshop integration) have resulted in far better interop than was really possible with EL. The good news being that with GC being as much a part of MKS as Firespitter or CRP, it means that I can focus on some other parts, but also invest time helping @allista make GC a better mod, and by extension, increase it's functionality in MKS, without having to worry about mismatches in interop. For EL, it will be just like any other mod - there are no direct conflicts, but no assumed support. Patches will be community based, and very likely, optional. Because by definition, any EL patch is going to mess with how EL works, and will require either new parts or configs to EL - i.e. the entire reason, with the lack of an official EL 'detailed mode' I could dovetail off of, that got us to where things stand now. To dig in a bit - and this may have changed - to handle the performance tradeoffs Kerbalism uses for this, it cuts a few of the less-used stock mechanics out. Mechanics that MKS very much depends on to work, as MKS is very tightly coupled to the stock resource and converter system. So anything that fundamentally changes this or swaps it out is going to have some really weird effects. @DStaal - going to hold off on merging anything EL related since either (a) we assume that there's no EL config change to the MKS production path (in which case, all we need to do is remove the current EL config entirely), or (b) if an optional EL config is included, it will need to override the behavior of EL parts to match the MKS production chain. I am ambivalent on this, either one works, since it's kinda in the same boat as TAC-LS (i.e. it works... but it is not native).

Yep, they do not conflict.

The only rub... is that any included community config will have to MM edit the EL parts to use an MKS chain, or we just don't include alternate configs at all. Otherwise, stuff gets wonky (and we head down the path of why I ultimately dropped native EL support anyway).

Do you use USI-LS? If not, then those configs don't really matter as the extra ones are USI-LS specific

Ok - that specific model is bugged. The other ducted fans look to be working, so leave the inline one be till the next update.

@jd284 - thanks for finding that Will go ahead and fix it in this end

Yes - only MPUs have push built in, drills do not.

umm... USI-LS has had this for months

All on the craft, and with that same constraint.

If it's still an issue I'd like to know so it can be sorted, but we'll have to agree to disagree on KSP's suitability for life support hard modes.

Then probably better to say 'a small mod conflict here or there' then, @Jebs_SY

Hey all, So with no planet mods and with SVE, I get a solid 60fps. With Kopernicus I drop to between 30 and 40 fps. Note this is still without any planets, and I have similar behavior with and without scatterer. Thoughts?