Gotmachine

Likely not so easy to do. The crew assignment stuff is quite messy, and messing with it might have unintended side issues with other mods... I will try to look into it.

V1.2.0 is out. Available from GitHub and CKAN. New QoL tweak, TweakableWheelsAutostrut [KSP 1.8.0 - 1.12.2] : Allow tweaking the autostrut mode of wheels/landing legs. Still default to "heaviest part".

I'm not pessimistic, I'm just saying that what KSP 2 is focused on isn't what I personally want to do in a KSP game. They obviously are making the "lets assure a commercial success" choices, I'm fine with that, but it isn't the "rocket game" I personally would like to play. I don't want things to be simple. I want game that I can play for hundreds of hours, with complex gameplay elements, and a less emphasis on the "derpy toy/scifi world" aspect, and more emphasis on the "real world rocket/space program simulation" aspect. Which is a much more niche genre. It isn't. If there aren't any branches, it isn't a tree. If you want a comparison with a commonly used game mechanic, it's like a "Level up ! Choose a new ability to unlock" thing.

Problem is, there isn't much choice to give. Every "technology" is mandatory at some point. You need parachutes, landing legs, heat shields, fuel tanks, RCS, reaction wheels, thermal control, solar power, batteries, etc... The only potential strategic choices are choosing between a handful of advanced propulsion systems, plus maybe the "nuclear power or not" choice. If they really want to give those choices, that would still work with a "single line" progression : when you reach X progression points, you can choose one tech between the 5-6 "advanced techs", and at the next "progression threshold", you can choose another, etc. But I don't see the need for a "tree" of any kind. You're missing the point of the "very few tech nodes". Those situations wouldn't happen because there is no such granularity, and because there are very few milestones before unlocking the vast majority of parts and functionalities. The progression revolving around what the player accomplishes (base/station construction, supply runs, etc) is enough, no need to create arbitrary and hard to balance low granularity "tech gating" on top of that. What I describe isn't what I would like. It is what I think we will get. Personally, I would definitely prefer an in-depth "space program management" sub-game complete with funding, a proper contracts system, time based rocket construction, time base science, individual part unlocks based on time based research, a proper life support system... But that's definitely not what we are gonna get. We are gonna get a "guided sandbox" with interstellar fluff, scifi propulsion, colonies, and multiplayer. All things that I absolutely don't care for.

We can't do much but speculate. But based on what they said and what I think would make sense, this is what I mean by a "slightly part availability gated sandbox" : A single "progression point" variable, where those points are acquired : Passively, on reaching various milestone (like the "world firsts" KSP 1 system) : distance traveled, speed attained, reaching a body SOI/orbit/landed/biome, using a mechanic (ISRU/in situ construction...) for the first time, colony achievements/bloom events, finding special places/easter eggs, stuff like that. Actively, by transmitting or retrieving part experiment results (same mechanics as for KSP 1 science points). Very few different experiments (~5-6), available from the start. A single branch, linear "technology" progression, with maybe ~20 "nodes", each unlocking a large batch of rocket/colony parts. Basically, one node for every major technological milestone : one for each propulsion technology, one for each major colony/station capability, a bunch of extra nodes at the start for not overwhelming new players with tons of options. They unlock passively, when the total acquired "progression points" reach a given amount. To spice it up a bit, that system could also have an "actively spend progression points" mechanic for : Launching rockets from KSC, with the progression point cost based on the rocket mass. Launching the special colony/station "core" parts. Hiring new kerbals. KSC upgrades, for example to increase launch mass limits or DSN range. Spending points wouldn't change how the "tech progression" works, it would be purely based on the total points ever acquired. This avoid the "part availability mismatch" issue of the KSP 1 tech tree where you inevitable end up doing silly designs due to parts being both categorized by size and function. This also avoid having to balance a per part "tech cost". The only limiting factor is vehicle launch mass, all part sizes are available once the corresponding technology node is unlocked. In that system, the vast majority of parts would be made available in the first ~5-10 tech nodes, designed to be achieved quite quickly, including all structural/utility/control/aero parts.

