Lisias

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.

"Excuse me sir, do you have a moment to talk about S.A.V.E.?"

This is your weak point. You have a dispute between GPU and CPU for the RAM bus. Set the maximum FPS to 60. This will lessen a bit that dispute, and so you can raise something else a bit and get prettier (or less ugly!) Graphics.

Be careful. This will change the scaling rules of all already living crafts on the game at loading, and once this happens, it's essentially impossible to fix. Be absolutely sure to follow the TweakScale Companions protocol about changing things from Default TweakScale configs, use a :FOR for your patches to mark their existence for MM (so people can detect it to adapt). You had already nailed it, the use of the "type" defines the exponent to be used. KSP is primarily a game, with some concessions made to being a simulator. It's not the aim of KSP (at least 1) to mimic real life rockets and technological limitations. Some artistic compromises need to be made to keep the game enjoyable at first place, not realistic - this is not Orbiter. And this is the reason I refrain myself from changing already stablished patches even when it would make sense (as yours, apparently) - they were created after a lot of trial and error and ended up becoming canon - changing these values will break all current savegames on the planet (not to mention all the crafts published on Kerbal-X using TweakScale). Doesn't worths the cost. On the other hand, there's Realism Overhaul where the aim is to be the most realistic possible. I think they are your audience for these changes. -- -- -- post edit -- -- -- Going back to your idea, I have the following suggestion: create a new scaleType called "stack_realistic" or something, and then use it on the parts you want. This would satisfy your desires without breaking canon. Just remember that, once you decide to publish it, to follow the TweakScale Companion protocols to avoid stomping everybody else's toes.

Humm.... I checked your KSP.log again, and didn't found Scatterer, Kopernicus, EVE or anything that could be involved on this. However... Perhaps the problem would be on the exhaust or any other kind of emission? It's a wild guess, but try to uninstall Smoke Screen to see what happens. Dark secret of modding KSP: most of the time, we neither.

Deinstalling TweakScale would break flying crafts that have scaled parts for sure. That's the reason I push S.A.V.E. to be used by everyone - something breaks somewhere (and not only on TweakScale), and we risk KSP shoving bad data on flying crafts. But the pink squares is a new for me - TweakScale doesn't touches textures, it scales the mesh and let KSP handle the texturing.... The Sanity Checks are about parts with known problems, and that are deactivated. TweakScale warns you about the deactivation because someone wrote a patch to it, and so it's expected that such part would be scaled. That parts you mentioned are parts with VARIANTS with mass, a known problem still to be fixed by TweakScale - it's scheduled to be (AT LAST!) handled on TweakScale 2.4.4 series - assuming a new pandemic doesn't shove all my plans on the trash bin again.... Since these parts were never really supported in the past, this is not a FATALity (i.e., something that will break KSP). That pesky warning, FINALLY, now are only issued when Module Manager redo the patching (to tell you the true, TweakScale checks the timestamp of the MM caches and suppress Warnings and Advises if they are older than 1 hour). Now... That Houstons you got are the real deal - Something is usually really bad (or looks like being bad - TweakScale is not really smart to tell weird things from bad weird things, so it yells on anything weird). One weirdness that can be really problematic (but not always) is double patching, i.e., when a rogue patch patches an already patched part uncontrollably. Last time this happened on KIS was due me forgetting to remove a old file from the TweakScale distribution - and, yeah, you are using TweakScale 2.4.3.11 - the one I had borked! [LOG 15:53:19.127] [TweakScale] Version 2.4.3.11 /L <yada yada yada> [LOG 15:53:27.167] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] [LOG 15:53:29.643] Applying update TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] Please use the latest TweakScale, 2.4.3.15 . It's currently only on Github, CurseForge will be updated tonight and SpaceDock (and CKAN) tomorrow night. However, the current patches for KIS are EoL, they are old and do not scales most current KIS parts. TweakScale Companion for KIS will solve that, but currently this is still in Alpha status, so perhaps you should wait a bit as I didn't ironed out all the bugs of that thing (if any, the true is that I don't know if there're bugs on it yet!). In time, I found a lot of MiniAVC dlls on your instalment. MiniAVC was deprecated by the maintainer, and it's known to play havoc on KSP >= 1.8, sometimes in a pretty nasty way. Please install ZeroMiniAVC - really, install it, it's a question of time until something triggers a crash. Cheers!