Lisias

So, yeah, you are right about the Particles on the lamps being the trigger. However, I was wrong about a using an older D3D being a possible workaround. I tried to download the logs for inspection, however... I will try again tomorrow. In a way or another, I think we will need to use Harmony to deactivate the Lamp's flickering. Don't know how it will cope with Forum rules about reverse engineering however...

Oukey, I managed to fool Murphy and got time to play a bit. I replicated @Commodore_32's installment, copied the settings.cfg file over mine, started KSP and created a new sandbox game, fire it up and gone straight to VAB. No TLAs. @Commodore_32's machine is beefier than mine, but @GuessingEveryDay's one is a bit near. At least three years newer, but performance are kinda near. He uses a Intel G4400, while I'm using an i7-3615QM one. Besides my i7 having a slower clock, it can turbo up to 3.3GHz by deviating some cores - but the cores still have hyperthreading, so I expect my CPU being a bit faster than him on multitasking - but not on raw power on a single thread. He have better bus speeds, so the overall performance should not be too much different on KSP. His graphics card is a Intel HD 510, while mine is an HD 4000. Surprisingly, my GPU is sensibly faster than him besides pretty older- so the test looked promising! More or less what I was guessing - a faster GPU choking up the CPU. But... No TLAs on VAB neither SPH. (sigh) Commodore_32' said the TLA is happening too when using OpenGL, that it's my only option on MacOS - so we already had ruled out this one. So the difference must be on the GPU, and so I started digging specs. My GPU, due it's age, still use OpenGL 4.0 and, on Windows, DirectX 11.1 GuessingEveryDay's GPU, on the other hand, uses OpenGL 4.6 and DirectX 12! Hummm.. Commodore_32's GPU is an Radeon R4 mobile, more similar to mine than to GuessingEveryDay's GPU on raw power. BUT... It also uses OpenGL 4.6 or DirectX 12! So the guess has teeth, I may be right on it. So I reread this thread looking for hints, and realized something: I don't have sparks on VAB/SPH's lights when the lights flicker! It's a new guess - as always, an educated one , but still a guess: I'm not getting problems on Particles because my GPU handles particles on DirectX 11/OpenGL 4.0. If I'm right, there's something on DirectX12/OpenGL 4.6 that's triggering the problem on Unity. So I dug a bit more, and remembered that KSP uses Unity 2019.2.2f1 since 1.8 (if they updated to a new version, it's not mentioned on the Version History). And digging yet a bit more, I found this entry on the 2019.3.0f6 Release Notes : And on 2019.3.0b8: Both releases newer than the one KSP uses. Of course I'm not absolutely sure about any of that, but it fits. So, and assuming I'm right, the only real fix is to update Unity 2019 to at least 3.0f6. What we need to do now is find a work around for this problem. I have a hunch that KSP is getting some heat due that Stop Action thingy, it appears to fit it crashing on VAB/SPH, as light's sparking appears to allow culling. So... new test: Start KSP forcing d3d11 with -force-d3d11 . Or even -force-d3d9.

