RoverDude

Not a fan of tweakscale - the Osprey is the big brother to the Akita and is a WIP. And trust me... even if I require more than one part, people game the system - they are incredibly creative

Need more info. Starting with KSP version, MKS version, and a screenshot of your GameData and USI folders, because I have never seen this issue.

The question still remains why. i.e. what is the specific use case for joining a non-construction port to a construction port? If you want to do traditional docking, use regular docking ports. Construction ports are meant to be transient parts used only for the purpose of welding two vessels together permanently.

Actually, I was just talking to @allista about the models for orbital construction and in-situ DIY kit creation RE rovers - the only rub is whenever I have had a rover mechanic like that, people just abuse it and spam the required part on their vessel

There must be at least one MKS part in the vessel

Pic of your base please?

@allista - congrats again on your new addition Enjoy them while they are young, they grow up fast!

Yep, it still does machinery but no longer does the ReplacementParts mechanic

Correct. Although I'm considering a rework on the wear mechanic but that's still on the drawing board

Show us the craft. Ducted fans should work on Duna, but there were some changes in prior KSP versions that may have them be less efficient due to atmospheric density.

Sorry, why not just use two construction ports? I really am having a hard time understanding the ask

Logistics should work with either QM or Pilot

I can pretty much guarantee that your issue is not this mod.

I think you're confusing dependencies with... something else. AT Utils does not require CC, it's the opposite. And no idea what the heck Kethane has to do with any of this as I have not supported Kethane in years.

It doesnt... but it requires pointing to a version file... and the instant that file is checked in at that location/branch, it is eligible for indexing. I generally make the version files and changelogs weeks in advance. And yeah, Git is pretty lousy at centralized version control.

Except for the whole rub that you need a specific branch for external tools to key off of (CKAN/KSP-AVC/etc) - as well as a simultaneous place to prep the release (i.e. Dev). The easiest solution is to just kick back every PR against Master and tell folks to go against the correct branch. I'm (sometimes) more flexible on this because I do realize people are being nice and doing stuff for free.

That would be USI-LS. And will also probably make a lot of modules kinda weird as their production chains and capabilities won't do anything anymore. Curious why it has things disabled instead of layered on top tbh

See above. Enable logistics on the kontainer then perform maintenance and you will be good to go. Semi-related side note, there's some discussion of this mechanic and some ideas floating about - will post more details once we've hashed them out Also - usual call-out if folks are interested in joining the team (toss me a PM if interested). Even if you can't code, folks that can help with Github issues and config files are always appreciated! Oh... certainly a possibility then if you are on an older version

Enable warehousing on the kontainer.

I went ahead and reverse integrated everything accidentally checked into Master back into Develop just to be sure For the benefit of those tossing in PR's... I work off of Develop. All PRs should go there. Once a release is ready, it is merged into Master (which is what CKAN and KSP-AVC check). So on release day, Dev and Master are the same. Where stuff gets shaky is when people do code changes in Master, because the DLL will be stomped by the DEV one (I compile on DEV then merge the DLL into Master). And yes, a release is being prepared with a few surprises. Earliest will be Sunday, tho I am likely going to do a constellation pre-release first so we can make sure everything got fixed and that there are no horrendous issues

That last sentence does not make sense. Life support containers are not required for USI-LS to work.

Unfortunately, sounds like you have an issue unique to your install - I'd recommend moving to 1.3.1 and the most current versions.

KSP version? MKS version? Sample craft?

@sh1pman - thanks! I wanted to do some optimization passes anyway

All good - any chance we can test that on a stock save? i.e. maybe hyperedit the base to orbit and swap back to stock then re-land it? (FYI the massive lag I had with GPP was because I had an upgraded settings file... which is bizzare but deleting my settings and redoing them fixed the lag)