Lisias

Are you using a MODULEVARIANTPART with mass? Please publish your KSP.log so I can give a peek!

Nice catch. I totally missed this feature, the effects are being scaled backwards! It's consistent, I tested with NERV as you, but also with Reliant and with Terrier. The glitch is less visible on some engines, but it's clearly there! I can't give you a deadline to have this fixed, as I have some more pressuring issues to solve (as to support stock parts at all). But I will tackle this down as soon as I get rid of that pressuring thingies. https://github.com/net-lisias-ksp/TweakScale/issues/27

KJR/L is known to work from 1.3.1 to 1.6.1 . I don't do too much testing on 1.3.x and on 1.5.x, but I do it on 1.4.1 and on 1.6.1 regularly. (and I fired it up twice on 1.2.2, by the way.).

I don't believe. I know it. I'm not really fixing things for now, I'm patching them up to prevent the worst scenarios. There're no easy way out of this. I'm not masochist , I really didn't found a better solution other than that Big Refactoring from Krakens of mine. That's interesting. I will investigate. [Reproduced. See the POST EDIT below] I think this is a good time to explain that Module Manager is not the problem. It only happens that it doesn't have, at least to the momento, any features that would allow it to be part of the Solution (at least, the Solution I managed to cook). The problem are rogue patches. And the only sane fix is to detect and fix the patches. Clutches to cope with the rogue patches will just make things worst, as the clutches themselves can induce new colateral effects in a chain reaction - sometimes without perceptible symptoms until the crash and/or game corruption. Thanks for your efforts. We don't need to agree on every step to recognize the huge efforts you are doing for TweakScale. If a purely stock with TweakScale is borking, you are right on pinpointing TweakScale as the source of the bork. I should had done this again after the new discoveries of past few weeks to tell you the true. What I know for sure is that TweakScale doesn't add itself to any part (and only recently I added code to withdraw itself from some nasty detectable scenarios), so the source of the glitch (to say the least) are the patches. This will be a dirty and gruesome task, but another one I need to accomplish is to test adding the patches gradually (it's a bit less painful using a binary tree search approach) in order to reduce the scope of the hunt. But, on the other hand (and again), that BFR (Big Fine Refactoring ) would render this task unneeded, as Add'On support will be dismembered, drastically reducing the surface of attack for such bugs. So I'm kind of uncertain if I should waste yet more time on patching new roles on the dam instead of solving the thing properly. This is where I'm get some reserves with. This will not fix the rogue patches, this will hide them. The reasons for that follows: A bad standard is better than no standard. It's TweakScale the reference for scaling. Instead of blindly patching it to cope with random Add'Ons, it's that random Add'Ons that should, ideally, be patched to cope with TweakScale. By doing this, everybody will be on the same page. If TweakScale would cope with rogue patches by demand, so we would have no standard or expected defaults to cope with - and that would be a unholy mess of biblical dimensions. It's already hard to cope with the current patches (as you are pinpointing above). Now try to imagine the huge colateral effects we would have by blindly changing the patches. See below for a technical explanation This will not prevent rogue patches to exist. It will make them harder to detect. Right now, it's feasible to monitor MM as it applies patches in order to catch who is duplicating things once you have named a part with double data. It's one of the features I'm planning for somewhat in future, by the way. Without this, I would have to instrument Module Manager itself so he would raise an exception when such part is detected - but this would need to inject more knowledge on MM than it really needs to work, and a already complex piece of software would had it's already huge surface of attack for bugs even wider without not direct benefit for its core business Dismembering the patch support will drastically reduce that surface of attack to manageable levels, as the majority of the users will not be exposed to more patches than they need. This appears to be the biggest lesson we can take from your reports. That technical reason I mentioned is due the way ConfigNode handles "arrays". When you add an array to a ConfigNode, you have a ordered (but not necessarily sequential) collection of data with the same name. You need to use a specific call to get all the values under that name, and if you use the call for singleton values you get the last value. But I'm used to see code that uses the "array version" of the call and then getting the first value (I wonder if by similar reasons). This last scenario would break beautifully if I edit an value that people are used to get duplicated and selecting the first one, and then people start to get the value from the later adders instead of the expected value added by the first one! And since by the ASCII ordering TweakScale tends to be the last guy on the chain, it also tends to be prevalent on that scenario - i.e., any guy that have a disagreement with TweakScale on something and is used to get the first value will get suddenly "wrong values" came from nowhere. So… It will accomplish very few, can potentially break expected behaviour (wrong behaviour, but a expected one nevertheless - remember when I said that a bad standard is better then no standard at all?) and the rogue patches will still be there. And the real problem are the rogue patches. Patches getting old without proper supervision. The dismembering will help on this too. You need to understand a bit about Module Manager patches first. A TweakScale config is nothing more than a patch. Unless you are considering support TweakScale directly, and then TweakScale would be a hard dependency for your parts. If this is the case, I would suggest you to rethink this. Not everybody wants to use TweakScale - this could limit your audience. In my humble opinion, the best approach is to write MM patches for your Add'On and include them on the release, and tell MM to ignore such patches when TweakScale is not installed (see the :NEEDS clausule). Or give a peek on the github directly, and make use of the auto-formatting features of the site. https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/Examples.cfg https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt @Tyko - some text editors are using proportional fonts as default nowadays, messing up beautifully the visualization of the good, old and faithful text files. It's one of the reasons I, by default, use TABs and not spaces on my projects - my colleagues can set up the TAB width in pixels as they want, and (almost) everybody end up happy. — — — POST EDIT — — — I reproduced the problem described above (with a screenshot). Things are a bit hairy, by the way. This is the grep for my KSP.log looking to EnginePlate4 (the internal name for the EP 50): $ cat KSP.log | grep "EnginePlate4" [LOG 00:31:43.977] Config(PART) SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4 [LOG 00:31:44.020] Config(@PART[EnginePlate4]) TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] [LOG 00:31:51.727] [ModuleManager] INFO: Applying update TweakScale/patches/SquadExpansion/MakingHistory/Coupling/@PART[EnginePlate4] to SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/PART [LOG 00:32:32.018] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' [LOG 00:32:32.048] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4/EnginePlate4' has no database record. Creating. [LOG 00:32:32.055] DragCubeSystem: Creating drag cubes for part 'EnginePlate4' [WRN 00:33:17.429] [TweakScale] Removing TweakScale support for EnginePlate4. [ERR 00:33:17.429] [TweakScale] Part EnginePlate4 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13. This confirms my thesis de the MM is not on the guilty list for this problem. I used MM3 by the way, to prevent any worries due the new parallelized patching routines. On the MM cache I found this: UrlConfig { name = EnginePlate4 type = PART parentUrl = SquadExpansion/MakingHistory/Parts/Coupling/EnginePlate_4 PART { name = EnginePlate4 module = Part author = RoverDude rescaleFactor = 1 node_stack_top = 0,0.4,0,0,1,0,4 node_stack_bottom = 0,0,0,0,-1,0,4,0,0,1,0 breakingForce = 2500 breakingTorque = 2500 fx_gasBurst_white = 0.0, 0.0650517, 0.0, 0.0, 1.0, 0.0, decouple sound_vent_large = decouple TechRequired = metaMaterials entryCost = 3000 cost = 300 category = Coupling subcategory = 0 title = EP-50 Engine Plate [ CUT -- CUT -- CUT -- CUT -- ] MODULE { name = TweakScale type = stack defaultScale = 5.0 scaleFactors = 0.1, 0.3, 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 20 incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2 TWEAKSCALEEXPONENTS { mass = 2 } TWEAKSCALEEXPONENTS { name = TweakScale DryCost = 0.5 } } } } Well. we have a problem: a duplicated TWEAKSCALEEXPOENTS thingy. This is fixed on the development branch, and was identified by @Tonka Crash here. The hairy situation is that TweakScale 4.1.0 is detecting the EnginePlate4 as an unsupported part, and then it's withdrawing itself from the prefab. However, the thingy somehow survived to tell the history on the GUI. Twice, as we can see. The double slider appears to be due the double TWEAKSCALEEXPOENTS , but frankly, the while shebang should had been deleted from the prefab by now. Need some time to figure my way out of this. The good news is that a new maintenance release for TweakScale is on the works to have this solved. The bad news is that EnginePlate, as any Part using MODULEVARIANTPART with Mass on the variants, is not supported and the patch will be withdrawn on startup. I'm sorry for this, but this part is one of the probably causes for the KSP crashes due improperly mangled mass.

