Lisias Posted June 5, 2020 Author Share Posted June 5, 2020 (edited) 31 minutes ago, moguy16 said: i am getting the houston we have a problem thing here's the log https://drive.google.com/file/d/1DAjmyTs0B_vzL5t5aYI4e4y-t6F9oJOn/view?usp=sharing Got it. And, boy, what a marvelous collection of FATALities we have here! Mortal Kombat is childish play near this! [LOG 23:25:45.815] [TweakScale] INFO: WriteDryCost Concluded : 3533 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1092 Show Stoppers found; 9 Sanity Check failed; 1874 unscalable parts. But such amount of FATALities is, usually, a problem while installing things, see: [LOG 23:13:41.178] [ModuleManager] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Bluedog_DB/Parts/Titan/bluedog_UA1207/PART [LOG 23:13:41.331] [ModuleManager] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Gamedata/Bluedog_DB/Parts/Titan/bluedog_UA1207/PART You have bluedog (and probably others) installed twice on the system. Delete GameData/GameData and you should be fine. In time, I also detected the very same problem from the last post above: [LOG 23:04:38.802] [ModuleManager] version 3.1.1.0 at E:\KSP - KSSRS\GameData\ModuleManager.3.1.1.dll won the election against Version 3.1.1.0 E:\KSP - KSSRS\GameData\Gamedata\ModuleManager.4.1.3.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.0.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.1.dll Version 3.1.1.0 E:\KSP - KSSRS\GameData\ModuleManager.4.1.3.dll As I mentioned above, MODULE MANAGER IS ELECTING THE OLDEST VERSION ON YOUR SYSTEM TO BE USED. This is unbelievable, but it's true, MM is utterly broken. Please delete every ModuleManager from your instalment but the latest one, 4.1.3 . (and these stunts is the reason I decided to ditch this thing and I'm using my own experimental fork). -- POST EDIT -- Additionally, install ZeroAVC. Really, MiniAVC is causing lots of troubles on KSP >= 1.8 and your instalment have some copied on it scattered on the folders. Edited June 5, 2020 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
LF_Ion Posted June 5, 2020 Share Posted June 5, 2020 Why does TweakScale affect the output of engines? I used it to make the panther engine smaller for my F20, but now it outputs hardly any thrust, but normal scale it works fine. Quote Link to comment Share on other sites More sharing options...
linuxgurugamer Posted June 5, 2020 Share Posted June 5, 2020 3 minutes ago, LF_Ion said: Why does TweakScale affect the output of engines? I used it to make the panther engine smaller for my F20, but now it outputs hardly any thrust, but normal scale it works fine. Because that what happens when you make something smaller in IRL Quote Link to comment Share on other sites More sharing options...
LF_Ion Posted June 5, 2020 Share Posted June 5, 2020 (edited) Fair enough. Regardless it's a good mod. Edited June 6, 2020 by LF_Ion Quote Link to comment Share on other sites More sharing options...
DylanBrown Posted June 5, 2020 Share Posted June 5, 2020 2 hours ago, Lisias said: Got it. [LOG 14:26:03.329] [TweakScale] INFO: WriteDryCost Concluded : 1596 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 5 Show Stoppers found; 0 Sanity Check failed; 386 unscalable parts. And the parts are: [LOG 14:26:03.288] [TweakScale] ERROR: **FATAL** Part AluminiumLiquidMetalEngine (Aluminium Liquid Metal Injection Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.289] [TweakScale] ERROR: **FATAL** Part AluminiumMonopropellantEngine (Aluminium Monopropellant Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.289] [TweakScale] ERROR: **FATAL** Part AluminiumPneumaticEngine (Aluminium Pneumatic Fuel Feed Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.293] [TweakScale] ERROR: **FATAL** Part kspiIHRMOR7HRM (Aluminium Hybrid Rocket Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 14:26:03.294] [TweakScale] ERROR: **FATAL** Part kspiIHRMOR7HRMhalf (Aluminium Hybrid Rocket Engine 3/4) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). And that was interesting.... [LOG 14:18:08.193] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART [LOG 14:18:08.223] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART Every part affected has this Modus Operandi. What makes this thing interesting is that the same patch is being applied twice. What makes it yet more interesting is that I wrote this patch myself and applied a Pull Request recently to KSPIE, to prevent a (future) problem when TweakScale 2.5 will be released (for the tech savvy: TweakScale will be moved out from the LEGACY patching from MM, and this will break some old patches). And I tested this thing, this obvious mistake would not had passed through. But, I just downloaded the most recent release and tried again on my test rig, and I didn't reproduced the issue here. Reveal hidden contents [LOG 16:22:08.191] [TweakScale] INFO: WriteDryCost Concluded : 787 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 9 Sanity Check failed; 121 unscalable parts. dry run on my test rig So whatever is happening on your rig, is not something from WarpPlugin neither TweakScale. What's not that good, because I would have a solution for you already if it did. So let's keep digging. Unfortunately, this diagnosis is now a phishing expedition. I'm now looking for weird things in the hope one of the weirdness is the problem - or at least, the trigger for the problem. I did a look on the DLLs loaded on your rig: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Scale_Redist v1.0.0.0 / v2.4.3.10 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 ModuleManager v3.1.1.0 MiniAVC v1.4.0.2 FilterExtensions v3.2.4.0 / v1.0.0.0 USITools v1.0.0.0 B9AnimationModules v1.6.0.0 / vv1.6.0 B9PartSwitch v2.12.1.0 / vv2.12.1 InstallChecker v1.0.0.0 CCK v5.0.0.0 / v4.1.0.0 for KSP 1.6.0 DecouplerShroud v1.0.0.0 DistantObject v1.9.1.29406 Atmosphere v1.8.0.2 CelestialShadows v1.8.0.2 CityLights v1.8.0.2 EVEManager v1.8.0.2 PartFX v1.8.0.2 PQSManager v1.8.0.2 ShaderLoader v1.8.0.2 Terrain v1.8.0.2 TextureConfig v1.8.0.2 Utils v1.8.0.2 _BuildManager v1.8.0.2 Launchpad v6.7.2.0 / v6.7.2 Firespitter v7.3.7240.11089 MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 KEX-Common v1.0.0.0 Kopernicus.Parser v1.0.0.0 ModularFlightIntegrator v1.0.0.0 / v1.2.7.0 Kopernicus v1.0.0.0 KEX-EmissiveFX v1.0.0.0 InterstellarFuelSwitch v3.13.3.5 MiniAVC v1.4.0.2 RasterPropMonitor v0.31.2.39964 KAS-API-v2 v2.0.7239.35367 / vKAS API v2 KAS v1.5.7239.36651 / v1.5 for KSP 1.8+ KSPDev_Utils.2.0 v2.0.7231.38433 / v2.0 for KSP v1.8+ MiniAVC v1.4.0.2 DeployableAeroSurfaces v1.0.0.0 KIS v1.24.7279.41031 / v1.24 for KSP 1.8+ KSPDev_Utils.2.1 v2.1.7279.39857 / v2.1 for KSP v1.8+ MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 NFPropUtils v1.0.0.0 Interstellar_Redist v1.3.0.0 MiniAVC v1.4.0.2 PhotonSail v1.4.11.5 Scale_Redist v1.0.0.0 / v2.4.3.10 BackgroundResources v1.8.0.0 MiniAVC v1.4.0.2 DeepFreeze v0.27.0.0 Restock v0.1.0.0 scatterer v0.0.0.0 MiniAVC v1.4.0.2 SmokeScreen v2.8.9.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 MiniAVC v1.4.0.2 MiniAVC v1.4.0.2 TarsierSpaceTech v7.9.0.0 TrajectoriesBootstrap v1.0.0.0 KerbalAlarmClock v3.12.0.0 KSPe.Light.TweakScale v2.1.0.17 Scale v2.4.3.10 Konstruction v0.0.0.0 USILifeSupport v1.0.0.0 KolonyTools v1.0.0.0 Interstellar v1.25.10.5 Interstellar_Redist v1.3.0.0 MiniAVC v1.4.0.2 Install ZeroAVC. Really, MiniAVC is causing lots of troubles on KSP >= 1.8 I also found something wrong on Kopernicus: [LOG 14:13:43.112] [AddonLoader]: Instantiating addon 'ShaderInit' from assembly 'KopernicusExpansion.EmissiveFX' [LOG 14:13:43.114] [Kopernicus] ShaderLoader: Loading asset bundle at path C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/Ko pernicusExpansion/Shaders\emissivefx-windows.unity3d [ERR 14:13:43.173] Unable to open archive file: C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/KopernicusExpansion/Shaders/e missivefx-windows.unity3d [EXC 14:13:43.227] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.ShaderLoader.LoadAssetBundle (System.String path, System.String bundleName) (at <0882401b48d84227ad9c2bbcf4ce8401>:0) KopernicusExpansion.EmissiveFX.ShaderInit.Awake () (at <514cb877ddec4c1781406e60905add56>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__89:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__70:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() And this is making Kopernicus bork terribly later, and this is hindering your FPS for sure, because the exception is happening on an Update event from Unity [EXC 14:44:27.485] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) [EXC 14:44:27.642] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () (at <0882401b48d84227ad9c2bbcf4ce8401>:0) [LOG 14:44:33.847] [UIApp] OnDestroy: I think it's unlikely this is causing the problems you are complaining, but this is also hurting your game for sure. So you need to fix Kopernicus or delete it at all from the GameData. And there's FOUR ModuleManagers 3.1.1 on your instalment??? Whatahell? I dig a bit more on the KSP.log and found this: [LOG 14:13:38.908] Load(Assembly): /999_Scale_Redist [LOG 14:13:38.910] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\999_Scale_Redist.dll [LOG 14:13:38.973] Load(Assembly): /ModuleManager.3.1.1 [LOG 14:13:38.973] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.3.1.1.dll [LOG 14:13:39.034] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.035] Load(Assembly): /ModuleManager.4.1.0 [LOG 14:13:39.035] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.0.dll [LOG 14:13:39.093] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.093] Load(Assembly): /ModuleManager.4.1.1 [LOG 14:13:39.093] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.1.dll [LOG 14:13:39.161] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 14:13:39.161] Load(Assembly): /ModuleManager.4.1.3 [LOG 14:13:39.161] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll [LOG 14:13:39.224] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 I'm not exactly thrilled on this issue, as there's code on MM to elect a "winner" when more than one is alive on Unity's guts, and this code depends of the correct Versioning to work correctly. And, right now, the wrong MM is being used! [LOG 14:13:42.646] [ModuleManager] version 3.1.1.0 at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.3.1.1.dll won the election against Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.0.dll Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.1.dll Version 3.1.1.0 C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll DAMNIT, THIS IS UNBELIEVABLE. I urge you to delete all Module Managers but the 4.1.3 one. I wil continue to dig for problems, perhaps we have some conflict on some other Add'On, but, right now I urge you to implement the fixes I'm proposing above, as these ones are known sources of problems (one of them, a very nasty one! - damnit!). If by some reason this fixes the FATALities, please, please, let me know. I unistalled all the Module Managers but the 4.1.3 and installed ZeroAVC but I still get the errors, anything alse I need to do? (I also laughed so hard when reading through this lol) Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 5, 2020 Author Share Posted June 5, 2020 3 minutes ago, DylanBrown said: I unistalled all the Module Managers but the 4.1.3 and installed ZeroAVC but I still get the errors, anything alse I need to do? (I also laughed so hard when reading through this lol) I'm still trying to reproduce this problem, I'm downloading every single Add'On mentioned in your KSP.log and installing them to see what I get. Until this moment, I didn't managed to reproduce it - so I'm kinda lost on it yet. Going bag to that double patching I quoted from that post: [LOG 14:18:08.193] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART [LOG 14:18:08.223] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART See, we have the same patch (Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]) being applied twice on the same node (WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART) on an interval of 30 milliseconds. This is a pattern, and it happened too on the other parts that got a FATALity. Initially, I though it would be a MM doppelgänger running in parallel, it happened once on TweakScale (when the user unadrevtidly placed a copy of the DLL somewhere else and forgot about), by so every patch would be applied twice, not only these parts and not only TweakScale - and, of course, that "Election" stunt my be electing the wrong guy, but it appears to be correctly ruling out the ones that lost the election. I'm really reticent on thinking this is a problem on some Add'On because by the time the problem happens, there's not too much thingies running on the system. These two log entries above are also consecutive, there's nothing between these two lines , as an exception or something. Currently, my only guess is MM itself. I'm using my own Experimental fork on a MacOS - and, by some previous experience supporting some fellow Kerbonauts used to run KSP on multiple environments, I know that there's some significant differences on the Task Switchers involved (TL;DR: Linux and MacOS appears to have more reliable task switchers, while Windows appears to be slightly faster on switching contexts). Since right now the only significative differences between my 1.8.1 test bed and your setup are that I'm running MacOS and my Experimental MM fork, I'm tempted to suggest you use my experimental fork for debugging purposes. In the mean time, I'm writing a brute-force "solution" to keep your game running in the mean time - it's Friday night, by God's sake, you wanna play. Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 6, 2020 Author Share Posted June 6, 2020 (edited) I made some testings shoving every single DLL from MM I have on the same GameData. This is what I found: ModuleManager.2.7.6 v2.7.6.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 ModuleManager v3.0.4.0 [LOG 20:54:53.735] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [EXC 20:54:53.753] MissingMethodException: PopupDialog PopupDialog.SpawnPopupDialog(UnityEngine.Vector2,UnityEngine.Vector2,string,string,string,bool,UISkinDef,bool,string) ModuleManager.ModuleManager.Awake () (at <e40c6d8935f74be49802d520dee420c7>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__89:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__70:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() [LOG 20:54:53.754] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [LOG 20:54:53.777] [ModuleManager] version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll Module Manager 2.7.6 is correctly detecting its version, but it's borking trying to call PopupDialog.SpawnPopupDialog that doesn't exists on the current KSP Version. So MM 3.0.4 is the next candidate, and by some weird reason, every single one of the others are also being tagged as 3.0.4.0 !!! So I decided to rename my fork's DLL to ModuleManager.1.0.0.dll to force it to be scanned first (and removed 2.7.6). And that's it: [LOG 21:03:53.892] [ModuleManager] INFO: version 4.1.3.1 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.1.0.0.dll won the election against Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Only the first Module Manager found wins the Election, no matter what. So I decided to pursue this problem, and compiled different versions of the /L Experimental to see what I get. And this is what I got: [LOG 21:48:52.126] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll What's happening is that only the first Assembly found is loaded into memory, subsequent Assemblies earn an entry on the Reflection tables but pinpoints to the first Assembly loaded always. Interesting. So a light bulb sparked in my head, and I copied all that DLLs into my 1.7.3 testbed, and got this: [LOG 21:55:05.448] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.0.4.dll won the election against Version 4.1.3.1 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.dll Version 4.1.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.1.3.dll Version 4.0.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.3.dll Version 4.0.2.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.2.dll Version 3.1.1.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.1.1.dll Not only the order of the DLLs changed on the listing, and now they are correctly identified. Interesting, because I had changed the election so the LAST assembly on the list wins and with the Assemblies correctly identified (and sorted), the 3.0.4 ended up being elected again. So I fixed the code to elect the First of that list again. And now things came back to work as expected on KSP 1.7.3: [LOG 22:11:56.202] [ModuleManager] INFO: version 4.1.3.1 at /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.dll won the election against Version 4.1.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.1.3.dll Version 4.0.3.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.3.dll Version 4.0.2.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.4.0.2.dll Version 3.1.1.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.1.1.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.7.3/GameData/ModuleManager.3.0.4.dll Since my fork works fine downto KSP 1.2.2, I decided to reproduce this test on 1.3.1. And got the exact same behaviour from 1.7.3. So this thing used to work in the past, but stopped working when 1.8.0 arrived changing how Assemblies are handled. In a way or another, this mechanism doesn't works anymore. I altered the code to sort the list only by the pathname, in the hopes that the Version would be a flaw and that the remaining Assemblies would be still on memory. And came to this: [LOG 22:25:46.692] [ModuleManager] INFO: version 3.0.4.0 at /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.0.4.dll won the election against Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.1.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.3.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.4.0.2.dll Version 3.0.4.0 /.users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/ModuleManager.3.1.1.dll But, frankly, I could had detected this sooner if I had paid attention to my own log messages: [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental [LOG 22:25:53.067] [ModuleManager] Version 3.0.4.0 /L Experimental Since every one of that copies were a propperly compiled DLL (with the Version matching the name, as you can check from the logs from KSP 1.7.3), we have confirmation that only the first Assembly is being loaded with the remaining ones receiving a new entry on the Reflection tables, but pinpointing to the first one loaded. Pretty nasty behaviour, as it is giving us false information. So this settle up the matter. From the next releases, no Add'On of mine will deliver Module Manager anymore. In its place, a utility will check if more than one Module Manager is installed and, if it found more than one, will halt the loading informing the user of the problem. Users of CKAN will not be affected, as CKAN correctly copies only what the NetKAN metadata tells it to copy, and my NetKAN metadata doesn't copy the embedded ModuleManager DLL (it was meant to make the life of manual installers easier, but as we can see, it backfired on me). Edited June 6, 2020 by Lisias Tyops, as usulla... Quote Link to comment Share on other sites More sharing options...
DylanBrown Posted June 6, 2020 Share Posted June 6, 2020 3 hours ago, Lisias said: I'm still trying to reproduce this problem, I'm downloading every single Add'On mentioned in your KSP.log and installing them to see what I get. Until this moment, I didn't managed to reproduce it - so I'm kinda lost on it yet. Going bag to that double patching I quoted from that post: [LOG 14:18:08.193] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART [LOG 14:18:08.223] [ModuleManager] Applying update Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]:FOR[WarpPlugin] to WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART See, we have the same patch (Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/@PART[AluminiumLiquidMetalEngine]) being applied twice on the same node (WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine/PART) on an interval of 30 milliseconds. This is a pattern, and it happened too on the other parts that got a FATALity. Initially, I though it would be a MM doppelgänger running in parallel, it happened once on TweakScale (when the user unadrevtidly placed a copy of the DLL somewhere else and forgot about), by so every patch would be applied twice, not only these parts and not only TweakScale - and, of course, that "Election" stunt my be electing the wrong guy, but it appears to be correctly ruling out the ones that lost the election. I'm really reticent on thinking this is a problem on some Add'On because by the time the problem happens, there's not too much thingies running on the system. These two log entries above are also consecutive, there's nothing between these two lines , as an exception or something. Currently, my only guess is MM itself. I'm using my own Experimental fork on a MacOS - and, by some previous experience supporting some fellow Kerbonauts used to run KSP on multiple environments, I know that there's some significant differences on the Task Switchers involved (TL;DR: Linux and MacOS appears to have more reliable task switchers, while Windows appears to be slightly faster on switching contexts). Since right now the only significative differences between my 1.8.1 test bed and your setup are that I'm running MacOS and my Experimental MM fork, I'm tempted to suggest you use my experimental fork for debugging purposes. In the mean time, I'm writing a brute-force "solution" to keep your game running in the mean time - it's Friday night, by God's sake, you wanna play. I think you might be onto something with the WarpPlugin mod because I tried removing it to see if it would work and no errors popped up. But why was it the WarpPlugin? Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 6, 2020 Author Share Posted June 6, 2020 (edited) I AM AN IDIOT!!! You had a double patched part because you have TWO COPIES of the patch on your instalment! [LOG 14:14:30.639] Load(Texture): Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine [LOG 14:16:13.347] Load(Texture): WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine MM is fine (at least, as much fine as it uses to be). WarpPlugin is fine. My patch is fine. I just was tired yesterday night, got focused on the bug I found on MM and didn't paid enough attention to simpler alternatives. Delete GameData/Parts from your game and things will be fine! What happened on your instalment follows: The parts affected has the following structure: PART { name = foobar yada yada yada } @PART[foobar]:FOR[WarpPlugin] { %MODULE[TweakScale]:NEEDS[TweakScale] { yada yada yada } } This was made this way so TweakScale would not be injected on the part when TweakScale is not installed, as well to order the patching on the new PASS patching mechanism from Module Manager. Since TweakScale 2.5 will be pulled out of the LEGACY patching, doing this way will help TweakScale to prevent double patching (that it was what was happening on a game installation of mine where I test drive TweakScale 2.5), as well any mishap would be easily detected (as it did, indeed). On your GameData, by some accident you ended up with two copies of the WarpPlugin/Parts - one on the right place, other on the root of the GameData (a pretty wrong place). So we ended up with two copies of the PART, but also with two copies of the Patch itself. So the patch was (correctly) ran two times, each time patching two parts - because Module Manager, when it finds two nodes with the same name, patch both (what's correct, Module Manager knows squat about PARTs, it only understands Nodes!). By a incredible lack of luck (of my part), this week I already had problems with some patches I applied on a PR to WarpPlugin (MM has, indeed, some idiosyncrasies that now and then bites me in the SAS - but this was not one of them!), so I jumped into the conclusion that I had, somehow, borked again (what I do now and then, but this one is not one of them). And how I, finally, detected the problem? Easy. I took some sleep and came back to the problem with a fresh mind, started to review what I already said to you and then the True hit me with the finesse of a piano falling from the 20th story. Oh, well. Case close. Cheers! -- -- -- A SERIE OF USELESS CRAP -- -- -- 9 hours ago, DylanBrown said: I think you might be onto something with the WarpPlugin mod because I tried removing it to see if it would work and no errors popped up. But why was it the WarpPlugin? I ruled out WarpPlugin when I run it using my Experimental fork on my MacMini (not sure what of the options was the "fix") and it worked fine. As it worked fine when I issued the Pull Request on Warp Plugin to fix a double patching that would happen when TweakScale V 2.5.0.x will go gold, when it wold be pulled out from the LEGACY patching. TweakScale 2.5 is something that it's being worked out for a whole year already, and you can bet your SAS it's being rigorously tested (and not just by me, there're crazy brave Kerbonauts helping me on the matter - so it's not only "working on my machine"). In a way or another, there's only one thing applying patches on your rig, and this thing is Module Manager - so, until further information is gathered (check your private messages, I need your help on this) - and until further evidences are found, I think we found (another) bug on Module Manager. So right now, and except a handful of Add'Ons I didn't bored to download and install as I think I caught the problem, what follows are the only differences between my KSP 1.8.1test bed and yours: I'm running on MacOS, you are running on Windows 10 I'm using my personal Experimental fork for MM, you was running "stock" 3.1.1 and later 4.1.3 Initially I was thinking that perhaps one old copy of Module Manager would be running unattended in parallel, but quickly I realise I was wrong - the double patching would be happening everywhere, not only sometimes. [The text on the spoiler below was wrong - I was wrong, this was a good patching!] Spoiler And I discovered that, indeed, MM is running some nodes twice, as we can see here from your KSP.log : [LOG 14:17:42.245] [ModuleManager] Deleting node in file Parts/Engines/Daedalus/Deadalus subnode: PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] as it can't satisfy its NEEDS [LOG 14:17:42.246] [ModuleManager] Deleting node in file Parts/Engines/Daedalus/Deadalus subnode: PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] as it can't satisfy its NEEDS See, PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] was "removed" twice, with 1 ms interval. This is not, yet, proof of wrongdoing - I need to inspect the PART and the patch to be sure, so it's what I'm doing right now: inspecting Daedalus and eye ball it. So this is not a problem on WarpPlugin, as Daedalus apparently may be suffered the same problem - [uh. Daedalus is a part from Warp Plugin! duh...] it only happens that it had something deleted, not added - but I suspect that is someone installs FarFutureTechnologies it would be double patched too. In a way or another, shove this patch into your GameData for while. It will force brute its way into a sane GameDatabase so you at least can play without TweakScale yelling on you: Spoiler // For DylanBrown // // Put this on __LOCAL/TweakScale/WorkArounds/MM-bug-on-WarpPlugin.cfg // // https://forum.kerbalspaceprogram.com/index.php?/topic/179030-ksp-141-tweakscale-under-lisias-management-24314-2020-0519/&do=findComment&comment=3798116 @PART[AluminiumLiquidMetalEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[AluminiumMonopropellantEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[AluminiumPneumaticEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale]:NEEDS[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[kspiIHRMOR7HRM]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[kspiIHRMOR7HRMhalf]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } You will need to delete this stunt when (or if) we find a proper fix, so please remember where you put it (it's the reason I recommend using that __LOCAL thingy). (and check your private message) Edited June 6, 2020 by Lisias Uh... I hate flying pianos. Quote Link to comment Share on other sites More sharing options...
DylanBrown Posted June 6, 2020 Share Posted June 6, 2020 6 hours ago, Lisias said: I AM AN IDIOT!!! You had a double patched part because you have TWO COPIES of the patch on your instalment! [LOG 14:14:30.639] Load(Texture): Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine [LOG 14:16:13.347] Load(Texture): WarpPlugin/Parts/Engines/AluminiumEngine/LiquidMetalInjectionEngine MM is fine (at least, as much fine as it uses to be). WarpPlugin is fine. My patch is fine. I just was tired yesterday night, got focused on the bug I found on MM and didn't paid enough attention to simpler alternatives. Delete GameData/Parts from your game and things will be fine! What happened on your instalment follows: The parts affected has the following structure: PART { name = foobar yada yada yada } @PART[foobar]:FOR[WarpPlugin] { %MODULE[TweakScale]:NEEDS[TweakScale] { yada yada yada } } This was made this way so TweakScale would not be injected on the part when TweakScale is not installed, as well to order the patching on the new PASS patching mechanism from Module Manager. Since TweakScale 2.5 will be pulled out of the LEGACY patching, doing this way will help TweakScale to prevent double patching (that it was what was happening on a game installation of mine where I test drive TweakScale 2.5), as well any mishap would be easily detected (as it did, indeed). On your GameData, by some accident you ended up with two copies of the WarpPlugin/Parts - one on the right place, other on the root of the GameData (a pretty wrong place). So we ended up with two copies of the PART, but also with two copies of the Patch itself. So the patch was (correctly) ran two times, each time patching two parts - because Module Manager, when it finds two nodes with the same name, patch both (what's correct, Module Manager knows squat about PARTs, it only understands Nodes!). By a incredible lack of luck (of my part), this week I already had problems with some patches I applied on a PR to WarpPlugin (MM has, indeed, some idiosyncrasies that now and then bites me in the SAS - but this was not one of them!), so I jumped into the conclusion that I had, somehow, borked again (what I do now and then, but this one is not one of them). And how I, finally, detected the problem? Easy. I took some sleep and came back to the problem with a fresh mind, started to review what I already said to you and then the True hit me with the finesse of a piano falling from the 20th story. Oh, well. Case close. Cheers! -- -- -- A SERIE OF USELESS CRAP -- -- -- I ruled out WarpPlugin when I run it using my Experimental fork on my MacMini (not sure what of the options was the "fix") and it worked fine. As it worked fine when I issued the Pull Request on Warp Plugin to fix a double patching that would happen when TweakScale V 2.5.0.x will go gold, when it wold be pulled out from the LEGACY patching. TweakScale 2.5 is something that it's being worked out for a whole year already, and you can bet your SAS it's being rigorously tested (and not just by me, there're crazy brave Kerbonauts helping me on the matter - so it's not only "working on my machine"). In a way or another, there's only one thing applying patches on your rig, and this thing is Module Manager - so, until further information is gathered (check your private messages, I need your help on this) - and until further evidences are found, I think we found (another) bug on Module Manager. So right now, and except a handful of Add'Ons I didn't bored to download and install as I think I caught the problem, what follows are the only differences between my KSP 1.8.1test bed and yours: I'm running on MacOS, you are running on Windows 10 I'm using my personal Experimental fork for MM, you was running "stock" 3.1.1 and later 4.1.3 Initially I was thinking that perhaps one old copy of Module Manager would be running unattended in parallel, but quickly I realise I was wrong - the double patching would be happening everywhere, not only sometimes. [The text on the spoiler below was wrong - I was wrong, this was a good patching!] Reveal hidden contents And I discovered that, indeed, MM is running some nodes twice, as we can see here from your KSP.log : [LOG 14:17:42.245] [ModuleManager] Deleting node in file Parts/Engines/Daedalus/Deadalus subnode: PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] as it can't satisfy its NEEDS [LOG 14:17:42.246] [ModuleManager] Deleting node in file Parts/Engines/Daedalus/Deadalus subnode: PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] as it can't satisfy its NEEDS See, PART/EFFECTS/running_closed/MODEL_MULTI_PARTICLE:NEEDS[FarFutureTechnologies] was "removed" twice, with 1 ms interval. This is not, yet, proof of wrongdoing - I need to inspect the PART and the patch to be sure, so it's what I'm doing right now: inspecting Daedalus and eye ball it. So this is not a problem on WarpPlugin, as Daedalus apparently may be suffered the same problem - [uh. Daedalus is a part from Warp Plugin! duh...] it only happens that it had something deleted, not added - but I suspect that is someone installs FarFutureTechnologies it would be double patched too. In a way or another, shove this patch into your GameData for while. It will force brute its way into a sane GameDatabase so you at least can play without TweakScale yelling on you: Reveal hidden contents // For DylanBrown // // Put this on __LOCAL/TweakScale/WorkArounds/MM-bug-on-WarpPlugin.cfg // // https://forum.kerbalspaceprogram.com/index.php?/topic/179030-ksp-141-tweakscale-under-lisias-management-24314-2020-0519/&do=findComment&comment=3798116 @PART[AluminiumLiquidMetalEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[AluminiumMonopropellantEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[AluminiumPneumaticEngine]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale]:NEEDS[TweakScale] { type = stack_interstellar defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[kspiIHRMOR7HRM]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } @PART[kspiIHRMOR7HRMhalf]:FINAL { -MODULE[TweakScale], * { } %MODULE[TweakScale] { type = stack defaultScale = 2.5 scaleFactors = 0.625, 0.95, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 15, 20, 30, 40 } } You will need to delete this stunt when (or if) we find a proper fix, so please remember where you put it (it's the reason I recommend using that __LOCAL thingy). (and check your private message) ahh yesss, it's all working again! Thank you so so much for your help! Quote Link to comment Share on other sites More sharing options...
SpaceFaringOrBust Posted June 6, 2020 Share Posted June 6, 2020 Hello @Lisias, I'm having some fatal issues as well with Tweakscale installed. If I remove the Tweakscale folder from the gamedata folder, eveything works fine. Except for the fact that I don't have Tweakscale and all my ships are corrupted now. Would you please take a look at my ksp.log and telling me what is causing the issue? Thank you https://drive.google.com/file/d/11GpVWw3gGZ972AT-XxTQ7xELeZAlLXZu/view?usp=sharing Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 6, 2020 Author Share Posted June 6, 2020 20 minutes ago, SpaceFaringOrBust said: Hello @Lisias, I'm having some fatal issues as well with Tweakscale installed. If I remove the Tweakscale folder from the gamedata folder, eveything works fine. Except for the fact that I don't have Tweakscale and all my ships are corrupted now. Would you please take a look at my ksp.log and telling me what is causing the issue? Thank you https://drive.google.com/file/d/11GpVWw3gGZ972AT-XxTQ7xELeZAlLXZu/view?usp=sharing Got it. I hope you made backups of the savegames... [LOG 15:44:52.599] [TweakScale] INFO: WriteDryCost Concluded : 1481 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 3 Show Stoppers found; 9 Sanity Check failed; 682 unscalable parts. And the FATALities are: [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:44:52.395] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Humm... Interesting. I recently released a Alpha for KIS on the TweakScale Companion Program. And, yeah, they are kinda of related. When you updated TweakScale, you forget to delete the older version. Things will change a lot on TweakScale in the next few months while I pave the way for TweakScale 2.5, and some files will be removed or moved. So you need to remove the old TweakScale folder before applying the update. [LOG 15:42:29.335] Config(@PART[KIS_Container1]) TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] [LOG 15:42:29.344] Config(@PART[KIS_Container1]) TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] Completely delete GameData/TweakScale then install it again and you will be fine. Cheers! Quote Link to comment Share on other sites More sharing options...
SpaceFaringOrBust Posted June 6, 2020 Share Posted June 6, 2020 @Lisias Thank you for such a quick response! I do not have any backups of the game. I did re-download TweakScale and used my old gamefile, but it didn't work. But I may not have deleted the old TweakScale first. I'll try that and see what happens. Do you think I can try my old gamefile or is it FUBAR? Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 6, 2020 Author Share Posted June 6, 2020 (edited) 8 hours ago, SpaceFaringOrBust said: @Lisias Thank you for such a quick response! I do not have any backups of the game. I did re-download TweakScale and used my old gamefile, but it didn't work. But I may not have deleted the old TweakScale first. I'll try that and see what happens. Do you think I can try my old gamefile or is it FUBAR? As long you don't save back what you loaded, no harm is done - HOWEVER, this also applies to living crafts on the savegame. So, in a nutshell, craft files are ok. Just don't save after loading, they will "survive". But anything flying around became broken, and since KSP automatically save the game on quitting, without backups they are doomed. You can try to avoid it by hastily killing the KSP process using Task Manager - but now and them, this fails. It's the reason I push S.A.V.E. to everybody. I must say this is not inherent to TweakScale, but to KSP itself. Anything borks a module, it became kaput and so any data from it is discarded by KSP on loading things. And then the artefacts are saved back without that data, and the aftermath is what you just saw on your rig. Fixing small craft files is not that hard. just resize the part - but complex crafts and living crafts on the Universe, unfortunately, it's not feasible (besides theoretically possible). Sorry! Edited June 7, 2020 by Lisias Kraken damned Autocompletes Quote Link to comment Share on other sites More sharing options...
SpaceFaringOrBust Posted June 7, 2020 Share Posted June 7, 2020 Ok Thank you for your help. I unfortunately didn't get to get my games back but at least the craft are there. Thank you again Quote Link to comment Share on other sites More sharing options...
moguy16 Posted June 8, 2020 Share Posted June 8, 2020 is there a wiki i can use to make my own tweakscale patches? On 6/6/2020 at 12:00 AM, Lisias said: Got it. And, boy, what a marvelous collection of FATALities we have here! Mortal Kombat is childish play near this! i actully didn't see this until now, but i had managed to solve it by deleting the extra gamedata and i remembered someone said having 5 module managers wasn't a good idea, so i deleted them just to be sure On 6/6/2020 at 12:00 AM, Lisias said: Additionally, install ZeroAVC. Really, MiniAVC is causing lots of troubles on KSP >= 1.8 and your instalment have some copied on it scattered on the folders. i will! i know avc can spam the log, but can it affect performence and loading times? thanks! Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 8, 2020 Author Share Posted June 8, 2020 6 hours ago, moguy16 said: is there a wiki i can use to make my own tweakscale patches? Yes. There's the canonical reference: https://github.com/sarbian/ModuleManager/wiki And there's my personal advices (TweakScale biased) here: http://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch 6 hours ago, moguy16 said: i actully didn't see this until now, but i had managed to solve it by deleting the extra gamedata and i remembered someone said having 5 module managers wasn't a good idea, so i deleted them just to be sure The problem is that the code that was electing the newest one broke last year with KSP 1.8, and nobody cared to fix or workaround the problem (assuming someone was even aware of it). Something on KSP or C#'s runtime decided to lie to us, faking loading any duplicated Assemblies while pinpoint it to the first one loaded instead - and this obliterated the solution. Weirdly, nobody cared to code a workaround - Module Manager already complains about a ancient Firespitter version, it would cost pretty little to deactivate the election code and issue a message box on KSP >= 1.8 when multiple Module Managers are loaded. 7 hours ago, moguy16 said: i will! i know avc can spam the log, but can it affect performence and loading times? It will waste a bit of memory and CPU, but the really bad problem is that sometimes it fails in a way that induces something else to fail (an idiosyncrasy on KSP internal guts, long story). 7 hours ago, moguy16 said: thanks! Welcome! Quote Link to comment Share on other sites More sharing options...
moguy16 Posted June 8, 2020 Share Posted June 8, 2020 2 minutes ago, Lisias said: Yes. There's the canonical reference: https://github.com/sarbian/ModuleManager/wiki And there's my personal advices (TweakScale biased) here: http://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch The problem is that the code that was electing the newest one broke last year with KSP 1.8, and nobody cared to fix or workaround the problem (assuming someone was even aware of it). Something on KSP or C#'s runtime decided to lie to us, faking loading any duplicated Assemblies while pinpoint it to the first one loaded instead - and this obliterated the solution. Weirdly, nobody cared to code a workaround - Module Manager already complains about a ancient Firespitter version, it would cost pretty little to deactivate the election code and issue a message box on KSP >= 1.8 when multiple Module Managers are loaded. It will waste a bit of memory and CPU, but the really bad problem is that sometimes it fails in a way that induces something else to fail (an idiosyncrasy on KSP internal guts, long story). Welcome! Thanks so much for answring all my questions! Quote Link to comment Share on other sites More sharing options...
AngryToddler Posted June 8, 2020 Share Posted June 8, 2020 (edited) [snip] Edited June 8, 2020 by Gargamel Giant wall of log text removed. Quote Link to comment Share on other sites More sharing options...
Azic Minar Posted June 8, 2020 Share Posted June 8, 2020 3 hours ago, moguy16 said: Thanks so much for answring all my questions! You are about to venture down the path of writing your own mods. First its going to be seeing which models will load for a new config file you copy and change just enough information for KSP to view it as a new part with some new differences. Maybe an engine that burns lithium and LF instead of LFO. But then you're going to get adventurous ... Its dangerous. And after a while, you'll come to have an opinion on tweak scale % scaling. Some people love it, others hate it. Welcome to the modding side. We mod our own cookies into KSP. (for the record, % scaling is the bane of my SAS) Quote Link to comment Share on other sites More sharing options...
Gargamel Posted June 8, 2020 Share Posted June 8, 2020 1 hour ago, AngryToddler said: [snip] Hey @AngryToddler welcome to the Forums! If you would like to share a log file with us, please host it on a site like google docs or dropbox and then link it. Posting Giant Walls of Text can mess up the forum display for some people on some devices. Thanks. Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 9, 2020 Author Share Posted June 9, 2020 (edited) 9 hours ago, Azic Minar said: Welcome to the modding side. We mod our own cookies into KSP. (for the record, % scaling is the bane of my SAS) What hinted me that I didn't proper answered that question!! (obfuscated a phrase that should probably be omitted) 20 hours ago, moguy16 said: is there a wiki i can use to make my own tweakscale patches? Let's try again! What follows is something that should be on that page I suggested above, but I ended up choosing to first finish my "TweakScale Companion Program" series and add to it the lessons learnt from the Program (and believe me, there're a lot!). But doesn't hurts to upfront some hints. There're basically two main "receipts" for a TweakScale patch: for a surface attached part, and for a stack attached part (there are some weirdos on the basket, but let's start with the basics). Surface attached parts usually have the format: @PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things { %MODULE[TweakScale] { type = free_square } } This is the free scaling (the % mentioned by Azic). You can freely scale down to ~3% (too small and things got rounded to zero on the physics engine, and Krakens feed on zeros inside the physics engine) to 400% (similar things happens above 400% - or at least, it used to happens in the past). Solar Panels, Radiators, Airbreakes parts are things in what you will, usually, apply this Receipt. When you scale Solar Panels, for example, the free type scales badly - while Radial Tanks should be scaled using a Cubic exponent (as you scale it on X, Y and Z and so , you change the total volume of the part), Solar Panels are thingies that you need to use a quadratic exponent, as the thing you want it to scale (the area used to catch light) has only two dimensions. In these situations, we use free_square as the type of the scaling. Wings also are something to use quadratic scaling (as we are scaling lifting surfaces, and a surface is an area!). So: you want to scale something in 3 dimensions (volume), you use free. you want to scale something in 2 dimensions (area), you use free_square. The other most common Receipt for scaling is for parts with stack attachment points. This one is a bit more tricky: @PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things { %MODULE[TweakScale] { type = stack defaultScale = 2.5 // or any other number, see text } } Stack parts on KSP have well defined diameters. Some parts are 1.25M wide, others 2.5M, etc. (At the end of this article I will list them for you.) So, we need to tell TweakScale the default (stock) size of the part, so TweakScale can infer how much it will scale something related to the well known "bulkhead sizes" on KSP. And I'm talking about bulkhead because, nowadays (and thanks God!), most parts have an information called bulkheadProfile that will tell us the profile of the part, making easier our job of defining the defaultScale for it. I need to tell you that it's pretty important to set this value right at first try, because once people starts to use that part, changing the defaultScale will distort all the crafts scaling it (as, as I said, the defaultScale is used to calculate how much TweakScale needs to scale something up or down to reach the next bulkheadProfile). This is my work in progress table of known bulkheadProfiles (incomplete, I'm still working on that tutorial): size0 = 0.625 size1 = 1.25 size1p5 = 1.875 size2 = 2.5 mk1 = 1.25 mk2 = 2.5 mk3 = 3.75 So, in a nutshell, if you find a size0 on the bulkheadProfile of that part, you shove a 0.625 on the defaultScale, and so on. If you find srf on the buldheadProfile, it's a hint that you should use the first Receipt above. Sometimes, a part have more than one profile, as the Adapters. When this happens, pick the greater one - it's a convention used by TweakScale patches, always use the bigger number as the defaultScale . Some few parts can be also attached radially (some fuel tanks, for example). These parts will have srf together other names. When this happens, use the largest one. Only use the "free Receipt" when there's only srf on the bulkheadProfile. Some examples from TweakScale stock patches for Squad, using the format: an excerpt of the original PART config followed by the TweakScale patch for the part: PART { name = HeatShield0 module = Part author = RoverDude yada yada yadaa bulkheadProfiles = size0 } this parts is scaled as follows: @PART[HeatShield0]:FOR[TweakScale] // Heat Shield (0.625m) { %MODULE[TweakScale] { type = stack_square defaultScale = 0.625 } } See the bulkhead profile? Since it's a size0, we need to use the second Receipt. And since when we scale a HeatShield we are scaling the amount of heat the shield can take (a surface), we use the free_square. PART { name = fuelTankSmallFlat module = Part author = RoverDude yada yada yada bulkheadProfiles = size1, srf } @PART[fuelTankSmallFlat]:FOR[TweakScale] // FL-T100 Fuel Tank KSP >= 1.5 { %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } This one is more interesting. See the bulkheadProfile ? It have srf and size1. So using the TweakScale convention of using the bigger profile (let's think of srf as zero), the defaultScale for it is 1.25. Since we are scaling a tank, those volume should be scale, the stack type is used (cubic). PART { name = adapterMk3-Mk2 module = Part author = Porkjet yada yada yada bulkheadProfiles = mk2, mk3, srf } @PART[adapterMk3-Mk2]:FOR[TweakScale] { %MODULE[TweakScale] { type = stack defaultScale = 3.75 } } This is the mk2 to mk3 fuel tank adapter. It's like the previous example, we just take the bigger profile, mk3 (3.75 on the defaultScale). Now, let's see a free typed Receipt: PART { name = ReleaseValve module = Part author = Squad yada yada yada bulkheadProfiles = srf } @PART[ReleaseValve]:FOR[TweakScale] // FTE-1 Drain Valve for KSP >= 1.9 { %MODULE[TweakScale] { type = free } } This one was tricky to define. Doing some research on hidraulics, I learnt that the capacity of the resource to be drained scales more alike cubicly, not quadratically - besides both options would be wrong on real life (it depends more on the pressure of the contained resource than only the size of the valve alone). So I took the "less wrong" approach. I think... These receipts will cover most parts on an Add'On. By using some clever receipts (called ScaleExponents inside TweakScale), most parts will have the Resources and Modules correctly scaled. But there are some Exceptions. Engines and decouplers the most notorious ones: @PART[LaunchEscapeSystem]:FOR[TweakScale] // Launch Escape System { #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } @PART[Decoupler_0]:FOR[TweakScale] { #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } The previous rules still applies, but you need to add that TWEAKSCALEBEHAVIOUR thingy to the patch when handling parts using stock engine modules, and stock decoupler modules. This is an instruction hinting TweakScale that this part is "uncommon", and it should use some extra instructions embedded on the "behaviour". For the sake of Curiosity, Firespitter modules demanded special behavirours . Custom ScaleExponents and Behaviours are something way more tricky than all of that, so let's left this for a next Opportunity. Feel free to ask for help every time you need! Cheers! Edited June 9, 2020 by Lisias Fixing a mistake on an exanple Quote Link to comment Share on other sites More sharing options...
Azic Minar Posted June 9, 2020 Share Posted June 9, 2020 @Lisias Its just a preference and nothing bad you've done at all. I like my rover wheels to have size scaling instead of % scaling. Makes it much easier to get a rover rolling right. Quote Link to comment Share on other sites More sharing options...
Lisias Posted June 9, 2020 Author Share Posted June 9, 2020 (edited) 14 minutes ago, Azic Minar said: @Lisias Its just a preference and nothing bad you've done at all. I like my rover wheels to have size scaling instead of % scaling. Makes it much easier to get a rover rolling right. I understood. But it was your comment that hinted me that I didn't propperly answered the guy! -- -- post edit -- -- Me too, by the way. But I didn't changed it because I would break savegames on the wild. With the Companion Program, however, we can have some degree of freedom to "reinvent the wheel" (pun not intended - kind of), as we can check for the presence of a hypothetical "TweakScale Companion Alternate Wheels Scaling" and block the loading of the savegame if it uses it! (yeah, future feature for TweakScale 2.5) Edited June 9, 2020 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
Azic Minar Posted June 9, 2020 Share Posted June 9, 2020 Just now, Lisias said: I understood. But it was your comment that hinted me that I didn't propperly answered the guy! Ohh, no! I did not mean that at all! I was just saying that this is the gateway to creating your own mods! You do a little, get adventurous and start doing more. Next thing you know, you are using Blender and what ever else to compile your own mods and put them up on here! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.