Lisias

"Constellation Urion" (Urine On)

Impressive. Mostly impressive. What can be more steam punk than a steam bicycle? (and now I want one for me!!)

It's not about how much you make by sell, but how much you make at the end of the month with the sum of all the sells. I need to eat too, inflation here are about 80% since before the pandemics and yet I still earn the same I was earning before - and I don't dare to try to raise my fees, as I have notice of competitors fighting to avoid dropping prices (while firing workforce). I don't see why Private Division would have an easier life than me (or anybody else), they are a business after all (as anybody else). It's better to sell 1000 copies at 35USD than 100 at 50USD. Do you see my point? (I'm not implying they should sell the Early Access at 35USD, that was just a number I pulled from my hat - what I think they should consider is a Demo release, teasing people to buy the early access — hey, this carrot and stick stunt worked on me, right? ) They have more than one foot to shoot at. Missing that one is not the same than saving the other. That said, I'm not disagreeing with you - we may have a small disagreement on how to accomplish it, but that's all. thats quite a big claim xD Just smile and wave, the Sons of the Kraken are lurking, waiting for revenge!

Well, they should if they expect to earn some money nowadays.

I see your point and, in fact, community workforce is easily abused by Companies. However… You may be missing a detail or two: not all volunteers are, in fact, doing "free work". Some are being paid by 3rd parties that want something fixed by personal reasons, others are doing it because they have stakes on the product and want to know early how things will work in order to be prepared when the thing finally hits the shelves. It's up to you to decide if it worths your time or not - and I agree that for most people it will not. No doubt. But I had seen people getting burn by doing a hell of a effort on voluntary work just to see their efforts being internalised on a closed product - without any kind of counterpart for himself. In extreme cases, things gone to court. So, it's not bad that such discussion happens now - so people willing to contribute knows exactly what are the terms and what to expect from their efforts. You will not get paid. You will not have your name on the product. This is a commercial closed product, not a open source initiative. You will not be rewarded at all - save some gratitude and recognition on the Forum and the chance of getting what appears to be a 100 to 150USD product by 50. If this is enough to you or you are getting something back by other means, then go for it. Otherwise, don't frustrate yourself with unfunded hopes of rewarding. Easy. I was working homeoffice even before the pandemics, and 2020 was a dead year for me nevertheless. No new clients, the ones we had were operating at low speed (if operating at all), so some of them didn't even had how to pay us. I was fortunate enough to had savings (intended to do some work on the house - that are still to be done, by the way… Need new savings now! ) and so I didn't had money problems, but most of the people I know had. And I will not even talk about the mood and mental state at that time - this is not a group therapy session. For all what matters, I had just removed 2020 from all criticise I had and have about KSP2 (and about almost anything else). That's an excellent point, by the way. KSP2 is not an Indie game made by a bunch of code-monkeys (just to clarify - I was one too on my early years, this is just slang and a kidding on the company's name) bashing their SASes building an unexpectedly high profile product while learning the trade. People love the underdogs. You should not expect the same level of good (read free) will from people when doing an AAA game - you are not an underdog anymore, people expect way more from you. It's the reason Linux have a huge amount of free help around the World, while Microsoft have a way more limited voluntary workforce. Both ends up getting what they need in the end, but by different methods. That's another very interesting thought. The key reason I had bough KSP at first place was the Demo - I had already aware of the bugs that were plaguing the current releases due people on Youtube trying to do things and getting screwed, so my first impression wasn't the best. But then I played the Demo and understood why a "so bugged game" were still making such a fuss - people were complaining about the bugs, but they were still playing the damn thing, and I understood why by "wasting" a month on it. I think this may stick, but I agree that there are better ways to accomplish that. I think we are not their Community. We are (still) the KSP1 Community. KSP1 is a product from a "competitor", money earned on KSP1 will not feed their pockets in the same way money earned on KSP2 will not feed KSP1's shop ones. Corporation politics are a mess - some of them live an effective war between the Contractors internally. I want to be wrong on this, however.

Did this on KAX, and I'm not satisfied with the results. The only real improvement is being able to use auto-pilots, as they only support Stock engines. It's a way out of the problem, but IMHO a less than ideal one. Yes, but wait a bit - I'll distribute a new release in the next 24 hours (not sure exactly when yet) with some needed changes to avoid conflicts with a new add'on from @Drag0nD3str0yer. — — POST EDIT — — Of course, while overviewing thing before shipping it, I found some horrible merge mistakes I let passed trough. I'm eye picking everything and, since I'm here anyway, I'm adding some more nice to have features (but nothing really new). This will take one day more at least, sorry for frustrating expectations! I will let you know as soon as I have something decent to kick trough the door. — — POST POST EDIT — — I'm fighting a weird and completely unexpected problem, apparently (but pending confirmation) caused by something on KSP that really caught me with my pants down even after so many years on modding. It's weird, it's unexplainable, and I'm spending all my available time on it. My apologies for yet another delay.

I think it is, but I can't promise you a deadline for it! https://github.com/net-lisias-ksp/DistantObject/issues/26

Yep. The Italians also operated the F114, with way less accidents. About 155 from 1964 to 2002, from a total of 359. About 4 per year in average. The Germans lost 298 from 1961 to 1989. About 10 per year in average. More than twice. But the Italians operated way less airframes than Germany, so the loss rate was sensibly higher - ~43.17% for Italians and ~32.52 for the Germans. About casualties, 69 Italian pilots were lost, or 69/155 = ~44.15% of the crashes killed the pilot. For Germans, the rate is ~39.38%. So even with corruption and all the lack of training documented over the Net, the germans managed to do a bit better than the Italians overall. So, yeah… It was a dangerous plane. Still a formidable one, but dangerous nevertheless. A fart detector using sound waves?

I would like to have any potentially prone to litigation technics away from this thread. We already had this discussion before. I would prefer you would talk about these matter in PVT messages or other threads, please.

Got a little break while paying some bills, and made a quick test. It's still too premature to be absolutely sure, but apparently the error on TweakScale is mangling the buoyancy attribute from PartModule. So, my previous statement are still valid: TweakScale is scaling the dragCubes the right way, and mangling with them in order to force a desired behaviour will mostly certainly screw up something else. What doesn't means that we should not toy with the idea. While thinking in what you had proposed, I came to the conclusion that even by not pushing it into the mainstream, there's no reason to do not allow a configuration to change the scaling of the dragCubes in the same way there's a configuration option to mangle the buoyancy. It's a mistake to use it if you want stock like behaviour, but hell - why prevent people from doing crazy things if this is what they would want? @ColdJ add'ons may be directly beneficed by it, as it appears. humm… I just called @ColdJcrazy!!! It was not my intention… This time. I understood. My point is that without knowing exactly how all the aspects of the DragCubes affect the game's physics engine, mangling them to induce a behaviour will fatally create undesired side effects somewhere else, usually on something you will not detect immediately. Been there, done that - and not only on TweakScale (I'm not new on this modding thingy). I have a Beta version of TweakScale running for two years exactly because of that - most features on Beta I wrote 1 year ago is only now reaching mainstream. It's perfectly possible that you are not wrong on assuming you can mangle the two or single dimensional attributes from the DragCube in order to induce a new behaviour - and, in fact, this idea appears to be too damn good to let it pass without a try first on the Beta program. But I'm extremely reluctant on shove this thing into mainstream without a lot of testings - and, most of all, will not do it as a regular feature on the standard patches without an absolutely compelling reason (like someone pointing a gun on my head). I stand corrected at the same time I still withhold what I said. For @ColdJ I think things would not gone south that way under a buoyancy equal to 1. See the exponent as the how many dimensions you want to scale: 0 = No Scaleing, 1 = Linear Scaling, 2 = Quadratic Scaling, 3 = Cubic Scaling, anything else = going extraterrestrial, metaphysical or doing a Leap of Faith without a hailstack downthere. But you are also correct : an exponent == 0 will effectively disable scaling the attribute, and this is apparently the correct way of fixing the buoyancy of the scaled parts! I have no problem on doing crazy (and sometimes stupid) things. I'm only reticent on pushing them into mainstream without some time on QAS first - and even by doing that, I got bitten in the SAS more than once. The idea of mangling the dragcubes by TweakScale is not bad, not bad at all. Using it to solve a problem that I think should be fixed in an orthodox way is the problem on my book. I think @ColdJ was bitten in the SAS due the way he mangles the dragcubes on the new parts - in order to force the buoyancy he needs, he gone the dragCube way. Since he is going nautical and/or subnautic (is there such world in English?), the stunt worked fine for him - and nobody is going to make a flying Titanic anyw… Hummm… belay that, this is KSP, of course someone will try to make a flying Titanic, Doctor Who style!!! Allons-y, Alonzo!!! Ahhh, that's the point!! I wasn't willing to use your idea to fix the part's buoyancy (unless not other alternative was possible), but I liked the idea of allowing users to mess with the dragcubes scalings! I just will not use it on the standard patches but, hell, someone will have fun mangling them once I implement it somehow, I'm absolutely sure! In a way or another: https://github.com/net-lisias-ksp/TweakScale/issues/267 https://github.com/net-lisias-ksp/TweakScale/issues/252 Cheers!

I will try to find it out. TweakScale only mangles the PartModule's "this.part.DragCubes.Cubes" thingy, if there's more to be scaled, I need to know! (not, it was not me - or I need to see a geriatrician! ). Cheers!

Setting the buoyancy to 0 is the same as removing the buoyancy from the ScaleExponent. Once I confirm the information from my side, the fix appears to be pretty obvious - don't touch the thing! Exactly. The dragcubes is used to help infer approximated volume, not the buoyancy value! Thus buoyancy thing plays a role, but not on volume! I think we are clashing on nomenclatures! I will try to graphically differentiate the real life concept "buoyancy" from the PartModule's buoyancy atribute from now on. Anyway, by mangling the dragcubes, we will be mangling the volume of the scaled part - something that by all effects, appears to be being done right. One way to confirm this is to brute force scale a part into a new part by hand, and let KSP automatically compute the dragcubes of that part, then scale the original part the same using TweakScale, and then launch a craft with both parts and compare the dragcubes. I think ObjectInspector may be of help on this task. Whatever KSP does to compute the dragcubes of the handmade part, TweakScale needs to follows suit on the scaled part. Point. Doing it differently will make the part misbehave once scaled. — — — I'm not dismissing the remaining of your post, I just don't have time right now to further explore it - so I rushed some thoughts that I wanted to highlight in advance in the hopes of saving some time in the mean time. Cheers!

Hummm… Interesting. Thanks for the trials! Hum… now you caught me with my pants down. What's `buoyancyUseSine` ? Sinking while setting it to zero makes sense, anything elevated to the 0 power is 1.0 and this is too low for the part. Setting it to 0.1 , on the other hand, surprised me. That part must be really huge to such a difference in the behaviour. Humm.. They should, as negative exponents are, in effect, roots. x**-2 is the same as the sqrt(x) . As a general rule I tell people to avoid negative exponents because small enough numbers can lead to a 0 after rounding, and you don't want it on calculating mass, for example! (been there, done that!! ), but in some other atributes is can make sense. So @damerell appears to have a point! Thanks! As soon as I have one, you will be one of the first to know! Hummm, ok. I had misunderstood you. Sorry for that. I think I'm seeing your point, but your point assumes that buoyancy is related to volume, and we don't have evidences that this is how KSP works. The @ColdJexperiments appears to suggest that, in fact, it's not. Jumping into conclusions is not something we want to do, it's something we unattendedly do sometimes. Kraken knows how many times I had done it on TweakScale in the past! I'm not trying to dismiss you, I'm trying to alert you from doing the same mistakes I did in the past! But you are not wrong, anyway. Changing the drag cubes will affect the flight behaviour for sure. You can hit F-12 to show you the force vectors then you can check the red vectors comparing between scaled and uscaled parts! Blue vectors will show you the lift. Yellow will show you the control surfaces forces (you will find that some parts don't give you lift, only "control surface forces"). I wish I had hit F-12 when I made this test, so I could better demonstrate the feature to you! Sure thing! But first I will need to know if you will be able to interpret the results, because otherwise I would be digging deeper the hole instead of working to fix it. There're a lot of experiments I think you need to do in order to be able to compare the results later, otherwise you would be too much prone into jumping into conclusions without being aware of that. As i did in the past. To tell you the true, I had completely missed this one. Really, I never really noticed this exponent before - I'm usually chasing game breaking problems, and these small details usually pass trough. It's the reason I usually try to reserve some quality free time to be pure R&D, without worrying about bugs or anything else - of course, always pending RealLife™ agreement. Anyway, @ColdJdid some pretty interesting test in advance, and they appears to suggest the buoyancy is not related to volume - things would not had gone south otherwise when using a buoyancy exponent 1 (or just removing it from the ScaleExponent). An interesting information is wheels floating even when using a 0 on the exponent (what would force the buoyancy to 1.0), so there's something else being used to calculate the "effective buoyancy", and you may have a point on suspecting the dragCubes. But even by being right, we need to balance the consequences. DragCubes are pivotal on atmospheric flights, and we may screw things badly by trying to mangle them to force a behaviour on a secondary feature. In the end, I really think the best approach is indeed took by Firespitter - just get rid of stock buoyancy and apply your own solution - that will work perfectly fine with TweakScale by installing TweakScale Companion for Firespitter.

Welcome! Don't mind, it was not a problem. I had assumed you wanted to automate your installation somehow - some add'ons use to have a "DLL only" distribution file, and by the description of you problem it made sense to build one. Automated tools rarely are smart enough to allow you to remove parts of the package, they usually just unpack the ZIP over the GameData and call it a day. "Float safe". Cheers!

We are not scaling blocks of concrete. We are scaling Parts, complex things with many different components with different "densities" (in quotes, as this is not really how KSP works). We don't take a part half-wood and half-iron and scale it as it was made only on iron. The way you can simulate such scalings are by (ab)using the Scale Exponents. KSP doesn't simulate the (hypothetical) internal components of a part, anyway. Take a Crew Cabin: it have lots os empty spaces, some seats, a bit of glass, lots of structs made of light material, etc. So we can't just scale everything up to the power of 3 and have something that could be used to build things more or less similar to something on real life. The same for engines: an airplane cabin does not have the same average density as a turbo-fan engine (besides both of them floating on KSP - with or without TweakScale). So we use a 2.5 Exponent to engines and a 2 Exponent for crewed parts and call it a day. The values are approximations far from the real life, but they are good enough for the purposes of this game. So the Exponents are used to scale the part's characteristics in order to have some resemblance with the real life counterparts. For simplicity, we have essentially free, free_square, stack and stack_square scale types with predefined Exponents. The *_square ones use a 2 Exponent, the other ones use a 3. Scale Behaviours are used to force a different exponent when applicable (as engines that are scaled on a 2.5 Exponent). Please note that the Exponent used to scale mass don't need to be the same one used to scale thrust, or ISP, or even toughness. You can tinker with different exponents on different attributes to make scaling relevant and challenging - you earn something but also lose something by scaling, what would be the best compromise for a given design? Way more challenging that just dumbly scale everything up or down using the same factor - life doesn't works this way. And there's nothing blocking you from toying with different ones to see what you get, as 3.5 or 1.75 - including values under 1.0 (but always above 0). You will have some fun toying these values - I surely did! On the stock patches, Aero parts and Cabins are usually scaled with the 2 Exponent because it was found that using 3 made the parts (excessively) unrealistic heavy (let's ignore the whole game physics is anything by realistic! ). Same for engines, that as I said are scaled by a 2.5 Exponent. Science also have a specific Scale Behaviour for them, as well Resource Converters and Decouplers. You may want to toy with the ScaleExponents instead of compiling TweakScale to meet your needs, you can toy this file https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/patches/020_ScaleExponents.cfg You will find some needed information on the files on this directory: https://github.com/net-lisias-ksp/TweakScale/tree/master/GameData/TweakScale/Docs I think it's too soon to jump into conclusions, you merely scratched the surface of the problem. There's a lot of scale factors to toy with before breaking scalings by removing code. See the links I posted above. I also ask to pay some attention to the thread I linked on my previous post, this is hot information from the game developers themselves, it may be of use while wondering why things works the way they works. In fact, while inspecting the files in order to suggest something to you, I think I had may found why you concluded that the buoyancy is being scaled to a factor of 16! Try the following patch and see if things change to you: @TWEAKSCALEEXPONENTS[Part] { %buoyancy = 1 } If it works the way I think it works, we may have found the problem for the crazy buoyancy on TweakScale! You may also want to try something pretty near 0 on it (something like 0.0001) to see what happens. I found that the buoyancy's exponent was set to 3 on a pretty anciant commit, from 2014 (0.23.5!!) and was never touched again since then... Well, you may had leaded me to the right path after all! I have a proposal for you: toy with the exponents I explained above (and with the buoyancy one above all) and see how things behave for you. I will do it from my side as time allows. In the weekend we try to find a way to chat about our findings and see if mangling with the drag scaling is really needed - I'm suspecting it is not, but if I'm wrong, I will cook a specific exponent to be applied to the drag cubes and so people can make their own choices about it.

All parts are scaled the same. What changes are the exponent (**3, **2, **1.5 - yes, you are not limited to 2 or 3!). The 4th item appears to be the faulty one. There's also this buoyancy attribute on the PartModule (not sure since when), but I don't know anything about it - not even if it really works. You may also be interested in seeing how Firespitter implemented buoyancy to see how it was implemented, it virtually destroyed the stock Buoyancy in order to do its business. You may also want to see this thread: In special the quote below:

Can't open this one. Damn. These are not ordinary tires, these heavy cars of that past were heavy as a truck - that tires need to withhold a lot more of abuse than the tires of nowadays cars! Yep. A friend of mine used to own a Landau : And dude… That car WAS HEAVY. His worst problem wasn't the fuel consumption (he owned a gas station IIRC - or perhaps a relative, I don't remember), it was to find tires for the damned thing. My truck used tires with a similar certified load, by the way. And, yeah, that truck had the very same dry weight as the landau above!

I could not explain it better! That's the thing: there's a value on the PartModule that I found but didn't understood yet, "buoyancy". I hope it is used somehow together the drag curves to calculate the buoyancy - but I need time to do some R&R, I mean, R&D on the matter. The time we realise how (or if) this "buoyancy" thingy works, will the time (assuming it works…) we will be able to do proper ship parts - and to scale parts without messing up the buoyancy!!!

Because Buoyancy is related to density, not volume. And the drag curves are scaled as the volume scales. For example, 1m³ of wood will float but 1cm³ of lead will sink. However, on KSP, there's no density on the parts - just the drag curves being reused to define how the part will float over water (and only over water - different liquids would give you different buoyancy for the same part, but on KSP we are all locked into water to handle Buoyancy). Since TweskScale needs to scale the drag cubes, otherwise you would have drones with the drag of a Boeing, and Jumbos with the drag of a Cesna, the currently unavoidable side effect is the buoyancy being completely screwed up as the video I post demonstrates. I need to find a way to compensate the Buoyancy as the part is scaled up and down in order to keep the same Buoyancy of the default part as the part scales. So I need to understand how the drag cubes feeds the Buoyancy calculation so I can compensate it on the other side - and using the weight is not an option.

1978 Star Streak Motor Home. I still trying to figure out what to think about this… More info here: https://www.autoevolution.com/news/the-star-streak-is-how-you-turn-a-cadillac-eldorado-into-a-fancy-motorhome-181778.html#

Good! PatchManager (and, most of the time, everybody else) was probably just the trigger. If you really want to use it, I suggest to temporarily uninstall MJ2 (so the diagnosing is easier), install PatchManager, make it work and then install MJ2 back. It's how I managed to diagnose weird things when MJ2 is installed (again, not because MJ2 is the troublemaker, but because somehow I changes how things are logged and this affects negatively my diagnosing). Well… This is another long story. So TweakScale now only officially supports Stock and (most of) Expansions. Everything else is now (or hopefully will be Soon® ), officially, on a Companion. You will find the current ones here: https://github.com/net-lisias-ksp/TweakScaleCompanion Currently, only manual installation. Add'Ons that rely purely on stock PartModules will work fine with a few lines of code on a MM Patch. The hard part is doing things in a way that make sense and it's useful - just shoving type = free on everything is a useful hack most of the time, but having proper ScaleTypes that makes sense does a better user experience, so it worths the trouble to make good patches. Please check the Companions, I like to think I did a good job on the Patches for the SCME one by way. In the mean time, All Tweak is a nice workaround while I don't provide the patches you want for the add'ons you use. And a new bonus on the more recent TweakScale releases is that I finally understood where KSP had changed on some primordial levels and could resurrect some very nice features that you probably had used on 1.3.x era, but I had to deactivate since 1.4.x - and this includes the ability to seamlessly adapt the scaling if a part when you change the patches. So using All Tweak is not only a convenient workaround, but also safe nowadays (some time ago I had to tell people using All Tweak that they could not install new patches on ongoing savegames - pretty annoying). Check all the Companions and install the ones that provides the support you need. And you can file suggestions on this link: https://github.com/net-lisias-ksp/TweakScaleCompanion/issues Don't bother trying to guess in which Companion you should file the suggestion - I will sort it out later this year when I will have another time window for coding on KSP again! Easy, yes. Convenient and useful, not always. Try All Tweak above for parts relying solely on Stock PartModules (or PartModules that I have already wrote a ScaleType) - don't use it on add'ons with custom PartModules (or without proper ScaleTypes), they will not scale correctly and sometimes will even break. On the bright side, once proper TweakScale support is added, AllTweak automatically steps aside for the new patch and things will usually work fine with the resurrected patch migration - at least, I didn't found any problem with it yet. There're some Stock Parts that I'm struggling to support due a lot of bugs they have - Robotics, to be more specific. The Serenity's Robotics are very nice parts, but unfortunately they are pretty buggy too. But you can try your luck with the TweakScale Beta and, if you are really, really brave , you can activate the Experimental patches on Beta by creating a Directory called "TweakScaleExperimental" on GameData. I don't know how Infernal Robotics are behaving nowadays - proceed with caution. I know that without Breaking Ground the IR/Next fork worked fine some few KSP versions ago. You will probably want to check KerbalJointReinforcement/Next too. Let me know if you need any assistance. Jumping from KSP 1.3 to 1.12.3 is a hell of a Endeavour , and since I still do support everything down to KSP 1.3.1 (and one or two things even on KSP 1.2.2!!!) I'm pretty sure I can be of some help on this Enterprise . (late night, infamous jokes can't be contained anymore!!) Cheers!

Yes, this is an issue indeed: you need to delete the doppelgänger DLL to prevent trouble (my last post explains in details why this is terrible). The only Scale_Redist.dll that should be allowed to be loaded by KSP is the GameData/999_Scale_Redist.dll one. Cheers!

Oukey, I'm finding my way on the mess. For starters, I need to do a better job on reporting problems o MMWD, a few more line of code and you could be able to help yourself on this one. Delete this file: [LOG 14:17:14.323] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\MagicSmokeIndustries\Plugins\Scale_Redist.dll The only "good" file is the "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\999_Scale_Redist.dll" . Let me explain to you and everybody else why this is happening nowadays (on a spoiler if you don't want to read it): Your second problem appears to be PatchManager: [LOG 14:17:14.378] AssemblyLoader: Loading assemblies [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ClickThroughBlocker' V1.0.0 [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ToolbarController' V1.0.0 [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' is missing 2 dependencies It is triggering that Assembly Loader/Resolver bug on KSP I mentioned above. Remove PatchManager and see if it solves the problem. If not, send me a new KSP.log and I will keep digging - you have MechJeb2 installed and it somehow mangles a bit how things are loaded, and then my diagnosing tools are not reliable. Usually , the first DLL to throw a ReflectionException are the trigger of the problem, but when MechJeb2 is installed this is not always true anymore. Additionally, your KSP.log was truncated before the Main Menu being shown. This happens because KSP has an internal buffer to avoid hitting the hard disk all the time (what would make things slower), but the price we pay for it is that it takes some time until the internal buffer is flushed into the file. Usually it's better to quit KSP before copying the files - or alternativelly starting some disposable savegame (or just a new bogus one) and then copy the KSP.log file later, as by then the new log entries had already forced the ones I'm interested to be flushed into the file! Cheers!

I had put it on the backlog, unfortunately pending Real Life™ agreement. https://github.com/net-lisias-ksp/TweakScaleCompanion_FuelSwitches/issues/5 I completely understand you. I'm still playing on 1.4.3 on some savegames… Well.. The mess is not from TweakScale. It happens that KSP has some internal bugs that, unfortunately, were being downplayed by the developers and also by some relevant add'on authors, and when some of these bugs bites TweakScale, it is rendered ineffective. And when this happens, all your scaled parts are screwed on savegame loading - for good. If you are on the gory details mood, search for "Assembly Resolver/Loader". Please note that this affects EVERYTHING, not only TweakScale. Anyone, absolutely anyone that have a custom data into the PART gets screwed when it's bitten by these KSP bug. It only happens that TweakScale is checking for the problem and yelling when it detects it, preventing you from loading and corrupting your savegames. Humm… There's a bug on ZeroMiniAVC (I think) where it's checking for duplicated DLLs where it should not - anything inside a directory called PluginData is plain ignored by KSP, and I use this place for integrity checks and seamless updates. This is unfortunate, because the alternative will be to obfuscate these DLLS, and this is really bad because it's how viruses work and I don't want to risk being flagged as one. Please send me the KSP.log so I can check this for you. I think you have multiple problems happening at once. Please send me your KSP.log using dropbox or similar service - don't try to copy & paste it here, it will screw up Forum, and it will be truncated anyway, rendering it useless. Yep. I know of some users that install TweakScale only for the safety checks, completely ignoring the feature itself (I think one of them even deleted the patches… ). KSP is being plagued by multiple bugs for years - did you know that if you have more than one ModuleManager installed, the oldest one is used instead of the newer one since KSP 1.8? This are that bad, and it's the reason WatchDog and TweakScale are extremely picky about things. There's no "simple solutions" anymore, people going to the easiest path are making things worse. Many things had changed. Some tricks that used to work in the past now cause problems - it's five years of piling changes to cope with…. If you have a somewhat older rig, I suggest you read these two threads two: Buoyancy apparently was an afterthought on KSP, as the drag cubes were used to simulate it. Problem: I need to scale the drag cubes, otherwise the parts will have a very unfair drag, so it's a catch22 situation for now. I demonstrated the problem on this video: I have a task for it here: https://github.com/net-lisias-ksp/TweakScale/issues/252 (pending Real Life™ agreement, unfortunately…) You are right in the sense it's not (at 99.99% of the time at least) a problem on TweakScale, however TweakScale is deadly affected by it, so I had to code that "Houston" thingy to prevent users from losing the savegames. (again, I want to stress out that TS is not the only one suffering - but it's the only one complaining about, as it appears). Publish your KSP.log on dropbox or something, please. I think I need to inspect this one. There're safeties coded on MMWD that may be at jeopardy due this, and if this is the case, I unfortunately will be forced to code a less than sympathetic counter-measure - or hell will be unleashed on me again!