Lisias

METAR The problem described below was solved. Right now I'm playing a bit with KSP to see if I find something, or if something else had a regression due the stunt (hopefully not, as the latests refactoring allows me to keep support for different KSPs sandboxed, preventing exactly that a fix on one would bork the others). Then I will attend some Real Life™ demands and, a bit later, I will try to fix some known issue more to stuff up the next Release that I will publish today night (or tomorrow early morning) on GitHub for the early adopters. — — — POST EDIT — — — Sometimes, you just can't win. I'm going back to bed, I will sleep the rest of the day. (had I not taking some medicine due the teeth, I would be getting wasted right now - Geez, what a week!)

People are getting fed up with the constant KSP and Add'Ons bugs and regressions, and this is perfectly understandable - because I too have my moments of fury about the matter. Some problems related to CC came to my attention due my experience on 3rd parties borks affecting TweakScale, that so ends up with me handling the mess, and my diggings suggest that there's something else borking somewhere else, breaking the chain of execution of initialisation code that, so, leaves a some data uninitialised - that so leads to 3rd parties to bork, potentially leaving yet more data uninitialised - and so on. We removed CC from the affected KSP installment only to see the same problems blowing up with someone else. I'm trying to help to pinpoint what's exactly going on on the matter on github with @Alexsys and another fellow add'on Author. As soon as we manage to tackle it down, I'm pretty sure things will going to be better after a Pull Request to the add'on's repository that triggered the NRE Fest. Assuming it's a 3rd party Add'On, this can be related to something on KSP itself (as usually happens to TweakScale, by the way).

Rush, Tom Sawyer - #unforgettable.

Publish your KSP.log on dropbox or something and I will inspect it for the problem! (wow… 4 minutes of SLA… a record!)

METAR Further testing suggests that the OnCopy code is behaving as expected. What's happening is that, apparently, something is resetting the attached part's position using the prefab's value after calling OnCopy (damnit!!), undoing part of the job OnCopy did. My current RiP (Research In Progress) is to determine if my thesis is right, and how to redo again the job after that Kraken damned code undid what OnCopy did.

For the sake of completude and transparency, last night I detected we have two problems stacked up! One it's this one you described. By some reason I still trying to figure out, when OnCopying a part (the code that handles the Alt+Click thingy), the part itself is correctly duplicated, but the parts attached to it is "reset" to the original place of its attachment node. "Great, let's reapply the code that scaled the attachment nodes and we are done!", right? Well, nope . If you detached the wrongly placed part, you will find that all attachment nodes are on the right place. And if you reattach the part, it will be placed correctly. This means that the attachment points are fine (otherwise the part would attach wrongly again). This one is the one that it's bitting my SAS on this moment. The other stacked problem is some stupidity I did when merging branches - a single line of code was removed that was restoring the scalings when you apply the subassembly in mirror mode - the original subassembly works, the copies didn't. This line was placed back, on the weekend I will release the fix. In time, all these problems only affect parts with Variants, so this is the Variant code on KSP overruling TweakScale on some borderline situations. It's not exactly a bug on TweakScale, but a change on the running environment. But still… Thanks! It will be a small program to be run on the system itself, without KSP on the circuit. In time, do you know if your NTFS filesystem has the case sensitivity activated?

