Gotmachine

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]

Interesting. The debug menu has a specific issue with having mipmaps enabled on its texture, that's a fact. It will become blurry on any graphic backend when you lower texture resolution. Your issue is weird, and a further indication that something is going quite wrong. Something is applying mipmaps to every texture loaded by the game, even textures that don't have them initially, which mean all textures are getting converted at some point (which could explain why loading is so slow too). Anyway, I'm indeed guessing here, that's about the extent of my GPU stuff knowledge. It's just that what you're showing (as well as your memory usage stats) isn't something I've ever seen reported, be it with OpenGL or DirectX, Windows, Linux or OSX. Again, the "blurry icons/ui" issue that is common knowledge around here is specific to png textures.

It's not "the GUI". It's only the debug menu, and that happen because they somehow forgot to disable mipmaps on the debug menu assets. The actual "blurry UI textures" issue was because prior to 1.8, KSP was applying mipmaps to *.png textures when loading them. I doubt you will find any other place where this actually happen. Edit : somehow missed your big post above Well, no. Linux "older rigs" will still likely have a discrete GPU that has much better OpenGL support than your HD4000. My 10 years old GTX 460 supports OpenGL 4.6 and performs just as well in that mode as my more recent DX11 card in terms of memory usage. Even if they don't, they might have an AMD iGPU which were vastly superior and better supported than Intel at that time. Again, your memory usage is not a normal situation, something is going wrong somewhere.

So do I. But again, there are significant differences between running the game with OpenGL, DX9 and DX11, and even within OpenGL, things depend on what OpenGL features your GPU actually support. On DX11, textures don't stay in RAM unless you don't have enough VRAM (and 1GB VRAM is enough for 1.12). As for loading times, even with both DLCs 1.12 load in about 70s on my machine. Arguably, comparing 1.3 loading times with 1.12 with both DLCs is comparing apples to oranges. I recently did quite a bit of testing on loading times, and KSP 1.12+2DLCs still load in under 2 minutes on a 5400tr/min 6 years old "storage oriented" 4TB HDD, so something else is at play on your end. Again, I'm no expert on the matter, but from your RAM usage and loading time, this feels like old-time DX9 Unity 5 KSP where textures were kept in RAM forever, maybe because your iGPU doesn't support the texture compression format through OpenGL. In modern KSP under DX11, as long as you have a GPU with enough VRAM, you can add tons of parts and that doesn't has any significant impact on RAM usage. Edit : To give you another figure, my heavily modded 1.12 JNSQ install with 6.3GB of DDS textures and 1075 loaded parts uses ~7.2GB of RAM and ~3.5GB of VRAM after playing for 2 hours or so.

This issue has been fixed since KSP 1.8 You need to exclude all files lying in the zDepreciated folder. Those aren't loaded at all. Also, your stats absolutely don't match mines. Considering only the Squad folder (not the DLCs) : - On 1.12.3, there is 898 MB of dds texture (excluding 45 MB of zDepreciated textures) - On 1.11.1, there is 782 MB of dds texture (excluding 23 MB of zDepreciated textures) - On 1.7.3, there is 519 MB of dds texture (excluding 22 MB of zDepreciated textures) - On 1.2.2, there is 302 MB of dds texture As for load times, for a non-DLC install, I'm getting 41s for 1.2.2, 48s for 1.12.3, so I'd say that given the 3x inflation in texture size and all the added/revamped parts , modern KSP is actually more efficient in that regard. Concerning memory usage, doing a repeatable test (new career save, swapping through the tracking station and editor scene, then launching a stock Dynawing, then teleporting it in LKO) gives me : - 3.4 GB RAM usage on 1.12.3 - 1.9 GB RAM usage on 1.2.2 My 7 years old midrange Windows 10 PC is very far from being a decent machine by today standards, but it has a discrete DX11 GPU (GTX 750Ti 4GB). I'm not an expert on the matter, but it is likely that your antique shared memory GPU is having trouble compressing textures on OSX/OpenGL, resulting in vastly inflated memory usage. The point is that you're getting to general conclusions based on a very specific setup (MacOS/OpenGL/shared memory crap GPU) that has very specific issues, and that is absolutely not representative of the majority of (potatoes) users. 1.12 runs quite decently on a my antique (13 years old) desktop with a core i5-670, 8GB of RAM and GTX 460 1GB, certainly not any significantly worse than what I remember from the KSP 1.2/1.3 times when I was playing daily on that machine. However, 1.2/1.3/1.4 was (vaguely) playable on my 10 years old discrete GPU with 512MB VRAM and 4GB RAM mid-range-for-the-era laptop, but 1.12 is a really bad experience in terms of FPS and load times due to RAM starvation. Modern KSP does indeed require a bit more RAM than Unity 5 era KSP, and it also does require a bit more GPU power (but still nothing compared to any modern 3D game). My experience (on Windows) is that as long as you have a discrete GPU that is less than 10 years old, and at least 6GB of RAM, modern KSP runs better than Unity 5 era (ie. 1.1 to 1.7) KSP. On very low spec potatoes (no discrete GPU and/or 4GB RAM), things are a bit different indeed. Note that a good way to alleviate VRAM starvation issues on iGPUs and old GPUs is to install the ReStock mod, which manage to reduce texture size quite a bit compared to stock (and while looking better, so win-win situation there).