Me? Expert? I'm only a smart SAS with some pretty good guesses! @SQUAD are the experts on this here - problem, the more you know about, more possibilities you find - what we are doing here what you are doing here is narrowing down that sea of possibilities in order to make easier (or less hard!) the heavy lifting @SQUAD need to do to nail down this Kraken Damned <insert your favorite non forum compliant compliment here> bug! I'm downloading the settings.cfg. I will take some time (RL job, I'm late on a task...), but I will try your settings for sure - yet this week, unless some crazy dude decides to change something on production again without testing it on QAS (or at least warning me, damnit! ). Hummm... Not exactly a powerful GPU. My guessing need some "refactoring". I was thinking a "too much" powerful GPU would be stomping the CPU's toes by doing things faster than the CPU can feed it. On the bright side, I'm using a Intel Graphics too (MacMini 6,2), so it's feasible I can reproduce the thing here too - unless we are facing something DirectX related crisis...

What's puzzles me is this thing happening on the VAB. I doubt it has something to do with Particles by now. Publish the settings.cfg too, I want to force my KSP 1.10.1 to behave like yours to see what happens!

Announce TweakScale Companion for Near Future was updated with fixes and patches revision. Please note that you will need the absolutely latest TweakScale 2.5 Beta or the (hopefully) near 2.4.4.0 otherwise ongoing savegames will be probably corrupted, as only the newer TS versions know how to overcome the KSP "automatic updating" that was rendering TS's scaling fixes useless. Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obvious, but now and then a bug leaks - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! @AlmightyR, I think you will be interested on this one. As long you only start new savegames using it, you can ignore the Show Stopper on startup (delete the DLL, if you want - it only serves this purpose). Please do not resume ongoing savegames that had NF parts with TweakScale with it until I manage to release 2.4.4.0 ! -- -- -- ANNOUNCE EDIT -- -- -- A bork was detected on the 0.0.4.0 release. 0.0.4.1 was issued with the fix. Ping @AccidentalDisassembly

Right click, and Zip the whole shebang. This will also garantee integrity. Do it while dinning - this can take a while! Then move the zip file to somewhere safe ("My Documents" or similar) Better not. Copy and pasting the whole directory is better than mangling with Steam. You should be doing that anyway, only playing with a "off steam" copy of KSP to prevent tragedies due updates. But having a zipped copy of the whole thing, besides taking a bit of time, it's safer as the zip will calculate checksums and you will be absolutely sure the thing is exactly what it was. Opening a issue on the bugtrack, and then pesking Squad team members to check this thread! It's the other way around - they will tell you what to do to help them! With a perfect copy of an installment where the TLA is deterministically activated and deactivated? BY ALL MEANS, YES! You have the Holy Grail of the almost impossible hard bugs to diagnose, you have a working test bed for the bug!

You did a great help here: you pinpointed the problem to something on Unity or KSP without any doubt. DirectX and OpenGL are pretty different engines, they would not give us the very same bug - you ruled out a device driver (direct) bug - it may be something triggered by it, but not something on it. You also kinda ruled out the Particles as inherent part of the problem. They are just one of the triggers (if that), whatever is killing the game with a TLA, it's something that also happens on the Editor Scene too. I'm updating my guesses to Lights and/or Reflection. Or shadows... Create carefully a new backup with the current blowing game (so you have a solid way to create new test beds for this problem!). I think you should try to contact Squad now, as you have an invaluable debugging artifact for them and they are the ones that really (should) know what happens on the scenes. In the mean time, and using a backup , and without meddling with the frame rate, and if you are on the mood (obviously!) try to reduce the Pixel Light Count, the Shadow Cascades or the size of the reflection thingy on the Graphics Setting to see if anything different happens...

The only way to know if something is ready is kicking the damned thing through the door and wait. If people starts to complain, it was not ready. If people does not complain, you are out of business.

Check the KSP.log for all messages with the string [TweakScale] WARNING: . It will tell you what part borked being checked, and why. With that information you can start digging what happened by following the patching process or looking for exceptions when loading the part.

The Companions "behave", I try very hard to avoid blindly patch things. But I can control things only to a certain extend - in the bottom line, a chain is so strong as its weakest point... Supporting directly RO is unfeasible to me. I barelly manage to suppor stock! Not so ideally, RO could target the patches against the Companion itself using :AFTER[TweakScaleCompanion_NF_NFxxx] (where xx is A, C, LV, etc). So they would make use of any adjstments the Companion does (including any cleaning up), but this is a decision up to them. "Not so ideally" because that stunt of mine on triangular dependencies would had avoided the whole mess at first place! I will. The problem on defining deadlines is that Murphy is omnipresent and omniconscious - 45 minutes after I posted, Hell broke loose on job!

"Great" Try openGL and se if anything changes! I will check the log by the morning!

Exactly what I was thinking. MODULE { name = TweakScale type = RealismOverhaulStackHollow_Adapter_Halved type = stack defaultScale = 1.25 } There's no fix for this, because authors around here just don't agree on some basic coexistence (proposed) best practices, as the current ones just don't work - as you can see. (and I even made a proof of concept here). The TweakScale Companion currently "solves" the problem by bluntly removing every existent TweakScale module for the part being applied (if existent), using my owns instead. So, perhaps, the problem will be "fixed" on the next Companion for NF release (as I think this is a new part from the NF series and I'm revising the current patches to include any novelties). I wrote fix between quotes because I'm bluntly forcing my way into the problem, as there's nothing more I can do about. However, this will make your parts working the TweakScale way, not the RO way - assuming RO patch is happening before TweakScale Companion one. If the patch is happening after the Companion, then RO is problematic as they should remove the current TweakScale patch before applying their own (or at least use "%" to prevent double patching the same TweakScale node, as it happened to you). The best I can do is to update the TweakScale Companion for NF to check for any new parts, then I will advise you. But if by some reason the new release of the Companion "fix" the problem for you, this means that you are using the Companion rules for scaling, not RO's one. In a way or another, perhaps you should consider removing the Companion for NF from your instalment and ask RO guys to provide the missing patches for the parts you want.