Found the problem. The attachment nodes are being reset when you apply a Variant after scaling the part! [Nope! The attachments nodes are fine, it's the part that was being reset to the wrong place! See the METAR below!] Issue: https://github.com/net-lisias-ksp/TweakScale/issues/219 I will try to have this fixed for the WeekEnd, but I can't make any promises on it - it's more likely I will be able to work on it on the WeekEnd, and so the fix will be published by Sunday night or something.

1/10 You are a extraterrestrial still trying to learn our culture. You should had learnt by now that there's no such thing called "intellect" around here.

TweakableEverything is completely unrelated to the current TweakScale (apparently they were tied in the past, but that was before my tenure). About the Companions, some of them have a hard dependency on the very same KSPe.Light. So they will bork the same - I don't play Microsoft on my "products", I don't promote DLL Hell by spreading duplicated dependencies everywhere. Having a dependency borking on you is extremely annoying, as you are seeing. On the bright side, once I detect the problem and fix it, EVERTYTHING ELSE gets fixed at the same time - and this is the reason we do DLLs. May I ask your assistance? I will need to run some small programs on your rig in order to detect what's going on. Once I build them (the source will be available on github), could you - please - download them, run them and send me the results? I hope I will have something by tomorrow night (I would like today by night, but I will probably not be able).

(sigh) So it must be something on the code itself. I need to figure out exactly what changed on Windows, because this was working when I wrote it. It was tested on the field by people that were helping me with the matter at that time. Since I didn't changed that code since them, it must be something on Windows that had changed. (sigh) Are you using the most recent release, 2.4.6.4? I reverted the KSPe.Light to the previous version. If even by reverting it, you are still getting this error, I will need to compile a special KSPe.Light for you in order to get it working, as it appears…

About this one, I made further tests and I could not reproduce it neither. Initially I thought it could be the recently fixed #208 resurrected, but it's working fine from 1.3.0 to 1.12.2 (yep, I do such tests). So, and assuming you are not using a old TweakScale version (it was fixed on 2.4.6.2), I will need your craft file and KSP.log in order to pursue this issue.

Publish your KSP.log on dropbox or something, and I will inspect it to see what's happening. Acknowledged. But I will need some crafts with the problems described. Preliminary tests suggests the nodes are being scaled correctly. Also, please note that the nodes visual cues has only 3 sizes, and any value between two of these sizes sizes are "snapped" to the nearest existent size. It's a game engine limitation, nothing I can do about - at least, under Forum rules. But the BreakingForce and the BreakingTorque are being scaled, and these are the values used by the physics engine. On the example below, the central tank is on default scale. The second to to the left was scaled to 1.875 and the next to the left was scaled to 2.5. Note that only the 2.5 one had the attachment note visual cue scaled, because there's no intermediary value available between 1.875 and 2.5. The same for the 5M scale, aggravated by the fact that there's not a fourth size - so once the attachment node reaches size 3, everything bigger will have this size and that's it. The right tanks were created by ALT_Click the left ones (i.e., using the OnCopy method). I could not reproduce your issue with the OnCopy handler (the Alt+Click thingy). It's always working for me. Craft file and SFS on this post on Issue track. Additionally, please remember that Stock KSP has bugs that hinders TweakScale and a lot of add'ons more. You need to have KSP-Recall installed, or some features (from TweakScale and also some other add'ons) will not work as expected - alternativelly, you can install a new alternative available on GitHub that appears to make things in a more straightforward (and clean) way, but since apparently Forum Rules doesn't allows add'ons with some of the techniques used, I prefer to do not mention it here - but once you use it and find something that may be related to a KSP bug, you will need to ask that Add'On maintainer for guidelines, as I can only give support for KSP-Recall. Additionally, until recently the node size limitation used to be tackled down by Kerbal Joint Reinforcement. It's my opinion that you are complaining about a KSP issue on the wrong Thread. This is perfectly possible. I need feed back in order to identify these borderline situations, because it's impossible to any author identity and correct every single one of them - at least, without breaking some Forum Rules. Perfectly understandable. If you read my last post, you will find similar complains, wrote on a similar mood under a similar state of mind. And I'm the author of the damned thing. And this is exactly what's happening, sir. At least on TweakScale. Please read the CHANGE LOG and also, the ROAD MAP. And the milestones, you can influence the order I will tackle down these ones. Looks like a known problem. I don't know if this is a new behaviour for this issue, or if it's a new problem at it own right - but when you "invert" the the part on a chain (i.e, you attach the bottom side of a part on the bottom side of the other), TweakScale misbehaves while calculating the part displacements. It's this way since forever, but by some reason it passed unnoticed all these years. It was only recently that I became aware of this specific misbehaviour. A easy way to reproduce it is to take a fuel tank (anyone), then take another one and attached it inverted (bottom to bottom), then attach a third one. Activate Chain Scale, and then scale up the root part. You will find a similar problem as depictured on your screenshot. For now, the only workaround until I have time to dig into this one is to do not "invert" parts while stacking them up - at least, if you want to scale them. Sorry for that. [nope, the #208 is not back from the dead. It's something else.] About *THIS*, I think it may be related to Issue #215 that I just closed for the latest Release (already available on GitHub, and finding its way into the other Distribution Channels). And it is, PRECISELY, the motivator for my bitter rant on the post I mentioned.

Oukey. So now we are in uncharted territory. There's one more situation I'm aware that may be causing this crash, once it's stablished that it's not a problem with your GPU. Weaker CPUs are known to starve the GPUs on KSP, and when this happens the game crash (exactly why I don't know, but we can presume it's a bug on handling empty task queues or something). In a way or another, there's something we can try to break the current CPU/GPU power play, exploiting yet another bug on Unity that it's known to slow down CPUs (and more cores the CPU have, more it is dragged by the bug). Open a CMD.exe, and type cd <the place where your KSP is installed> set MONO_THREADS_PER_CPU=1 KSP.exe (I don't have a Windows machine around, so I hope I made it right - it's a long time since the last time I booted a Windows machine). This trick will fool the Unity, telling it to use only one thread per CPU - and since some of these threads are the cause of the CPU being dragged, less threads will have less draggers, and so the CPU will work better. Think that each thread is a rower, and each CPU is a row of rowers on a greek trirreme. The Unity bug is like placing some of the rowers rowing backwards - the less rowers doing that, the less worst, and this is what that command above does. If I'm right (and this is a loooong shot!), by having less threads screwing up, the CPU will have more time to keep the GPU fed up, and so this may help to prevent the situation in which the GPU crashes (assuming the other long shot of mine about the reason the GPU is crashing, of course).

ANNOUNCE Release 2.4.6.4 is available for downloading, with the following changes: Turns off by default (and makes hard to activate) the StealthSave due a (another) bug related to the Upgrade Pipeline. Reverts the KSPe.Light.TweakScale to the previous release due a excrementsstorm apparently related to borked Kernel32.dll on some systems See OP for the links. Notes This is one of the bitter releases I ever made. The UpgradePipeline has bitten me in the SAS again, reopening old wounds. One of the worst and most problematic problems I had on TweakScale in the past (and that was the trigger for a lot of nasty problems, as "scaling" parts to 0 mass) was exactly this Kraken damned feature, as it was injecting back into parts prefab information overwriting the current info on the section of the part being loaded. So, a perfectly sane craft (or savegame) became mangled (or corrupted, depending of the severity of the mess on the prefab) on load if an update on your rig renders problematic. This thingy also prevented TweakScale from migrating scalings when the default scale for a part changed on the prefab, as the UpgradePipeline was acting before TweakScale could try to fix it and so, the old values needed to recalculate the new scalings were lost. So the need to be incredibly picky to the point of risking being obnoxious to avoid anything even slightly weird on the patching. This crap took me more than a year to be tackled down, what happened on Issue #137 and was published on Release 2.4.4.0. [addendum] Besides being incredibly mad by this problem, originally I liked the feature after I learnt how to live with it - it intended to allow us to update KSP and Add'Ons to newer bug free releases, what would be an improvement over the past M.O. where you was locked down on a set of versions (including KSP) for the duration of the savegame. So, besides the immense trouble the UpgradePipeline gave me in the past, I had welcomed it once I understood what it was doing and why. In the end, I concluded it had worth the pain. One of the reasons I'm incredibly mad with the stunt now is, PRECISELY, I'm being happy with it until recently - as it would theoretically open some pretty nice possibilities not only to updating broken things without breaking more things, but also on Module management as I was trying to do with the StealthSave. Had I never seen any value on it, I would be way less angry now. [/addendum] And now, due a combination of yet another bug on the thingy and a old bad design decision that weren't correctly reworked, the StealthSave feature for TweakScale is from now on deactivated - with the express recommendation to be not activated unless you really want to push your luck on the matter, what apparently I did with success the whole year as the problem I will describe now never hit me in the whole time I was using it. And this is the problem: some PartModules are installed more then once on the Part, being the ModuleEngineFX one of them: when you have multimode engines (as a turbofan with afterburner), each engine mode has its own ModuleEngineFX, and another module called MultiModeEngine manages the situation. However, this creates a problem: how to univocally identify a PartModule on this mess? How about an UUID for each module? Or perhaps adding a hash to the name, like is done with the parts inside a craft? Nah, let's use the index of the damned Module on the array in memory and call it a day, what could possibly go wrong, right? Well, by using the index of the PartModule, what happens is that YOU CAN'T UPDATE ANYTHING ON THE PREFAB without risking screwing up the savegames. You add an add'on, you remove an add'on, you UPDATE an existing add'on with something new, you even update KSP itself, and you may change the index of some PartModule and so, you are prone to the problem described on the Issue #215 . Essentially, updating things is playing Russian Roulette with your savegames. Simple like that. It's not possible to overstate my displeasing (Forum Rules forbids me to express myself correctly) about this situation - not because I'm deactivating a nice-to-have but definitively non-essential feature, but because this means that for the last 2 3.5 years, since KSP 1.4.0, every single one of us shouldn't had update anything once a savegame is initiated. The whole UpgradePipeline stunt is near useless, what also means that all my work related to it was wasted. Not being bitter enough, some pretty old stupidity from Windows is still alive and kicking nowadays. For some reasons I'm still working on, some Windows rigs are missing a system file called Kernel32.dll. There's no other option but to fix the system using DISM (after trying a stunt or another in the hope of avoiding it). Full information here. So, until I cook a way to detect this problem and avoid letting the blame fall on TweakScale, I'm rollbacking the KSPe.Light.TweakScale for the previous version - that also has the need for Kernel32.dll on Windows, but since it handles less borderline situations, the incidence of the problem is near nill . Of course this will cause some borderline situations on Windows to pass through, triggering false alarms on some users. But I have to be pragmatic on this, I do not work for Microsoft after all: I'm choosing the less traumatic path on the short run, as I have RL™ duties to carry on at the same time. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

What doesn't means that everything else will be fine. This kernel32.dll stunt is plaguing Windows users for years, as it appears. Intel, Unreal Engine, VS Code users… You name it.

You too? I'm pretty "liquified" because I had to spend some serious money on a minimally reasonable machine for professional work - so the damned thing need to be small (to do not clutter the desk), reasonably decent and still be power eficient, as this thing will be on the whole day and I can't afford a new refrigerator style power hungry device. My current professional machine is starting to get too old, and it almost died on me this week - can't take the risk on relying only on it anymore. It will be demoted as backup machine soon. Problem - everything at hand around here are cheap, and crappy, or reasonably good and costing me the price of a side by side fridge. As long as I don't try to add a GPU card, situation in which the damned thing starts to cost more than a second hand car. So I ordered components from half the World, in the hope they are delivered yet this year. Meno Male, I'm paying half the price of the "cheaper" useable device I found here for a twice more powerful machine. But I'm still "liquified" because I spent the Xmas' money on the freaking thing. (sigh). I will have to submit myself to a UHD 630 APU. And I need to thankful to manage to get at least this crap - GPU prices are insane around here, a crappy GTX 1030 is costing the same as a entry level computer. I could buy a freaking professional Workstation with smoking Quadro last year by the price they are asking by a GTX 3060. I almost had a heart attach when I checked the price for a 3090. — — — And, just to make things even "better"… I had to extract 3 teeth today. This is what the last year pandemics taxed me, I was on the middle on a dental treatment when this crap blowed up the Civilisation as we knew it. Besides the fact itself and the pain, I had to spend some more serious money on this (I hope the health insurance will cover it, I just contracted it)

I opened the damned thing, and that's what matters!

So even by installing 2.4.6.2's KSPe.Light.TweakScale, or by rollbacking entirely to 2.4.6.2, the issue is still present? well… In a way or another, I just found information that clears TweakScale from the problem. Kernel32.dll is part of the Windows Operating System, and it's not being available is a problem on Windows that need to be corrected. Kernel32 provides Win32 File System File Management Functions for both Win32 and Win64 programs, and it's needed to provide support for one of the many Namespaces Windows uses. In a nutshell, the terrible Microsoft DLL practices that always plagued this sad excuse of Operating System they call Windows are bitting us again. @Moshbot, @Axelord FTW, @KAO, you guys need to fix your Windows, I found instructions for how to fix your Windows from a trustable source here.

Got it: [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (Small High Explosive Warhead) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) You have BDArmory installed twice on your rig! Config(@PART[bdWarheadSmall]:AFTER[BDArmory]) BDArmory/BDArmory/Localization/part_deformatter/@PART[bdWarheadSmall]:AFTER[BDArmory] Config(@PART[bdWarheadSmall]) BDArmory/BDArmory/MMPatches/BDA_TweakScale/@PART[bdWarheadSmall] Config(@PART[bdWarheadSmall]:AFTER[BDArmory]) BDArmory/Localization/part_deformatter/@PART[bdWarheadSmall]:AFTER[BDArmory] Config(@PART[bdWarheadSmall]) BDArmory/MMPatches/BDA_TweakScale/@PART[bdWarheadSmall] Completely delete GameData/BDArmory/BDArmory and you will be good! Cheers!

I got these the whole day!!! What means that the constant TweakScale borks were hitting your FPS (sigh). Well, let's fix this. What's happening is that I had "split" TweakScale in many cores, each one specialised on a situation on user's rig. This saves me from creating a different TweakScale version for every possible situation in the World (it's like the Companions, but focused on KSP only). But since that bug is screwing up exactly the Assembly Loader/Resolver, KSP is not fulfilling TweakScale's requests for loading them. Right now, I can think of two choices for fixing your problem until I nail that pesky bug on KSPe.Light.TweakScale: Remove 2.4.6.3 and install 2.4.6.2 (the previous version). Download 2.4.6.2, extract the KSPe.Light.TweakScale.dll file and copy it into GameData/TweakScale/Plugins folder. Or just download this file (a 2.4.6.3 release with the DLL already replaced) and use it to reinstall TweakScale, after completely removing the current one. This will allow you to play while I fix that pesky `Kernel32.dll` problem on a way that doesn't hurt users. But it's there, I assure you. Check this link on how to locate KSP.log and then publish it on dropbox or something (and post the link here!) so I can inspect it for you. I can advance that there're one rogue patch on your GameData that it's patching a part with TweakScale twice, and this is really far from being safe, as this can lead TweakScale to confusion and screw up the scaling of that part on flight on the next boot. It's a way to redirect directories and folders from one location to another. It's also how Windows "mounts" a disk "inside" a directory on another one, so you can use everything as one big disk without having to remember in which disk things are. Check this link for more info.