It rained a lot around here today. To tell you the true, since yesterday night. And some ferocious winds. For 7 hours. This morning, the city was in chaos. Fallen trees (damn it! it's 15 to 20 years for a replacement to grow up!) everywhere. The only place I didn't saw a fallen tree in on the subway - but sooner or later, I will see one there by how things are going here. =/ https://globoplay.globo.com/v/7413061/ (cut the sound - it's all on PT_BR anyway) edit: The counting by now is about 411 fallen green warriors.

Are you using the "Standard" Welding tool? There's a fork (mine!) that (mostly) works for 1.6, so it should work for 1.5.1 (it's 1.5.1, right? Or Squad released an extra KSP on the 1.5 and I'm not aware? ). This is a nut hard to crack. The lights are a Effect set up on Unity's (a "transition" on the texture used for the windows), and there're nothing saying what texture is the "on" and what texture is the "off" - just a setting telling KSP "this is a texture, this is another texture, this is a effect that changes from one to another. Use this one as default on launch". So you can set up the first as "on". And the Welding tool has no way to foresee this. If I remember correctly the code (it's a long time already), the Welding tool just get the last texture on the pile and use it and that's it. The transitions are thrown away. Yes. Manually edit the texture on the resulting CFG file to pinpoint to the "off" one. You will need to open the original part's CFG to see who is who, but other than that, this is not exactly a hard nut to crack. An automated way to do that (or even a way to preserve the effect) however, is a hard nut to crack.