Nah, it's more a UI problem than human problem - the current UI makes complicated computer things easy to do, but also makes easy computer things almost impossible to do. Moving files around are "complicated", you need to move one by one, make sure the timestamps are the same, check if there're not something with the same name on the target, etc. This is where the UI makes things really easy. Making sure you are moving the damn thing to the right place it's a easy thing to do, but the UI makes it extremely hard to check because the thing just executes the action on the spot (and I'm assuming your mouse's mechanical switch is reliable - you don't have the slightest idea the havoc a misfunctional switch can play), and it's hard to find the new copy on a cluttered window full of names. TL;DR: Current UI designers are clowns that don't really know how to use computers, neither interview users to see what they really need. Got it. This appears to be something new... I look into one of the parts affected, and got this huuuge patching process: I already have a hunch about how to work around RO on this (I will update then TweakScale Companion with it), but while I work on this, can you send me the MM ConfigCache for inspection? It may help me to pinpoint the really culprit of the mess, as currently there're too much patches meddling with these parts and I would like to save some time before digging on it. In a way or another, expect a new release for the TweakScale Compantion for NF for today - I can't fix other people's mispatches, but I can work around them on the Companion. Hi. These happens due bad patching - when misbehaving patches are applied, rendering the GameDatabase unsafe for TweakScale. I will look on the KSP.log as long you authorise me to access it. Hi! I just found your post today - the Forum delay on approving the first message an hurt sometimes... In a way or another, I got it: [LOG 21:25:40.256] [TweakScale] ERROR: **FATAL** Part Thoroughbred (SRB-25-060 "Thoroughbred" Solid Fuel Booster (12m)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:25:40.257] [TweakScale] ERROR: **FATAL** Part Clydesdale (SRB-25-123 "Clydesdale" Solid Fuel Booster (22m)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:25:40.258] [TweakScale] ERROR: **FATAL** Part Shrimp (SRB-06-07 "Shrimp" Solid Fuel Booster (4m)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:25:40.258] [TweakScale] ERROR: **FATAL** Part Mite (SRB-06-03 "Mite" Solid Fuel Booster (1.8m)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:25:40.277] [TweakScale] ERROR: **FATAL** Part rocketNoseConeSize4 (AN-50 Protective Rocket Nose Cone Mk16A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 21:25:40.277] [TweakScale] ERROR: **FATAL** Part Size.1.5.Cone (AN-18 Protective Rocket Nosecone Mk5A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 These one is already known: [LOG 21:21:47.735] Applying update AllYAll/ModuleManager/AllYAll/@PART[*]:HAS[@MODULE[ModuleEngines]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:21:48.284] Applying update AnimatedAttachment/AnimatedAttachment/@PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[AnimatedAttachment] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:21:49.336] Applying update KerbalKrashSystem/Configs/KerbalKrashSystem_Engine/@PART[*]:HAS[!MODULE[ModuleKerbalKrashSystem_Exclude],@MODULE[ModuleEngine*]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:21:53.333] Applying update TweakScale/patches/Squad/Squad_Engines/@PART[Thoroughbred] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:21:54.148] Applying update ReStock/Patches/Engine/restock-engines-srb-25/@PART[Thoroughbred]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:21:56.780] Applying update KerbalKrashSystem/Plugins/KKS-mods/KerbalKrashSystem_Repair/Configs/KerbalKrashSystem_Repair/@PART[*]:HAS[!MODULE[ModuleKerbalKrashSystem_Exclude],@MODULE[ModuleKerbalKrash*]]:AFTER[KerbalKrashSystem] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] <here!> [LOG 21:21:57.511] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] </here!> [LOG 21:22:01.449] Applying update BetterBurnTime/SRBurnTime/@PART[*]:HAS[@RESOURCE[SolidFuel],@MODULE[ModuleEnginesFX]:HAS[@PROPELLANT[SolidFuel]]]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:22:01.938] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 21:22:02.717] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] Remove BladeTweaks and everything will be fine! -- -- -- -- Cheers to all

Microsoft now owns Github and Bethesda. Right now it's Sony who's getting their balls kicked, but... Tomorrow? How this will affect the Open Source Add'Ons scene?

Hi! Got it. [LOG 01:05:42.286] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container1 (SC-62 Portable Container). [LOG 01:05:42.286] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Portable Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 01:05:42.286] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container2 (ILC-18k Container). [LOG 01:05:42.286] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 01:05:42.287] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container3 (ISC-6K Container). [LOG 01:05:42.287] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Container) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Yep, known issue. What's happening is that you forgot to completely clean up the older TweakScale folder before installing the new version - and since some things are changing on TweakScale, by doing that you ended up with some oldies left polluting the instalment: [LOG 01:01:52.195] Applying update TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] [LOG 01:01:52.789] Applying update TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1] to KIS/Parts/container1/part.cfg/PART[KIS_Container1] Completely delete the TweakScale folder and reinstall it from scratch and you will be fine! Cheers!