Check if you didn't forgot some fan disconnected, just in case- I do it all the time, to the point that I only put back the screws after testing everything! (or perhaps some other power line badly connected, this causes overheat) — checking Player.log — Nothing. I found nothing. Not even a Warning, the log is clean. Your card crashes only with KSP? Did you tried running some benchmarks as PassMark or 3DMark? Additionally… There's a bug on Unity related to particles that are triggered when looking into a VAB/SPH lamp while it's sparking, it crashes the game. This happens with you? I found interesting that you said that things only blows up when you fly the craft - I'm assuming you are not building low cost airliners so you probably are crashing when the atmosphere or heat FX triggers (again, particles). If the problem only happens with KSP, it should be related to something Unity does or needs that it's clashing with the GPU's device driver, I had heard of people that solved some problems like yours by installing a older (or newer) version of the device driver.

There's a thing called Player.log (I'm on mobile, can't search for where to find it now, sorry) that may have a hint about what's happening. Find it and copy it on Dropbox or something, then publish the link. With some luck, we will find some error message that can help. In the mean time, my crappy GPU has problems with atmospheric effects on crafts with many parts, usually set them to low. But I!m blind guessing on this one. — — POST EDIT — — Additionally… There's something else to be considered, that just happened to me last week... I'm on the South Hemisphere, and I just leaved a moderate winter into a somewhat hotter than normal spring, and curiously my professional machine started to overheat. The thermal protection prevented it from melting, but it got so hot that it broke the (crappy, I admit) HD of the secondary machine stacked above. It ended up that the machine was so dirty inside that there was no air flowing anymore - but since the clogging happened on winter, it passed trough - but on the first hot day, that extra degree on the environment's temperature was the straw that broke the camel's back. By opening the machine and cleaning it (and remembering to be sure that the air vents were unclogged), everything came back to norma now - the machine is running cooler than were running on winter, by the way. What you describes is interestingly similar to what I was seeing on the machine - perhaps you just need to clean up your machine guts, check the fans, etc….