It is fundamentally linear. Launch a basic rocket, reach orbit, go to the moons, go interplanetary, go interstellar. Arguably, the 4-5 "technological steps" for doing so are quite linear : first chemical, then chemical++, nuclear fission, nuclear fusion and finally sci-fi exotic stuff. There isn't really enough there to build a meaningful "tech tree choice" gameplay around that, unless they actually develop a whole in-depth "space program tycoon" sub-game, which at this point we know won't happen. This is why I doubt there will be any significant depth to the "adventure mode" mechanics. They gave strong hints that they won't repeat the same mistake as KSP career mode : introducing "tycoon/strategy" like mechanics without having any significant gameplay elements to back them. Moreover, a "player decisions" gameplay will already exist through colonies/stations building/growth and associated gameplay elements : ISRU, colony growth, offworld vessel construction, resupply lines... Arguably, this is the progression gameplay, directly involving the core "lego building / piloting vehicules around" element. Why would they need to add complex abstracted progression concepts on top of that ? To satisfy the 0.1 % of players that will play the game more than 100 hours ? The fundamentals of KSP are about building rockets, flying them and reaching space and distant worlds in a somewhat physically accurate way. This is the fun part. They will succeed if they get that right, and this in itself is a huge task. At some point, some of the KSP 1 devs commented that when analyzing the collected statistics, they discovered that vast majority of people that bought the game didn't ever get past Kerbin orbit. The "forum population" is NOT representative of the player base. They are the 1% advanced, noisy, nerdy players. If the KSP 2 devs are doing their job right, focus will be accessibility of the core gameplay elements : building rockets that work and piloting them to their destination so Kerbals can go interplanetary/interstellar and build distant colonies, and making exploration interesting by making beautiful worlds, with more variety and unique features. It would be a much higher payoff to introduce "lore" stuff (kerbal artifacts, alien/kraken stuff...), then create some sort of "quest/story" gameplay element than building a pointless progression system. They have given a lot of information on the accessibility/core physics/stuff to explore topics, but they have been quite silent on the "adventure mode" mechanics. Likely because there isn't much to it, and the "KSP 1 nerds community" has huge misplaced expectations on that front. But I wouldn't be surprised if that is because they have a "lore/story" progression element they want to keep secret until launch. Advanced progression mechanics are the realm of mods, or DLCs / extensions. Which are an essential part of the economical model of a game like KSP. But it certainly won't be a launch-day feature.

You (and a lot of people in this thread) are assuming that there still will be a KSP1-like tech tree, KSP1-like science points, KSP1-like experiment parts... All we know is that the whole progression system is completely different, and somehow based on "achievements", which can come from doing science, going places, reaching specific milestones... There was a few hints that concepts like funds or a tech tree tied to science points acquired by performing experiments don't exist anymore. This leave a lot of room for interpretation on the actual gameplay mechanics involved, but thinking about it by taking KSP 1 mechanics as point of reference is a bit pointless. Personally, I expect things to be a lot more basic than in KSP 1. From the developer POV, the progression system is the least important aspect of KSP. Nobody is gonna buy that game for its progression gameplay mechanics. They are clearly counting on the interstellar/colonies stuff wow factor, as well as graphics and multiplayer. So this is where the development resources are. The likely only design goal of the progression system is to give new players directions, and to cost the least possible to develop. Likely a single "progression points" variable that increase passively when you go somewhere new, or perform something for the first time, and probably a single "technology tier" system that passively unlock new parts when you you have accumulated X progression points. I doubt we will have any significant "experiment system". I would be very surprised if its anything more complicated than "be somewhere" > "click on a perform experiment button" > "have an antenna or return the data" > "get progression points". Arguably, the only real KSP 1 issue with that system is a UI one. Frankly, I expect the so called "Adventure Mode" to be a slightly "part availability gated" sandbox. I doubt there will even be any form of "costs" for doing stuff like launching a new vessel or hiring kerbals for example.

