Lisias

Não exatamente… O Module Manager é um mecanismo para editar, controladamente, o banco de dados de parts do jogo (também chamado de prefab). O Patch é o "código fonte" que o Module Manager usa para saber o que fazer. Un Patch pode consertar algo, pode eliminar algo, pode alterar algo e, quando não feito adequadamente, pode realmente esculhambar algo (e o resto do jogo inteiro!). Excelente! Quem sabe a gente agita um pouco o Forum em Português? Ele anda às moscas… Meu… SEIS MESES DEPOIS…. O melhor lugar para procurar ajuda é o Forum em Inglês. Tá todo mundo lá - inclusive eu. Dei uma olhada no seu perfil, e vi que vc usa um MacBook para jogar. Eu uso MacMini, então eu sou provavelmente uma das melhores pessoas para resolver pepino por aqui. Só que eu apareço pouco no Forum em PT, e acabo deixando ele um pouco de lado. Façamos o seguinte, e isto vale para todo mundo - mencionem o meu some começando com o arroba (@), assim: @Lisias - assim eu sou notificado. Ou, quem sabe uma melhor idéia?, postem a dúvida na thread abaixo: Amplos Amplexos! Scale Safe!

Alô, Kerbonautas. Eu sou o Lisias, mantenedor do TweakScale (e dos Companions), Distant Object Enhancement, KSP-Recall, KAX e Impossible Innovations. E eu falo português. (melhor que o Inglês, por sinal!! ). É fato que a maioria dos usuários acaba ficando pelo Forum em Inglês, onde está quase todo mundo por aqui (eu inclusive). Mas como nem todo mundo se sente confortável fora da sua madre lingua na hora de pedir ajuda, eu achei uma boa idéia criar um tópico só para isso aqui - um que eu possa ativar o 'Seguir' e ser notificado sempre que alguém postar algo. Eu constantemente dou suporte para os add'ons que mencionei acima, mas acabo também dando uma mãozinha pra todo mundo. Então por que não o fazer em português também? Eu gostaria de evitar que pedidos de ajuda feitos aqui acabem caindo no esquecimento, como eu percebi que aconteceu em Abril deste ano - eu estou seguindo este tópico, então sempre que alguém postar algo aqui acende um sininho na minha barra de notificações. Quem comecem os jogos.

And some R.A.T.O.s!!! https://www.flightmuseum.com/explore/rato/

It's on the backlog, I will work on it as soon as I ship TweakScale 2.4.6.2, currently on the works!

Nothing just works, Entropy is the natural course of action. For every single thing that works, at least one guy (usually more) had bashed their SAS in the past to make it work. Software development is not easy neither simple, even when it appears to be. For using Firespitter with TS, you will need the TweakScale Companion for Firespitter. Otherwise, you can ignore these Warnings, they will not appear to you again unless the ModuleManager cache is rewritten (what means you installed or removed things, when so the warnings pop up again). Additionally, be absolutely sure that the Firespitter on your rig is the latest one, available here. (I think it probably is, but be absolutely sure - a borking Firespitter can ruin your entire rig).

This is one of that very annoying bug of KSP - once someone borks on loading a dependency, everybody later ends up borking the same - something is badly coded on a thingy called AssemblyResolver, and everything and the kitchen's sink depends on it for loading code. On your case, the problem is here: [ERR 18:27:45.081] AssemblyLoader: Exception loading 'Konstruction': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <cd473063d3a2482f8d93d388d0c95035>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000066 (from typeref, class/assembly USITools.UI.Window, USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) assembly System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' System.TypeLoadException: Could not resolve type with token 01000066 (from typeref, class/assembly USITools.UI.Window, USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) What make things pretty hard to diagnose this time is that "token 01000066" thingy. It happens when the caller (Konstruction.UI on your case) is trying to loading an existing DLL (USITools.UI.Window) that used to have something inside that now there's not. (as a side note, it's the reason TweakScale 2.4.6.x is a deal breaker with older Companions - I had to change something on the KSPe.Light.TweakScale library that did exactly this on the older Companions, and it's the reason I launched 2.4.6.0 and 5 other Companions at the same time). I think that the github release of USITools must be the one you need to download in order to fix this one. In a way or another, this is a USI problem now (TweakScale is only the only openly talking about). If by downloading the newest USI.Tools you still have the problem, you will have to ask the Maintainer for help, as I can't help further on this specific case. Cheers!

