Lisias

DAMN! I screwed up the merge. KSPe should be a dependency only on the Beta branch, not the mainstream! As you will observe above, I'm nailing the problems as follows: 1st Check: something changed on KSP 1.11.x, and the code cleanup I did on TS probably removed some crappy code that was masking it. I will check the change log to see if this is not something I had already fixed but forgot about. EDIT: Nope. I never handled it before, this really caught me with my pants down... 2nd Check: By some weird reason, when using Auto Scale, by attaching the part back, all the parts (original and symmetries) get scaled to the size of the parent (as expected). But the root part keeps its resources as is was still scaled. This one is my fault. I forgot to send a Message to KSP-Recall to rebuild the Resources cache. You will note that the only KSP versions affected are the ones that need Resourceful to be applied! EDIT: While fixing #282 (see below), I detected that once Auto Scale started to behave nicely on KSP <= 1.10.2, on 1.11.2 it started to behave exactly like #283. I think KSP 1.11.x screwed up royally this.part.symmetryCounterparts I'm inspecting your logs and will redo the tests your way now. In a way or another, I had to withdraw 2.4.6.20 . Too much hassle, I will issue a 2.4.6.21 as soon as I fix the KSPe mishap, the fix for the "2nd Check" (it should be a easy pick) and whatever I need to do to survive the mess KSP 1.11.x brought to me. I think your issues are the same, being the reason I intend to reproduce "your" way on KSP 1.12.5 and then on 1.10.1 to see what happens. — — POST EDIT — — Yep… It's it. The symmetry handling was broken on KSP 1.11.x , but since I was still forcing my hand on things by brute force, I didn't detected it. Once I removed that half baked solution I had coded, the problem ceased from being masked by it and so… https://github.com/net-lisias-ksp/TweakScale/issues/283 And since we are here, this one is on me: https://github.com/net-lisias-ksp/TweakScale/issues/282

That's the problem: I'm easily reproducing this on KSP without B9PS installed. B9PS is just an innocent bystander yelling about something else hitting him by behind. TweakScale appears to be the hitter, but I can't rule out something else inducing TweakScale to the err, because… Hell, this damned thing is working on most test beds I have (1.4.3, 1.7.3, 1.8.1, 1.11.2 for sure). Anyway, this is how I reproducing the problem now, using a pretty clean KSP rig only with Recall and TweakScale: Start a craft using MK1 LF Tank Place a second MK1 LF Tank radially, using symmetry (I'm using 3) Scale the original radially attached tank once. All the clones scale fine Scale the original radially attached tank again All the clones are not scaled right, they retain the previous RESOURCES settings. Then I made another check, starting from the point I left : I detached the original radially attached tank Attached it back two more clones are created All parts are descaled back to the original size But the original tank retains the previous RESOURCE settings. I reproduced this on KSP 1.12.5. I will check this behaviour on previous KSP releases I still have around to confirm if the problem is on TweakScale, or if this is something new. Or both... — — POST EDIT — — **NOW** I could reproduce the problem deterministically on KSP 1.11.2 too. Checking all the others. — — POST POST EDIT — — I got things right on KSP 1.10.1. So I'm guessing something changed (again) on Editor on KSP 1.11.x (probably .0 , but I don't have a working 1.11.0 test bed anymore). This ruled out (apparently) TweakScale of any wrongdoing, it's something "new" that happened on the 1.11.x series that, somehow, my previous crappy code was making. Now that I decided to "trust" ModulePartVariant, KSP's Editor (apparently) decided to strike back in revenge. I had already saw this movie before - or one pretty similar: Editor is squashing current's part data with prefab's again. I will keep testing things down to 1.3.1 just to be absolutely sure about this working theory - this can be also a race condition unadrevtidly created by TweakScale's code since ever and that I uncovering now. If I'm right, I will probably detect an anomaly or two sooner or later by going back KSP versions, as each version added or removed something from the Part's Life Cycle and this would have some effect on the race condition. Still working on it. I need to be reasonably sure about the race condition or the Editor's prefab squashing because the solution for the problem will differ accordingly. — — POST POST POST EDIT — — Interesting. On 1.9.1, the first part of the test (scaling the radially attached thanks) passed, but the second (detaching e reattaching) failed. Redoing the test (both this time) on 1.10.1, From now on, I will just update the following table as I do the checkings (1st check is the scaling the radial tanks twice, the 2nd is detaching and attaching again): KSP 1st Check 2nd Check 1.12.5 Fail Fail 1.11.2 Fail Fail 1.10.1 Pass Fail 1.9.1 Pass Fail 1.8.1 Pass Fail 1.7.3 Pass Pass 1.6.1 Pass Pass 1.5.1 Pass Pass 1.4.5 Pass Fail (!!!) Pass 1.4.3 Pass Pass 1.4.1 Pass Pass 1.3.1 Pass Pass Note: the 2nd Check on 1.4.5 didn't really failed, I messed the test myself. Doing the check properly 'fixed' the results

