Gotmachine

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.

No, it runs in the background on certain events. I'm sure it at least trigger a background computation on active vessel switches and every time a maneuver node is created or deleted, no matter if the widget window is opened or not. I think it also run in the background when your orbit eccentricity or inclination goes past a threshold, but I haven't investigated in detail. I guess the design intent was to have those (potentially lengthy) calculations available right away without having to click on a "compute" button and wait a few seconds for the results (this is what happens in similar tools from mods like TWP or Mechjeb). This could have been kinda fine without the implementation bugs, as KSP only use/need a single thread and most people are usually sitting on a ton of unused CPU cores/threads. Anyway, the point is that this tool is buggy and will cause severe stutter or even indefinite hangs in larger-than-stock systems.

The whole thing is... messy... Robotics give you 2 slider adjustments over the joint "stiffness" : the motor "torque limit" and the "damping" . It also gives you 2 toggleable states : "motor engaged/disengaged" and "locked/unlocked". After a bit of testing, it's not even clear how the stiffness adjustments are supposed to work in conjunction with the toggleable states. The damping slider is always accessible, however depending on the sequence in which you enable/disable the states, changing it has sometimes no effect. As for the torque limit tweakable, it is only available when the motor is engaged, but it still condition joint stiffness after you disengage the motor. And that's just by messing around with toggling those states in sequence. I'm pretty sure things are even more inconsistent after a vessel reload, and I can't begin to imagine the mess of how all of this interact with the "power loss" stuff. The implementation of those states is the very definition of a spaghetti code plate, with each possible state combination (locked-motorized, locked-unmotorized, unlocked-motorized, unlocked-unmotorized) being manually checked everywhere instead of using a basic state machine. And then you have the additional "powered/unpowered" states to check for every of those 4 states. TBH, putting my hands in this rat's nest isn't on the table for now. I fear this isn't something I can really fix without having to rewrite huge portions of the robotics code. And for reference, here are related official fixes : This is for disabling the stock maneuver planner widget introduced in KSP 1.12, this stuff : This feature uses a not very robust multithreaded implementation, and when it fails to "solve" transfers quickly enough it will cause the main thread to hang. This doesn't happen too much in the stock system, but with custom Kopernicus systems this is quite frequent, especially with bigger-than-stock systems. The end result for the user is performance issues in the form of random stutter. In some extreme cases this can cause the game to freeze for several seconds or even minutes, at which point your OS will usually tell you that the game is not responding and should be closed.

"Locking" a robotic part doesn't prevent it from moving... Depending on how much mass is attached to it and how the joint is configured, it can move quite easily. From my recent tests with that part from BDB, I seem to recall the joint is quite weak. This being said, I wouldn't be surprised if there is some stock bug where the servo joint isn't correctly initialized when the servo is locked. In any case, I really doubt this has anything to do with KSPCF. I don't have the time to test that right now, but if you have some, can you un-lock, then re-lock, then quit the scene and return back, do you confirm the joint is clearly less strong than it was when you unlocked it ? (and ideally, test that with the RoboticsDrift setting option enabled and disabled, to rule out that KSPCF is involved ?)

I think @Grimmas was referring to your RAM usage concerns. Making Less History allow to cut down on RAM usage when the MH DLC is installed by preventing the "mission editor" feature from being loaded. That's trivial to do but it won't be enabled by default. You will need to edit the Settings.cfg file to enable it (or better, to add a MM patch for that so your changes are kept when KSPCF is updated).

Whoops. Well indeed by fixing stuff for rotation servos I broke something for all translation servos. Just released a hotfix in KSPCF 1.13.2 : RoboticsDrift : fixed a rotation offset being wrongly applied to child parts of translation servos following the fix for issue #35 released in KSPCF 1.12.2 (see report 1, report 2)

The loading time might get a bit better or a bit worse, it depends on how many IVA vs non-IVA stuff your install contains and how fast your disk is. In any case, we are talking about no more than a handful of seconds either way. But beside reducing RAM usage, technically this also reduce VRAM usage, which is beneficial to performance if your GPU doesn't have enough VRAM to hold everything and is using shared RAM to make up for what it needs. This also is beneficial to scene switch time and overall performance, but don't expect anything really significant. If you have a good gaming rig, disabling IVAs likely won't make any measurable difference. If you have older hardware, it can help a little bit. Personally, I see that patch as convenient way to disable a feature I never use and that just annoy me when I mistakenly hit the "C" key and then don't remember how to switch back

Turns out the medicine had a few side effects V1.13.1 is out. Available from GitHub and CKAN. Changes in that release : Fixed NoIVA patch causing missing part textures when the part reuse/share IVA textures (ex : SXT). Note that this change negate the loading time gains of the original patch, and might even cause a small increase (a few seconds) if KSP isn't running from a SSD.

V1.13.0 is out. Available from GitHub and CKAN. Changes in that release : New modding patch : ReflectionTypeLoadExceptionHandler [KSP 1.8.0 - 1.12.3] Patch the BCL Assembly.GetTypes() method to always handle (gracefully) an eventual ReflectionTypeLoadException. Since having an assembly failing to load is a quite common scenario, this ensure such an situation won't cause issues with other plugins. Those exceptions are logged (but not re-thrown), and detailed information about offending plugins is shown on screen during loading so users are aware there is an issue with their install. This patch is always enabled and has no entry in Settings.cfg. New QoL patch : ShowContractFinishDates [KSP 1.12.0 - 1.12.3] For archived contracts, show accepted/finished dates. Contributed by @NathanKell New QoL patch : NoIVA [KSP 1.8.0 - 1.12.3] Allow to disable IVA functionality and prevent related assets from being loaded, which can speed-up loading, reduce RAM/VRAM usage and increase FPS. Has a "use placeholder IVA" option allowing to keep crew portraits. This patch is disabled by default and must be enabled from the KSP "ESC" settings menu. It has no entry in the Settings.cfg file and require a restart to take effect. Do not use this option alongside IVA mods like RPM or MAS. Added localization support Added tooltips to in-game settings