METAR Yeah, I had misdiagnosed the problem. As I said before, sometimes a lightning strike the same point twice. Worst, sometimes it strike the same point 3 times… in a row. It's somewhat embarrassing, but together the known bugs on KSP (that may or may not be having a role on the problems at hand) and the known TweakScale technical debits (also known as bugs), I found some incomplete tasks lingering around… Tracking down the code on the git history, these commits are from late 2019 and early 2020 - and I think that troubling times imposed a higher toll than anticipated. So we have three lightings striking TweakScale right now: KSP bugs besides being uncertain if any KSP bug is really playing a role on these ones, by merely existing and having similar behaviours they mess up things enough, as they interfere with the diagnosing. TweakScale technical debits I err too, not to mention that as KSP evolved and new bugs were added, I ended up spending too much time on KSP-Recall and my own bugs ended up on a second plane - priorization is a "beach" . minor annoyances or bugs that can be easily worked around are always left behind when you have dealbreaker bugs to handle (as the freaking IPartCostModifier bug on Stock, that still persists until this moment). Unfinished tasks that I thought to have finished Last year was a pandemonium, I completely lost track of the backlog. Some tasks were left behind, but since they are tracked on the issue tracker this is usually an annoyance, not a problem. But the problem was some tasks that I started and left unfinished, and later I ended up creating a bug for the problem instead of labelling it as it should, a unfinished task. This is a huge problem because, as I said before, I have to prioritise tasks as time is always a scarce resource and some compromise is needed. And while prioritising things, its status plays a hole: annoying bugs always have lower priorities than unfinished tasks and dealbreaker. By labelling an unfinished task as a bug, I ended up postponing the execution forever… (sigh) Anyway… Problem is detected and I working on it. Once you know where the problem is, things happen faster - I already detected a borderline situation that was preventing me to correctly diagnose a problem that was happening since 1.4.4, but since it was a borderline situation it only happened on… borderline situations and I ended up thinking it was something that changed on KSP 1.5.0 or something. Oh well… The Code Must Flow - my coffee's mug is filled, let the hack and slash begin.

Yeah, tons and tons of NRE on the Sanity Checks. This happens when you install a 4rd party add'on that is broken. That's the thing: when KSP startups, it builts a thingy called "prefab" that it's a database with the full data of every part. In order to build that database, evert PartModule is called for evert Part at startup. However, if a PartModule borks it's job on this phase, it corrupts the process for this part because KSP breaks the chain and don't call the PartModules that are on the queue for that part. This explains the huge amount of exceptions like this one: [LOG 15:03:20.544] PartLoader: Part 'UmbraSpaceIndustries/MKS/Parts/LightGlobe/MKS_LightGlobe' has no database record. Creating. [LOG 15:03:20.545] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 15:03:20.551] DragCubeSystem: Creating drag cubes for part 'MKS.LightGlobe' [EXC 15:03:20.554] NullReferenceException: Object reference not set to an instance of an object ModuleDeployablePart.AssumeDragCubePosition (System.String name) (at <cd473063d3a2482f8d93d388d0c95035>:0) DragCubeSystem+<RenderDragCubes>d__34.MoveNext () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <12e76cd50cc64cf19 e759e981cb725af>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <RenderDragCubesCoroutine>d__31:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <SetupDragCubeCoroutine>d__46:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Do you see? TweakScale is not the only victim of these problems. There's no way to fix these ones but to hunt and remove the add'on that it's borking. Additionally, I found a lot of Sanity Check exceptions that suggests you are using pretty dated versions of some 4rd party add'ons: [LOG 15:05:20.659] [TweakScale] ERROR: **FATAL** Part Tube2 (T-25 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:05:20.660] [TweakScale] ERROR: **FATAL** Part Tube3 (T-37 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 15:05:20.660] [TweakScale] ERROR: **FATAL** Part Tube4 (T-50 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Hunting for the troublemaker the patching process will pinpoint the culprit: [LOG 15:01:05.792] Config(@PART[Tube2]:NEEDS[SquadExpansion]) KerbalHealth/Patches/KHMakingHistory/@PART[Tube2]:NEEDS[SquadExpansion] [LOG 15:01:05.929] Config(@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock]) ReStock/PatchesMH/Structural/restock-mh-tubes/@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] [LOG 15:01:05.981] Config(PART) SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2 [LOG 15:01:06.066] Config(@PART[Tube2]:NEEDS[SquadExpansion,TweakScale]) TweakScale/patches/SquadExpansion/MakingHistory/Structural/@PART[Tube2]:NEEDS[SquadExpansion,TweakScale] [LOG 15:01:06.074] Config(@PART[Tube2]) TweakscaleMakingHistoryConfigs/Structural/@PART[Tube2] [LOG 14:59:11.892] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:12.941] Applying update KerbalHealth/Patches/KHMakingHistory/@PART[Tube2]:NEEDS[SquadExpansion] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:27.031] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Structural/@PART[Tube2]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:27.516] Applying update TweakscaleMakingHistoryConfigs/Structural/@PART[Tube2] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:29.889] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:37.440] Applying update ReStock/PatchesMH/Structural/restock-mh-tubes/@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 14:59:58.509] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 15:00:01.119] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2] [LOG 15:02:59.222] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2' [LOG 15:02:59.263] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2' has no database record. Creating. [LOG 15:05:20.659] [TweakScale] ERROR: **FATAL** Part Tube2 (T-25 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 And on this case, it's my old friend "TweakscaleMakingHistoryConfigs". You still having this oldie lingering around suggests that you are updating your older KSP to 1.12.2 right now (it's already years since I'm dealing with TweakScaleMakingHistoryConfigs), what also suggests you are using pretty dated versions of add'ons, and inspecting some of them I found some that stopped working since KSP 1.7.3. I'm sorry but I'm afraid you should create a new KSP 1.12.2 installment using only the most recent versions of the add'ons you want that are certified to work on KSP 1.12.2. I hope you had a backup of the previous KSP installment before updating to 1.12.2. In a way or another, do not load any savegames without creating a backup of them first. Good luck!

