Lisias

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.

Yes! You found it! And... UGH. It's worse than I though - it's the other way around! This patch is changing every TweakScale part those name starts with an "K" to stack. Problem: it ignores the defaultScale! So parts that where free are being patched with stack without a defaultScale! So the ScaleType's default one is used instead, what's not always what you would want... Mainly on a free type that uses Percentage for scale, and suddenly have an absolute metric value (1.25 M would be used as 1.25 % - way below the bottom threshold of 3% on TweakScale, by the way). Well, open a ticket to that Add'On's maintainer and ask him to fix this. You just saw what this can do. (be aware that by fixing this, your crafts will be broken again...)

More or less. The vsync "syncs" the current refresh with the vertical sync of the monitor. Nowadays with LCDs, the "vertical sync" term sounds like awkward, it's like more "refresh", but ends up doing the same: the videocard waits until the monitor has finished refreshing the current screen before sending the next frame to avoid sending it at the middle of the process, what ends up with you having part of the screen with the previous frame and part with the new one for some time. On fast pacing animations you perceive the line that divides the two images, and this is annoying. If you are using 60 fps, your GPU will wait for the vsync 60 times per second. If you are using 120 fps, the GPU will wait for the vsync 120 times per second. it worths to mention that not all monitors support a very high refresh rate - mine, by example, goes up to 75Hz. Using 120 fps on my monitor is not only a waste, but a source of additional delays because the GPU would waste a bit time every frame trying to sync with an completely different refresh rate. 120 / 75 = 1.6 , i.e., the GPU ends up waiting for a frame 60% of every second frame. So I configured both KSP and the GPU to use 60Hertz for maximum performance - the GPU wastes almost no time waiting for the vsync, and Unity have to call the drawing methods "only" 60 times per second, with the rest of the game earning more time to do some computations between two frames.

The problem is happening when something wrong happens inside the thread while doing the backup, as a file not found, lack of privileges to read or write directories, etc. It's an error handler. When you are logging only on KSP.log, no problems, things work fine. But when you activate logging on the screen, the windows process crashes because Unity's UI thread cannot access data from another thread. On MacOS the thread just dies, and you can't shutdown the game normaly probably because the master thread tries to join a thread that's already dead. On Windows, unsurprisingly , it's sudden death for the whole process. Then easy solution is just to do not log Exceptions on the Screen. The proper solution is a special logging system that accepts logs from any thread and controllablily injects it on the UI thread (as we do on Java Swing!).

It's not a problem on TweakScale. You have a rogue patch somewhere shoving twice the whole TweakScale config section. TweakScale detects this situation, and once it's deterministic that only the first one is used, the dupes are marked as such to prevent breakage later. Publish the full KSP.log and a craft file with the rogueduplicate and I will locate the rogue patch for you. With that information, you can reach the Add'On maintainer or, if he/she is not reachable, we can try a HOTFIX. Usually, the full KSP.log is needed for diagnosis. But on this case, I already know what's happening - you unzipped the new TweakScale version over an old one, with an old file that was deprecated still there. Completely delete the TweakScale folder and install the latest again and you will be fine!

What doesn't means that I may not had borked somewhere. However, from about 16 parts, KNES now have 188 parts (last time I counted, new parts were introduced while I was working on the patches!) - so I think we have something else on the equation. There're about 170 parts that were not being scaled, they can't be broken now. Unless... The original patches were tweakscaling only about 16 or 17 parts - there're more than a hundred and a half more parts being scaled now. I think it's somewhat improbable that every legacy craft is borking because of that 16 ones - mainly because they were not wrong, I kept the same defaultScale and scale type for these ones (or at least, I intended to do so, I will double check them just in case). What I think it's happening is that, now, the "canon" TweakScale patches on Knes takes precedence above others - so I'm guessing that you had installed previously some other Add'On or custom patches that were shoving "free" scale type on every part, and now that Knes have proper patches, the crafts suddenly had the parts using a receipt - and the older values didn't coped with the new receipt. I would need to check your KSP.log before you applied the new patches, and a new one after, so I can see what's happening. But if it happened to you, it may happens to other people too. So if you could send me a KSP.log without the new TweakScale patches I will be grateful!

Try to deactivate logging Exceptions and Errors on the Screen. On the settings.cfg, make sure the following options are set to False LOG_ERRORS_TO_SCREEN = False LOG_EXCEPTIONS_TO_SCREEN = False I think this will "solve" the issue, but didn't tested on a Windows machine. Linux and MacOS don't crash on these stunts, Windows does - but, granted, my KSP hangs on quitting and I need to kill -9 it. By deactivating that options, all messages are logged fine and KSP keeps going as nothing had happened. With the options off: [EXC 13:28:01.445] FileNotFoundException: Fake exception. Nereid.SAVE.BackupSet.CreateBackup (System.Boolean preRestore) (at <f5cc573fbecf4c83a65192d6588fac6e>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) KSPe.Util.Log.UnityLogDecorator:UnityEngine.ILogHandler.LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) KSPe.Util.Log.UnityLogger:logException(String, Exception) KSPe.Util.Log.Logger:error(Exception, String, Object[]) Nereid.SAVE.Log:error(Exception, String, Object[]) Nereid.SAVE.BackupSet:CreateBackup(Boolean) Nereid.SAVE.BackupJob:CreateBackup() Nereid.SAVE.BackupJob:Backup() Nereid.SAVE.BackupManager:BackupWork() System.Threading.ThreadHelper:ThreadStart() With the options on, that last log entry is never logged. My guess is that the Exception that would be serialised to be displayed on the screen is out of bounds for the Unity UI thread (different threads, different stacks and perhaps different memory pools), the thing ends up with an invalid pointer (for that context) and BADABOOM. I have some cases of Unity abuses that breaks up Windows processes, but passes through on MacOS (Unity was born on MacOS, after all). Deactivating the Threads will impact the game play when automatic background backups kick in, as they will be run on the Unity's main thread, mainly when using compression. So I think that deactivating that options would be better for the end users, as many of them don't have exactly a top notch rig for playing.

