Gotmachine

No. It's impossible to have a KSP plugin built for .NET Core / .NET 5, because KSP isn't shipped with the corresponding CLR runtimes. That mod is using .NET 5 for the external to KSP executables it provides, not for its KSP plugin. It would be possible to run on .NET Core up to version 2.x if KSP used the .NET Standard 2.0 CLR (the Unity version that KSP uses does provide that option), but that would require a non trivial refactor of the KSP codebase, which is never going to happen. Unity is a quite awkward situation, as it relies on Mono, which is severely lagging behind the now "default" .NET ecosystem, and is likely to just disappear at a middle term horizon. They just updated to the latest Mono version which bring .NET Standard 2.1 / .NET Core 3.x / complete .NET Framework 4.8 support, in the beta versions. But that will likely be the end of the road for Mono in Unity. It's unclear what they will do, but they likely won't have another choice than switching to the .NET runtime (instead of the Mono one) to provide .NET 6+ support (they already stated that they will skip .NET 5 in any case).

You are mixing things. But the evolution of .NET is arguably hard to follow. A picture is worth a thousand words, so : In short, there are 3 different products : - ".NET Framework" : discontinued since v4.8 in 2019 - "Mono", historically a non-Microsoft open source version of the ".NET Framework". In the process of being absorbed by .NET (which is now open source and not owned by Microsoft anymore), will likely be a thing of the past in a few years - ".NET Core", recently renamed just ".NET", is the currently active product. KSP is technically running on a Mono fork, which is (almost) fully compatible with the .NET Framework. .NET Core / .NET is a different product, and isn't compatible with the .NET framework or Mono. Your project opened just fine because in its *.csproj file, it define that it uses .NET Framework 4.5 : https://github.com/rvalle7/Omicron/blob/96e249a4ef34cd2d33220bcc4cae9d38036b7114/Omicron/Omicron.csproj#L12 So Visual Studio used that version (Visual Studio very likely ship it, but it make sense that it doesn't offer you to create new projects with it out of the box, it's likely an option buried somewhere). The issue is likely that your compiling against the .NET framework installed on your system. As I said, KSP is running on a Mono fork, not on the .NET framework, and there are a few differences, especially if you try to use v4.8. Moreover, KSP isn't shipping the whole framework, there are entire namespaces that are missing (System.IO.Compression is a quite annoying example), because they are "optional" from Unity's point of view, and Squad didn't "check the boxes" for those options. KSP mods should always be built against the KSP provided framework (ie, the content of your KSP_x64_Data\Managed folder), and should remove the reference to your system provided framework that is added by default when making a project in Visual Studio.

Changing the "difficulty setting" option doesn't change it for existing vessels, it only change the default value on the future vessels you will launch. To change it on existing vessels, you need to go to the "cfg" tab of each vessel (in the Kerbalism flight UI).

@IgorZ I've been messing around with the stock inventory / cargo part code in KSPCommunityFixes, to fix some of the stock issues and limitations. Quick summary ; BetterCargoPartVolume : Parts that have a ModuleCargoPart with no "packedVolume" field defined in their config will have their volume auto-computed from the part bounds at prefab compilation. This also handle multiple volume per part when using the ModulePartVariants mesh-switching feature, and provide a C# interface for mesh-switcher mods to handle volume switching. See documentation for details. AllowNestedInventoryPart : Remove the "inventory parts can't be cargo parts" stock limitation. Require the BetterCargoPartVolume patch to be enabled. I've not released it yet, but I've written the details here, and the relevant code is here. I would appreciate your feedback on this.

RO redefine the whole EC balance around realistic values. I think it has some support for NF Electrics, but you will likely find that the reactors are quite heavily nerfed compared to what you are used to in stock. As for ISRU, I believe this is even harder than in stock Kerbalism. RO is basically a completely different game. First thing to do is to basically forget all I think you know about KSP. Unless, of course, if you cheat your way around.

