Lisias

This week for sure. Is not on the wild right now due a formidable bork of someone (not me this time!) at work, and we are running 24x7 to diagnose and fix the problem.

It's due the log being called from another thread. As you said, it's like Swing - only the main thread can access the Widgets. I think it's am overlook from Unity, threading is going to be very important now that CPUs are doubling the cores instead of doubling the speed. Yes, there's. It's essentially what I'm doing, but in a smarter way. Stay tuned. invokeAndWait, however, is essentially squashing the thread to the main one - it will tax the main thread in a similar way as Co Routines would. Ideally, a invokeLater mechanism is more performatic. Halting the game I think it's a bit harsh, perhaps a popup dialog at the end of the process, showing a report of the whole process when the user is on a Scene where the popup would not interfere with the game? (opening a dialog when the user is executing a suicidal burn would render some compliments directed to your parents!) Yep, that's it. Your way is way simpler than the thing I'm implementing, but I think "my way" will be faster and more versatile. Now I have two more solutions to benchmark with my idea to see what will work better! Here, I fixed that for you.

Salutos! (Hehe, couldn't hold myself!) Something is double patching some parts. Publish the full KSP.log on dropbox, google drive or something and I will give a look to identif who is stomping toes this time. Recently I moved some configs on TweakScale, and since most people don't clear the old files on updating, KIS ended up double patched after the update (as the oldie KIS patch ended up lingering together the new one). If TweakScale was recently updated, completly remove TweakScale folder and then install it again and see if the problem is solved. If not, send me the KSP.log. Cheers!

Yes and no, it depends on how and where you want to implement the thing. On Career, you can use the TechTree. A minimalist walkthrough can be found here. Note: I didn't tested any of this. On the other hand, if you want to set hard limits for the scaling disregarding anything else. you can brute force your way replacing scaleFactors and incrementSlides on a part that uses stack or stack_square on the scaleType: @PART[LiquidEngineKE-1]:AFTER[TweakScale] // Kerbodyne KE-1 'Mastodon' Liquid Fuel Engine { %MODULE[TweakScale] { // type = stack - Only apply this to parts with stack or stack_square // defaultScale = 2.5 this part is originally sized 2.5 meters %scaleFactors = 2.5, 3.75, 5.0, 7.5, 10, 20 %incrementSlide = 0.05, 0.05, 0.1, 0.1, 0.2 %freeScale = false // Add this if you want to force the scales to 'snap' on a predetermined scaleFactor } } Now the Kerbodyne KE-1 will only scale upwards, and only on the predetermined scaleFactors unless you delete the %freeScale thingy. type = surface can also be restraint this way, but you need to use a normalised scaleFactor values (0.4, 1.0, 1.5, etc, where 1.0 is the "defaultScale"). type = free is the same, but it uses percentage instead of a normalised value (what I find kinda of weird the need for this, multiplying the normalised scale by 100 would accomplish the same on the User Interface - but whatever).

Not a problem. Everybody Borks And some people don't like the __LOCAL, you may be one of them, and this is perfectly fine. Just avoid changing things inside the "official" Add'On folders due the situations I described above and everything will work fine for everybody. YES! I managed to reproduce the problem! This is what I got after installing ReStock on an already ongoing savegame (with the rogue module and without the workaround): MODULE { name = TweakScale isEnabled = True currentScale = 1 defaultScale = 1 defaultTransformScale = (0, 0, 0) DryCost = 888 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section. isEnabled = True currentScale = 1.53999996 defaultScale = 1 defaultTransformScale = (1, 1, 1) DryCost = 3243.20996 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } This is my worst nightmare, a perfectly valid and working Module Section being ruled out because something shoved a different one ahead of it, and then everything else started to use it instead of that previous, good one. We would not had detected this without my Rogue Stunt, and in the past I'm pretty sure TweakScale took the blame for the problem in the past - nobody would diagnose it at that time. The only way to fix this mess is to manually remove all instances of the first, defaulted TweakScale module sections and then rename the Rogue ones back - what's pretty unfeasible on a big savegame. On my testbed, not only the defaultScale was changed to (0,0,0) (what results on some "interesting" renderings on code that relies on this thing being different than Zero), but also it descaled the part. And suddenly descaled parts became suddenly weaker, and weaker parts blows up when suddenly have to withhold de load that a a bigger, stronger one was withholding. (sigh). I still don't know why this happens, and so I don't know how to work around it. But at least now I know WHAT is happening. Unfortunately, my only advice for now is take a deep breath and try to ignore the annoying messages about the missing TweakScaleDuplicatedRogue module on loading things. Trying to fix this, now, on your savegame is leading to worst results. I need to read and understand ReStock source code in order to understand what's happening to make a proper fix first - what will take a bit, because I have a ton of tasks (not only on TweakScale, but on RL too) to carry on and I already spent too much time on this issue. I don't know how in hell Kerbals manage to do something useful on 6 hours days, I need at least 32 on my ones. Feel free to kick me here (or anywhere else) in 3 or 4 days for this issue if I stay silent that much - as I have a somewhat big backlog of things to do, I frequently end up forgetting a thing or two - but rest assured, I want to solve this one in a way or another. I don't take easily savegame corruptions! -- -- POST EDIT -- -- I think I need to update the message on the SFS file. This is not safely ignorable anymore, there're situations in which ignoring it is worse. Oh well... We learnt something new today.

Yeap... I borked on that one. Somehow, I leaked a double patch on the Knes-Launcher_TweakScale.cfg file when I pulled a request to Knes. Well, i fixed and just submit a new pull request. It should be available soon, but if you are in a hurry, download this file (click on Raw Button) and replace the one on your Knes/GameData/Knes/Compatibility/Tweakscale/ folder. Nothing new. The only difference on your config cache and mine is depicted below: Mine: MODULE { name = ModulePartInfo originalPartName = SYdecouplerRadial1 } MODULE { name = TweakScale type = surface } MODULE { name = TweakScale type = surface HOTFIX = https%3A%2F%2Fforum.kerbalspaceprogram.com%2Findex.php%3F%2Ftopic%2F179030-ksp-141-tweakscale-under-lisias-management-24315-2020-0622%2F%26do%3DfindComment%26comment%3D3812504 } yours: MODULE { name = TweakScale type = surface } MODULE { name = TweakScale type = surface } It's not something on the patching mechanism, it's code on runtime. Well, that ruled out all my suspects but one, ReStock - it's the only thing on your GameData that I think can cause this problem on the texture. I'm downloading the latest ReStock to give it a try, I will come back to you soon. @HDSpanky, I don't advise creating custom patches inside TweakScale main folder (as well on any other Add'On). Completely removing the previous version of TweakScale before applying the new version is the current recommendation (not only from me, but from a lot of Add'On maintainers), and by doing this you risk deleting your customisations on updates. I push GameData/__LOCAL/TweakScale/Workarounds because __LOCAL is pretty easy to locate on GameData using Windows Explorer, Finder or even the Midnight Commander tool I use - it's always the first or the last entry on an ordered list. But anything will do as long you correctly use :AFTER, :BEFORE, :FIRST, :LAST or :FINAL. Some people like zzz_PERSONAL-PATCHES or something. Just don't shove custom patches inside Add'Ons folders. This force you to remember things while updating Add'Ons when doing manual updates, as well tricks CKAN to keep the Add'On folder alive when deinstalling the thing, fooling everybody on believing the Add'On are still installed and failing patches that relies on :AFTER, :BEFORE, :FIRST, :LAST or :FINAL.

Yep, that stunt is my fault. Exactly. And this was precisely the reason I came to that stunt. TweakScale is still one of that not so nice Add'Ons using :FINAL on some things (because I can't take out, yet, TweakScale from the LEGACY phase as it would break some very used add'ons, and I didn't had the time to apply pull requests for everybody!), but yet I still need a standard place for users put their hotfixes and overrules to keep their games going while rogue patches are not fixed on the mainstream. Since some Add'Ons (including TweakScale, but this will change soon! promise!) are using :FINAL, by shoving the user's patches on __LOCAL would put their :FINAL patches after any other :FINAL patch. However.... And this is where my stunt failed. Internally, I think Unity changes "_" to "." on ordering as it does on part names., and so suddenly __LOCAL would be ordered as ..LOCAL , and my stunt didn't fully worked as intended. However, and aware that some Add'Ons are publishing directories starting with "zzz", I decided to keep using "__LOCAL" as it is easier to be located by the users: it would be always on the last or on the first position on the Explorer/Finder/MidnightCommander file list. MM is innocent on this one. MM fetches the patches from the GameDatabase, after KSP had loaded all of them into memory, when MM scans the GameDatabase looking for the patches to be applied. All your patches from __LOCAL ends up being applied first because all my patches I publish to be shoved there uses :FINAL, and fortunately fewer and fewer Add'Ons are still using :FINAL on their patches.

