Jump to content

Gotmachine

Members
  • Posts

    341
  • Joined

  • Last visited

Everything posted by Gotmachine

  1. 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 crashing, causing the whole loading process to stop. 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 () GameDatabase+<LoadObjects>d__90.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() 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 can have some (unlikely) side issues, and 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. I've initially tried to make a Mono.Cecil based patcher for the KSP Assembly-CSharp.dll assembly, however Mono.Cecil fails to rewrite the KSP assembly correctly due to obfuscation. So the fix is implemented through BepInEx, a popular Unity/XNA runtime patcher and plugin framework used for many games (Valheim, Outwards, WorldBox...). 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
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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).
  11. 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.
  12. 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).
  13. @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.
  14. 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.
  15. 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
  16. 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.
  17. 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 :
  18. @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.
  19. 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 ?
  20. 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.
  21. 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
  22. 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.
  23. 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.
×
×
  • Create New...