Lisias

There's two years since I looked on that code, but you may be right - looking on it again, it appears to be only applied when the craft is made before or on 1.8.0, when then the 1.8.0 upgrade script would be kicked in. That hack of yours (editing the craft file to appears to be made on 1.8.0) throwed some light on this equation!

This DLL fixes a problem on a thingy called UpgradePipeline (a thingy that convert crafts on older formats to the current one, migrating modules too) where the Aero Control Surfaces were being "inverted" (something specially nasty on flaps where the direction in which the control surfaces goes when deploy is crucial). This problem started to happen on KSP 1.8 , and I don't know if it still needed on KSP 1.12.x If you are curious about the need of the thing, check this post: Hey, nice hack! Install the KSPUpgradeScriptFix.dll and see if it fixes the problem for you, I think it's way more convenient. Otherwise, the KSPUpgradeScriptFix would probably need some fixing itself...

ANNOUNCE KSP Recall 0.2.0.2 is on the Wild, featuring: ChillingOut is still needed on 1.12.x series. Reactivating it. Some missing logging stats added. This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. <aborted> SpaceDock (and CKAN users). <aborted> The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps, as I will have a hell of a Week and can't handle too many issues if something wrong happens. Cheers!

Why? If SpaceX needs a bigger nosecone on the same shape, they will not just scale everything up and take the extra mass hit, they will try to optimise the materials to save money and mass. Whoever made this initial values for scalings (never bothered to dig out the Log History for checking), they just got the size and weight of a lot of "aero" components on some maintenance manuals and realised that "2" would be an acceptable compromise between simplicity and plausibility for this game. He/she probably had to balance somewhat the game play given the current scale exponents from other parts. My guess is that he/she researched the empty weight of many types and sizes of wings, plotted the data on a graph and estimated that 2 would be a good approximation for the slope of the curve he/she was seeing. By analysing (hate this word, a typo and I get banned from forum!) the current scale exponents, you will see a pattern: Aero parts scales mass at 2 Engines scales at 2.5 (I remember someone hinting it, without realising that this is already the case since 2015 - and he was probably complaining about a 3rd-party add'on that forgot to include the Engine behaviour on the patch). Accomplished by a special Scale Behaviour Most other things scales at 3 Including fuel tanks, what's terribly wrong as my example on Saturn above demonstrates. But crewed parts scales at 2!!! (I remember toying some fractional scales for some other parameters, by the way) I agree, there's no magic here. There's engineering, and engineers spend a lot of time studying Strength of Materials exactly to be allowed to do such things. Nope! This is a common misconception from non-engineers that don't know about Strength of Materials!! (I'm not an engineer, but I know a bit about it). Research about Honeycomb structures!! So, I don't see a reason to change these rules now. Of course some people my not agree with me (Reality Overhaul dudes, for example). Well, this is the reason we Mod things, a new setup of scales for people willing to try new scalings is far from being a bad idea - as long precautions are taken to prevent people from ruining their savegames: once you build a craft with a scale set, you are locked on that scaled set for good and trying to switching will be a carnage. And, frankly, it's the reason I restrain myself to change a lot of values I think I should - at least, until TweakScale 3 hits (if ever) the road - where I can break reverse compatibility without risking killing people's savegames. Hi! Without the KSP.log (and the Module Manager Patch log) I can only guess. Your patches looks OK, so it's probably some interaction with 3rd parties - I just checked the deprecated Tantares patches, by the way, and these parts are not handlede there, so it's not me. May I suggest to try this? @PART[eridani_crew_s1p5_1,eridani_crew_s2_1,eridani_crew_s2_s1p5_1,eridani_node_adapter_s1p5_s0p5_1,eridani_node_s0p5_1]:BEFORE[YourAddOn] { -MODULE[TweakScale],* { } } @PART[eridani_crew_s1p5_1]:FOR[YourAddOn] //eridani_crew_s1p5_1 { %MODULE[TweakScale] { type = stack_square defaultScale = 2.5 } } @PART[eridani_crew_s2_1]:FOR[YourAddOn] //eridani_crew_s2_1 { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } @PART[eridani_crew_s2_s1p5_1]:FOR[YourAddOn] //eridani_crew_s2_s1p5_1 { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } @PART[eridani_node_adapter_s1p5_s0p5_1]:FOR[YourAddOn] //eridani_node_adapter_s1p5_s0p5_1 { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } @PART[eridani_node_s0p5_1]:FOR[YourAddOn] //eridani_node_s0p5_1 { %MODULE[TweakScale] { type = stack_square defaultScale = 3.75 } } Replace [YourAddOn] with the name of the package you are building, usually the name of the directory on GameData you are using, for example: <KSP_ROOT> ksp.exe [GameData] [Squad] [SquadExpansion] [TweakScale] [YourAddOn] Here goes your files! ModuleManager.dll What my patch is doing is to get rid of any eventual patching someone else has done on these parts, so when you apply yours you don't risk any leftovers screwing you over by contaminating the TweakScale module with undesired data. Additionally, keep in mind that the part on the patch is called eridani_crew_s1p5_1 and not antares_eridani_crew_s1p5_1 - since it's a long time since the last time I checked Tantares (more than 2 years, really..) I don't know the real name of the part, but I can say for sure that if the real part name starts with "antares", your patch will not work for it. Also, mind the spurious braces at the end of your patch. MM don't likes too much loose braces on the file, it's better to keep them in check. Cheers!

