Gotmachine

There is no way to do this directly through CC. A workaround could be to use MM patches to detected cupolas, and to add a dummy PartModule so you can detect it through the partModule PartValidation parameter (check documentation here : https://github.com/jrossignol/ContractConfigurator/wiki/PartValidation-Parameter) I would suggest making a tiny dll with an empty PartModule derivative named something like "ModuleCupolaContractValidation" for the purpose. Side note : checking the part title or tags will fail due to localization. You can only (somewhat) rely on the part name.

I guess you're using an IMGUI button. KSP will reset the selected part if any mouse click happen outside of the gizmo / selected part, unless the mouse is over an UGUI element : the EditorLogic FSM checks EventSystem.current.IsPointerOverGameObject() in the on_offsetDeselect.OnCheckCondition KSMEvent update delegate. There isn't any out-of-the-box solution to do what you want. It's doable but will involve quite a bit of reflection. Something that might be worth trying would be to instantiate a dummy transparent UGUI panel the size of your window. I don't think there is any way to prevent the deselection, beside replacing the KSMEvent instance by your own with a custom delegate in the EditorLogic FSM (which is doable, but arguably a bit hacky). Re-selecting the part is also gonna be a bit tricky. First step would be to save a reference to EditorLogic.SelectedPart when your IMGUI window/button is hovered. To restore it (properly) after the button has been clicked, you will need to call a bunch of private stuff. I won't extend further on the exact steps, since this is forbidden knowledge that will attract moderators like bees to honey. The real fix is to ditch IMGUI and to use an UGUI based UI for your mod.

If you mean the persistent thrust mod (there is no such feature in stock), that's what I mean by "significant effort". That mod is quite a large piece of code, and is far from working correctly in all situations. But to be clear, I wasn't saying it's not doable, just that it would require a lot of work and debugging, and that this is advanced stuff that require a good understanding of KSP internals. Yep, this is indeed a minor limitation that can be worked around relatively easily. Well, when timewarping, all vessels are packed. Here we introduce a situation where some vessels are packed and other aren't. I suspect it has to do with the floating origin system and the frame velocity becoming null when the active vessel is being transitioned from the in physics to packed state. This can be probably be worked around, but identifying and understanding the exact issue will likely be a bit tedious.

First, rigidbodies and collisions are two separate, mostly unrelated things. Collision detection is done through collider meshes, that might or might not be part of a rigidbody. The amount of colliders has almost no performance impact in itself, as long as no collisions happen. Arguably, it incurs a small cost when a raycasting call is being made (solar panels and radiators for example). What is CPU heavy is the rigidbodies constraint solving, or said otherwise, part joints. While the idea make some sense, the implementation would be a nightmare. The "default" physics state is just too deeply relied upon by too many pieces of stock code, and even if we were able to patch everything, that would still cause tons of issues with mods. In retrospect, I think PrunePhysics just isn't working (it isn't actually setting parts as physic-less parts), that's why we didn't ever see the slightest performance improvement. Since then, I've done quite a few tests on that front, and yes, actually setting that state can result in non-negligible overall performance improvement, up to 30 % with high part count vessels (500+ parts) when physics are the main thing running, but more realistically in the 10-25 % range in general. Physics significance works by parenting the part gameobject to its "KSP hierarchy" parent gameobject and removing its rigidbody and joints, which cause Unity to directly update the child position/rotation, instead of calling the PhysX solver. Theoretically, if you set it on all parts beside the root part, you end up with no joints at all, and a single rigidbody (the root part) whose mass is the sum of all the vessel parts mass. In practice, this doesn't work because : This mean that the vessel CoM becomes the root part CoM. The mass summing isn't entirely reliable (not investigated much, but it likely ignore IPartMassModifier modules) Almost everything that attempt to provide forces/torques like atmospheric lift, engine thrust or attitude control (reaction wheels, RCS, control surfaces) will be heavily borked. This breaks tons of things that rely on individual rigidbodies to exist on the part : wheels, legs, docking ports, robotics to cite a few obvious ones This completely breaks the stock landed checks and landed easing code. In short, there are just too many corner cases to attempt to apply that globally without causing tons of bugs and game-breaking side effects. Yep, that's mine : https://github.com/gotmachine/PhysicsHold It takes a different approach, relying on the fact that KSP already provide a "physics disabled" mode in the form of the "packed" vessel state that is used during (non-physics) timewarp. The mod just force-activate that mode when you don't timewarp. On the technical side, this is a very different. The "packed" state change the state of all rigidbodies to "kinematic", essentially disabling all PhysX force/torque/joint interactions on them. In that mode, KSP also put the vessel "on rails", updating every part position/rotation manually instead of letting the joint physics do the job of keeping them in their place. Performance wise, it's a bit less efficient than the "physics significance" trick (directly parenting the gameobjects), but very comparable. Since it's a default KSP state, KSP (and most mods) handle it correctly in most situations, the main "hacks" in my plugin are because I'm enabling EVAing/boarding, docking/undocking and partially enabling physics for robotic parts when the vessel is on physics hold, which are scenarios that weren't provisioned for in the KSP code (but making them work is relatively easy). The huge advantage of this solution is that it doesn't change fundamentally the state of the parts : rigidbodies still exist, their mass and physical stats are still computed. This being said, the plugin only applies to landed bases, because things can get a bit more complicated in other situations : Kinematic rigidbodies can only collide with non-kinematic rigidbodies. This is a well known effect seen in stock when timewarping, with vessels passing right through each others. However, kinematic rigidbodies will collide with non-kinematic ones. This mean that for a landed base, setting the packed state isn't an issue, since two bases relative positions are fixed (so they won't ever collide), and things that can move (rovers for example) will collide with them just fine. However, this is definitely an issue in space, where two packed vessels can collide with each other. This is the main reason why I only did this for landed bases. Still, this is an issue that could be worked around, either by naively re-enabling physics when a collision is about to happen, or by a more complex implementation that handle collisions manually. Packed vessels are "on rails" and are essentially unmovable, be it for attitude control, thrust, or reacting to collisions. These are all things that could be re-implemented, but that would require a significant effort. There is a problematic issue with setting the packed state on the active vessel if other non-landed vessels are in physics range, causing those vessels velocity to be reset to zero. The workaround is likely to be a bit difficult. This can't work for rovers, due to them relying on wheels physics. This can't work for atmospheric flight.

Try : @SUBTYPE,* And while you're at it, also do : @MODULE[ModuleB9PartSwitch],* So you don't only the target the first module if there are multiple ones.

I was aware your issue is solved. I was just randomly chatting on the more general topic. Sorry if I annoyed you. But still, no, that mod, like any KSP 1.8+ mod, runs on the .NET Framework 4.x : https://github.com/jrodrigv/OfCourseIStillLoveYou/blob/3a44cc650cde0ecfb116dbb0beaa375f437b3682/OfCourseIStillLoveYou/OfCourseIStillLoveYou.csproj#L12 Now, I will see myself out, sorry again

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