Yeah, I have these problems too. Fire up KSP to diagnose something, ended up playing with the thing until late night - and no diagnosing at all. Thanks. This will help me to iron out my current hypothesis. I think I misdiagnosed the thing since the beginning…

Don't bother, reverting to 2.4.5.9 worked fine now!!!! Since last week I had a power failure on home and so, a reboot. It's the only thing I can think now that could be influenced. And I'm only considering this because earlier this year I got a really weird behaviour on MM, that I reported here: In a way or another, this appears to clear the Stealth Save from the crime. Well, two lightnings can strike the same place more than once - and if there's a lightning rod there, you can bet your SAS it will happen. On a side note, rebooting the machine to solve software glitches was the reason I ditched Windows 10 years ago. I never thought I would face this crap again on MacOS - but hey, C# is Microsoft, right?

Yep. TweakScale just set the multiplier to a field on the IVA mesh and that's it: this.part.internalModel.transform.localScale = _size_multiplier; this.part.internalModel.transform.hasChanged = true; So this is not ReStock specific (as I had already inferred). Well, now with another part being hit by the problem I can try to compare the parts to see if I find a pattern and, perhaps, zero into the problem. The interesting thing is that your M.O. is a bit different… On my tests, saving the craft after manually fixing it solves the problem for good - but, granted, I only have two crafts from the same source with the problem, so my sample space is somewhat limited. Can you send me your craft with the problem? I would like to inspect it. Well, it helps a bit. On my tests, reverting to 2.4.5.9 did not improved the situation. I did a roolback to 2.4.4.6 and still got the problem on the ReStock test bed. The interesting thing is that once I manually fix the problem and save the craft, everything works fine again and for good, I didn't got the problem again in any circumstance. — — — Anyway, I'm cooking a (yet another) release with the Stealth Mode deactivated (you will need to use a patch to activate it, the same way I did to activate things on KSP-Recall). If I'm right (and there's a pretty decent change of it), it will prevent that new crafts triggers the Wrath of the Screwing Pipeline under us - I just can't fight the thing… Humm… Or perhaps I can? I had an idea… https://github.com/net-lisias-ksp/TweakScale/issues/207

Tex Johnson. The most Jebediah of all pilots! (The video is a bit lengthy, but it worth it!)

You have a point, 'The Rover' is a fiction magazine… I found it on Archive: https://archive.org/details/the-rover-0950-1940-06-29 Well, it was entertaining for sure!

Yeah! Thanks! About distributed computing… Believe me, game programming ends up using a lot of these concepts. We have a physics engine that conceptually (i.e., we pretend it does! ) works in parallel with the Game Modules (PartModules, VesselModules, etc), and all of that (also conceptually) works in parallel with the GPU. Unity ends up squashing everything on a sequential process - but since there're some parallelism on the thing it worths the effort to pretend everything is parallel and code this way. If you manage to grab one of that older "Many Core" processor cards, there're some pretty interesting things to explore!

In PT-BR, when we say "Essa ferramenta não escala…", we are meaning that the tool works on small jobs but as the load increases, the tool can't withhold the load under a vertical landscape neither allows being used on many appliances on a horizontal landscape. When the tool does it fine (i.e., can withhold loads on vertical, and/or allow easy deployment on many appliances on an easy maintainable way, we say "A ferramenta escala bem!". It's a concept that involves all what you said and a bit more. It's the near concept that came to my mind now. Cheers!

Welcome! Humm... what's NEAF? Right now I don't recollect this one... I will checked it later anyway. KIS may have the thing renamed? Or perhaps a missing Module... Humm.. send me your KSP.log. Just in case. cheers!

Oh, dear… This is going to be a mess.. There're tons of support already written for KAS, it will be a riot to update them all. I'm not saying this is not going to worth the pain, I'm saying that it's going to be a pain - so please consider the consequences to see if it will really worth it. On a personal note, I think your modus operandi somewhat better than current Stock (at least about what is related to KIS) and I even tried to replace the Stock with KIS instead of having both, but unfortunately I found that I can't remove stock modules without breaking some internal guts of KSP (they hardcoded the support, damn it!). I'm inclined to think the same about KAS. I would really like a way to replace the Stock support with KIS and KAS, instead of having both system at the same time. I have successfully replaced a PAW from Firespitter with my own facade to overcome a FS deficiency (i.e., I "hijacked" the event handler from the original, hid it and showed my own instead, that so would update the original seamlessly in a way it would not borks). No Harmony or similar involved, just wise use of the current KSP API. Perhaps a similar stunt can be accomplished for KIS and KAS? That would solve the confusion too...

ANNOUNCE Release 2.1.1.6 is available for downloading, with the following changes: Some brain-farts of mine on handling Scene switch were fixed Thanks for the report, @darthgently! And for the one from @Krazy1too! While fixing the previous, I detected what could be happening on this one and (hopefully) fixed it. Testings down to KSP 1.3.1 suggests it works on these, but "Development" was done on KSP 1.4.1 and 1.4.3, and then tested against 1.7.3 and 1.12.2 and no problems (others than my own ones) were found! #HURRAY!! KSP 1.3.1 appears to work, but I didn't "certified" it yet. Try at your own risk On the bottom line, the thing runs downto 1.3.1, but I'm not confident enough yet. I essentially remade VesselDraw this time, as the previous coding style was becoming hard to "escalate" (how is the exactly term in EN-US?). This fixed a bunch of issues by itself, as they were originate by my attempt to prevent doing exactly that (if it's working, don't fix it! It only happened that it was not working as I needed, so now I fixed it). I think it will work fine on KSP 1.3.1, I surely did some test runs on it. But not close from the scrutiny I'm doing on KSP 1.4x to 1.12.2 (1.4.3, 1.4.5, 1.7.3, 1.8.1 and 1..12.2 - as experience tells me that if the damned thing works on these ones, it almost surely with work on the others too! KSP 1.5.1 and 1.6.1 passed the smoke tests at least, I ran out of time to keep testing the Unity 2019 series, except by 1.12.2, of course). As I said before, it was by plain luck I didn't used anything not available (and working) on KSP 1.3.1, so we still may get strike by something. So I prefer to deferrer an official statement for the WeekEnd, when I will have time to play with the thing. No screenshots this time, I'm in hurry. See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. The rationale is to gradually deploy the thing in order to cope with eventual mishaps before it reaches too much people.

Use the cheats. Perhaps the indestructible one can help?

It should not…. Please send me your KSP.log so I can check where the bork is happening. I'm surely misconfigured some KSPAddOn attribute! POST EDIT Don't bother, I found it already. I completely missed that! POST POST EDIT There was another issue hidden on the thing: when you click on the "Apply" from the Settings Menu, a function called "Commit" is called to, well.. , commit the changes on the running Module so you don't have to switch scenes to get the setting applied. But I forgot to check if the Module is meant to work on the current Scene on two use cases (I handled it correctly on a third, so I think I was interrupted by some R.L. issue and ending up thinking I had concluded the job after), so the after math was that VesselDraw was being activated no matter the current scene by that click. This may also explain the problem detected by @Krazy1 - if VesselDraw is already active when entering the Flight Scene, there's a very good chance that a unloaded vessel ends being the current vessel without VesselDraw getting the chance to check it - ending up with the MeshEngine trying to draw the meshes over an active one (a mishap that the original programmer surely ended up doing otherwise he wouldn't had wrote the code - and now I'm pretty glad he did!). Well, I'm finishing the tests and I think I will release the fix in the next couple hours. [ha… :P] POST POST POST EDIT This is extremely frustrating. The latest ReStock, somehow, added something to the mess that is fooling DOE on think that some parts that should not be rendered, should be. [LOG 17:35:35.348] [DistantObject] WARNING: Failed to load model Squad/Parts/Utility/launchClamp1/model for part launchClamp1 from vessel Tower Of Doom! Vessel will not be rendered as expected! I will release what I have ready as it fixes some problems being reported, and I will let ReStock for another day - there's so much I can do at once on working days. I probably will add a new "Engine' just for ReStock, and I will deliver the DLL stand alone for beta-testers. It's not fair to non ReStock users delaying the development cycle due ReStock...

Now I was caught with my pants down… There should be no binary interaction between the Scale and Recall assemblies…. Well, I will give this a try later, thanks for the heads up!

You should had forgot to completely remove the TweakScale folder. I downgrade things here now and then just to see what happens, and no problems were detected - as long you completely get rid of all binaries before "downgrading" to the previous release. Keep in mind that 2.4.6.x is a deal breaker to some Companions (it's the reason I had to update some of them). In order to use TweakScale 2.4.5.0, you will need to downgrade also the Companions mentioned on the github's Release page. Breaking binary compatibility sucks, I know, but I had drawn myself to a corner with some APIs and had to do it sooner or later, and took the opportunity to do it now since some new APIs would need the Companions to be rewritten anyway, so we would endure two pains by the price of one. Exactly. Scaling Crew down works - since nobody is launching exceptions when this happens. Observe that the U,I. adapts itself normally with you scale down a 3 crewed part to 2 and then 1 crew. I fail to understand why this would be a problem for scaling up. The excuse of "people would find weird the IVA not following the new crew size" - as people would not be using borrowed IVAs from other parts and shoving more (or less) kerbals on it that the available seats. As I said, you can MM your way on it and KSP doesn't complains about the part having more crew on the prefab than IVA seats. Mangling the IVA seats was something that I had though, but since KSP resets everything to the prefab on launch, TweakScale needs to reapply the scaling on the first frames of life of the Craft - and by then, KSP already had thrown that Exception on me. The Solution for this would be writing a new PartModule with a new Crew support to avoid the KSP's ban (like KIS does with cargo). From there, I could do anything I want (including generating IVAs at runtime - a somewhat daunting endeavour ). But then we have R.L. kicking my balls and forcing me to compromise - there're more pressing things in need to be done ASAP (as you can see above).

Yeah, unfortunately it's a known issue. It's two bugs bitting you in a row: the first (and most serious, as it affects everybody) is from KSP, that now and then screw up something on the UpgradePipeline (probably) and invert the Z Axis of the part (or at least, from the attach nodes). Sometimes the fairings get inverted, and you can't build the fairing towards the right end of the rocket due this. This I can't help, it's a long standing KSP problem that started to happen on 1.8.0 (I first noticed it on the control surfaces). The second bug is on TweakScale. In all these years since the first version, no one (including me) thought that someone would want to invert the part before scaling, and so the code was made assuming the part is always pointing towards the root. This is scheduled to be fixed for the next release, in which I (hope) to start to work on the middle on this next week. Until there, the only workaround is to detach the affect parts, invert it, and reattach them. This solves the problem for good on this craft - or at least, I still didn't got a report of the thing happening again on the same craft on the same savegame - the KSP bug triggers when loading crafts from another savegame I think (but I'm not 100% sure). Until this moment only ReStock parts are being reported - but I really doubt this is a ReStock problem. Once you fix the craft and save it, you can remove and reinstall ReStock that the bug doesn't triggers anymore. A more thoughtful discussion can be found on this post:

Announce! TweakScale Companion for PKMC 2.1.0.1 is on the wild! Fix a bug on patch. Thanks to AccidentalDissassemly! Closes issues: #5 Missing curly braces in patch file Downloads here and in the OP.

Not yet. Eventually I will deprecate for good the old patches on TS distribution, but this will not happen until I tackle down this dependency problem. As far as I know, the current patches for KAS are still acceptable, so is unlikely that I will rework them in the short run. But you can aways check the TweakScale Companion thread for news. Cheers!