RL hit me in the balls badly on the last 10 days, and so just now I could (minimally) restore core functionalities on my (recently murdered by Apple's <insert your non forum compliant favourite expletive here about how to call people that does less than smart decisions>) MacMini 6.2 . On a first stance, yeah - KSP 1.12.x just screwed my MacMini 6.2 performance the same way KSP 1.8 did on my MacMini 5.1. HOWEVER. At least for KSP 1.12.1 (as I essentially missed the 1.12.0 due the hard disk recovery problems), I realised that setting the MONO_THREADS_PER_CPU=1 did not helped at all. At least, initially. The stutter on the rest of the machine was slightly less worst with the MONO_THREADS_PER_CPU stunt, indeed, but still stuttered a bit (moving the Windows around, playing Youtube videos, etc). And the Main Menu animation was simply horrible - less than 1 frame per second I guess, as the animation was "jumpy" with the kerbals freezing 2 or 3 seconds sometimes. That was unexpected. I was pretty convinced that the MONO_THREADS_PER_CPU stunt would solve the issue again. Then I noticed that apparently the performance of the CPU was not being exactly crippled by KSP, but the video updates. The apparent performance of small programs on the terminal apparently was't affected, only the terminal updates. (with the MONO_THREADS_PER_CPU stunt active, just to made it clear). So apparently I have another problem with similar effects - two different lighting bolts hitting me at the same spot, if you prefer. Thinking about, checked the KSP change log to see what had changed from 1.11.2 to 1.12.0 and 1.12.1 to see if a light bulb sparkles somewhere inside my dull head when I got an insight: a lot of visual's enhancements were deployed on KSP 1.12. Well, it makes sense, this rig uses a shared memory GPU up to 1.5G of VRAM, 3 times better than the previous rig but still less than the 2G that it's usually the minimal recommended for gaming nowadays (I will ignore the fact that Steam recommends 1GB of VRAM, and states 512MB as the minimum). So I played a bit, or better, A LOT with the Settings always starting with the default ones in order to reach the less amount of changes from the default values that would make my rig useable again - at least, on a vanilla (no Mods) installation. And I managed to do that. So, if you are running KSP 1.12.x on a old rig and/or are facing some serious performance issues, this is what worked for me: Go to Settings, click Graphics, click Reset Settings, click Accept Set Render Quality to Good. Set Texture Quality to Quarter Res. Set V-Sync to Every Second V-Blank. Set Frame Limit to Default. Click Accept And this solved the second performance issue for me (because, yeah, I still need to use the MONO_THREADS_PER_CPU stunt in order to avoid stuttering too much the rest of the rig). I still didn't installed any Add'Ons on this thingy, probably I will be forced to reduce somewhat the quantity of add'ons installed for the tests, what will be an annoyance to say the least. But at least I'm back to business…. (sort of) — — — POST EDIT — — — Installed TweakScale and the mininum set of Add'Ons I use for toying it, and I had to reduce the Texture Quality to Eighth...

The SpaceX's Dragon capsule once exploded on a test, then the video was published and a lot of people had disturbing thoughts. But let me tell you, that explosion was a bless. They found a inherent flaw on the fuel system, and by knowing that a lot of resources and even lives were saved, as that thing was being considered on some other crafts too (not only by SpaceX). You will have terrible FPS on code compiled for debugging, as lot of checkings is being made befir3 executing every single task to detect any mishap that could screw up something later. Fail early, fail often. This is good engineering - hidden flaws are flaws that will not be fixed. If they are showing us their 'flaws', it's because they know they are going to be fixed. Users do what users do. :) I would prefer people to openly address any concerns they have here than whispering them somehwere else, so someone can explain them when to worry and when do not - and eventually get an early warning about one detail or two they may had missed. In the very end, users have the ultimate knowledge about how the product works - as they are the ones using it 24/7 - there's no test team in the world that can match such working force.