Three options, from the hardest to easiest : - Code your own module that add a PhysicMaterial to specific Colliders on the part. - Design separate parts having a single collider for the "feets", and use a stock ModulePhysicMaterial module on them. - Design your part around the stock "grip pads" parts from the Breaking Grounds DLC.

Do you really need to do a simulation (ie, the last bool arg set to true) instead of just consuming the resource ? Can't say for sure but the whole "simulation" thing is likely to be quite buggy. It's unused by the stock codebase, aside from the stock delta-v calcs which has also has a bunch of issues with resources having uncommon flow modes. if you need to do conversion/recipe stuff, I would suggest using the stock converter module stuff as a base. Edit : actually, to be more useful, since what you're trying to do is get the amount of a resource available, I would suggest using the "Part. GetConnectedResourceTotals()" methods, or easier, to use the public methods of a "ResourceBroker" instance (you can use a single static instance). That's what BaseConverter and derivatives are using. Not the simulation thing.

@Zorg@MashAndBangers@GoldForest Just letting you know that I just released KSPCommunityFixes 1.12.2, which should correctly handle the "Hokulani OCO-RT90 Truss Structure" skylab truss robotic part (as well as potentially other modded robotic parts). Sorry for the inconvenience, and thanks all for reporting.

V1.12.2 is out. Available from GitHub and CKAN. Changes in that release : RoboticsDrift : fixed issue #35, incorrect handling of non-stock servo parts having MODEL{} rotation/position offsets and/or a model hierarchy where the rotation transform has a position/rotation offset relative to the model root. Notably fixes incorrect behavior with the BDB Hokulani OCO-RT90 Truss Structure.

I've (hopefully) identified the issue. Tracking it here : https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/35 Will try to push a fix soon. In the meantime, you can disable the KSPCF robotic drift patch by editing the KSPCommunityFixes\Settings.cfg file and changing "RoboticsDrift = true" to "RoboticsDrift = false"

Yep, just tested, there is definitely something the KSPCF robotic drift patch doesn't handle correctly for this specific part. This is very weird. I will investigate ASAP.

It probably won't happen, but as a modder I hope they won't directly use Steam Workshop and instead implement a decent mod loader / game launcher. Steam Workshop is fine for "additional content" stuff, but it is definitely not up to the task for a complex modding ecosystem like KSP involving complex chains of hard dependencies, optional dependencies, mod conflicts, etc. The only benefit of Steam Workshop is that it offer free hosting for large mods (this is arguably the weakness of the KSP+CKAN model where most mods are hosted on GitHub, resulting in slow download speeds for end users). Maybe they can have their own custom mod manager with extended functionality built on top of the SW API, but I have some doubts this is a supported scenario. As for "official modding tools", we don't really need much. Hopefully KSP2 will abandon the custom model format mess of KSP1 and modders will be able to create assets using the regular Unity Editor toolchain. This being said, it would be incredible if they release an "Unity Editor" version of the game with whatever custom internal tooling they have in the form of an Unity package. Not sure how technically feasible this is, but that would be quite awesome for developing and debugging plugins, configuring visual stuff like planets or engine effects, not to mention making UIs (which is a real pain in KSP1).

Don't quote me on this but AFAIK RP1 disables the stock delta-v calcs entirely, probably because they don't work quite right in combination with RO/RP1. So this is kinda "working as expected".

I would suggest getting The OP doesn't show it, but beside the Tokamak habs pictured in the OP this also feature the Porkjet inflatables, including 2 centrifuges. The mod include some unrelated parts like deployable heat shields and base mounts, but you should be able to delete those of you want. This being said, while a much bigger mod, SSPX is a lot more efficient in terms of texture size (not to mention most of the Tokamak textures are distributed as png). Kinda same issue with the SETI Greehouse model, it is awful in terms of texture size and model polycount.

See https://github.com/Kerbalism/Kerbalism/wiki/PlayGuide-~-Signal#range-and-rate But TLDR : - Combining (same) antennas will only increase max range, data rate will stay unchanged. - Having different antennas with high data rate and low data rate is a bad idea, as this will lower the max data rate to something in the middle. Also, I suggest using :

My bad, this was actually fixed in KSP 1.10, not 1.8. Also note that prior to 1.10, you could place *.png files for which you didn't want mipmaps in any subfolder named "Icons", in a mechanism similar to the "PluginData" special folder name. But unfortunately this has never become widespread knowledge and indeed everyone re-implemented manual png loading (or even worse, re-reloading of existing textures).

Yes, and the issue is perfectly known, it was fixed in 1.8 and latter and it only concerned *.png files, not *.dds ones. This happened because when possible (ie, when a texture width and height is a power of 2), KSP convert uncompressed ARGB textures loaded from png files to dxt5 to save on VRAM usage. However, prior to 1.8, KSP also added mipmaps while doing that conversion, resulting in ui textures loaded from png becoming blurry when lowering texture quality. This was changed in 1.8 and latter (they basically just flipped the "updateMipmaps" boolean in the Texture2D.Apply() call). Also, [snip] I just looked up, and ONLY the two loading screen images (out of more than a dozen) you took screenshot of happen to have been exported with mipmaps, which is why they are affected by the texture quality setting. I can't find anything else that has a such a mipmap issue, and although it's possible that similar mistakes exists here and there, that's hardly a problem. Unless you have proof that "everything" is blurry and that there is actually an issue with KSP 1.8+ wrongly autogenerating mipmaps, stop [snip]