Oh well, at least is a step ahead. I hope. Removing Add'Ons is not the best way out of the mess IMHO, but sometimes we need to make compromises. Let's hope that by solving the remaining problems, you can reinstall it back. Sorry! I'm so used to it that sometimes I forget that people my not know it. About your log... [LOG 17:53:17.884] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> System.TypeInitializatio nException: The type initializer for 'KSPe.IO.Hierarchy' threw an exception. ---> System.ComponentModel.Win32Exception: Не удается найти указанный файл. at KSPe.Multiplatform.LowLevelTools.Windows32.GetFinalPathName (System.String path) [0x0002b] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.Multiplatform.FileSystem.Reparse_windows (System.String path) [0x00000] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.Multiplatform.FileSystem.ReparsePath (System.String path) [0x00015] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Directory.RealPath (System.String path) [0x0001f] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Directory.Exists (System.String path) [0x00000] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Path.EnsureTrailingSeparatorOnDir (System.String path, System.Boolean blindlyAppend) [0x00033] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Path.Combine (System.String path1, System.String path2) [0x00007] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Hierarchy..ctor (System.String name, System.String dirName) [0x0000d] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.IO.Hierarchy..cctor () [0x0008c] in <f267864bc5b14efd9db6b3cdd8146f53>:0 --- End of inner exception stack trace --- --- End of inner exception stack trace --- at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr) at KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) [0x00000] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) [0x0002e] in <f267864bc5b14efd9db6b3cdd8146f53>:0 at TweakScale.Startup.Start () [0x00018] in <45182d9103c649a9b01afeb7178d397a>:0 at error:0 This one is on me. Something changed on Windows 10 and it caught me with my pants down. I'm going to work on it this week https://github.com/net-lisias-ksp/TweakScale/issues/216 But in the mean time, you can download the 2.4.6.2 release and manually extract the KSP.Light.TweakScale.dll and replace the one from 2.4.6.3. Of course you may also just rollback to 2.4.6.2, but the .3 release has some interesting fixes and I think it may worth the pain. These ones are annoying, but harmless. I will tackle them down ASAP, but it's hard to wave a important bug fix or a nice feature to fix something that, at least until this moment, it's completely harmless. You need to reach WildBlueTools' maintainer for that! Yep, now we nailed it. A proper solution is work in progress, but the workaround above (use KSPe.Light.TweakScale from the 2.4.6.2 release) will work for now. In time, are you using SymLinks, mount points or similar on your rig?

