Gotmachine

Should be doable. Will look into it.

The fix might help with that, but this is unverified. The specific case it might fix would a simultaneous decouple-launch action (think Apollo mun lander departure) where the "grounded" parts are staying behind. It does fix a general vessel state update logic potential issue in the KSP code, but there are many things that could be responsible for the "stuck landed state" issue and without analyzing a reproduction case, it's all very hypothetical.

V1.17.0 is out. Available from GitHub and CKAN. Changes in that release : New KSP bugfix : StickySplashedFixer [KSP 1.8.0 - 1.12.3] Fix vessel never leaving the splashed state if it starts out splashed, and decouples from its only splashed parts. This also fixes an issue where Splashed overrides Prelaunch as a situation. (@NathanKell) New modding bugfix : DepartmentHeadImage [KSP 1.8.0 - 1.12.3] Fix administration building custom department head image not being used when added by a mod. (@NathanKell) PersistentIConfigNode patch : added Guid serialization support to CreateObjectFromConfig(), LoadObjectFromConfig() and CreateConfigFromObject() methods (@NathanKell).

Aside from being a bit out of scope for KSPCF, this is something I won't touch as the omnipresent ToolbarController mod is already somewhat taking ownership of the stock toolbar. I suggest you ask for such a feature in that mod instead.

HighLogic.LoadedScene

