Lisias

Tonka, I found some docs on MM about exactly this, and the problem is… Damn, @DylanSemrau's patches should be working by now: Source: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax TweakScale fails the first criteria, as the DLL is named "Scale.dll". But it should had been caught by the second criteria, as the there is a directory called "TweakScale" on the GameData. On the bright side, I will apply the FOR clausule on TweakScale this weekend, and then release (another) minor revision with the latests fixes until the moment. I think we finally are nailing why things are getting hairy with TweakScale lately. I wanna to dig in some code, however, before telling anything more about the issue. — — — POST EDIT — — — Boy, this is going to be a hell of a weekend! Near 1900 patches to apply that !#$#@$@#%@$% FOR. macmini:patches lisias$ find -name "*.cfg" -exec grep -H "@PART" {} \; | wc -l 1892 If I understood correctly, TweakScale is being caught by the "LegacyPassSpecifier" , that always returns "true" on the check. In order to be correctly ordered on the :AFTER , :BEFORE and (I'm not sure yet) :NEEDS , I need to apply that :FOR stunt on everything that "it's mine".

Humm… Unexpected. Well, there must be a reason for the stock parts names not using "_'. So I edited your CFG files and got rid of "_" and " ", ie, named the parts as FirstStageEngineCluster and FirstStageFuelTank on all configs/patches. That made some difference: macmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance" Provenance Aerospace [LOG 20:27:27.931] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal [LOG 20:27:28.070] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture [LOG 20:27:28.229] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal [LOG 20:27:28.321] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture [LOG 20:28:03.507] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model [LOG 20:28:07.625] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model [LOG 20:28:29.208] Config(@PART[FirstStageFuelTank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] [LOG 20:28:29.208] Config(@PART[FirstStageEngineCluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale] [LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster [LOG 20:28:29.208] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank ProvenanceAerospace [LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageFuelTank]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 20:28:29.940] [ModuleManager] INFO: Applying update Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[FirstStageEngineCluster]:NEEDS[TweakScale] to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 20:28:37.626] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass [LOG 20:28:37.626] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass [LOG 20:28:37.626] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass [LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 20:28:37.627] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 20:28:38.069] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster' [LOG 20:28:38.216] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/FirstStageEngineCluster' has no database record. Creating. [LOG 20:28:38.323] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' [LOG 20:28:38.335] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/FirstStageFuelTank' has no database record. Creating. But… TweakScale is not being applied yet. =/ Well, I have some ideas, I will be back to this post soon.

So… I was a young man. Slightly more than a teenager, and finally got my first sound card for my PC. The very first thing I did was to listen to this music, one of the things I envied from my best friend's Amiga 500. And it was on this very program, the Tetra Compositor Demo, that it used to came on the install disks for the SB 2.0. (mine was a clone, but it worked fine in emulation mode. Dude, PAS16 was the card!). (Listen using a headphone - and no, the program was not that laggy at the time. There's something wrong on the emulator used by the guy)

We posted at the same time! Check the name of the part on the CFG file, you forgot the "_" there.

MM is not applying your patches. acmini:1.6.1 lisias$ cat KSP.log | grep -i "Provenance" Provenance Aerospace [LOG 19:27:54.280] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Normal [LOG 19:27:54.401] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/New Glenn First Stage Engines Texture [LOG 19:27:54.494] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Normal [LOG 19:27:54.571] Load(Texture): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/New Glenn First Stage Texture [LOG 19:28:29.814] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/Model [LOG 19:28:33.852] Load(Model): Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/Model [LOG 19:28:56.347] Config(@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale]) Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale/@PART[First_Stage_Engine_Cluster]:NEEDS[TweakScale] [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster [LOG 19:28:56.347] Config(PART) Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank Added : Provenance Aerospace/Compatibility/Tweakscale/Provenance_Tweakscale.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster.cfg Added : Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank.cfg ProvenanceAerospace [LOG 19:29:05.221] [ModuleManager] INFO: :BEFORE[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :FOR[PROVENANCEAEROSPACE] pass [LOG 19:29:05.221] [ModuleManager] INFO: :AFTER[PROVENANCEAEROSPACE] pass [LOG 19:29:05.222] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/PART [LOG 19:29:05.223] [ModuleManager] INFO: Applying update PartInfo/PartInfo/@PART[*]:Final to Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/PART [LOG 19:29:05.675] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' [LOG 19:29:05.839] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Engine Cluster/First Stage Engine Cluster/First Stage Engine Cluster' has no database record. Creating. [LOG 19:29:05.972] PartLoader: Compiling Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' [LOG 19:29:05.988] PartLoader: Part 'Provenance Aerospace/New Glenn/Parts/First Stage Fuel Tank/First Stage Fuel Tank/First Stage Fuel Tank' has no database record. Creating. Look how it applies the PartInfo patch, but remains silent about TweakScale. (I'm testing the HEAD from the repository you pinpointed). — — — — — POST EDIT — — — — — Are you sure you named the part correctly on the patch? I'm not finding a part with that name on the GameData… macmini:Provenance Aerospace lisias$ find . -name "*.cfg" -exec grep "First_Stage_Fuel_Tank" {} \; @PART[First_Stage_Fuel_Tank]:NEEDS[TweakScale] The command above should had returned at least a second occurrence of the "First_Stage_Fuel_Tank" string from the basket of cfg files that it's GameData! — — — — POST POST EDIT — — — — HERE. You forgot to put "_" on the partname. PART { name = First Stage Fuel Tank

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.