Send me your KSP.log and I will check what happened - TweakScale usually logs a cry for help there, telling what had happened! I confess that odd it was the damned stunt doing the trick on my side. Just for the sake of curiosity - did reproduced the problem on an almost vanilla installation? (KSP + DLC + KSP-Recall + TweakScale) That's absolutely weird. I will do some more checks. Can you send me a new KSP.log from your rig after reproducing the problem? How exactly it stopped to work? Do you see a TwesakScale icon on the toolbar? Or it's a functinal problem (i.e, TweakScale is there, but it's not working as expected, perhaps with weird behaviours)? I'm curious about these problems, because I did tested the thing (in multiple KSP versions!) before releasing it. I need to find a pattern. Please send me your KSP.log in a way or another, so I can see what's installed on your rig and check for anything smelly.

I hate grammars. Thanks for the tip! Something is resetting their PAWs on every frame, so I can't replace some actions from the Tourist (they are Tourists, not regular Kerbonauts!). I will reach my notes and open a github issue on KT/L with the details and I will mention you there. Thanks!

Not necessarily, they choose to keep their SpaceDock entry. I'm working with CKAN guys about it from now on! Cheers! (and thanks again, @whale_2!!)

Thanks! Other than some rebalancing on training Tourists because I created lots of new easier contracts, yes. Geez!! I forgot about! Working on it!!! — — POST EDIT — — I reached whale_2 in a private message about the subject. As soon as it answer it, I will take action accordingly!

Until 2.4.6.19, I was screwing (and being screwed back) by ModulePartVariants. The first time I implemented support for it, I thought that some weirds interactions I was having in the code was due some idiosyncrasy (or plain bug) from the PartModule itself. I think I managed to kick this thing trough the doors on the KSP 1.6 times. Now, back to the problem at our hands on B9PS: I managed to reproduce the problem Any part with B9PS switching fuels is being affected, so CryoTanks is out of the problem - but you already knew it. But I reproduced the problem after uninstalling CryoTanks, CommunityResourcePack and Dynamic BatteryStorage just to have hard evidence of it. You are right - when you scale the original tank, everything works fine. When you scale a clone, only the resources of the clone gets recalculated, the other two keep the last values before the scaling. KSP-Recall is not involved on the mess, I removed it from the parts with B9PS and the misbehaviour kept happening. On the bright side, apparently B9PS doesn't needed it. So I will remove KSP-Recall's AttachedOnEditor and Resourceful from parts using it and save some memory and CPU cycles. My code on the Scaling Engine for ModulePartVariant was innocent anyway, because B9PS removes the ModulePartVariant from the Part, and then TweakScale reverts to use the Classic Scale Engine - and this one is solid for almost a decade by now. So the change in behaviour is happening because I gave up trying to be smart and decided to rescale the whole part all the time on Editor, instead of doing it only when I thought it was needed - this commit is the only thing between .19 and .20 that could be influencing on the change of behaviour. Humm.. Perhaps B9PS is innocent, and it only happens that you noticed the problem by using it? So I fired up an almost clean KSP 1.12.5 (only TweakScale 2.4.6.20 and Recall) and reproduced the problem the same. Damn. Worst. It's happening also with parts without ModulePartVariant (Mk1 LF Fuselage). Danm²: Start the craft using a MK1 LF Tank Attach another one radially using symmetry (I used 3) Scale any cloned tank (do not scale the original one). Problem reproduced: by opening the PAW of every tank, you will note that at least one of them will have the wrong fuel capacity - most of the time, only he one you scaled up will be fine. And interesting… If you use Chain Scale (and scale the root part), all the parts are scaled correctly! But… Such a marvellous bork would be detected while development. So I decided to make regressions tests on 2.4.6.20 into other KSP versions too (I usually develop on 1.4.3 and test things up, because KSP 1.4.3 is fantastically faster on my old potato than anything newer!). Hell, the damned thing worked fine on KSP 1.4.3!! Damn³!!!! (not a surprise, right? I would had detected the problem on it) Tried it again on KSP 1.8.1 : Works fine!! Tried it on KSP 1.11.2 : Works fine!!! So this is a new problem introduced by KSP somewhere on the 1.12.x series, apparenlty. I don't have 1.12.0 neither 1.12.1 installed anymore, so I tried it on a 1.12.2 test bed that I forgot to delete: It worked fine!!! That's weird… This kind of bug usually happens on the .0 release. Something wrong is not right here... So I tried again on 1.12.5 (didn't had touched that thing since the last test a couple hours ago). And the problem was there... Confusing. Why only my 1.12.5 is being screwed by 2.4.6.20? 1.12.2 worked fine. Then I noticed the TweakScale button on the toolbar was greenlit - and I remembered that on all the other tests, that button was turned off. Then I thought to myself, what a wonderful world… I mean… "Nooooooo… IT CAN'T BE….". And then I clicked on it twice - don't even unchecked anything. Guess what? The problem vanished!!!! So that's the "fix": open and close the TweakScale's Option Menu and everything (apparently) will be fine after!! At least on an almost pure stock rig. @AccidentalDisassembly, please reproduce the problem using B9PS and try my "fix" - right now I need to take some rest, it's still working days and I just had recovered from a nasty flu (I'm wasted, to tell you the true). @Sokol_323, the problem you described here may be related! If the problem you reported ever happen again, try clicking the TweakScale button twice to see what happens (do not bother setting or unsetting any options!). My current working theory is that I forgot to initialise something when one (or all) of that Options are set when booting KSP! I will investigate it further on this weekend! Cheers for all, and thank you for your reports! That one I would never caught by myself!!!! Cheers!

NOTAM I just released the latest BETA for the (now) near coming TweakScale 2.5. A huge refactoring was finished (I think the last one before - if I ever - start to think on TweakScale3), and I need to have this tested on the field in order to check for any unexpected problems these change may cause. I reverted a (now) old decision on using :FOR[TweakScale] in the standard patches. In these two years, very, but very few Add'Ons had adopted the needed protocol to prevent breakage (i.e., using :AFTER[TweakScale] or even :FINAL when in need to change a TweakScale standard behaviour). So that ship has sailed at this point, and the Right Thing™ will just not happen anymore. "Vida que segue." On the bright side, TweakScale 2.5 BETA is now completely free of any "alien" code. To tell you the true, not even Stock and DLC specific code is there anymore, everything is now on the specialised DLLs for each KSP version. I finally made TweakScale's Scale Engine completely game agnostic (with some obvious limitations, as it still depends from the KSP's life cycle and GameDatabase!). This means 100% clean 3rd party support without the weird shenanigans I had to code in the first TweakScale Companions (some of them will be soon™ rewrote to this new programming interface), and I now have a decent place to shove any Robotics specific code I need to prevent a myriad of problems from being escalated by TweakScale (and without risking screwing up what works fine). I suggest to anyone willing to risk their SAS with this stunt to have TweakScale Companion "ÜberPacket" installed, as I'm removing even the alien patches from the standard distribution into the Companions - and some ones, like Firespitter, will cause crashes without the specialised support from the respective Companions. Links into the spoiler below: Keep in mind: you are using a BETA release, and things can go down trough the tubes pretty fast if any mistake had passed trough. MAKE BACKUPS of everything to be on the safe side, and use them instead of your main gaming files. Ideally, you must be able to remove TweakScale 2.4.x series from a game, install 2.5 and the TSC ÜberPacket and things will just keep working as nothing had changed (other than some improvements on the new patches). But this is what I'm intending to do, what may not be exactly what I effectively did on this BETA release. So, again, MAKE BACKUPS if you decide to help me up with this BETA. And don't risk your valuable savegames on it. Please report any problems, anything, on the issue #42 (lucky number! ) on TweakScale's issue tracker. IMPORTANT NOTE: You need to use the 2.5's 999_Scale_Redist.dll (versioned to 1.2), completely replacing any older on GameData, or nothing made for 2.5 (including itself) will work. Everything compiled using the older 999_Scale_Redist.dll (versioned to 1.0) are expected to work fine, as the new Scale_Redist is backwards compatible down to the first one from 2013. Do not compile anything against it, however - remember, it's still BETA.

Ah, Fuel Switches! That's the thing: TweakScale needs to be taught about Fuel Switches, so things would work as you (reasonably) want. Problem - historically, shoving 3rd party Fuel Switches support directly into TweakScale leaded to tons os bugs - you fix something for a dude, another one to two got screwed. You rush to fix one of these two, you screw up the first and make things worst for the second... And B9PS had earned me a huge lot of headaches in the past by doing exactly that. In special, when B9PS detects a second Fuel Switch on a part, it refrain itself from working on that part, but it keeps handling events from people that needs to announce or asks things to/from it, causing breakage. Breakage that leads to a support fest to innocent add'ons that were just doing what they are expected to do! It's the reason "Stock" TweakScale only supports Stock + DLCs and that's it. However… This doesn't means that 3rd parties will not be supported. It only happens that such support was delegated into specialised "add'on' add'ons", called TweakScale Companion. You will find more on the TweakScale Companion Program's thread: In time, I just incepted the TweakScale Companion for Fuel Switches here. However, this only works on the TweakScale Beta branch - that soon™ will be promoted to the new 2.5 TweakScale series. I had made some heavy refactoring on TS to allow easier and better coping with such more exotic PartModules B9PS is the next on the line for being implemented, I'm planning to have it working when I launch 2.5 into the main stream, hopefully in the next few weeks.[Not anymore: just realised that B9PS handles TweakScale itself!!] — — — POST EDIT — — — Not a problem, but please remember that TweakScale doesn't supports anything but Stock + DLC. Anything else will be supported on a specialised TweakScale Companion, and currently I didn't wrote one for B9PS. Yet. Once I publish it, then please file bug reports on the thing! — — — POST EDIT² — — — Humm… Perhaps this is related to KSP-Recall ? Since KSP 1.9 Editor is royally screwing up TweakScale by resetting things to the prefab on some circumstances and since this is a KSP issue and not TweakScale, I solved the problem on KSP-Recall so TweakScale could focus on its core business instead of trying dark magic to workaround them (and this was another source of immense headaches for me in the past - things got infinitely better when I decided to handle KSP idiosyncrasies on KSP-Recall instead on TweakScale). Since B9PS probably had to cope with the same problems, and probably decided to work around it themselves, they are probably having the same problems TweakScale had in the past - i.e., a toe stomping fest between more than one add'on trying to save the day at the same time. Try this on the affected rig (save it somewhere in GameData, I suggest GameData/__LOCAL/KSP-Recall/B9PS.cfg to be easily findable later): @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FINAL { -MODULE[AttachedOnEditor] { } } Let me know if this solves the problem for you - if yes, it's KSP-Recall the one that needs to be updated!

NOTAM KAX is working on KSP 1.12.5. I failed to manage time to do proper playing, I mean, testings (working heavily on TweakScale, and still have Day Job® and Real Life™ to cope with), but the thing passed trough the Smoke Tests. Remember: Firespitter is an optional dependency, but believe me: you want it installed Install Firespitter Core at least. If you have TweakScale installed, you need to install TweakScale Companion for Firespitter!! Or just install the TSC ÜberPacket and forget about!

ANNOUNCE Release 2.4.6.20 is available for downloading, with the following changes: MOAR bug fixes! Updates KSPe.Light with yet moar bug fixes. Closes Issues: #261 Misbehaviour (again) while scaling parts with VARIANT #238 TweakScale is failing to consistently resize the Attachment Node’s sizes. I finally nailed the Editor's Attachment Problems!!! #hurray!!! Now you can change variants, do duplicates, multiple subassemblies radially, etc on "inverted parts" (turning them 180º) without worries on Editor (it never was a problem on Flight Scene). This freaking bug was pesking me for years and, frankly, things just started to fall in their places after working on KSP-Recall - where I could have a glimpse on how and where things get screwed on KSP, and what Squad did to fix or at least workaround some things. And then it finally passed trough my dull, thick skull: ModulePartVariants is working fine (or didn't misbehave on the test beds I built for this problem). Editor was the one royally screwing things, and all that code I wrote since 1.4.5 times (when the MPV really started to kick in) was coded around an Editor's bug, not over a PartModule one. TL;DR: I was fighting the wrong code - once I stopped trying to be smarter than ModulePartVariant, it stopped fighting back and, then, KSP-Recall did its job on Editor. Fixing bugs by removing code is, well, embarrassing. In a way or another, this was the last major bug on TweakScale. Now I can, finally, be back on doing real improvements on TS. I will soon™ publish a new Beta release with some serious refactoring which will allow me to work better and faster on supporting 3rd parties futurelly - things on the Companion Program will start to develop faster once 2.5 reaches the main stream - and I'm considering speeding it up by reworking the ROAD MAP to postpone some things in favor of other ones. Disclaimer By last, but not the least... 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). A bit less Soon™. 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.

Humm… The Near and Far Future mods from Nertea have some pretty aged patches on TweakScale distribution, kept there to prevent breakage on existing crafts but, frankly, I had deprecated them for a reason. On the bright side, TweakScale Companion for PKMC have (probably) up to date, pretty fine patches for them! Alternatively, you can download and install the TweakScale Companion ÜberPaket here (CurseForge - CKAN is pending acceptance). The ÜberPaket is the easiest way to have TweakScale support because it have them all (or, at least, the ones that are proven in the field - no bleeding edge on this one). Install the ÜberPaket or qhe TSC_PKMC if you prefer, and check it again. What you are describing is looking as a "defaultScale" too big. If you are attaching a 1.25M fuel tank on a 5M one, but the defaultScale is messed up and someone shoved an 7.5M instead of 5, then you will have the behaviour you are describing, But this only happens if you choose Auto Scale or Chain Scale (the TweakScale icon turns green when at least one of these options are enabled). If you are absolutely sure the Green Icon on TweakScale is not there, and still the small parts gets automatically scaled up this way, I think we may had found some toe stomping fest with a 3rd party. In this case, please reproduce the problem and then send me both a craft file with the broken thingy and the KSP.log (quit KSP first to avoid having the log truncated). Additionally, I'm publishing right now TS 2.4.6.20 with a pretty importing fix that perhaps may solve your issue! Check it out here. Cheers!

Very interesting concept - and highly kerbalizing, I think!

Sorry, but nope. It's not a bad idea. but I'm unsure If I will ever work on it. But, I at least I will not forget about it neither! https://github.com/net-lisias-ksp/TweakScale/issues/275 The "problem" with sounds is that they don't "scale" exactly (no one wants a 186 dB sound effect coming from their speakers!) - I would need to change the pitch, but also how far the engine can be heard. But it sounds (pun not intended) like a nice idea, worthing of at least a try! Cheers!

NOTAM I just published a new deployment model for the TweakScale Companion Program: the Überpaket!! For a long time I had received complains and suggestions about how TweakScale did things in the past, delivering to you everything and the kitchen's sink into a single, monolithic package. I will not discuss about the reasons TweakScale the main package only supports Stock and DLC nowadays, but you can find the reasons on this PhD thesis I wrote some time ago. The way I found to support 3rd parties without being screwed up was the TweakScale Companion Program - specialised Companions grouped by thematics or features would be the tool for specialised TweakScale deployment into the wild. But not every one liked this model, and I agree that it can be a bit cumbersome without some tooling to help on sorting the mess. Problem: such tools didn't existed at that time, and unfortunately still don't exist today: no widely used deployment tool (used by this Community) supports triangular dependencies solving, ie, a mechanism to automatically install something if two or more other things are also installed (but not just one or some of them). On the absence of such a tool, my hand was forced into kinda going back to the Monolithic Days - but, this time, made right. Every single Companion was created from the start to be allowed to be installed without the target add'on presemt and do not give problems to the user. Other than a bit of disk-space used (and a bit of time on patchez being removed by Module Manager - what is solved by the ConfigCache!) and some memory wasted by the stub dlls, no harm is done. Point. And on the exact instant the user installs one of the target add'ons, the thing cames to life and just works. These stunts costed me some long coding nights and a lot of experimental releases until I finally nailed them right, and I admit I'm pretty proud of this accomplishment. The Überpaket is currently available on github, and I'm working on CurseForge, SpaceDock and CKAN on this exact moment. The versioning number will differ from the Companions (and TweakScale), I'm versioning it using the release date of the most recently published Companion, currently 2022.05.22.0 . Any fix needed on this release will be issued incrementing the build number. This package will not be updated too much, I'm planning doing it once a month tops (unless I screw up something). Each Companion will be available separately, so I will update the Überpaket only when some (more than one at least) Companion is updated/created or too much time passed since the last release and there's something new. Users willing to be kept on the bleeding edge should use KSP-AVC (the full one) in order to be kept up to date with the individual Companion Releases! Cheers!

Announce! TweakScale Companion is, now, also being distributed as a über mega package with everything (and the kitchen's sink) included for the lazy installers !! This package will be updated (more or less) regularly, Download here or in the OP. Soon available on CurseForge, SpaceDock and CKAN. Currently available on CurseForge and SpaceDock. CKAN is waiting for approval.

@AccidentalDisassembly had nailed it, but you can find a walkthrough about the subject here: https://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch/Part-01 https://ksp.lisias.net/blogs/tech-support/TweakScale/How-to-write-a-patch/Part-02

Reproduce the problem and send me your KSP.log. If something wrong is happening, it will be there. Also, send me the craft file exactly as it was after reproducing the problem. Remember to quit KSP before fetching the KSP.log, otherwise it may be truncated, ruining the diagnosis!

Check if you have the AutoScale option set, by looking into the video I noticed the TweakScale Icon on toolbar is greenlit! Cheers!

Yep. This is going to be tackled down on https://github.com/net-lisias-ksp/TweakScaleCompanion_FuelSwitches - unfortunately, I didn't had time to kickstart this project yet, as I'm getting my SAS mercilessly bashed but some stupidity I did while handling ModulePartVariant. There's little to no point trying to support B9PS before properly support ModulePartVariant first… On the bright side, last weekend I finally detected exactly what I did wrong on the Beta branch, removed a lot of code that became redundant and only expanded my surface of exposition for bugs. I'm making something wrong on getting the right attachment point from the Variant. Anyway, still on the fight. You know, this is a hell of a relief.

Found this one today. Not bad! Bicicletes, from BLAUMUT. (don't ask, never heard of them before!)

Everything TS shows you are colour coded as follows: RED Something potentially destructive, you should take this seriously. Now and then it is a bit overstated because such situation may not cause immediate damage right now, but it caused carnage in the past and until I have time to recheck this thoughtfully again, I prefer to err to the safe side. Yellow Something that you are not going to like, but usually is not dangerous. Like removing TS from parts that are known to be incompatible with TS, but were patched anyway. You will have some disruption if you managed to use these parts with TS in the past, but since these crafts are going to crash the game, you really don't lose anything on it. white Informative things that you probably should be aware, but they rarely gives you any headache. Usually you want to avoid them all, but if you are hungry for the game and got one of these, the rule of thumb is: NEVER load a savegame if a RED message appears from TweakScale. Remove TweakScale from your game if you prefer, but don't use a savegame with TweakScale if it issues a RED message. I prefer to lose an user than a savegame. You can proceed with a YELLOW message, but make constant backups - better safe then sorry. You can ignore white messages (they have a countdown and close by themselves), but it will not hurt to ask about around here and see what can be done as you get annoyed by it. Cheers!

I found nothing like that in the KSP.log you sent. But I know these problems, had diagnosed then before. Both on BDArmory and from ATW. You have incompatible DLLs fighting on your rig. ATW, in special, was already diagnosed by me in the past here. You need to reach BDArmory guys for help on this one. I don't know BDArmory enough to help you here. Found no problem related on scanray on that KSP.log neither. But it's probably something similar, older and newer DLLs of something fighting. Again, only the scanray author will be able to help you on this one. But with a bit of luck, solving the BDArmory problem above may fix this one - sometimes, more than one add'on get screwed by the same problem.

Well, you made a mistake while installing TweakScale! You copied it twice into the GameData! [LOG 19:20:05.933] Applying update patches/SquadExpansion/Serenity/Propellers/@PART[mediumPropeller] to SquadExpansion/Serenity/Parts/Propellers/mediumPropeller.cfg/PART[mediumPropeller] [LOG 19:20:14.954] Applying update TweakScale/patches/SquadExpansion/Serenity/Propellers/@PART[mediumPropeller]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/Serenity/Parts/Propellers/mediumPropeller.cfg/PART[mediumPropeller] See? You unzipped the TweakScale directory into GameData (what's correct), but then you unzipped (or copied - sometimes Windows' UI gets laggy, and a click ends up being interpreted as a drag!) the patches directory inside TweakScale into GameData again, and then you ended up with two sets of TweakScale patches in your GameData! Completely remove KSP_root/GameData/patches and you should fix at least this problem - it's affecting every single Stock part in your rig! I also found a lot of Exceptions pestering BDArmory, ProceduralSRB, Tantares, and another one I didn't recognized (ye8). I don't think all of these exceptions are due bugs on these add'ons, it's more likely that faulty patches screwed up them too, the same way TweakScale was. I suggest you remove all the add'ons from your GameData and started again from scratch, but taking care to avoid mistakes while installing them. May I suggest using CurseInstaller or CKAN? Cheers!

It's not TweakScale. These "tokens 0100006b and 010004f" means that something in your GameData was compiled to an older or a newer version of something that broke the ABI (Application Binary Interface). When this happens, a buggy thingy called Assembly Loader/Resolver inside KSP gets triggered, and from that point everybody that tries to load a DLL or to use a thingy called Reflection borks relentlessly, including (but not limited to) TweakScale. TweakScale is the only one yelling about the problem, but make no mistake, a lot of add'ons also get screwed by this problem - it only happens that most of them ignores the problem and let you get screwed later when you load your savegame with a borked installment. You didn't gave permissions to read the files you linked. Please set them to public and ping me here, and I will inspect the files. Make backup of your savegames. If you insist on keep going besides the TweakScale warning, your savegames will get corrupted for sure!