V1.1 pre-release is out. A lot of new stuff in there, so I will wait a bit before pushing the update to CKAN and updating the OP. Meanwhile, you can get it from GitHub Please report any issue, and please use KSPBugReport to do so. Required and must be downloaded separately : HarmonyKSP : Download - Homepage - Available on [CKAN] ModuleManager : Download - Forum post - Available on [CKAN] Installation Download the file named KSPCommunityFixes_x.x.x.zip Open the downloaded *.zip archive Open the GameData folder of your KSP installation Delete any existing KSPCommunityFixes folder in your GameData folder Copy the KSPCommunityFixes folder found in the archive into your GameData folder Changes in 1.1.0 KSP Bugfixes ModuleIndexingMismatch [KSP 1.8.0 - 1.12.2] : Prevent modules persisted state from being lost in existing saves/ships following a mod installation/uninstallation/update. Note that this won't handle all cases, but it massively reduce occurrences of that issue. StockAlarmCustomFormatterDate [KSP 1.12.0 - 1.12.2] : Make the stock alarm respect the day/year length defined by mods like Kronometer. Fix the underlying AppUIMemberDateTime UI widget API to use the mod-provided IDateTimeFormatter if present. PAWGroupMemory [KSP 1.8.0 - 1.12.2] : Fix the expanded/retracted state of Part Action Window groups being reset when the PAW is closed or internally rebuilt (especially frequent in the editor). KerbalInventoryPersistence [KSP 1.12.2] : Fix the whole kerbal inventory persistence system being inactive in KSP 1.12.2. This cause multiple issues, like being able to bypass kerbal inventories mass/volume limits, and various cargo part duplication / disappearance issues when EVAing / boarding. FlightSceneLoadKraken [KSP 1.8.0 - 1.12.2] : Prevent kraken events on flight scene load in laggy situations Quality of Life tweaks PAWStockGroups [KSP 1.11.1 - 1.12.2] : Part Action Window groups for a selection of stock modules Mod API MultipleModuleInPartAPI : This API allow other plugins to implement PartModules that can exist in multiple occurrence in a single part and won't suffer "module indexing mismatch" persistent data losses following part configuration changes. See documentation on the wiki.

*sigh*... No, the dll isn't there. Should I really explain it a third time, or are you gonna read the post just above yours ?

No. The CLS core functionality is in "ConnectedLivingSpace.dll", which is only distributed with CLS. That one will cause the "ConnectedLivingSpace" keyword to be added by MM (as well as the fact that a "ConnectedLivingSpace" folder exists in GameData). "CLSInterfaces.dll" is an additional assembly distributed by both CLS and other mods using it, for the purpose of plugin interoperability. It will indeed cause a "CLSInterfaces" keyword to be added to MM, but nobody should ever be checking that in a MM NEEDS.

No. MM will only register a CLSInterfaces keyword if the interface dll is present. MM adds NEEDS keyword by looking for *.dll names and gamedata root folders names. As long as no ConnectedLivingSpace.dll exists, and that no ConnectedLivingSpace gamedata root folder exists, a NEEDS[ConnectedLivingSpace] patch won't be applied. The best solution to work around that KSP bug is having mods using CLSInterfaces.dll redistributing it from within their own mod folder, but renaming it with an unique name like "CLSInterfaces_MyMod.dll" I confirm that this work without side issues, both in 1.12.2 and 1.11.1 (so before and after Squad modified the assembly loader). The assembly loader will have two separate wrapper entries, but only one common interface assembly will actually be loaded : This solution is the one that will have the least impact and require the least work from everyone's POV. It doesn't require any change on CKAN and neither on the CLS side and won't break any player install that isn't already broken by the KSP bug. It only require updating mods using the CLS interface.

It will cause any mod having a MM patch relying on a NEEDS[ConnectedLivingSpace] to have that patch wrongly applied when CLS isn't actually installed.