I wonder exactly where and when Unity made that wrong turn. This is what Unity should be pursuing, it's my understanding that this is how Unity started. So the Game Industry is already walking fast into the verge of a collapse, more or less as it was happening on 1983/4. One of the signals of such market disaster is what I will call (mainly by lacking the proper language skills) the "squashing" of the production chain. The really big and few ones and the really numerous small ones are squashing the middle ones, that are the ones where most of the really good and innovative titles comes from. The small ones never manage to really score a big hit, because they lack the resources for such. The big ones stagnate on their own mediocrity, protected by their ability to exercise their muscles to supress/harass/buy the competition, instead of exercise competition itself. The net result is that sooner or later you flood the market with bad products. As it happened o 1983/4. The present distribution mechanics should prevent things to go south in the exact same way it happened in the past, no doubt. The Stores may force a shift in this balance, but I think this will more likely postpone the unavoidable. Without the middle game publishers, the big ones will just mate with the biggest stores and exercise their muscles from there. I'm not exactly thrilled with a potential career on this industry by now. Our loss, IMHO. The problems caused by Unity are a clear and present danger to gamers. If we have no viable alternatives to it, things will keep going as they are now. And they are far from being good. Really, really far.

Robert Bartini. Hail one of the most kerbal enginners that ever lived!

