Lisias

I need the full KSP.log, please publish it on dropbox or something and then send me the link. Additionally, do not publish long dumps of a log on Forum. It overloads pages, making things bad for everybody. Publish it on dropbox or something, quoting only small pieces of it if you think you found something interesting - I always need the full thingy anyway, and Forum can't cope with long and boring walls of text! Cheers, and waiting for you log!

MOAR BOOS, uh, WHEELIES!!! Source: http://southern.railfan.net/road/4023/up4023.html

Even by trying a powered descent? I usually have (some ) success by hitting the thrusters and ascending again when things start to get too hot. This will cool of the airframe, and then here we go again - rinse, repeat. Something that I would like to have is "optional heatshields". Parts would have little to no heat resistance (perhaps enough to survive Mach 7), but for reentry, the good and faithful refurbishable, Space Shuttle alike, heat shield would need to be attached to the parts to provide heat protection. This would also make our airplanes lighter, as we don't need heat shields for atmospheric ferrying. Nice bird, by the way. In time, just in case you let this pass trough - you can save some fuel by deactivating all the rapiers but a pair or two, the minimum necessary to keep her flying if needed. Engine modelling on KSP are not exactly precise, we can exploit a thingy or two - having 4 rappiers providing 20kN of thrust each consumes the same fuel as 2 providing 40kN each (the fuel consumption is directly proportional to the thrust given the same flight regime), so by using only 2 you save a bit of fuel on turning them on. You also can close some air intakes and save some drag, as you have less engines sucking air from them.

I'm on mobile, so I can't quote the excerpt of the log where I found this, but there's a 'DidntReadTheInstructionsException' from Parallaz complaining that it doesn't works on that KSP version. I suggest you to uninstall Parallax and see what happens.

(Offtopic, but too good to let it go) Sooner or later, someone need to make a IVA like this for KSP: Source.

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.