I guess @Tacombelidea of just using an unique name for dll when redistributing it might work. Unfortunately, there is no way to fix that KSP bug through a plugin, as the presence of duplicated dll will either : - Causes the plugin loader to crash with an ArgumentOutOfRangeException - Silently delete random plugins from the list of plugins to be loaded. At best, in the former case, the issue can be detected (but not avoided, since in any case, it's already too late). My fix (the one I linked a few post above) rely on using an external Unity mod loader, so I'm able to run some code before the KSP plugin loader execution.

I think that may work. At the runtime level, if I remember correctly, only the "first found" one will be loaded. However, this will definitely have some side effects on the plugin loader. How problematic that will be, I don't know. Probably not much in that case.

This has drawbacks and would be a breaking change. Standardizing CLSInterface to be a separate mod is a better solution. If CLSInterface is distributed by everyone as "GameData\CLSInterface\CLSInterface.dll", the likeliness of end users having duplicates becomes quite low.

The plugin loader in 1.12 is broken and will crash when multiple *.dll files with the same name exists in GameData. Details here : https://github.com/gotmachine/StuckOnLoadingPartUpgradesFix

They are indeed extremely cheaty. Not because they don't have saturation mechanics, but because compared to real world reaction wheels, for an equal mass, the torque they provide is about 100 times higher. For example, you can compare the KSP 0.625m small reaction wheel that weight 50 kg and provide 5 kNm of torque to that real CMG assembly that provide only 0.075 kNm of torque, weight 70 kg and is roughly a 0.6m cube. The figures for the much larger ISS CMG assembly are identical : 280 kg, 1.2m, only 0.26 kNm. Said otherwise, to be realistic from a mass POV, the KSP 0.625m reaction wheel should be weighting about 5 tons. If you want a quick and dirty fix, you can use the following ModuleManager patch (put that in a *.cfg file anywhere in your gamedata folder) @PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL { @MODULE[ModuleReactionWheel] { @PitchTorque *= 0.01 @YawTorque *= 0.01 @RollTorque *= 0.01 } }

The loading times on scene switch is due to a bad design decision to have the core game database belonging to scene objects instead of being DontDestroyOnLoad root objects, which cause KSP to make almost the whole game to go through an useless full serialization/deserialization cycle. To their discharge, managing that pattern is quite a lot easier in recent Unity versions and the "additive scenes" feature. KSP doesn't use the ECS system. It's entirely built on the GameObject system. And BTW, Unity's ECS implementation is merely a few years old, and has been out of "experimental" only since last year. This is a (common) urban legend. There is zero threading involved in any part of KSP, at the notable exception of the stock delta-v calcs. The only threading happening is on the Unity renderer side and on the PhysX engine side.

How "exposed" something is doesn't matter as far as the EULA is concerned. The EULA forbid an act, it doesn't care about the tools you use. The only thing that the EULA doesn't explicitly forbid is purely "additive" modifications. For example a new part. But even in that case, the "red line" can be quite blurry. For example, in intent, a combination of Kopernicus + OPM doesn't end in a modification, the stock system remains as originally provided. But under the hood, there are still significant alterations being performed, and those still are a "reverse engineering/decompile/dissemble" act. In the end, the issue is that the EULA is completely disconnected from the existence of modding. It's a copypasted standard end user software contract. From there, any attempt at rationally determine how it apply to modding is an exercise in futility. Which is why the so-called "addon posting rules" with the "follow the EULA" statement doesn't make much sense. To take a step back on the situation, it should be noted that at the notable exception of Minecraft, as far as I know, all games in existence having a "recognized" modding community are in the same situation with their EULA. At best, the developer/publisher has made a public statement, or has a separate contract for using the official mod sharing services (that's what the KSP addon posting rules are), saying that modding is tolerated, sometimes with some additional details. The KSP addon posting rules are a relic of a 9 years old forum post, written by a modder with a quite aggressive and restrictive policy in mind at the time. But since then, the modding scene has been blooming in size and technical ability, resulting in daily infringements on both the EULA and those rules, all that while Squad was praising said mods in "thread of the month" posts and saying how proud it is of the modding community. For example, at the time, there was a hardcoded ban in the plugin loader on the System.IO and System.XML namespaces, something that was reverted latter without any explanation (as far as I know, but I bet there is a juicy story behind that). Somehow, what this guy said 9 years ago and that long gone forum post has become the "source of truth" over the years. My bet is that neither Private Division, Intercept games, or what now remains of Squad has an actual "modding policy", beside interpretations and opinions of individual employees or of the forum moderation team members. An example how this is completely arbitrary : the forum moderation is aggressively removing any discussion containing technical details obtained trough KSP assembly reverse-engineering, but has no problem with technical details obtained by reverse engineering the KSP assets. All this to say I wholly support and understand your position, and would very much like to see the "officials" taking a stance that acknowledge the reality of KSP modding : modders need to break the EULA and they need to reverse-engineer the game. You can't mod what you don't understand. It would be wonderful if the KSP forums actually allowed the exchange of all technical information between modders, instead of us having to hide on unofficial channels. Due to KSP being a tiny game now belonging to a AAA publisher, I doubt we will ever see a custom modding-friendly EULA. But maybe they could release an actual "modding policy" that doesn't try to supersede the EULA while not doing it at the same time like the current addon posting rules, and just acknowledge that they are wishing to "look the other way" on EULA infringements in the context of modding. If you think this is a silly idea, this exactly what Rockstar (a T2 subsidiary, like Private Division) has for GTA games : https://support.rockstargames.com/articles/115009494848/PC-Single-Player-Mods

If I may, Kopernicus has always violated the EULA in its intent, and in practice by replacing the PSystem prefab. There is no legal or technical difference in the act of replacing a game asset by using the tools provided by the underlying Unity engine API or replacing a portion of the game code using the tools provided by the underlying CLR and .NET framework through the Harmony library. In both cases, this is a reverse engineering act performing a modification of the provided software, which is a double violation of the EULA.

THIS MOD IS DEPRECIATED AND THE KSP ISSUE IT TARGETED WAS FIXED IN KSP 1.12.3 Just update KSP to the latest version. Moreover, this mod conflicts with other mods using KSPHarmony, installing it will cause issues. OP for reference : This is a fix for the KSP 1.12.2 bug that cause the game to be stuck on Loading Part Upgrades on a modded install. This bug happens when you have a duplicated *.dll file in you GameData folder/subfolders. In KSP 1.12, the code that is supposed to be handling that (perfectly normal, mod authors aren't doing anything wrong) situation is either : Crashing with an ArgumentOutOfRangeException, causing the whole loading process to stop. Silently removing random assemblies from the list of assemblies to be loaded, causing random issues. If that is happening to you, you will see the following error near the beginning of your KSP.log file : ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) System.ThrowHelper.ThrowArgumentOutOfRangeException () System.Collections.Generic.List`1[T].RemoveAt (System.Int32 index) AssemblyLoader.FlagDuplicatedPlugins () This also fix two other issues that have the same effect (but are less likely to happen, as most mod authors have already implemented workarounds) AssemblyLoader crashing on attempting to load a *.dll file with an absent or non-parseable FileVersion attribute : bugtracker issue AssemblyLoader crashing when an unmanaged *.dll file exists : bugtracker issue How to fix ? Download the KSP1.12.2-StuckOnLoadingPartUpgradesFix.zip file from the GitHub releases page. Extract that zip content to the root KSP folder (NOT GameData) : On Windows, this is the folder containing the KSP_x64.exe file On Linux, this is the folder containing the KSP.x86_64 file On MacOS, this is the folder containing the KSP.app file Done ! Details See corresponding KSP bugtracker issue. Note that there is a manual workaround to this bug : search your GameData and subfolders contents for *.dll files with the exact same name, and rename the duplicates to something like *.dll.duplicate (or just delete it). However, this is quite unpractical, so while we wait for a proper fix in an hypothetical KSP 1.12.3 release, I've attempted to to provide an easier solution. Fixing this bug can't be done from a KSP plugin, since it cause the whole KSP plugin loader to crash before any plugin has a chance to execute. So the fix is implemented through BepInEx, a popular Unity/XNA runtime patcher and plugin framework used for many games (Valheim, Outwards, WorldBox...). Note to modders : workaround If you are redistributing a *.dll file that is likely to be also redistributed by another mod, you can prevent the issue by renaming that *.dll to something unique. For example rename SomeLibrary.dll to SomeLibrary_MyMod.dll. Due to the fact that mono will only load a single instance of the same assembly by internal name, this is safe to do. The only caveat is that there will be multiple LoadedAssembly entries in PluginLoader.loadedAssemblies for the same assembly, so keep that in mind in the very unlikely case you are iterating on it. Common cases : MiniAVC (depreciated and shouldn't be used) KAS-API-v2.dll (Kerbal Attachement System API) CLSInterfaces.dll (Connected Living Spaces API) Unity Mono/.NET libraries missing from the KSP distribution, like System.IO.Compression.dll Any nuget package Changelog V1.1 : Added fixes for AssemblyLoader crashes on dlls containing no FileVersion attribute, or non-managed dlls. V1.0 : Initial release Licensing The provided download contains : BepInEx 5.4.17 : LGPL-2.1 license A BepInEx plugin (source) named AssemblyLoaderFixBepInEx.dll that patch the faulty KSP 1.12.2 method : MIT license

This is a KSP 1.12 bug : https://bugs.kerbalspaceprogram.com/issues/28036 It happens when you have two *.dll files with the exact same name in your GameData folder (including subfolders). To identify them, do the following search in your GameData folder : You will find two files with the same name. Try renaming one of them from "nameofthemod.dll" to "nameofthemod.dll.disabled". Depending on the load order, this might cause the mod using it to fail to load. If that's the case, restore the original name of the one you modified, and try renaming the other one.

If you really want to avoid it, you can use a dummy ModuleDragModifier, which has no code and is just being checked at the part prefab compilation. As long as you don't touch the default "1f" value of its " dragModifier" field, it's garanteed to have zero effect. But it has a "dragCubeName" string KSPField that you can check with the CC extended partmodule check.