And that's what I did. I switched the skybox to one with way more resolution and tested the thing on my oldest MacCrap, that have only 384MB of VRAM (no to mention a crappy Intel HD3000 as GPU). You can't ask for a better rig for easily test performance, sir, every extra MB can make the textures being fetched from the CPU's RAM, plummeting the performance. And some other interesting effects. Read the rules again. I'm allowed to hack KSP, as long I stay away from private thingies and do not reverse engineer the thing. And I didn't did any of them. And I'm not the one claiming how the GalaxyCubeControl works. I'm just telling you how I think it works based on my Clean Room tests made on weaker machines, where such behaviours are way easily spotted and measured. Of course, I may be wrong about your claiming. Please pinpoint where in the KSP API Docs are the information needed to know exactly how the GalaxyCubeControl works.

Sorry, dude, you fail to understand how these things work. RGB manipulation on the skybox involves duplicating a base image and applying changes on it, pixel by pixel, for every frame. So you need to have both images on the VRAM (and so the GPU can do the job, at expenses of duplicating the skybox footprint in memory), or you have the base image on CPU's memory, makes it apply the change, and then 'upload' the result into the VRAM, so the GPU can apply it - and this transition is way more expensive than having the GPU using the VRAM exclusively, even nowadays using PCIEx16 buses. I suggest you read the code yourself - it uses something already existent on the codebase, the GalaxyCubeControl, and unless you are engaged in Non Forum Compliant activities (see item 9), you don't have grounds to do such affirmation. I also suggest you follow an ongoing (besides slow as hell) discussion about how to enhance the feature on DOE.