Interesting. I found this on your log: [LOG 16:58:53.954] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\TweakScale\Plugins\Scale.dll [LOG 16:58:53.956] AssemblyLoader: KSPAssembly 'Scale' V2.4.0 Initially I though that perhaps I borked the release on SpaceDock (the reference I choose for CKAN), but I just downloaded it and double checked it, I made it right, This time. It should had been updated in the mean time (SpaceDock is a bit laggy for me today, by the way). Since we are here, please remember: if by any means some craft gets a scaled part reset to the default size, don't save the game neither the craft. (Kill the KSP process by brute force). And ping me here, there's a trick to manually salvage the files.

I just got notice that on the next holidays the block where I live will be out for power for maintenance on the public power lines. "Sweet". Not only I will have one less day to work on my projects, as my Real Life duties will have to be crunched on the remaining time of that holidays. The good thing on living where I live is that a lot of things keep working on holidays. The bad thing is that all them are on the same block. But to add offense to the injury I live on the 13th floor of my (old) condo. So I have 13 flights of stairs to go up every time I decide to go out. So now Im deciding if I get bored to death inside my home, or if I get a heart attack to death on going back if I decide to go out. Vacuuns, Laundry Machine, MicroWaves, even the oven lighters. All useless. I need to check my stock of candles and matches.

Krakens.