The 1.12 maneuver planner tool has many issues, some are simply UI/usability problems that are relatively trivial to fix, but others are just the solver(s) not being up to the task (not to mention implementation issues that can cause the game to freeze). I have no intent to "fix" it as there are more complete and actually maintained alternatives in the modding ecosystem, and I believe that unless somebody starts some active development to fix/expand the stock thing (possibly reusing code from existing mods), it will simply never be something really up to the task. Which is why currently, the only fix for the maneuver planner in KSPCF is adding the ability to disable it. This being said, the main issue with it is that it often simply doesn't update the transfer solution according to the current orbit if it has changed since the last time the craft was loaded, which result in garbage transfer time / transfer parameters. That could be fixed, but before anything is done on the usability/features front, the major bug causing stutter/freezes must be identified and fixed. I personally have no intent to work on that. @theJesuit@JonnyOThan It's quite possible that there is a Kerbalism issue with the EVA propellant handling. I did add support for the "new" KSP 1.11+ EVA propellant system using cargo parts at the time, but I think I saw some related changes in 1.12, so maybe the support code isn't working as intended anymore. In any case, this isn't the right place to talk about it (but don't count on me to work on that even you talk about it elsewhere :P)

V1.16.0 is out. Available from GitHub and CKAN. Changes in that release : New KSP bugfix : EVAKerbalRecovery [KSP 1.11.0 - 1.12.3] Fix recovery of EVAing kerbals either causing their inventory to be recovered twice or the science data they carry not being recovered, depending on the EVA kerbal variant/suit. Thanks to @JonnyOThan for bug-reporting. FairingMouseOverPersistence : patch now only applies to KSP 1.10.0 and latter, as the field it relies on doesn't exists in prior versions, causing exceptions in OnLoad()/OnSave(). Thanks to forum user @DeliriumTrigger for reporting. Codebase cleaning pass, analyzers are now happy (or silenced). @DeliriumTriggerCrappy report is better than no report And perfect timing, I was just about to do a release.

No, this is likely a different issue. That seems weird to me. KSPCF doesn't touch anything related to EVA or resources, and I've personally been using KSPCF and Kerbalism together without seeing that issue. You can disable individual patches by editing the "Settings.cfg" file, read the OP. Or better, by making a MM patch that disable them. That way you won't have to do it again if you update the mod manually. Something like that : @KSP_COMMUNITY_FIXES:FINAL { @PatchName = false }

This is actually a deeper issue. You will notice that this only happen to the base male EVA variant. If you use a female Kerbal or one of the EVA suit variants, science data gets recovered, but the carried cargo parts gets recovered in double amounts. This incoherent behavior also affect potential modded modules implementing IPartCostModifier. I know where the issue is, but fixing would induce a somewhat breaking change in the "GetAllProtoPartsIncludingCargo()" public method so I need to do a few tests.

V1.15.0 is out. Available from GitHub and CKAN. Changes in that release : New KSP bugfix : ScatterDistribution [KSP 1.8.0 - 1.12.3] Fix incorrect terrain scatter distribution when a partial longitude range is defined in the PQSLandControl definition. (credit to @R-T-B) New KSP bugfix : LostSoundAfterSceneSwitch [KSP 1.12.0 - 1.12.3] Fix audio source not being centered/aligned with the current vessel after scene switches, causing loss of vessel effects audio and random volume or left/right channel weirdness. (credit to @ensou04) Fixed KerbalInventoryPersistence patch not being applied on KSP 1.12.3

Hi. Not familiar with this issue, but from a quick look and judging from your current fix, the issue seems to be in the "FlightCamera.EnableCamera()" and "FlightCamera.DisableCamera()" methods. They are re-parenting the "AudioListenerGameObject" using the "Transform.SetParent(Transform parent)" overload that set the "worldPositionStays" parameter to true, which will induce a local position/rotation offset when reparenting. Patching those methods to use the "Transform.SetParent(Transform parent, bool worldPositionStays)" overload with that last parameter set to false should prevent any offset to ever be introduced. Will prototype a patch and come back to you for testing.

Retracted antennas are disabled. But for non-deployable antennas, no. If you search this thread, I think I remember someone made a MM patch a while ago to add a fake deployable module to fixed antennas, but I'm not sure this ended up working correctly.

These logs are usually in the "Logs" folder, but there is no rule here, some mods can use a different folder. And no, while I disagree with the "separate logging" practice, I won't touch what other mods are doing, it's their responsibility, not mine. Beside, there is a also a valid use case for keeping around "one-time" logs that are only generated the first time a mod is installed (like the MM patching log for example).

V1.14.1 is out. Available from GitHub and CKAN. Changes in that release : Fix KSPCF issue #39 : AltimeterHorizontalPosition patch causes state inconsistencies with vessel filters. Fix KSPCF issue #40 : UIFloatEditNumericInput patch breaking IR custom FloatEdit control. Don't alter the control prefab list, instead return our custom prefab on the fly in the KSP methods searching the prefab list.

The issue is that IR tries to copy the stock FloatEdit control prefab to create a custom version of it, but it doesn't find it because KSPCF replace it with a derived type (because it add support for numeric input to the stock control) This could likely be fixed by a one line change in IR, but I will look if I can change how the KSPCF patch work to avoid this.

V1.14.0 is out. Available from GitHub and CKAN. Changes in that release : Updated Harmony to v2.2.1 New KSP bugfix : PartListTooltipIconSpin [KSP 1.8.0 - 1.12.3] Fix editor tooltip part icons not spinning anymore after hovering on a greyed out surface attachable only part while the editor is empty (investigation efforts by @StoneBlue). New KSP bugfix : AsteroidSpawnerUniqueFlightId [KSP 1.8.0 - 1.12.3] Fix the asteroid/comet spawner generating non-unique Part.flightId identifiers. This has a few minor side effects in stock (mainly incorrect science bonuses), but this field is heavily relied upon by various mods and this can cause major issues for them. New QoL patch : DisableNewGameIntro [KSP 1.8.0 - 1.12.3] Disable the "intro" popups appearing in the space center, VAB/SPH and tracking station upon creating a new career game. Disabled by default. New performance patch : PQSUpdateNoMemoryAlloc [KSP 1.11.0 - 1.12.3] Prevent huge memory allocations and resulting occasional stutter on PQS creation happening when moving around near a body surface (investigation and fix by @Gameslinx). Fixed multiple RoboticsDrift patch issues: Improved general numerical stability by normalizing input/output Quaternions. Fixed potential NRE spam happening after in-flight vessel hierarchy changes (ie, docking/undocking/decoupling...) Fixed random child-parts-of-robotic-part displacement after timewarping/reloading (bug introduced with the changes made in 1.12.2) Modded robotic parts whose servoTransform has a position offset relative to the part origin (either due to non-zero local position in the model hierarchy or a position offset in the part config MODEL{} node) are now unsupported. This mean drift correction won't be applied for them, and the stock behavior will apply. KSPCF will issue a log warning when unsupported parts are loaded in flight. Note that such a configuration isn't fully supported by stock either, and such parts will also have issues when manipulating their angle in the editor. And while I might find a way to fix this issue in the future, I strongly recommend mod authors to check/alter their models to ensure the servoTransform has a zero relative position/rotation from the model root. As of writing, this issue notably affect the BDB Skylab truss, the "More Servos" mod by @Angel-125 and possibly others. Thanks for the report. Will try to fix this for next release.

Unless some savior step in to put its hands in that mess, no.

Retrieving airlock air instead of dumping it overboard involves a big pump and additional equipment. This add complexity and weight, so unless the mission involves a lot of EVAs, it is way more efficient to just bring a bit more nitrogen and oxygen. As far as I know, only the ISS Quest airlock has such a recovery system, and only something like 70% of the air is reclaimed (because the closer you get to vacuum, the harder it is to pump), some amount is still dumped overboard. And there is the issue that pumping air is slow, unless you have a really huge pump. If I remember correctly, for the Quest airlock, the procedure takes about 1 hour. During that time, the EVAing crew is stuck waiting in the airlock, consuming their EVA suit air/electricity/etc, so there is a point of diminishing returns there too.

Automatic bug reporting is bad. As other have mentioned, all it does is swarming the developer with useless reports. However, automatic bug report creation vastly improve the feedback quality for users that are actually willing to properly support their request. An in-game button that grab the log files, current save and game database dump and put all that in a zip file on the user desktop, ready for being uploaded is something that would have saved thousands of user and developer (both for Squad and mod developpers) man-hours in KSP1. Additionally, I would argue that automatic background error collection and statistics is very useful for the developer (ie, automatic upload of errors/exceptions and basic associated info like a stacktrace which are then automatically analyzed on the server to produce statistics). But people are usually loosing their temper as soon as any application tries to automatically collect and upload some data, so from a PR perspective this is usually a bad move.

@R-T-BHaven't tested it but pretty confident that's a stock issue and has nothing to do with Kopernicus. I will take a look. Edit : I gave a look, @RodgerDo you have your vessel type set to "Space object" (in the vessel type selection available from the "rename vessel" popup) ? If so, the auto-renaming is a stock "feature". I guess the idea here was to avoid loosing the original comet name. Good idea, bad execution. If you want to avoid it, either : - assign another vessel type to your vessel. - change every comet name to the vessel name you want (using the "Rename Comet" button on the comet parts PAW).

Nah the PAW is fine. Those wheel controls are awful and have no reason to exist if you have mouse input. Their usability falls down drastically once you have more than a handful of actions/items. They also are unintuitive and slow to read for random items. When they are implemented on console games, they work well because they always have the same items in the same place, so you quickly learn how to navigate them intuitively. But your brain is much more efficient at parsing a vertical pattern than a circular one. That's why newspapers are (were) formatted in narrow columns. That's basic UX/design principles. The PAW clutter and usability issues in KSP1 are caused by the absence of a top level vessel-level UI, a "VAW" for "Vessel Action Window". Stuff like camera controls, crew transfer/EVA, control point and target management, comms management, science data management, resource management and transfer, crew inventories, etc should be implemented in a vessel-level UI, not in a part-level UI. And arguably, the vessel-level UI should also have a part/module list allowing to access part/module level actions, unifying the PAW system and the "action group" system.

MechJeb has an autopilot, amongst many other features. Like a DV calculator and many maneuver node planners.

Mechjeb

Yes, obviously it also runs when you manipulate the UI. I have no intent of actually fixing this thing. There are better alternatives in various mods. It entirely remove the component from the game, including the button. Yes At the bottom of the KSP in-game settings menu (the one you get when pressing ESC > settings)

That's just not true. The decision to upgrade from Unity 5 to more modern versions was the best thing that happened to KSP. It fixed tons of issues and increased performance on multiple fronts (for example, remember the whole GC stutter issue ? It's a thing of the past thanks to the Unity incremental GC mode). And it was a godsend for the modding community. It allowed to use modern .NET tools and Unity features. Many mods like RealAntennas, Parallax, EVE, Scatterer or TUFX are taking advantage those features. Nate Simpson stated multiple times that they envision KSP2 as a game that will be supported and expanded for many years. It would make no sense to freeze the Unity version. Unity is a fairly stable product at this point and they are committed to preserve backward compatibility. Letting the game engine fall behind mean falling behind the entire PC ecosystem, both in terms of software and hardware support. Unity LTS versions are supported for 2 years. A game engine is like every software in the world. You have to keep yourself updated regularly. In the specific case of Unity, updating while in development isn't difficult at all and is very unlikely to break anything major. Freezing the engine version is only justifiable once the development cycle has entered the final refinement/bug-hunting phase where every major feature is complete.