Kerbalism - RO compatibility is provided by the https://github.com/KSP-RO/ROKerbalism config pack. But forget about a manned grand tour. RO, as the name suggests, changes everything to realistic "current technology" constraints (if you believe the worst issue is nerfed reaction wheels, you're clearly not aware of what RO is), so unless you intent is to massively cheat your way around those, this is silly. If you really want to make a RSS grand tour using stock-alike rules (aka science-fiction technology) don't install RO, use SMURFF and maybe tweakscale. But knowing you, you will feel even more motivated just because I said that, so here is the RO/RP1 installation guide : https://github.com/KSP-RO/RP-0/wiki/RO-&-RP-1-Advanced-Install-for-1.10.1

You're missing a "{}" and a ",*" in the patch : @PART[*]:HAS[@MODULE[ModuleTestSubject]] { !MODULE[ModuleTestSubject],* {} } As for the viability of the idea, honestly, it will be quite hard and messy to achieve what you want through configs only. Creating a plugin that : 1. Always reset funds to zero 2. Patch away all part costs 3. Implements unlocking a facility level when a specific tech tree node is unlocked isn't very hard to write. This being said, you will always run into compatibility issues with mods that rely on funds in a way or another to do some custom actions.

It's not as easy to get ride of all part costs. Some costs are dynamically added by PartModules (basic example : fairings). You might be able to patch away some of them through configs, but things will start to get messy when modules from other mods are involved. But since you don't intend to completely get ride of all funds sources, that might be acceptable. Depends on how refined you expect the end result to be. Note that removing/editing the facilities upgrade costs and kerbals hiring costs is possible via configs if you add CustomBarnKit as a dependency :

@Wowa Ilyich I've done some work to identify and fix that bug. I implemented a fix in a beta version of the KSPCommunityFixes mod. You can download that beta version here : https://github.com/KSPModdingLibs/KSPCommunityFixes/releases/tag/1.0.5-b1 Note that this is for KSP 1.12.2 only, it will crash with older KSP versions (but that bug is quite old). Please report if that fixes your issue.

So I guess it will have a custom clause in its EULA that actually allow modding to the full extent without risking legal pursuits or arbitrary hostile actions, contrary to the standard TakeTwo EULA that is currently in application for KSP 1 ?

No, this is a very old bug. If you are able to reproduce it consistently in a Stock+Kerbalism only (or even with a few mods) install, I'm interested in getting my hands on your save.

It's a stock bug, not caused by Kerbalism, but Kerbalism (as well as other data-heavy mods) make it more likely to happen. It will also happen way more often if you have increased the "Max physics delta-time per frame" setting in the main menu settings > "general" tab. In case you have changed it, I highly recommend that you set it back to the default 0.04 value. See https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/9 for details on that issue

A word of warning : this mod will cause all your vessels to suffer from a similar issue as what you can experience with breaking grounds robotics "drift". To be more clear, it will make the current in-physics deformation permanent : - Every time you engage timewarp - When the vessel is saved (ie, every time you quit the flight scene) This will lead to all vessels parts positions/orientations randomly and permanently shifting every time either of those actions are performed. Also, contrary to the stock robotics issue that only affect the child parts of robotic parts, it will do that for all parts and all vessels, even if they don't use animated parts. The issue is here : https://github.com/KSPKatten/AnimatedAttachment/blob/b80b7c2acdfef750a7928805ef5728cdba265d92/AnimatedAttachment/AnimatedAttachment.cs#L858 Nobody should ever call Part.UpdateOrgPosAndRot() outside of the editor for existing parts.

Absolutely not true. Prior to robotics (and now docking ports), there was nothing in KSP that altered the original part positions as defined in the initial craft created in the editor. The physical joints are created on a vessel load, using the initial parts position/rotation. When no robotics/new docking ports are involved, you can do as many save/load cycles as you want, the parts will always fall in place in the exact same position/orientation. The troubles started when, with robotics, they decided to alter those (previously set in stone for the lifetime of the vessel) position/rotation values on vessel unload and vessel packing, using the robotics displacement, and as a side-effect, the in-physics deformation. It was a huge mistake. They should have stored the robotics displacement/rotation as offsets to apply on top of the initial ones, this is for example what DockRotate does.