I think we are talking about different problems. The mess with the wheels is not mutually exclusive with the mess with the (lacking of) clamping on some physics values that ended up leaking into the parts and inducing spurious forces. Apparently some overshooting PIDs (or something similar) were also to blame (and this can be directly related to multithreading too, and so Unity is also implied). And I think this is the reason the wheels took so much time to be fixed (assuming they are, I'm currently unable to test KSP 1.12 by many reasons, 100% of them related to Unity). They were looking on the wrong place, expecting to see a problem on something that was working fine (of the most fine it can), and forgetting that you don't need a lightning bolt striking twice the same place to get your house fried again. I'm not telling you are wrong. I'm telling you are not the only one being right on this subject. As already said by Linus Torvalds, "Reality is messy". I, obviously, disagree. Most of the problems derived from the development mishaps can be worked around, sometimes easily, sometimes not (see the KSP-Recall stunt). But once Unity strikes, it's game over™ - the user is toast and there's no way out, he stops playing the game. See the TLA Crash thread (a text book example of catastrophic failure over a silly and superfluous feature). And, as most of people that waste their time reading what I write must already know, Unity is brittle, to say the least. There's no graceful failures on this thing. And this is hurting KSP1. I would like to say that ignoring MacOS would be too, but hell - I'm a Mac users and I don't support this thing anymore, my less old rig is a MacMini 6,2, (mid 2012) and I don't plan to ever buy another Mac again. Newer Macs just don't worth the price. It's sad, as this were one of the finest machines on the market, but sometimes enough is enough. Not to mention that Mac now is two different machines, M1 and x86. each one with their own idiosyncrasies. (sigh) However, this leaded me to another elephant on the room, and Unity is screwing up KSP (and other indie developers) on this too. Recent Steam's hardware surveys states that the games machines are aging, a not unexpected effect from the current economical situation - employment issues, inflation, electronics shortage, you name it. QuadCore machines like the one I own and can't run KSP 1.12 are still the most popular machines on Steam, and besides 6 cores CPUs are starting to catch up, it's reasonable to assume this will take at least a couple years more than everybody was expecting to happen. It's 38% of the installed base, by Turing's sake. An Indie game like KSP just can't lose these guys (hell, even mainstream games, as it will be KSP2, can't afford to loose them). Right now, from my developer point of view, Unity is a terrible option for any potential Indie project I could start. Godot may be even worse, but the "may" keyword implies that it's already a better option (as it at least gives me hope it may not, something that Unity does not), at least for my purposes: I don't aim to expend my free time trying to help users to survive Unity crashes forever, something this forum is virtually littered with. Frankly, I expected Unity would have professionals working on these issues on their paid time, not random Internet dudes like me burning free time. If by any chance this is related to the subjects I'm talking about, I'm afraid this "Unity Bad" statement is a gross misrepresentation of what is being said here.

Uh, nope. The patch: @PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[#antennaType[INTERNAL]]] { !MODULE[ModuleDataTransmitter] {} } Is not working as you intended. It is issuing the MM warning: WRN 21:53:31.364] more than one :HAS tag detected, ignoring all but the first: /Axel/@PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:HAS[#antennaType[INTERNAL]]:FINAL What essentially says that your path was degenerated into: @PART[*]:HAS[@MODULE[ModuleDataTransmitter]] { !MODULE[ModuleDataTransmitter] {} } What means that you will remove the module from parts not intended to have it removed.

But the less, the better! It's a trade: features for problems. Too much problems, and the features doesn't matter anymore. That's interesting - I really enjoyed the new wheel model. Way more plausible and fun to mess with (working suspensions! this is great!). But I agree that they took a bit too much to iron out the idiosyncrasies on the new model - but guess what, it was not the wheels code, it was something else that ended up screwing up the wheel's code. Ultimately, also related to Unity (but, granted, not necessarily Unity's fault). In the end, you need to use the right tool to do the job right. IMHO, KSP had grown bigger than Unity, and this is not the first time I say it. However, this doesn't means that using Unity for KSP1 was a bad choice at all (and this is not the first time I say it neither). I sincerely doubt KSP1 would had reached this absolutely amazing success had it be built using a C++ centric 3D Engine. Point. But I also think that at this stage, Unity is the thing pushing it back nowadays, IMHO KSP really had overgrown Unity, and this is not KSP's fault. And probably neither Unity's, it never aimed to be a full feature space physics simulator to be used by Universities or by people to run NASA's code. It only happens that KSP is being used as a fast prototyping physics space simulator by Universities, and there's people really running NASA code on it. Sooner or later something will snap. As I use to say, choose your poison: what matters more to you? What's going to matter more for KSP2? (You can't have the cake and eat it too, after all). It's my feelings too. And one of the very reasons I don't see (at least for now) too much value for KSP2 on still use Unity. If they have the intention to at least try to support other platforms, however, I may change my mind - but yet, Unity has competition on this niche, and I think it's time to people start to consider it (at least for indy projects, since Unity aims now to be "mainstream" nowadays, as it appears). Neither on be wrong on have such concerns. And when we manage to create an environment where concernings are tackled down instead of concerned people, things get even better. Yep. Features versus problems. The new features we got with modern, preemptive task switching on a memory protected model are way more valuable than the efforts we had to expend learning how to cope with them. And believe me, it took a lot of time. Most people don't have the slightest idea the damage the first Pentium IV with Hyper Threads made to the marked, tons and tons of really bad code that were abusing the multi-thread model only worked on single core CPUs. And then lots and lots of really bad code were written that only worked on HT CPUs - not a really good idea when about 80% of the userspace was still using single core ones. (been there, diagnosed that - that stunt was one of the reasons for the shutdown of a million USD project, by the way. And I'm talking 2008 USD here. Do you see some resemblance with some other problems we have nowadays?) KSP2, as far as I know, aims to be pretty different. They told us they will implement an proper API for modding, and that hacking on the engine will not be necessary (and perhaps, not even tolerated). And, frankly, this is one less reason to stick with Unity, IMHO. So do I. Experience on the field tells me that I'm mostly right than wrong, but by all means this isn't the same of being always right. And there's nothing wrong on being wrong, by the way. Sometimes, it's even preferable to be wrong (as in the current subject).

Good. Please don's use it on me so.

TLA crashes, Joysticks not being recognized on Linux, random crashes, terrible performance (worked around by hacking the mono runtime) you name it. Unity is one of the worst problems KSP has for years already. Granted, it's not the only one. Yep, on that there's no doubt. But, frankly, how useful is an engine where indy developers need to reimplement things in order to offer a good product? You see, Unity - AFAIK - aims to make things simpler for the developer. If the dude is going to reimplement the World, would not be better to use Unreal Engine, id Tech or something else? On the other hand, Unity allows you to "easily" target Linux and MacOS - what is an edge for indie games. Programmers are committed to the task, not to the product (or the users). They will gladly kill the product by "fixing" a problem completely disregarding if it will hinder the users - sometimes, users just want the "bug" - as the unorthodox assets loading used by KSP1. Make no mistake, a huge lot of add'on authors rely on this one. And add'ons are one of the best features from KSP1 (see the Wired article I posted above). Since KSP2 is aiming beyound the indie market, it's reasonable to believe that some of the "terrible" characteristics that KSP1 users love will probably be gone, so it's reasonable to have them worried about it. Since programmers usually ignores users's wishes and demands, favouring technical details over user satisfaction (and we have some text book examples on this very thread), it's reasonable to believe that perhaps KSP1 lovers would not be completely satisfied on KSP2. Mac and Linux ones will not for sure. Since Unity plagued KSP1 for years with some really nasty bugs that appears to hit random users, and Unity bugs they are (this forum is plenty of evidences about it), and since it's reported on this forum that Private Division is (was?) helping Squad on some KSP1 issues, it's reasonable to believe that if PD was aware of such problems, they would be helping to fix them. Since the problems still happens on KSP 1.12 (worsen, by the way), it's reasonable to believe that PD is not aware of such problems, and so KSP2 may be plagued by them too. It's really a surprise there're so many KSP1 users worrying about KSP2? These guys play KSP1 for almost a decade, give them some credit. Neither do I. I'm liking what I'm seeing in their videos. However it's what we are not seeing the source of concernings, see the OP.

You are wrong. Sorry. Unity, now, it's my worst source of performance problems on KSP 1.12.

Whoops. It was not NASA, it was the University of Alabama. The paragraph immediately followed one talking about NASA and I ended up mixing the information. Sorry for the memory failure. https://www.wired.com/story/test-out-next-gen-space-tech-kerbal-space-program/ The information I have is that they were supporting each other on development (ksp2 devs giving a hand on ksp1, and vice versa. It was published here on forum sometime ago. But using the same engine does.

Bell X14 VTOL Interesting Kerbal. Wondering if the Junos would be powerful enough for a replica.

The smallest company I worked was contracted by Nokia, at that time the biggest Mobile maker in the World. We also made games to Samsung (C3300 was one of the phones I targeted, if memory serves me well), and this game used licensed material from a really big Entertaining Company) to be bundled on a promotional models sold on the whole country. At 35USD, these cheap phones sold as water - but, obviously, I don't have a clue of how many were that promotional models I coded the game. At that time, Android phones were still fighting for the limelight and were expensive as hell, so Nokia and Samsung were still a thing on the market. I can tell you in details how was to work for these two different companies. The shop was localized over a bakery - hell, that (wonderful) smell on the morning, I must had earn 20 pounds at that time. Even by walking home at the end of the day trying to lose some. You see, you guys are not the only ones in town. What I fail to understand, however, is where this liquiding context matters to the subject at hand. Unless you have privileged access to the binaries (and so, please be cautions about the NDA you signed), what you have seen is the game running on developer's workstations. As long they are aware of some some less than ideal decisions on Unity and had a workaround for them. Some decisions on how to handle multithreading are way less than ideal, and even beefier machines are being harmed somehow by them. And since the workarounds are terribly counter-intuitive, it's not impossible that they could be caught with their pants down on the subject. Since I have notice that they are helping on KSP1 development, and since KSP1 is somewhat messed up on performance on some still popular architectures, I think the OP concerns are pretty valid. On that, I agree with you (except by the leak). However, it was exactly that extremely unorthodox loading scheme one of the reasons for KSP's huge success. This is extremely modding friendly, and mods are (was?) one of the cornerstone of the game. But there are some vast opportunities for improvement, no doubt. However, I disagree about the memory leaks. Memory overhead are tied to less than ideal coding (been that, screwed that) but also due that very multithreading bad decisions I mentioned, that ended up screwing the garbage collector itself. Some leaks appears to be related to this too - with less cycles available to the GC, it does a less than ideal job with the time it have. But usually leaks are related to coding problems, what I agree with you are not expected to happen on KSP2 (at least, until mods start to be made for it).

It's exactly the other way around. And yet, KSP1 has inspired some of the most specialized professionals on the aerospace industry. NASA uses KSP1 for fast prototyping some ideas, just for starters.[Nope, it's the University of Alabama, see my post below...] It's not about how much money you put on it. It's about how you use the money you put on it. People love results, not the money you spent. As Boeing/Starline versus SpaceX/Dragon 2 ? Big Corps also screws up. Badly. See CDPR Red. There's no such a thing as "Too Big to Fail" anymore, you can lose your job by buying IBM if the thing doesn't work nowadays. I don't know if KSP2 will be a huge success, a flop or will have just a moderate response from the market. But I know that whatever it happens, it will be a direct consequence from how money is spend there, and not how much.

As a matter of fact…. And I on my counter proposal! They are molluscs that evolved into a higher form of life using hemocyanin on the blood - they virtually have blue blood, what on a yellow flesh give them the green colour.

Hi! This file sounds like something made by third-parties, the stock installation don't have it, neither the Deutsch localisation depot (I use Steam, I downloaded it using the Steam Console). Probably a left-over. Out of curiosity, what's on that file? You can probably ignore it, but since it's an "alien" artifact contaminating stock assets (GameData/Squad and GameData/SquadExpansion ideally should be considered sacred land), the ideal solution IMHO would be to remove it - assuming this is not needed by some sacrilegious 3rd party add'on - since the curiosity on checking what's inside of it.

Hyperspace. Clever trick, it replaces the default BinaryReader constructor with one that creates a bigger read buffer, and this speeds up reading things, as you less IO commands for the same file. At that time, there was a gotcha, however. Apparently this thing was affecting BinaryWriters too and this was kinda annoying when you are debugging things and monitoring the KSP.log, as the file buffer gets bigger too and so the flushing happens with really large amounts of text at once. ideally, the developer should trim the buffer size to the kind of file he/she is dealing with. Large blobs read at once will benefit from large buffers, but big files made of many, many small chunks of data (as databases) are better served by smaller buffers.

[snip] Some of the biggest companies on the World were born from garages, dude. And they shadowed most of the "reputable" manufacturer out there.

That may or may not be enforceable, depending of the country the guy is (exactly as the software licenses, by the way). Did you ever checked what would happen if you try to get permissions to track data from kids under 13? Unfortunately, it's not that simple. There's the P/R factor. Being involved on a lawsuit even when you are right and can prove you didn't did anything wrong still hurts your reputation, and reputation is something expensive to fix. I agree. Unfortunately, things takes a lot of time to get fixed - and we still need to keep our lives going on in the mean time. So some compromise is needed. Me too. And exactly by that I understand his motivations, besides not agreeing with them. You can be "wrong" and still have good reasons to be "wrong" - sometimes, all we can do is to try hard to be the less wrong possible given circumstances we have no choice but to cope with. Not exactly. KSP is great because, besides some disagreements that could theoretically ended up in a Court of Law, the absolute majority of people here puts the game above their personal feelings, and almost every time we settled up on doing what's right in a way or another. What makes everything here be so great is not the absence of problems, but the willing to fix them how we can and do better next time.

It's in Beta yet. It's perfectly safe for use (the Alpha ones are potentially harmful), but it have an issue that prevents it to be published widely at this moment: by some reason that I still don't understand, the Revert to Launch resets the plume to the original scale… You can save the game, load the game, switch between vessels, revert to editor and launch again, no problem. But if you Revert to Launch the plumes are descaled, and I just didn't found the reason yet…. (working on it as RL allows)

Hi, Guilty as Charged, Your Honor. Sorry. What happens is that, on KSPIE, TweakScale is made unavailable* for new crafts when full third-party modules support is not available (existing crafts and savegames are preserved, but as is - use them at your own risk). Currently, this happens when you have Waterfall installed, but not the TweakScale Companion for Visuals, that would provide support for scaling the plumes - and scaling engines without scaling the plumes was considered undesired by KSPIE. Your current choices are to deinstall Waterfall or to install TSC for Visuals. One of that will make TweakScale available gain for new crafts. *obs. Since 2.4.5, TweakScale provides ways to "soft ban" scaling on some parts at System's Integrator discretion (i.e., TweakScale never soft-ban anything, it's up to third-party authors such decision). It's called soft ban because it does not screws up any already existing crafts and savegames, but prevents TweakScale from being used on new ones. This was originally intended to be used on Challenges where some (or all) parts should not be TweakScaled (preventing the need to uninstall TweakScale for playing such Challenges), but this stunt found its way into situations where systems' integrators found undesirable to allow TweakScale to be used punctually by other reasons.