@Rodger So, after experimenting a bit... I won't implement RCS angle / torque cutoffs : The main reason is that this would introduce a change that would mess up things for all other plugins relying on the stock RCS module behavior (KOS, TCA, MechJeb, RCSBuildAid, kRPC...). There is some value to such a feature but with many gotchas. Especially for the rotation/torque limits (it's less of an issue for translation limits), making it usable from an user-facing perspective isn't straightforward. Depending on the control scheme, absolute angle limits as shown in the picture you linked don't always work. A fixed torque cutoff might be a bit better, but in any case defining a fixed limit only work for a fixed control scheme, with a fixed CoM. Your carefully in-VAB tuned RCS would produce garbage after any major in flight vessel re-configurations (staging, docking, control point toggling, CoM shifting...). For all those reasons, this would be better implemented as a separate mod. Also note that there are already mods that implement RCS control scheme dynamic optimization (TCA, Mechjeb...). Fixing ModuleRCS.GetPotentialTorque() definitely helps a lot with RCS fuel consumption when using the stock SAS. There are likely other refinements that could be done at the stock SAS level. For example, it doesn't correctly account for the GetPotentialTorque() results, always taking the highest available torque for a specific axis regardless of the direction. I will look into how to improve things there.

Mmmh... I guess that could be something. I could add two advanced PAW tweakables, a threshold for rotation and another for translation. Clamping it by default would be a bad idea, first because that would alter stock behavior (one of the first principles of this mod) and because it's impossible to predict a vessel control scheme. Fuel use more efficient, yes. But that wouldn't change much about inducing unwanted torque. Edit : Actually, that reminds me that ModuleRCS.GetPotentialTorque() has been broken since forever and is the main cause of the stock SAS wasting tons of RCS fuel, as well as generating random amounts of torque. Will fix that first.

Don't worry, I appreciate the feedback and suggestions, and discussing them can't hurt. I would personally really appreciate a stock DV UI integration for MechJeb (which has the most reliable and up-to-date DV simulator currently).

Same deal here. I'm not really interested in fixing anything related to the stock DV stuff. This is a complicated matter and there are already mods (KER, Mechjeb...) doing a much better job. Ideally, those mods should be updated to override the stock DV calcs and hijack the stock DV UI. This would take much less effort than trying to fix the stock DV calcs. Note that the "Basic Delta-V" mod is exactly that, it reuse the KER calculations to feed the stock UI : Unfortunately, it is more or less abandoned and doesn't work in recent KSP versions.

Well, there are already a bunch of related launchpad/runway dialog UI suggestions on the github issue tracker. I agree that the stock UI is quite lacking, and while I could see a replacement being a KSPCF feature, this would be quite a bit of work and I personally don't care much (mainly because I almost never use the launchpad/runway UI). I will accept contributions on the matter (as long as they are of reasonable quality), but this is something I will probably never work on myself.

V1.12.0 is out. Available from GitHub and CKAN. Changes in that release : New QoL patch : AutoSavedCraftNameAtLaunch [KSP 1.8.0 - 1.12.3] Append [Auto-Saved Ship] when relevant in the Launchpad / Runway UI. New KSP bugfix : StockAlarmDescPreserveLineBreak [KSP 1.12.0 - 1.12.3] Stock alarm preserve line breaks (and tabs) in the description field. New KSP bugfix : DeltaVHideWhenDisabled [KSP 1.12.0 - 1.12.3] Hide the stock stage delta-v UI elements and navball extended burn info when DELTAV_CALCULATIONS_ENABLED and DELTAV_APP_ENABLED are disabled by another mod or in the KSP settings.cfg file. Courtesy of @NathanKell

