Lisias

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

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