I was (re)reading the Unity documentation, and I just realised that I misunderstood the vsync. When you activate the vsync, the FPS is ignored - and, frankly, I don't know how in hell I could had missed this detail. Just for the piece peace of mind, turn off the V-Sync option ("Don't Sync") and keep cranked up the Frame Limit. If this doesn't trigger the TLA on you, then definitively the Particles are not he culprit for this. And, by the way, magnificent screenshot!

You have Bluedog installed twice on your rig... [LOG 15:30:24.206] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] [LOG 15:30:24.210] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] <yada yada yada> [LOG 15:30:29.962] Applying update Gamedata/Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] [LOG 15:30:29.966] Applying update Gamedata/Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA] You unzipped Bluedog on <KSP_ROOT>, but also on <KSP_ROOT>/GameData , and so everything is duplicated. Remove the Bluedog from the KSP_ROOT (the folder where your .EXE is), and everything should be ok. Cheers!

I don't know, but you may had found something new. Perhaps the thing is related to something on DirectX, not OpenGL. And since MacOS runs under OpenGL, it may be the reason I never managed to get something like this here. New test - configure your KSP like the last time you got that TLA. Try to get the TLA, and once you manage to get one, change to OpenGL and try again. The hard part is getting a TLA intentionally, apparently...

I think that we need to find a "sweet" spot where the GPU is rendering faster than the CPU can feed it - it's what I am thinking is happening with the TLAs, pretty damn good GPUs running over not up to the task CPUs. Try it again lowering the textures to the minimum bearable, as well lowering the rendering quality (so the 3D engine use less vertices on the mesh). But keep everything else up. The intention is to overload the CPU while speeding up the GPU, to see if this really is the problem on the TLA - particles is a good educated guess, but at this moment it's still only a guess. We manage to artificially and deterministically reproduce the TLA, the Squad guys will have something solid to start debugging on to fix it on the next versions, and we have a starting point to find a (or confirm an already existing) workaround to be used on the current and previous ones.

So, what do you think of a TweakScale Companion for USI? Doing this way, both of us would get rid of a headache - you, by not maintaining an artefact you don't want to know about and don't use, and me by removing an unrelated artefact from TweakScale. Any heat is taken by the Companion itself, and it's the Companion's maintainer problem (being this guy that other me, not me). From your side, just tell people to talk to this guy on anything related to TweakScale and you are set. The Companions are designed to cope with legacy.

Ei, @yeyehboi, I think you will like this one!

Could not decided if I post this here or not, so I flipped a coin. Kraken damned coin, I say - this is its fault. Open the spoiler at your own risk.

KSP specifics, if any on this case, will be handled by KSP-Recall. Every single Add'On I lay my dirty claws on is aimed to work on every KSP version still in use. Sometimes I win, some times I loose - but I really try hard.

In the 80s, the read/write heads were way.bigger than nowadays. And so more prone to the inertia. At that time, we were still using MFM and RLL technologies, not too diferent from what was used on floppies by the way. With the software having direct access to the step motors and solenoids, yes, it's feasible to abuse the mechanism by stepping the motors faster than the design allowed, stressing the heads' mounting and leading them to crash into the platter. Nowadays every HD has its own CPU for doing this - hard disks are essentially specialized computers atached to a host using some kind of network. But at that time, the hardware was fully exposed to the userland. The even older MSX computers had a design flaw that allowed the PPI (a peripheral control chip) to be programed in a way that it could short-circuit itself and burn, rendering the machine without access to joysticks and the keyboard. And yes, they wrote virus for it. And yes, that PPI chip was expensive.

Yes, it was. Not a problem on asking for it. I ask myself for them too! The problem is lack of time for proper testing. The Robotics introduces a lot of new Modules that I do not fully understand yet, and need time toying them to see what happens. I have a video made from the times I was toying with the wheels, so you can see how deep the rabbit's hole goes: And even when I manage to make the damn thing to work, surprises are always well hidden somewhere, waiting to bite you in the SAS. These things are not exactly 'show stoppers', are just problems to be solved. But this demands time, and if you are following TweakScale development, time is a very scarce commodity lately due an avalanche of not directly related problems I need to solve in order to do my job. I have a road map for TweakScale here. Serenity is planned to be tackled down on 2.4.4.1 (2.4.4.0 is what I'm working now, and it will be focused on Variants)