Search you whole GameData folder using a wilcard search : "*.dll". You will find at least two dlls with the same name. Rename them so they don't have the same name, and the issue should disappear.

That isn't true. Even with if you can't see it, there is always at least a small displacement, even in zero-G. Every time you exit the scene, that displacement will be added to the previous one. Over the course of several reloads, this will add up, inevitably borking you vessel in the long run.

The "global" situation is the one that happen when no other is true. So yep, for Kerbin you can't get the "low global" situation, as you always will be in Kerbin magnetosphere at "space low" altitudes.

The ArgumentOutOfRangeException doesn't always happen, in some cases the AssemblyLoader.FlagDuplicatedPlugins() method will just remove random assemblies from its internal list without further noticeable consequences. It depends in which order the plugins are added to that list, itself dependent on the folder/file composition/naming inside the GameData folder.

@linuxgurugamerNote that in addition to plugin assemblies having a mandatory AssemblyFileVersion attribute, the KSP 1.12 AssemblyLoader.FlagDuplicatedPlugins() method is completely borked (and still not fixed in KSP 1.12.2). Basically, having 2 mods that package the same dll (for example miniAVC) will trigger that issue. There is no workaround (beside making sure all installed mods packaging the same dll use different file names, because ironically this piece of crap use the file name instead of something reliable like the AssemblyTitle attribute to check if two assemblies are the same) See related Squad bugtracker issue : https://bugs.kerbalspaceprogram.com/issues/28036

By doing nothing beside being in space low / space high Yes. https://github.com/Kerbalism/Kerbalism/issues/642

My mistake, the patch should be : specifically, instead of : @PART[*]:HAS[@MODULE[ModuleInventoryPart]:HAS[!MODULE[ModuleCargoPart]]]:FINAL it must be : @PART[*]:HAS[@MODULE[ModuleInventoryPart],!MODULE[ModuleCargoPart]]:FINAL Otherwise, the second patch gets applied to parts that already have both modules (the "SEQ-X container module" parts for example), adding an extra ModuleCargoPart

Just to be clear : does the contract work or not ? Because the nullref itself is likely quite harmless, excepted that it prevent the orbit UI tooltip from showing. Edit : And also, I can't replicate it in 1.12.2. No nullref when hovering on available contract orbits. Will add this to next update. Thanks for notifying. This replace one of KSP-Recall fixes (recovery funds). Both mods can be installed together, and the recovery funds fix from KSPCommunityFixes will be used. This being said, for KSP 1.12, I think the only other active fix in KSP-Recall is "Attached", and I have absolutely no idea what this is doing. That seems like a good UI QoL improvement. Feel free to open an issue for it, or even to submit a PR.

For plugin development, I have a stripped-down install that load in less than 30 seconds on my potato by taking those actions : - Use Janitor's Closet to permaprune a good 2/3 of the stock parts (usually I keep only the 2.5m parts) - Remove the "GameData\SquadExpansion" folder (DLCs) - Remove all files in "GameData\Squad\KSPedia" excepted "kspedia.ksp" - Remove all folders in "GameData\Squad\Spaces" (IVAs) excepted "Placeholder", working in conjunction with the following MM patch : @PART[*]:HAS[@INTERNAL[*]]:FINAL { @INTERNAL[*] { @name = Placeholder } }

No, this is handled. There is a patch to un-do JPLRepo's own patch, the KSPCommunityFixes one (which doesn't replace ModuleDockingNode with a derivative, thus avoiding tons of mod compatibility issues, that's the point) will take over. And in case someone still want the original, features in KSPCommunityFixes can be individually disabled with a MM patch : https://github.com/KSPModdingLibs/KSPCommunityFixes/blob/master/GameData/KSPCommunityFixes/Settings.cfg

I did, hopefully that's alright ? The goal of that repository is to centralize bug fixes, instead of having a myriad of uncoordinated mods. The organization/repository is community owned/maintained, you are very welcome to contribute.