Yes and yes. And to be clear, this will happen even if only one docking port is unlocked. To have autostruts crossing docking ports, you have to make sure both ports are locked. And side note : you can visualize autostruts in flight (or in the editor) by going into the ALT+F12 menu > Physics > Visualize Autostruts

I would suggest installing CKAN, setting compatibility to 1.12/1.11/1.10 and browsing the mod list. At a few exceptions, all active mods are there. The forums are a terrible way to find mods and dedicated mod distribution sites (spacedock, curseforge...) are bloated with outdated and unmaintained mods.

V1.11.2 is out. Available from GitHub and CKAN. Changes in that release : TextureLoaderOptimizations : restored compatibility with KSP 1.10 and 1.11 DockingPortRotationDriftAndFixes : fixed autostruts crossing docking ports not being disabled if only one of the port pair is rotation-unlocked.

V1.11.1 is out. Available from GitHub and CKAN. Changes in that release : TextureLoaderOptimizations hotfix : was causing loading to hang on KSP 1.10 and 1.11 due to using an Unity method only available since KSP 1.12. Will restore compatibility later, for now the patch is disabled for all versions below 1.12. AutoStrutDrift bugfix : fixed potential ArgumentOutOfRangeException. Thanks to @Rakete and @dok_377 for the bug reports.

Whoops. ModuleManager is right, I'm using something in Unity that isn't available in versions older than 1.12. Turns out I did some modifications after I checked compatibility with older versions. I will push an update that limit this patch to 1.12 ASAP. I can't reproduce it. Did the test in a pure stock install and in another with KSPCommunityFixes, with the vessel fully drained of all LF/OX hitting the water at a consistent 8.3 m/s. Parachutes pre-deployed and teleporting the vessel at 200m altitude and SAS disabled, in order to hit the water with exactly the same angle every time. It neither break in stock or with KSPCF, tested five times in each. But if I force the vessel orientation to be slightly different, I can manage to break it under the same conditions, both in stock and with KSPCF. The vessel has several underbelly parts having only a crash resistance of 6 m/s (FL-T400, FL-TX1800), so depending at what angle you hit the water, those parts will break easily. With the tanks about 25% full, I'm hitting the water at 9.4 m/s and the vessel consistently breaks in both installs. I also double checked that the part buoyancy integrator is running in all those tests. I think I know what's going on, I will look into it latter. Edit : Just opened your save. Can't reproduce it. Are you sure you're on the latest KSPCF version (and that the patch is enabled) ? There is such an issue (docking port rotating around the wrong axis) in stock (so it would happen if the "DockingPortRotationDriftAndFixes" patch isn't enabled), and I didn't fix it until KSPCF 1.10.1 Edit2 : Ok, turns out it happens on one side and not the other. Will look into it. Aaand it's autostruts... I will look into how to fix it. In the meantime, you can avoid it by ensuring both docking ports are unlocked ("Rotation gesperrt") before attempting to rotate.

Then just opt-out in the popup. Yes (although not immediately, it will be deleted on the next KSP launch). Giving me a reproducible test case (ideally a craft or save file with only stock parts, or a minimal amount of modded parts alongside the mod list) would help.

Since this optimization is patching the texture loader, it has to execute right away on KSP launch, before the asset loading phase. ModuleManager executes during the asset loading phase and the patched configs are only available after that. This mean that this specific KSPCF patch can't make use of a MM patch to be enabled/disabled. So while I could have kept an entry in settings.cfg, having it "immune" to a MM patch trying to change it would have been incoherent and confusing. Beside, because this optimization can potentially lead to a lot of additional used disk space (depends on what mods you have and how they package their textures), I prefer to have that mandatory opt-in popup to warn the user.

Could you give more details ? This sounds like the KSP 1.12 bug where some modded solar panels are starting in the extended state on part creation in the editor and on scene load in flight. If so, there is a fix for this by installing https://forum.kerbalspaceprogram.com/index.php?/topic/204002-18-112-kspcommunityfixes-bugfixes-and-qol-tweaks/

Quick note for users of this mod under KSP 1.12 : the bug that cause solar panels to always be extended is now fixed in