I think I have a suspect, but I want to get more information before saying what I have in mind. Please send me ModuleManager.ConfigCache on your GameData, I want to compare its values with what I found on your craft.

Yep. I confirm the problem. I don't know yet if TweakScale is failing on unregistering itself from the OnShipModified event list (and if yes, why it was working before?) when its part dies, or if something changed on the PartModule's life cycle (intentionally or by accidente) on KSP 1.10. I will work on it tomorrow. Thanks for the report! -- -- -- post edit -- -- -- Uh... I borked on that. This will be fixed on the next TweakScale release. https://github.com/net-lisias-ksp/TweakScale/issues/119

Check if the 999_Scale_Redist.dll is on the GameData, if not, manually install it. You are not the first to complain about this, and the last one haven't the file on the place (and also used CKAN). [forget that, just check it - it's there!] Ignore this. It's something to fix indeed, but it's on the very end of the priority list. -- POST EDIT - Apparently, things started to go through the tubes on mk2LanderCabin.v2 : [LOG 17:09:12.432] Adding default item(s) into seat's 0 inventory of part [Part:mk2LanderCabin.v2 (id=C4293790632)]: KIS.electricScrewdriver,KIS.evapropellant [LOG 17:09:12.433] Adding default item(s) into seat's 1 inventory of part [Part:mk2LanderCabin.v2 (id=C4293790632)]: KIS.electricScrewdriver,KIS.evapropellant [ERR 17:09:12.436] Exception handling event onEditorShipModified in class TweakScale:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour.get_enabled(UnityEngine.Behaviour) at TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) [0x00000] in <c3d11dd12519438cafd8dbec2a0a0668>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c168e21ec56346b082f89043e76162e1>:0 <yada yada yada> [LOG 17:09:12.596] [AttitudeAdjuster] Initialized for mk2LanderCabin.v2 [ERR 17:09:12.611] Exception handling event onEditorShipModified in class TweakScale:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour.get_enabled(UnityEngine.Behaviour) at TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) [0x00000] in <c3d11dd12519438cafd8dbec2a0a0668>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c168e21ec56346b082f89043e76162e1>:0 <yada yada yada> [LOG 17:09:30.425] Adding default item(s) into seat's 0 inventory of part [Part:mk2LanderCabin.v2 (id=C4293786244)]: KIS.electricScrewdriver,KIS.evapropellant [LOG 17:09:30.426] Adding default item(s) into seat's 1 inventory of part [Part:mk2LanderCabin.v2 (id=C4293786244)]: KIS.electricScrewdriver,KIS.evapropellant [ERR 17:09:30.428] Exception handling event onEditorShipModified in class TweakScale:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour.get_enabled(UnityEngine.Behaviour) at TweakScale.TweakScale.OnEditorShipModified (ShipConstruct ship) [0x00000] in <c3d11dd12519438cafd8dbec2a0a0668>:0 at EventData`1[T].Fire (T data) [0x000b0] in <c168e21ec56346b082f89043e76162e1>:0 I'm working on it.

I made Valentina to climb a tree on KSP 1.10 Don't ask... I'm still trying to figure it out - I just looked to the other side for a few minutes and when I came back to her, I found this.

Now I need you new KSP.log to try to understand what's happening. I moved the conversation to TweakScale's thread to avoid cluttering Kopernicus one. (original post here). I second that!

Oukey, this calms me down. A problem I understand is a problem I can fix. The previous situation, on the other hand, was baffling me. =P Right now, it's the only remaining option. Publish your current KSP.log and I will try to hunt it. Also, install ModRocketSysLite just to see what happens. Welcome to the KSP Modding Club. Take a nice chair, you are going to stay around for some time.

Kinda of, but not too much. Souptime is using TweakScale 2.4.3.11, a previous version that wasn't aware yet of a new behaviour on KSP 1.8 and KSP 1.9 while loading Part Modules: on KSP <= 1.7.3, removing the Module section from the prefab before launching a savegame would prevent the Module from being loaded on memory, but on 1.8 <= KSP < 1.10 (1.10 still in tests, not officially supported by TweakScale yet) the Modules are loaded anyway at the same conditions. This borked TweakScale because it inspects every single parts for show stoppers conditions and remove itself from parts that are not supported and were patched anyway - the removing mechanism stop working on 1.8.0 and TweakScale start to bork on that deactivated parts because KSP was starting it on them nevertheless, something that TweakScale never had to cope before. @Souptime, please install the latest TweakScale (2.4.3.15 at this time). Please note that on KSP 1.9.x, you also need to install KSP-Recall due a glitch on the Editor on handling Resources - unless you are using Interstellar Fuel Switch (as you are), that are imune to the problem by handling Resources its own way, overruling any Editor changes (what's kinda what KSP-Recall does for parts using KSP standard Resources management). Cheers!

Weird. CKAN fetches the ZIPfile from SpaceDock, and I just downloaded the SpaceDock file and the DLLs are there... Things also appears to be fine on the ckan file. Don't have a clue. Things are working here, and I don't have more reports of this misbehaviour. I just downloaded the SpaceDock's latest TweakScale zipfile, and it's all there. The ckan file also looks alright. Perhaps we have a misunderstanding? Would you be talking about 999_Scale_Redist.dll ? This file is on the zip alright, and the ckan is instructed to copy it into the right place: "install": [ { "file": "GameData/999_Scale_Redist.dll", "install_to": "GameData" }, { "file": "GameData/TweakScale", "install_to": "GameData" } ], Until this moment, I didn't found Recall being necessary, the workaround Recall implements is not needed anymore on KSP 1.10 - at least, I'm not using it on my 1.10 test bed and no misbehaviour were detected yet (but, I have pretty little time to play KSP on working days, so perhaps I just didn't tested enough). Also note that TweakScale, besides apparently working fine on my machine, is not yet "homologated" to be used on KSP 1.10 - and TweakScale 2.4.3.15 will pesky you remembering you about it every time. I'm currently testing 1.10 and if I don't find anything serious, I will publish a new TweakScale version in the Weekend. I think I need to see your KSP.log in order to have a clue about what's happening.

Humm. Interesting. I tested it before publishing the stunt... Humm... I think I downloaded the wrong Add'On then? You see, there's an Add"On called ModRocketSysLite and it is double patching the very same parts... (hacking into your KSP log) Yeah. Working late night can be dangerous, by plain lack of luck, Google should had given me ModRocketSysLite when I typed ModRocketSys and I just didn't paid enough attention. Found it here. Oh well... Look on the bright side: you are learning your way on patching : you detected and fixed a mistake of mine! Yes, it worked. I forgot to mention that you will still get the TweakScaleRogue stunt on crafts and savegames already saved, but once you save them again the HotFix will prevent the new crafts to have the Rogue TweakScale section, and by then the problem is solved. However... THAT is something new... I just removed a deactivated copy of the TweakScale section on the GameDatabase - and so, TweakScale didn't found anymore a second copy of it on the part, and so it didn't deactivated it by brute force on saving crafts and savegames. I made this way because, as you probably is getting aware, if someone install a new Add'On those name come first on the alphabetical order, and this Add'On rogue patches an already in use part, then the SECOND COPY of TweakScale would be the one that should be preserved. Doing the way I did at least allows me to manually fix a savegame by removing the first copy and reactivating the second one (and this is just one more reason to use S.A.V.E.!). However... What you describes is something completely... Awkward. Removing all copies TweakScale support and then shoving back the first one (that is the one your game was using) should not cause this breakage - unless there's something else changing it and I didn't caught it - it was late night, and I already missed an detail, so I can be did missed another one. You would accomplish by "hardware" what the HotFix does by "software". Essentially: ModRocketSys (Lite or not) applies a 'hard' patch for TweakScale on two parts from SpaceY SpaceY correctly applies a 'hard patch' on these two parts again Correctly because it owns that parts - the owner applies a 'hard' patch, everybody else applies 'soft' patches. The HotFix deletes the previous two patches, and reapply a hard patch mimicking the one ModRocketSys applied And the aftermath is that you have a "sane" GameDatabase where the "rogue patch infection" is not spreaded anymore on crafts and savegames - what would be the exact result you will get by manually deleting one of the copies of the patches. The HotFix aims to allow you a sane GameDatabase without having to edit third parties patches (what would be nullified on each Add'On update). Of course, it worths a try (really, make backups of everything). But I can foresee two possible results: you edit the patch, things explodes the same, and we end up confused about the reason of the explosion you edit the patch, things work fine, and we ended up confused about the reason the HotFix (allegedly) caused the explosion Allegedly because something else could had happened by coincidence (or by side effect), and perhaps we have a new problem do diagnose! In a way or another, I'm giving a second look on your case. I'm puzzled about it, there's something else happening where I can't see. -- -- -- POST EDIT -- -- -- I think I found something.... This is the patch for SYejectatron on Space-Y: @PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron { MODULE { name = TweakScale type = surface } } And this is the patch for it on ModRocketSys (Lite or not): @PART[SYejectatron]:NEEDS[TweakScale] // super-sized sepratron { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } MODULE { name = TweakScale type = surface } } And that behaviour changes something - only the mass exponent, but changes something. It still doesn't explains the textures being blown up, however. I updated the hotfix to cope with that, by the way. I'm still working on it.

Today, I decided to revisit a test I made on KSP 1.9. Yeah, the hydrofoil ship that took off into the skies. If you followed my previous attempt on 1.9.1, you already know I was pretty disappointed by the results at that time. But KSP 1.10 fixed a lot of things, and the performance improvements are yet greater, so (of course) it worths a new shot. --------------- So I launched the very same vessels from my last attempt (download links on the last slide), cheated by way into the water and hit the thrusters. One thing that I noticed is that the message Physics easing in progress just didn't disappeared, as it does when I place the vessel on the ground. It's a glitch to be aware of, as the next slide will demonstrate. And yessss, the thingy took off. Note the lack of drag, by the way. Oukey, I thought, back to 1.7.3 so... But then I reconsidered due that Physics easing message. This stunt is not there just because, right? And if the glitch was not in the physics engine as I thought, but on the Easing itself? (I just reviewed my last attempt on 1.9.1 just to be sure, and there's no Physics easing message there - but the behaviour are curiously similar!) So I installed Vessel Mover and gave it a try. Vessel Mover is an old friend. Nothing to add about. Yeah. Famous last words. The Place Vessel's Place Vessel didn't worked as intended on this vessel, when the vessel touched the water the rear hydrofoils were ripped off and throw into orbit, as it appears... Of course, dropping the vessel didn't did better. But I found a solution - pretty obvious, to tell the true. Use the Fine option from Vessel Mover (hit TAB) and place it carefully on the water yourself! And then hit Drop Vessel (the Place Vessel explodes the rear hydrofoils the same). SUCCESS I have successfully moved the vessel into water without triggering the Physics Easing bug neither exploding her! Vessel Mover needs to be updated, as it appears. I just remembered this happened too on KSP 1.9 (and probably happens too on KSP 1.8). But a working around exists, so this is not a show stopper. Let's proceed! AND YESS, BABY!! We are surfing the Kerbin Seas at >65 M/sec! Things had changed, but now they changed into something compatible to the behaviour on KSP 1.7.3. The speed is slightly lower, and it's slightly harder to correctly make the vessel to "take off" without loosing balance and diving the nose on the water, turning over. Do you now what? I like more this way - the whole point of doing this stunts is by the challenge of doing and using them. Wee need"accidents" on the game to keep it challenging, otherwise it would be just another casual game to be played while waiting kids and wife to get ready for dinner. I'll redo all my previous testings on KSP 1.8 and 1.9 (including the ones I published here) to see what I get, but I think that at least some of my KSP 1.7.3 gaming can now migrate to get better graphics and, above all, way better performance! I'm happy with this successful test session. Really happy. Things look promising. The vessels are still the very same, you can download them from the last slide of my last attempt.

Welcome! It's not that hard, after some months working on it. The hard part is the start, but once you find yourself on that jungle, things snap in on your head and everything become easier. It's annoying, but that's all. (Potentially) Bad things fires up a "Houston". There's a colour code on TweakScale warnings: Red (the "Houstons"): dude, you may have problems. Cry for help here, TweakScale will prompt you to close KSP (but you can override it). Yellow : things that you are not going to like, but it's harmless (as unsupported parts having TweakScale uninstalled). White : things you need to remember. Every time Module Manager redoes the patch's cache, the Yellow and White ones will be issued while loading KSP until the cache is 1 hour old, and then they will not bother you anymore - until you change something and Module Manager redo the cache again. Done! I wrote it on the post above to keep the explanation and the solution on a single post (useful to people that finds it using the Search function - as me, as I usually forgot things and need to search my own thread for information!! ). Cheers!

NOTAM I did a very minimalist smoke test on KSP 1.10 and TweakScale 2.4.3.15 (clicking on Cancel on the Houston). Apparently TweakScale 2.4.3.15 is working fine, and KSP-Recall appears to be not needed on 1.10. In a way or another, this was a preliminary test - there're a lot of things I want to test first before lifting the Houston for KSP 1.10 - if you decide to try it, please, pretty please, make backups of everything! My findings on the matter will be published on TweakScale's Issue #115: https://github.com/net-lisias-ksp/TweakScale/issues/115 -- -- -- post edit -- -- -- Clicking ok Ok closes the game by design. It's not a bug. I did this way because people usually just clicks on OK without reading, and Houstons were made to prevent people from running a potentially problematic game without being aware of the problem.

NOTAM I did a very minimalist smoke test on KSP 1.10 and TweakScale 2.4.3.15 (clicking on Cancel on the Houston). Apparently TweakScale 2.4.3.15 is working fine, and KSP-Recall appears to be not needed on 1.10. In a way or another, this was a preliminary test - there're a lot of things I want to test first before lifting the Houston for KSP 1.10 - if you decide to try it, please, pretty please, make backups of everything! My findings on the matter will be published on TweakScale's Issue #115: https://github.com/net-lisias-ksp/TweakScale/issues/115 -- -- -- post edit -- -- -- Clicking ok Ok closes the game by design. It's not a bug. I did this way because people usually just clicks on OK without reading, and Houstons were made to prevent people from running a potentially problematic game without being aware of the problem.

999_Scale_Redist must be placed on GameData/ (on the same place as ModuleManager.dll). CKAN TweakScale's netkan should be doing that for you: "install" : [ { "file" : "GameData/999_Scale_Redist.dll", "install_to" : "GameData" }, { That insane lag usually is about exceptions being thrown on the KSP.log. If the problem was caused by the lack of the DLL, shoving it on the right place must have this solved. KSP Recall doesn't acts on Flight, only on Editor. Due the way I intercept the OnVesselModified editor's event, yeah... Some lag theoretically can be introducing some lag while editing a huge craft as yours. But once the thing is launched, nope - Once Recall restores the part Resources on Launch, it's done and have nothing more to do. Post the KSP.log for a session where the lag is hurting so I can check what's happening.

That's where we have to disagree again. I want you to have a fork and try to prove me wrong. It's how we discover things. I just think it's premature to talk about adoption it on Forum.

On your machine. There're people using shared memory GPUs, spinning disks and lower clocked CPUs. And I had some reports of somewhat more powered machines having to lower the FPS to 60 to prevent crashes inside the Unity. Again, the project is not abandoned yet. I think it's premature to assume it's dead in the water.

Whoa.... Your craft have 144 Rogue TweakScale sections! (from the 752 Parts used). Gosh. First, the good news: this is annoying, but right now is not dangerous. Nothing bad will happens. BUT Your kind of rogue patching is the dangerous one, both sections have different receipts! Look what I have for SYdecouplerRadial1_4290221204 : MODULE { name = TweakScale isEnabled = True currentScale = 2 defaultScale = 1 defaultTransformScale = (1, 1, 1) DryCost = 7104 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section. isEnabled = True currentScale = 1 defaultScale = 1 defaultTransformScale = (0, 0, 0) DryCost = 888 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } currentScale , defaultTransformScale and DryCost are different between the the used and the rogue section. This means that if we 'fix" the patch that patched it first (let's suppose a toe stomping patch from an Add'On those name starts with "S" - they are patched earlier than TweakScake ones on the LEGACY pathing phase), all your crafts and savegame will be corrupted, like this: Do you see why I code these pesky warnings now? On the bright side, after running a report on your log file, it ends up that only two parts are, effectively, being rogue patched - so it just happened that you used that parts a lot. macmini62:1 lisias$ cat KSP.log | grep -oP "Duplicate TweakScale .+\[(.+)\]" | sort -u Duplicate TweakScale module on part [SYdecouplerRadial1] Duplicate TweakScale module on part [SYejectatron] This make things way easier. This is the patching for the SYdecouplerRadial1 : [LOG 23:15:54.232] Applying update ModRocketSys/Patches/MRS_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:15:54.564] Applying update SpaceY-Lifters/Patches/0_TechTree/@PART[SY*]:NEEDS[!CommunityTechTree&!HPTechTree] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:15:54.612] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYdecouplerRadial1]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:02.889] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:02.983] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEngines]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] [LOG 23:16:03.180] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SpaceY-Lifters/Parts/Decouplers/SYdecouplerRadial/SYdecouplerRadial1.cfg/PART[SYdecouplerRadial1] From this report, I learn that SYdecouplerRadial1 is a part from SpaceY Lifters. And that this fine Add'On has its own TweakScale patches (there're no embedded support for them on TweakScale). However, the ModRocketSys Add'On also patches this part - and this is where things get hairy as they are being applied before the canonical ones from the SpaceY. Messy. Since no one of the involved Add'Ons have git public repositories, I will need to download them to eyeball the patches - what I cannot do right now on working time. I will go back to this issue later, don't worry. Right now, DO NOTHING. I will code a custom HOTFIX to you in order to have this sorted out for you, and then I will see what can be done to solve the problem for everybody on the Add'On themselves. Stay tuned! @renejant, here is your HotFix. Download this file (click on the Raw button!) or copy and paste the contents of this box into notepad or some other text editor: @PART[SYdecouplerRadial1,SYejectatron]:NEEDS[SpaceY-Lifters,ModRocketSysLite]:FINAL // Space-Y Radial Decoupler, regular { -MODULE[TweakScale],* { } %MODULE[TweakScale]:NEEDS[TweakScale] { type = surface HOTFIX = https%3A%2F%2Fforum.kerbalspaceprogram.com%2Findex.php%3F%2Ftopic%2F179030-ksp-141-tweakscale-under-lisias-management-24315-2020-0622%2F%26do%3DfindComment%26comment%3D3812504 } } Save the file on somewhere inside your GamData I strongly suggest GameData/__LOCAL/TweakScale/HotFixes , so it's easy to keep track of any hotfixes and to get rid of them when needed. Essentially, this patch deletes any TweakScale support from the affected parts and install a fresh copy, based on the SpaceY-Lifters (identical to the rogue patch on ModRocketSysLite). This will fix your issue, but there's one caveat: if anyone else repatches that part, even by following every good practice, this patch will obliterate any change and brute force that one instead. Ideally, this should be removed from your instalment as soon as ModRocktSysLite is fixed so you don't have to keep remembering about it. Cheers!

IMHO, these ones are not improvements. We will need to agree on disagree on this. Co Routines inserts themselves on the critical path of the Game Engine, threads can be set to use only the sparing time of the CPU (not to mention better using CPUs with a lot of cores/hyper-threads). Nereid had committed something on his repo 3 or 4 days ago, so the upstream is still alive. I will implement the fix suggested by @micha and apply a push request.