Lisias

It was not what I intended to do at first, this happened more as an accident than a planned thing - but since the thing ended up yelling on everything that goes badly on the spot, I decided to further explore it and promote it as a core feature. (Kerbals proposes, Kraken disposes - they say… )

It's more like a false cognate. We should be using the term Concurrency, but on modern software development (at least on system and comercial level), nowadays concurrency and threads are (wrongly) used as synonymous. Co Routines, as used on Unity, are a kind of concurrency: on the old days of Win16, Workbench (Amiga), TOS (Atari ST), MacOS (on the 680x0 times) et all, the Concurrency were achieved by cooperative multitasking that is, in essence, Co Routines with steroids, but still Co Routines - we had the same problems and the same limitations from what we have on Unity (and used some of the same hacks too). But it's nearly THIRTY YEARS since everybody is using threads to achieve MultiTasking, and so everybody ends up using both words as synonymous (including me). It worths to mention that a lot of the problems I faced on Unity are copycats of problems that I had faced when giving maintenance on older Win16 code on Win95 (when finally Windows started to have Preemptive Multitasking, besides half baked). And I can't describe properly the huge pain that was porting these code into to Windows NT later, where Preemptive Multitasking were done right. As was said above, not exactly - there're a lot of missed opportunities to explore parallelism on KSP - and, frankly, not all due legacy code. You can rewrite system level functionalities without breaking (well behaving) userspace programs, and the Linux Kernel is one of the most formidable examples on how this can be done. Even Win32 is not that bad (it's messy, but not bad - go see how was POSIX on the old days), most programs compiled agains Win32s (on the Win16 yet) could be compiled and run on Windows 95 almost without a change. Even Win16 using WinG could be recompiled to Win32 on Windows95, damn it. And it worked (or the most near to work you can expect from Windows 95). But a huge amount of software could not be ported to Win32, and one of the reasons are very similar to the problems we have nowadays on KSP: completely ignoring Concurrency concepts. Sometimes, I think there're some MS-DOS game developers lingering around. (not going pejorative on them, by Kraken's sake - these guys were heroes on a war time. But we are not on a war anymore!). Going back to the multi-vessel problem, one problem on going multi-thread on them is the Reference Frame. KSP has only one Reference Frame, the user PoV. So, when you switch vessels, the whole Universe is transposed in order to make the User's current position as the Origin (0,0,0) - essentially, the user never moves, everything else does it instead. This hack was needed because Unity (at that time) used floats for everything (what made sense, we were using 32 bits CPUs at that time), and floats don't have the needed resolution to allow precise calculations on two far points of the Universe - so transposing everything to make the User the Origin alleviated the problem by removing from the user's visible space the problems related to low float resolution. Interesting enough, DOE is an excellent way to check exactly that, since it works from Unity 5 to Unity 2019 - recreating my demo scenario (the SpySat thingy) on KSP 1.4.3 and on 1.8.1 gave me radically different rendering results on the 1.3.1 (due Unity 5), from texture fighting to weird polygons. So a possible way to solve this mess is to decouple the Origin from the User's position, create many Reference Frames (one for each living vessel) and allow the User to transition between the different Reference Frames as a discrete entity (and not as the Origin of the Universe). This would decouple the vessels from the float problem, you could have loaded vessels scattered about the Universe at the same time without needing to unload them into Rails all the time (as long you have CPU to handle everything). Reference Frames should be handled on 64 bits, vessels inside each Reference Frame can still be processed on 32 bits - not differently from what was made on Windows 95 to run WIn16 programs. In essence, each Reference Frame can run on a thread or core concurrently with the other ones. And the process that macro handles the Reference Frames could also run on a dedicated thread/coroutine/whatever too. As long the vessels don't get near each other. Once two vessels enters into the each other's physics range, you will need to merge their Reference Frames (and later split it again when they get far from each other). I think this is where things can get prohibitively complicated. [addendum] It's worth to remember that we are terribly underusing our GPUs nowadays. The machines are made to munch numbers, and we could offload a lot of heavy computing from the CPU into the GPU, as long we can cope with the limitations. GPUs handle floats tens orders of magnitude faster than they handle doubles, so keeping the Reference Frames on floats is desirable as it at least allows us to have hope that we could offload these into the GPU someday. [/addendum] What's not different from system programming. Parallel compiling is one perfect example of this problem being solved on real life. The two concepts are not mutually exclusive. You can use both, exploring the strengths and avoiding the weakness. What we need is good interfaces on well defined borders/layers - give me a good interface, and I can make an Apple II running ProDOS work together with a SAP box running on a Sun M9000, or use a Raspberry PI to offload some work from it.

This is more a KSP fatal flaw than only a USI mishap. USI probably is doing the same I am on KSPe (Light, on TweakScale case): decluttering the API from bad ideas. If you do it right, you can keep source code compatibility (i.e. just recompile - I hate this word - and you are set). But binary code compatability is sometimes non achievable. I fought 1 year until I had to give up binary compatibility - and yeah, it sucks: it royally screws up things. Check the Linux Kernel dev mailing list for examples of how bad this can be. So, you deliver a new API level with broken binary compatability and so you have to update everything that uses it, as I had to do with KSPe.Light.TweakScale (and now you should be having an idea about the reason DOE, Recall and KAX have their own versions of KSPe.Light - I knew this was going to happen someday and so I boxed each add'on on its own mini ecosystem). But additionally to all this pain, we have KSP messing up things even more: there's a huge and fatal flaw on a critical component called AssemblyResolver: when a loading DLL fails due a missing or incomplete dependency, the Resolver breaks some thing inside the System.Reflection and, from that point, EVERYTHING BORKS RELENTLESSLY. So, yeah, USI is changing an API and it's breaking some legacy, but this should be affecting only its dependent DLLs - but KSP makes the situation way worse spreading the pain to everybody else.

I completely agree. Exactly. There's a pretty old Design Pattern called DocView, created by Microsoft for MS Word and it's a simplification of the MVC one. The Office Team (the group where the real improvements happened in the past, as DDE, COM, DCOM, etc) realised that they don't need to have all the visual thingies tied to the code that handles the bits of the document, but yet the MCV was overkill for them. So they wrote two components, the Doc (where the Controller and the Models live) and the View responsible for the U.I. And then suddenly you can have multiple views working fine on the same Doc (one view for preview the print, other to edit, perhaps yet another one to edit another part of the same document - you got the drill). Games should be doing something similar - assuming, of course, they are not doing it already - at least, the ones made with better 3D engines than Unity (that it's not exactly bad - it's just not good neither). Give a peek on how the venerable PlayStation 2 works. The Emotion Engine is still respectable even nowadays. You can do a lot with low memory footprints when you know what you are doing.

ANNOUNCE Release 2.4.6.2 is available for downloading, with the following changes: Maintenance Release. Closes Issues: #208 Chain Scaling Parts with variants are borking when the parent part is inverted #207 The Upgrade Pipeline thingy (or something else?) is playing havoc with TweakScale #175 Wrong displacement of the attached part placed inverted when scaling its parent #163 Radial Symmetry (when using variants) are misplacing parts. #131 Chain Scaling parts is playing havoc with the Radial Attachment Positions. #36 TweakScale Warning] Exception during ModulePartVariants interaction See OP for the links. Notes While fixing a lot of annoying (and one serious) bugs, some others still remain and I probably created another one (still researching if it's really my fault). But, overall, this release is way more useable and stable than the previous one. In the mean time, behold your Destiny, oh Kerbals, this is the Tower Of Doom Overdrive!!! The madness never ends! — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock (and CKAN users). Right now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps - RL™ is bitting.

I don't think this is TweakScale related, I think you can get better results on the Modded Support Thread. Be sure to had read this thread first, as it explains how to give in advance needed information, saving a lot of time on the process. On a wild guess, you may have a 3rd party DLL borking on load and, due a KSP bug on a thingy called AssemblyResolver, after this bork everything else borks too at DLL load. I don't think this is related (at least directly) to TweakScale because TweakScale checks at startup if its auxiliary code was loaded and yells on you if not, and this happens still while loading KSP. In a way or another, without the KSP.log we are in the dark and can't help.

The knowledge to bring Kerbin to its DESTINY!!!! Behold, Kerbals, the Tower of DOOM REDUX!!!

Yes. There's the hackish way, and the proper way! First things first, let's go hackish - a lot of opportunities to screw up something but, hey, what's life without fun? Take the part you want to overscale, set it to 20m. Then attach something to it, be sure to have Chain Scaling active (Ctrl-K) and scale this part until the target part reachws the size you want (or you hit the 20M on the auxiliary part). By removing the auxiliary part and adding a new one with the default size, you can scale things until the bitter crash. You will need to reroot the craft into the auxiliary part when adding it, and to reroot the craft into its next fellow on the chain before removing it. And do a lot of "Tool:Move" due the way the colliders are made (usually slightly smaller than the mesh itself, so small parts ends up "inside" the mesh of the bigger ones), as well an annoying bug I resurrected yesterday while fixing a show stopper (TweakScake 2.4.6.2 is getting out of the oven in a few minutes). Not all parts will behave being overscaled, but most simple parts will do - you need to trial and err your way on the mess. And there's the proper, boring way: edit/patch (patching is better, avoid loosing the changes on updating) the Scale types. You can shove any value on these ones, the default ones are meant to match the most used bulkheads of the game (way convenient), but you are not locked to these ones. In fact, the Companion for SMCE use custom Scale Types for the ships. Once the parts get big enough, the colliders problem described about starts to kick in the same way however. You can change these values at will without impact on the existing vessels, as these values are used on Editor only - they are the guidelines used by the U.I. TweakScale imposes some limits on scaling down things (anything below 3% of the original part is clamped to 3% - IRRC), but there's no limit imposed while scaling up (other that crashing KSP into the Desktop! ).

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...