Yeah.... The 80s....

What you are getting is something slightly different. It's not a fix, it's a workaround to keep you playing - but it worths the try: On the Main Menu, Settings, Graphics, Set the Frame Rate Limit to 60 fps. The hard part on all of this is to try to replicate the problem here on my machine - once I manage to do that, I will have something to sniff on.

Already answered above - but I prefer to state KSP Recall as a dependency of KSP to have TweakScale running. The problem is on a glitch on KSP 1.9 Editor, not on TweakScale (or any other Add'On that changes resources). Search for "KSP-Recall", it's the identifier for it on the NetKan file. Absolutely not, unless you don't mind scaling up Tanks without being able to scale the Resources. A LFO fuel tank would be bigger and heavier, but still have the same amount of Liquid Fuel and Oxidiser as the unscaled part. TweakScale will not stop you from running KSP, but you are not going to get good results by doing that - and once you install KSP-Recall later, the crafts already launched will suddenly be scaled as they should, and this can imbalance your designs.

Hey, excellent material. You followed the instructions to the letter, thank you! Now let's crack this nut: [LOG 11:58:09.201] [TweakScale] INFO: WriteDryCost Concluded : 902 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1 Show Stoppers found; 9 Sanity Check failed; 410 unscalable parts. Not that bad, only one FATALity: [LOG 11:58:09.142] [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (#loc_BDArmory_part_bdWarheadSmall_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 There's a rogue patch somewhere double patching this part. Since TweakScale is not smart enough to tell weird things from bad weird things, it yells on anything weird. Let's the the patching: [LOG 2020-06-28 11:55:57.689] Applying update BDArmory/MMPatches/BDArmory_TweakScale /@PART[bdWarheadSmall] to BDArmory/Parts/smallWarhead/part.cfg/PART [LOG 2020-06-28 11:55:57.689] Applying update BDArmory/MMPatches/BDA_TweakScale/@PART[bdWarheadSmall] to BDArmory/Parts/smallWarhead/part.cfg/PART [LOG 2020-06-28 11:56:01.194] Applying update BDArmory/Localization/part_deformatter/@PART[bdWarheadSmall]:FINAL to BDArmory/Parts/smallWarhead/part.cfg/PART And a rogue patching we have. There's two possibilities: the BDArmory maintainers forgot to delete an oldie or moved patch and ended up publishing the patch twice. they renamed the file and when you installed the new revision over the older, you ended up with two copies to that file (the current, and an oldie). This happened on TweakScale 2.4.3.11 too, by the way (with the KIS patches). It's usually a best practice to completely delete the older install of the Add'On before installing the new version, but some Add'Ons saves user configurations and other customisations there and by doing that, you end up losing them - so It's best to check with the BDArmory guys how the best procedures for it. For TweakScale, you can delete the older version without thinking twice. I'm assuming you are using the latest BDArmory and checked the github repo to see if I find any oldie there (and so, saving some time for everybody on the diagnosing), and no, there's not trace of the file BDArmory_TweakScale.cfg there. So I think it's the second option. Delete BDArmory/MMPatches/BDArmory_TweakScale.cfg and you will be fine. Cheers!

Because there's no patch available to it yet. Follow the TweakScale Companion Program thread. New patches are being published there - since there's already interest on it, I will kick Kerbal Atomics ahead on the queue. Hi. I need the full KSP.log, otherwise I can't help. The information I need to check what's happening is there. See this post about how to publish the needed files.

With a hell of a machine like that, I really doubt your problem is the GPU or VRAM. Let's try a trouble shooting. Create a completely new (and disposable) savegame. 1) Fly a pretty simple craft - 5 parts maximum. Check how things are going. 2) Fly a part with about 100 parts minimum. Check how things are going. If the number 1 is laggy already, then you had abused the EVE settings to a whole new level or you have something borking relentlessly on your system. Some Add'Ons can bork on a pretty special place called Update (or, worst, on the FixedUpdated) that are code that runs a really lot of times per second. If something goes wrong on that code, a error message is logged on the KSP.log file - and having this file being written tens or even hundred times a second can put the best of the computers crying on its knees. Check the size of the KSP.log, when this happens you have a really huge file (hundreds of megabytes, once I reached 1G). If the item 1 runs OK, and the 2 goes bad, try a 50 part craft and compare it with the option 1 and 2. This will help me to guess what's going on (different Add'Ons induces heavy computations in different ways - if you don't feel a difference between 50 and 100 parts, then it's probably something related to the simulator itself. If 50 feels better than 100, then it's probably too much add'ons installed, and you will need to profile them to choose who will leave). Do you have some sparing paper tissue to loan?

On a personal opinion, I would prefer a 4GB GPU card if you are willing to shove the newer Add'Ons with the new shining textures. These beasts are eating a lot of VRAM (not only RAM), and since the VRAM needs to feed not only the textures, but also the framebuffer for the video mode (usually two or three framebuffers, to allow smooth animation), you will find that 2GB will be not enough - when this happens, the videodriver usually allocates some RAM to act as texture RAM, and we have that dispute between GPU and CPU on the RAM bus again (but, granted, a bit less harsh). By the same reason, you will probably enjoy having 16G RAM on the machine too - on KSP, textures are loaded into CPU memory anyway, and fed into the GPU's VRAM on demand.