@Tonka Crash, @bcqJC, Your contributions were hugely appreciated, thank you. The fixes were applied, you can follow what I'm doing about the duplicated weeds on TweakScale garden. https://github.com/net-lisias-ksp/TweakScale/issues/24 — — — — -- In time, I just get notice that my block will be out of power in the first days of the following local holidays, when I intended to deep dive on TweakScale refactoring. Well, it's one less day to code the thing, but also one less day to do needed housekeeping and other Real Life duties that, then, will leak to the remaining holidays. Damn. (And I live on the 13th floor of the condo - DAMN² - there're 13 flights of stairs to go home after I leave. DAMN³ )

Uninstall half your Add'Ons. Twice. Kidding. I'm on it, I will edit this post as soon as I finish checking your log. — — — — Bad news. You are suffering from the Duplicated TweakScale syndrome. [WRN 21:56:25.870] [TweakScale Warning] Duplicate TweakScale module on part [Decoupler.1p5] TD-18 Decoupler This can be the reason for the following problem on the KJR (that appears to be the real source of the NRE): [WRN 21:21:52.641] [Part]: PartModule KJRDecouplerReinforcementModule at Decoupler.0, index 9: index exceeds module count as defined in cfg. Looking for KJRDecouplerReinforcementModule in other indices... [WRN 21:21:52.641] ...no KJRDecouplerReinforcementModule module found on part definition. Skipping... [WRN 21:21:52.641] PartModule is null. [ERR 21:21:52.653] Cannot find module 'TweakScale' (-699235618) [ERR 21:21:52.653] Module TweakScale threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 I suggest you to update to TweakScale 2.4.1 , that it's handling this "Duplicate" problems on a somewhat saner way. I also noticed that you have "000_KSPe.dll" inside the KerbalJointReinforcement folder. This is not the correct place for it, it needs to be on GameData. In a nutshell: "GameData/KerbalJointReinforcement/000_KSPe.dll" is wrong. The right place is "GameData/000_KSPe.dll" . Sooner or later some other Add'On of mine will bork due this, in a way somewhat hard to detect.

Hot Blondes? I was a kid first time I heard this one. What a impress it made to me at that time. (Bette Davis was a bombshell too, but I had born to late for her ).

Banned for staying away from her… Oh, wait… Wrong thread.

I think the button is working on this fork. https://github.com/net-lisias-ksp/UbioWeldContinuum/releases It's many KSP Versions since I touched this, I don't have the slightest clue how this thing will behave on the new parts and with MH installed. The only thing I know is working by now it's the button. Dependencies: ClickThroughBlocker, ToolbarControl and KSPe. You need to use Module Mananer 3.x, as the 4.x series has internal changes that break Add'Ons trying to use its functionalities the way UbioWeld does. Known Issues: The last time I used this, I was using 1.4.1 without Making History. Any new part from 1.4.2 and forward (and MH) can or cannot works - anything using ModulePartVariant is expected to bork and inject some nasty NaNs on the gameengine. You need to be using a Module Manager from the 3.x series. UbioWeld will not work on the 4.x series for while I detected the problem with the MM4, but I didn't tried to understand it in order to fix it. The easy way out would be undo the MM4 change on that specific spot on my personal fork, but that would break expected behaviour - that guys are the reference for MM. So the logical move is to update UbioWeld to cope with the new MM at the same time keeping legacy compatibility to MM3. I will tackle down this sooner or later - probably later. — — — POST EDIT — — — The MM4 problem was workarounded on this post.

This 23 hours and 56 minutes (and 4.1 seconds) per day stunt of nowadays are a pain in the sas - it's just too long, I get sleepy too soon for my taste. I miss the good old days with 22 to 23 hours per day. That was perfect.

Yep. It's confusing to tell you the true. I got "late" to this thing - on the last quarter of 2018 more or less, I had the need to use KJR, but I was on the 1.4 series already, and Ferram wasn't interested on migrating KJR to it. So I cloned his repo and started to study the thing to adapt it to 1.4. Later I realized that KJR were working fine from all versions of KSP since 1.2.2 (with a binary that I compiled for 1.5.1), what hinted me that in reality, KJR is a Add'On for Unity. Anyway, i found a branch merging Rudolf's code that was been unmerged or something like that, reapplied the code because it looked pretty good and I even added some bells and whistles until someone found it and tried it and then ask me for some help on it. It was just by then that I had realized that Rudolf opted to withdraw his repository. There're other forks from KJR available, but apparently mine is the only one with Rudolf's code merged and "maintained" ("kind of" because I intended to use that fork only for my own crazy ideas, since that dependencies). It's not impossible that Rudolf's code can cause some collateral effects on some Add'Ons (I'm not aware of any case - it's a theoretical hypothesis), as there must be a reason to the unrmerge (perhaps Ferram had another idea to solve the performance tax, who knows?). But now, at this moment, this code is the best KJR available for my needs. For a mile. In time, I updated my previous post with the test run without any kind of joint reinforcements. Now we have a base line for comparing performances.

MacMini mid 2011. i5 Mobile 2.3GHz, Intel Graphics 3000. The IG3000 is not the problem, Elilte Dangerous works fine on it. The real culprit is the i5 Mobile *and* that nasty memory compression adopted by Apple and made not only the default option, but the only one since El Captain (I miss Mavericks). However, there's the thing: by making tests on the worst machine I have, I can easily measure differences on code performance. Any single bit of improvement are noticeable, and that's the reason I develop on that MacMini. (that is fast enough on every other task, except running KSP… That thing has 16Gb of memory). And thats the reason I can say for sure that Rudolf's code does not taxes the CPU, while the original does. (recording the screen does not impacts at all the FPS. The i5 is good enough. The problem is on software) — — — — — — I redid the very same test, using the very same KSP Installment, with the very same Add'Ons (including the ones that I mangled and are throwing Exceptions), but using "Stock" KJR recompiled without the KSP version restrictions, the one I mentioned above. The differences are noticeable, the performance tax affects even the Toolbar scrolling. The IR/Next parts not working can be easily fixed by adding IR parts to the Exceptions List, where you define what parts should be ignored (If I remember correctly, they came pre-installed on KJR/L). My verdict? I can't see a single reason to avoid Rudolf's code. It may be some glitches yet, but his code is way faster than "Stock's". — — — — — — And, finally, the same KSP with the same vehicle but without any kind of joint reinforcements (not even auto-struts):

Well.. I was planning to publish this thing on the weekend, with a video showing it on work. But I will spoil the "Premiere" (hehe) here, to show you guys the excellence of the work done by Rudolf until the moment. It worths it. This is a 142 parts vehicle, with Rails, Hydraulics and Hinges working in tandem. There're some glitches, and perhaps some of that glitches are on the IR/Next code (as a Rail that I just can't adjust correctly the speed/acceleration, and a Hinge that doesn't mirror correctly), but yet, the thing is working where it really matters. I managed to build this thing without the need of KJR, but fired up my MacPotato with KSP 1.6.1 and KJR/L to see what I get. This vehicle was already pushing my potato to its limits, so it's a perfect test case for KJR/L (that is, in essence, KJR/RM with some fancy whistles). I guarantee you, guys, that my MacPotato behave in the very same performance with KJR/L than without it using this vehicle. The same bad performance, to tell you the true. This video wasn't edited in any way. It's the raw footage of the Performance Test. The KSP.log of that session is on a link on the video, and also here. The Infernal Robotics Next download is on this Thread OP. The KJR/L is available from this post (link to this forum). That video proves that yes. It works with IR/Next on 1.6.1 . KJR/L was tested on every KSP version from 1.2.2 to 1.6.1 (seriously!! I swear!). I think I installed IR/Next on a 1.4.x KSP, but don't remember using it. But it worths a try, go for it.

(shhh… don't talk that loud!) Let's try this first. I heard of a guy that took the original ferram4's code and deactivated the KSP version check: https://forum.kerbalspaceprogram.com/index.php?/topic/50911-13-kerbal-joint-reinforcement-v333-72417/&amp;do=findComment&amp;comment=3507600 I didn't bothered to check for myself, however. You are on uncharted waters (at least, on my router). Try it and see what happens. Perhaps it would fits for you. I have a hunch that your problem is KJR/RM recalculating the joint lists, once your aircraft "misses" some parts. If I'm right, you should experiment "worse" performance on the overall, but a bit less "cranky" decoupling. Well, you can't have the cake and eat it too. Let us know what you find on it. Perhaps, there're still some optimization waiting to be applied - and it's time to give Rudolf something back for what he had done - and he did a lot.

For reasons way off-topic, the maintainer choose to drop his repository for his fork of KJR. Currently, the only available fork using his (very good) code is this one (please read the fine print - there're some unusual dependencies). This fork's maintainer is doing his very best to keep things up, but he's not MeiruMeiru - give him some slack.

Well… It's after work by now. Let's properly answer things. What doesn't means you wont suffer from it. TweakScale is somewhat loud while being a Screaming Victim because TS mangles with a critical datum on the game: mass. Almost everything need the mass somehow, and since we are not talking about Quantum Physics simulation, everything needs to have mass. This misbehaviour, by inducing TS to apply zero on the part mass, make the thing critical. But this doesn't means you are immune by not using TweakScale. Even by uninstalling it, you are still prone to the problem in the event it hits another module. And if such module also mangles the mass of the part, we have another source of trouble lingering to show its ugly face. I just managed to get TweakScale out of that nasty chain of events. But I can't prevent any other link to close, so more chains of events are still possible. I'm not satisfied with this, but at the moment, it's all what's possible to be done. And this is why things are going kaput around here. It's not about "ego", it's about maintainability: this fork of TweakScale is the reference for… TweakScaling. Its perfectly ok to disagree with the Defaults and mangle with it, but not in a way that breaks TweakScale and KSP. Personally, I have no love for the patches included on TweakScale, I would gladly give up on most of them to third-parties (the main focus of the TweakScale3 - The New Breed, by the way) - they are a huge surface of attack for bugs the way they are right now. And you stated that clearly (and rightfully). Again, it's perfectly OK to an Add'On Maintainer to have his personal ideas about how his/her parts should TweakScale - and they are more than welcomed to apply pull requests to this repository, or even request being the official Maintainer of such patches (what makes every sense in the World), situation in which I would delete such patches from the main distribution (and then, they would be distributed on an "Extras" directory, for people willing to go old ways). On the bottom line, TweakScale needs your help in order to proper help you. Otherwise, nasty things will happen - as we can, easily, observe on this last two releases. As I said before, that would accomplish almost nothing. Besides the fact that TweakScale should be the reference for scaling (as it is, well… needed for scaling the parts! It's like buying an car, switching the fuel system, and then complain to the manufacturer about a bad engine performance!), this would not prevent any other Add'On to induce the problem by itself. Two rogue patches named before TweakScale (ascii ordered), or a single one named after TweakScale, and we have the problem again. There's no way TweakScale could cope with this alone, everybody need to follow the rules - or KSP will ending up crashing sooner or later. Point. Your suggestion about the "FOR:", on the other hand, is valid. I'll check it myself as, if anything goes wrong, I am the one that need to understand and fix things. But other than that, I'm pretty sure I will jump suit with you on this - by not doing that, I would be the one preventing others to follow better rules, and so, I would be part of the problem. (I'm managing to get myself understood on this? Sometimes I don't know when I'm being too much verbose - I just need to prevent misunderstandings - I'm not complaining about people disagreeing with the TweakScale defaults. My problem is what's happening due such disagreement happening without I'm being aware of it) Known issue, to be tacked down on TweakScale3 - The New Breed. Related issues: https://github.com/net-lisias-ksp/TweakScale/issues/2 https://github.com/net-lisias-ksp/TweakScale/issues/7 https://github.com/net-lisias-ksp/TweakScale/issues/11 https://github.com/net-lisias-ksp/TweakScale/issues/12 https://github.com/net-lisias-ksp/TweakScale/issues/13 This is smelling as a unhappy merge done late light. GIT was built with C code in mind. This will be fixed. https://github.com/net-lisias-ksp/TweakScale/issues/23 Ha! That's funny. So the Tallinu's report was indeed about a second occurrence of the problem! I had run out of time for Add'On authoring, and left this alone to be dealt later, once any really nasty consequences were handled. This is now just an annoyance, not a problem. Bur once you nailed it for me, https://github.com/net-lisias-ksp/TweakScale/issues/24 Right! However, this is far from being… convenient. An automated tool is needed. Talking with the Kerbal-X as I brainstormed above is not the best approach, now that I thought on it twice. There're the Steam Workshop guys too to care about. But the solutions are not mutually exclusive, once I manage to fix what's pending for a 2.4.1.1 release, I will see what they think about. Exactly again. I'm happy to see I managed to pass the message through, besides my English skills being somewhat compromised by the tiredness. Detecting , reproducing and cooking something for it was a somewhat heavy task. Right again. However, at that time, I was too worried and ended up choosing to be safe than sorry. Resaving everything is safer than asking a user to open a file "God knowns where in the filesystem" and visually inspect each part. A considerable amount of users are not tech savvy. Obviously, I could made a second post with most accurate details, but… Dude, I was wasted. I slept until Sunday's noon next day. And had a lot of house keeping to carry on! (still have, but I didn't said that) "%" would work only if everybody is used to agree with some rules. But if that would be the case, we won't had this marvelous mess to cope with at first place, so… Problem is - TweakScale make heavy use of presets. And a preset is exactly as it says, a preset. I thrust that presets, and it's with that presets in mind that deliver the "product". At this present time, I have no idea how presets will behave with the "%" - and, frankly, I have no time to spare to check 444 use cases of them. (check for yourself, the command is "find . -name "*.cfg" -exec grep -H "#" {} \; | wc -l"). The use of the :FOR, on the other hand, is pretty straightforward, well documented (with some glitches ) and broaded used. Way easier to cope. So I'm going for the :FOR . It's a somewhat more proper solution, by the way, as it self documents what :NEEDS to be done. (ugh… I think it's time for some rest). Of course, I still :NEEDS that everybody correctly follow MM rules, so in the very end this is so good as to try the "%" stunt. Or even doing absolutely nothing - the net result is, currently, exactly the same for all options. But the :FOR allows me to be part of the solution, not of the problem, and it's "cheaper". What, frankly, it would be way better - Add-On's authors/maintainers following the rules, and them blaming me for not doing the same. I just imagine how many of the crashes I had on the past year would not be related to this. (I'm positive that not all of them, I identified some other add-ons crashing KSP too. I didn't forked all that net-lisias-kspu hierarchy just because I don't have anything better to do! ). DAMN! Just now you tell me that? Jokes apart, I'm the current responsible for TweakScale, so in a very specific and non-personal way, yes, I am the one to "blame" every time TweakScale misbehave. I'm not saying I'm the one to fix every possible glitch (as this one), but once TweakScale is involved, I should respond (the real meaning of responsible) about. To cry for help sometimes, but yet, it's a response. Otherwise, we will destroy the very thing we intend to enhance, KSP itself. We, Add'on authors, don't have a duty on keeping KSP error-free, of course. This is not a job, we are not getting paid. But we are committed to a task: enhance KSP. In my humble opinion, once you publicly commit yourself to a task, you must do your "better" to carry it on. (but, again, giving the better of you is not the same as doing the "best" - this is not a job). About Module Manager and TweakScalem they are "old". The very first TweakScale version on CurseForge dates May 16, 2014. This thing was intended to run on KSP 0.23.5 ! I didn't found Module Manager on CurseForge, but from the Maintainer's repository, I learnt the the very first commit for the project dates May 6, 2013. Barely a year of difference. A LOT of water crossed under the bridge on these 4 to 5 years. A lot of things changed. And some of them got stuck in the past or just forgotten. I expect some more glitches ahead - it's the main reason I taking some pain to implement safeties now. I think it's related to how things were architectured on KSP and Module Manager in the past, and how things changed, and how MM had to change too without breaking legacy behaviour. Given the current status quo, I think that :FOR should not exist. It should be the bare default on every patch. But even by me being right on this assumption, Reality talks louder. By doing the "best thing", sometimes you cause such a breakage that the net result is negative. Sometimes, you just can't win a battle - all what remains to be done is to lose it the less costly way possible and live to fight another day. — — — — — — Hey! I found a Forum bug! If you forget an empty code block (or apparently, an empty box of any kind), everything below "collapses" to a quote box!

Fair enough. This will be work in progress on my first free time window (probably some night on the next few days). You can keep an eye on this here: https://github.com/net-lisias-ksp/TweakScale/issues/21 Because it's working. MM 4 introduced some changes that *can* (I'm not telling it is, but since I didn't checked it enough to be convinced about…) be playing some role on the problems above. So, by keeping it on this long time tested version for the minimalist users, I expect to reduce a bit my "surface of attack" for bugs. Of course, most users had updated to MM 4 already. Well, so is the life. MM is known to cope well with older copies of the MM, deactivating automatically the older copies, so this is not a problem for bleeding edge users. Documentation "Sheet" happens. MM's documentation is better than most "corporate grade" software I had worked on my times on the big guys. If you are talking about the WIki from the GitHub's official repository, I bet my SAS the maintainer will welcome any fixes you both (Tonka and Tallimu) would apply. Bills and taxes eats the best part of our available awaken time. Something have to gave in on the process, and usually, it's the documentation. And yeah… I'm guilty too… So, https://github.com/net-lisias-ksp/TweakScale/issues/22

That's the reason MM has the "AFTER[<MODULENAME>]" thingy. Add'Ons that adds support to TweakScale must be sure themselves to run things after TweakScale, or things will break for sure. Otherwise, the only sane option left is to drop TweakScale support for everything else, and then every Add'On author should be responsible for applying TweakScale patches themselves. About the remaining, I will read again by night. It's working hours by now.

Install Toolbar Control and see if this fixes the problem. My guess is yes, but I will be sure only by night.

[ Hi! ] You forgot to setup the dependency for Toolbar control on the AssemblyInfo file. Anyone having problems to run this , try installing ToobarControl to see if it fixes it.