Jacke

The following is my ModuleManager config file to add MechJeb2 to all command pods. You need MechJebLocalSettings as well.

You don't create a log file. KSP does that automatically. Mod developers need log files to troubleshoot issues. Read this post to find out more.

Shouldn't you report this in the Kopernicus topic, that perhaps it shouldn't adjust the cloud altitudes in clouds.cfg for Kerbin ?

Realism Overhaul includes a large number of dependent mods to be a total conversion mod set to convert the Kerbin system into the Sol system and all that entails. Whenever KSP changes in a significant way (most version changes) those dependent mods have to be updated to mature working versions before RO itself is updated. Having so many dependent mods works for RO (and is likely the only way to make such a transformation) but it's why other mods try to limit their dependencies.

I saw this thread and thought "Thuds in KSP ?!?" Different Thud.

The one big flaw in stock action groups needs to be removed: linking action group availability with building upgrades in career. Action groups are a user interface convenience to ease access to right-click menus with some player ship design planning. During critical flight sequence they are essential. That Squad linked that to career progress is mind-boggling. Even players who forego engineering mods and delta-V for rocket design still use action groups. @Diazo, you've included an option to disable that in the past. When I couldn't use your mod, I looked at making a mod just to do that one thing. Unfortunately, I couldn't find enough good information to make my own mod.

Add a command line option to launching KSP of "-nyan-nyan" and the cat will come back the very next game launch.

This is getting away from Realism Overhaul. However, not knowing any of the details of what happened, I still think there's hope that @sarbian will update MechJeb, especially as he updated Module Manager. I for one would find KSP to be almost unplayable without many of the tools and the configurable windows of MJ. In the unfortunately case that MJ isn't updated, there are other engineer mods (KER, VOID) for info display. For autocontrol, there are mods like Pilot Assistant, but it's more an aircraft autopilot. You'd have to search the mod subforums for anything else.

There are forum policies against pestering a mod writer about when a mod gets updated. Complex mods always take time to get updated after a KSP release. I suggest you just follow @sarbian's MechJeb thread (closed last month on his request, likely due to being him being pestered yet again back in September) and just check his Jenkins page for MJ development releases. He did put out a Module Manager update for KSP 1.2 (and thank you for that, @sarbian).

I imagine it'll only be in time we'll find out as much as possible as to what happened. And how it truly affects KSP Well, I needed something to refer to them and "recently departed" is what came to mind. Despite the mention of cake and the homicidal situations often associated with promises of cake, I imagine all the "recently departed" are still alive. But has anyone seen them?

No, just the cake. And it is good to hear one of the recently departed is still going to continue modding.

Wow, I just saw this. And from the very little I can find, this bodes very very poorly for KSP and Squad. Will have to see what happens. With 1.2. What happens to the mods some of these guys provide. But until I hear differently, I'm assuming the worst.

Parts overlaying can happen even without explicit clipping; happens when attaching parts. Usually it's when the adapter parts are used; another common case is with multiple subassemblies are attached. Easiest way to identify it if you're not sure is to check the numbers. All the parts, even multiple ones overlaying each other, will be summed up. So resources and masses will be too high.

That's the usually effect if you have multiple parts clipped over top of each other. Are you sure you haven't superimposed parts?

@ElWanderer's formula is correct: SHIP:VELOCITY:ORBIT + DELTA_V = TARGET:VELOCITY:ORBIT DELTA_V = TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT

You're right about active control. I'm well aware that without context, numbers can be very easily deceiving. I'm unaware how much a given value of torque is going to affect a design unless I start delving into external analysis. And without an idea of the moment of inertia, that won't get far. But the offset between the different CoM from fully wet to fully dry is a distance that we can easily imagine. And for maneuvering at some random value between them, making that CoM difference small enough is very helpful to tune a design to remove coupling between orientation and lateral movement while doing things like near rendezvous. Especially when monopropellant is tight. I'd like you to restore the offset display if you can do so in keeping with your other goals for RCS Build Aid.

To control memory increase from Alt-Tabbing, perhaps it could be solved with a full-sized borderless window for KSP. WIth any Unity game, launch it with the command line option "-popupwindow" and set its resolution to the same size as the desktop. Then you get fullscreen KSP but not in an alternate video display like with conventional fullscreen.

So, the system reported a faulty part. Your Kerbal went EVA and checked the part and no fault was found. Hmmm...that's just like in.... Be afraid. Be very afraid.

Perhaps you want to try RealPlume - Stock Configs Continued. It handles stock engines and most mod engines as well.

If you have one screen element overlaying another, both with clickable widgits (example 2 windows both with buttons), then if the upper one has click-through protection (which is what is expected) when you click on the upper element, only its widgits get the click. If the lower screen element's widgits get the click event as well, even when covered by the upper screen element, and react to it, it's likely to be unintended and lead to problems. All the overlain screen elements should have click-through protection that doesn't cause other problems. Unfortunately, as we found out here, that doesn't always happen.

I noticed that the Distant Object Enhancement included in the SVE download has a .dll from April 28. Latest DOE has a .dll from June 23. Should there be any problems using the DOE versions from its topic?

Well, despite your smart remarks, wheel physics did change. This has been discussed over and over again. Squad had to completely recode it for KSP 1.1 and Unity 5. It's why any parts mod from KSP 1.0.5 and before had problems with their wheels and landing legs until they were upgraded. And unfortunately there are bugs in Unity that caused the wheel problems in KSP 1.1. The workarounds have been improved over each KSP subversion, but will only be resolved with another Unity upgrade coming in KSP 1.2.

I would highly suggest using Stock Visual Enhancements. It uses the EVE plugins and shaders but provides its own config. It comes packaged with EVE and Scatterer, so you just have 1 download. There are 3 resolution versions so you should be able to find one that works for you.

I too use JSGME to install and remove mods to KSP. I've used JSGME a lot so I know how to work with it to get what I want. The problem with CKAN is that they are trying to recreate the Debian GNU/Linux packaging system apt without having the time-tested policies of the Debian Policy Manual (which lays out requirements for the file system directories, file names, package version numbers and number format, alternatives, file substitution, source and install package components, package dependencies (including pre-depends, conflicts, and breaks), preconfiguring package software, and many other things) and without CKAN being the central authority to insist that the policies have to be followed. When you have that environment that Debian built up over many many years and make central policy, it all mostly works very seamlessly when policy is followed and errors are rare. And even when there are packaging errors the strong tested standards makes them easier to find and fix. Only Squad is in such a position to impose such a good working standard. They have some standards, but should have extended and tightened up the way mod packages are done a while back. Now that the mod community is established, they'd be very reluctant to do such a policy shift as it would likely be highly negative for a long time. CKAN, both via its operators and its supporters, have gotten very pushy in effectively and often explicitly just expecting mod developers to take on the extra burden of both configuring CKAN for their mods and supporting fixing its faults when things go wrong. Even within its restricted purview, CKAN should have expected to do this work itself and should have bent over backwards to make sure it didn't piiz off mod developers. Well, CKAN didn't. It sowed the wind and now it's reaping the whirlwind.

There's another mod that already does that.