Lisias

Just silliness. You will be the first to know when it's ready! The bad news about this problem is that it's not simple as someone borking on the code. It's a System Integrations conflict - a specific combination of things, that works perfectly fine by themselves or with each other when you get one of them out of the equation. Most of the time we misdiagnose the problem and pinpoint just one of the variables of that failing equation thinking we found the problem, but in reality, we had just identified one chain of the chain of events that culminate to the problem. On a side note, we are having a glimpse of what they got through while building Saturn V and the Apollo Missions - no joking. At the time most of the problems were on integrating hardware components, not software - but the theory is similar to what we get here: identify the whole chain of events that lead to the problem in order to get the root cause of the glitch and see the most economic/safe/both way to prevent it to happen. There's no time enough on a lifetime in order to learn all we need to really appreciate what was done! https://www.zdnet.com/article/to-the-moon-ibm-and-univac-appollo-11s-integrators/

Fellow Kerbonaut, you gave me a hell of an idea. (Pun really intended). Thank you!

Here, I fixed that for you. TweakScale is not affiliated with the butchery I promote on my unofficial efforts!! Things is… Neither do I. Every single time TweakScale had to "cope" with IFS was due rogue patching, where third-parties were shoving unsupported configurations into a part and, so, we ended stomping each other toes because that configuration was just not supported (not to mention feasible - we just should not shove more then one Fuel Switch on a part, it's insane!).

Well. Finally we diagnosed the problem! Things is… All Tweak is the Add'On in need to be maintained to fix this (or not, it's up to All Tweak maintainer to decide if he wants to support AirplanePlus this way!). The nice thing with All Tweak is that it's a quick&dirty way to add support to parts not supported by TweakScale or third parties. The not so nice thing is that it doesn't works perfectly every time. You found one of this times where All Tweak doesn't works perfectly. Unfortunately, I'm currently completely out of time to engage into such entrepreneurship. I'm currently overwhelmed by TweakScale's back log, that includes the included patches for third parties Add'Ons. I just can't build this patches myself - not because it's hard, but because I don't have the time to proper do it; implement, test, check for compatibility issues with others, implement again, repeat until it's good to ship. Additionally, I'm reticent on adding such patch into TweakScale, as it's already fat enough - and all that weight is costing me too much when inside TweakScale. My goal is to create a "TweakScape Companion Pack" where third parties support will be added (and properly supported - no Savegame will be left behind!), leaving the "vanilla" TweakScale with the duty to support only Stock and DLC parts. More than half of TweakScale releases this year were sorely due problems on patches!! I barely touched TweakScale code for more than six months. What's a problem, because there're interesting Research in Development in need to be retaken. See the next post of mine, to be published in the next few hours with a interesting report with findings of mine!

If we are talking 1.8.1, yes it is. Since Oct 30. Yes, it works on career. My own experience using TweakScale on career is mixed with fun, but sometimes with making things too easy. By trial and error, I found that by avoiding scaling the engines up I manages to prevent spoiling the challenge on some missions. But if you are running a modded career, it can also help to try completely different approaches to some Contracts. I remember mapping Kerbin using an first war bomber inspired aircraft using Firespitter. I had to upscale some parts in order to get the part count low, and upscale the prop engines to simulate a WW1 bomber engine. (I was committed to avoid upgrading the installations just because I would be harder) Some screenshots of that time:

Hi, guys. TweakScale maintainer here. I just diagnosed a glitch where a dude, while migrating from the previous version to the latest, forgot to delete DSSHU-Tweakscale.cfg that he manually installed (it was optional by then), and then ended up with two copies of that patch, that so were applied twice, and that triggered TweakScale into some FATALities. The distribution ZIP is OK, is was a human error (also known as "bork" ). But since I (yeah…me, myself. ) also did a similar mistake this week on some patch of my own, I though it would be a good idea to advise. Murphy works in strange ways...

To tell you the try, I just fixed one of mine "production" installments with his exact very same problem. I'm migrating one of them from 1.7.0 to 1.7.3, using the 1.7.3 test bed as base install. Things is… The newer installment had some patches of mine on the "new, correct place" as they are now stable. The 1.7.0 was where these are being final tested (and since it's months since I played on 1.7.0, I completely forgot about). Guess what? When I merged the installments, my patches were duplicated exactly as it happened to you. 70 FATALities. And I'm the author of the damned thing!

Lots and lots of inspiration. I will try the lawn mower version.

A not so comfortable True on Software is that we build things on a Castle of Cards. We have some resilience, of course: once one of that Cards fails, it stresses the other Cards and as the fails pile up, the Castle goes down. And as a Castle of Cards, the higher is the Castle, bigger is the basement and so, slightly more resilient to failures down there, as there are a lot of Cards to take the hit of a failing Card - as long the Castle stops growing, because as the Castle keeps growing on a faulty basement, it gets heavier, and sooner or later that redundancy "down there" will be not enough anymore, and so things will collapse. In a nutshell, the bigger is your KSP installment, bigger are the chances of a hidden and usually inoffensive bug be that last straw that breaks the camel’s back. So, going back to your problem, yeah - you have 4 FATALities on your instalment: [LOG 21:07:49.211] [TweakScale] INFO: WriteDryCost: Started [LOG 21:07:51.705] [TweakScale] INFO: WriteDryCost Concluded : 2390 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 4 Show Stoppers found; 21 Sanity Check failed; 0 unscalable parts. being them: [LOG 21:07:51.375] [TweakScale] ERROR: **FATAL** Part HDUConnector (DSSHU 4-way connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 21:07:51.375] [TweakScale] ERROR: **FATAL** Part HDU1 (DSSHU - Habitat Unit 1) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 21:07:51.376] [TweakScale] ERROR: **FATAL** Part HDU2 (DSSHU - Habitat Unit 2) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 21:07:51.376] [TweakScale] ERROR: **FATAL** Part HDU3 (DSSHU - Habitat Unit 3) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). They appears to be all related, so there's a good chance that they share the same glitch. Let's check one of them: [LOG 18:28:17.640] Applying update DSSHU/DSSHU-KerbalInventorySystem/@PART[HDU*]:NEEDS[KIS] to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:17.645] Applying update DSSHU/DSSHU-Tweakscale/@PART[HDU*]:NEEDS[Tweakscale] to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:17.648] Applying update DSSHU/Patches/DSSHU-KerbalInventorySystem/@PART[HDU*]:NEEDS[KIS] to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:17.652] Applying update DSSHU/Patches/DSSHU-Tweakscale/@PART[HDU*]:NEEDS[Tweakscale] to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:18.539] Applying update REPOSoftTech/AmpYear/MMConfigAmpYear/@PART[*]:HAS[!MODULE[KerbalEVA],!MODULE[FlagSite]]:NEEDS[AmpYear] to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:36.265] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] [LOG 18:28:36.804] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to DSSHU/Connector/HDUConnector.cfg/PART[HDUConnector] And yeah, I think we had found it: do you see that DSSHU-TweakScale and also Patches/DSSHU-TweakScale on these lines? There're two copies of that file on your installment. My guess is a mistake on the package (there're two copies of that file on the ZIP file), or perhaps the newest version changed the place of the file for better maintenance (I did it more then once on my projects), and when you (or the tool) installed the update, the older files were not removed. The Add'On Install Best Practices says you must remove all the older files before installing the new version exactly to prevent this kind of problem. However, with Add'Ons saving configurations and settings on the same place as most of the Add'Ons does (not mine, I'm moving them to <KSP>/PluginData/<name>), I agree this can be somewhat tricky. No one wants to lost all his settings on a update.

A Bad Standard is better than no Standard at all. I just got my cheeks bitten by this. AGAIN. TODAY. There's few to no point on hiring a Senior to do a job if the dude wastes most of his time redoing the job due the absolute lack of commitment to Quality from the people he depend on. Seniors are not baby sitters, they are not supposed to second guess every single decision from the young boys, and yet, it's what's happening to some partners around here - there are no experienced professionals on this country, we have only a few (stressed) seniors and a horde of juniors playing havoc with anything they got his hands on, as it appears. It's plain horrible. These youngster got their way trough some critical government services already...

By not being deleted. Or you have more than one installment, and ended up sending me the wrong one (that one I checked is 1.8.1). Or you have deleted it after copying the logs. I don't know you, but more than once here I ended up checking the wrong log from someone (search on the thread, you will find at least two… hehehe). Anyway, everybody borks, including users. My best guess at the moment is that at some point on that older installment's life, you installed Tmasterson5's (or perhaps some alternative that I don't know about) patches and forgot about, because I know for sure that AirplanePlus never included TweakScale support (at least, from the point in which I first used it), and I know for sure that I never kicked TweakScale through the door with a AirplanePlus patch neither. One thingy that could had happened (being that patches from tmasterson5, or something equally aged) is that early on my TweakScale career, I implemented a change request asking for adding the 1.875 scale as standard due Making History had introduced this size as standard. Due the nature as Scale Types are configured on TweakScale, that datum changed from: scaleFactors = 0.1 , 0.3 , 0.625 , 1.25 , 2.5 , 3.75 , 5.0 , 7.5 , 10 , 20 to scaleFactors = 0.1 , 0.3 , 0.625 , 1.25 , 1.875 , 2.5 , 3.75 , 5.0 , 7.5 , 10 , 20 And this could be a perfect explanation for what you are complaining, because now, suddenly, a old patch (or module that choose to hardcode TweakScale in its guts) is getting 1.875 instead of the 2.5 it is used to get on the 5th index. So, yeah, I'm pretty sure your report is valid, the behaviour fits a valid hypothesis. We are getting some trouble on reproducing it, almost surely because you forgot about the things that you had installed and deinstalled on the older installment - unless we have something deleting things for you when you are not looking, but it's way too soon to be paranoid on the matter - Occam's Razor: the simpler (valid) explanation is, usually, the correct one.

I got it. [LOG 17:46:58.565] [TweakScale] INFO: WriteDryCost: Started [LOG 17:48:05.421] [TweakScale] INFO: WriteDryCost Concluded : 1069 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 20 Sanity Check failed; 399 unscalable parts. The good news: no FATALities or exaggeratedly insane parts being sanitized. So, whatever is bugging you, will not kill your KSP. I also found no part from Kerbal Standard (the Manufacturer name used on Airplane Plus) with a TweakScale module on the ConfigCache. I didn't checked every single one of them, of course, but I checked that ones you mentioned plus a few more. So, I decided to check every single patching made by Module Manager on a Airplane Plus part: I realized that Airplane Plus is patching some Stock engines (I didn't knew that!). And then we have 32 patches from OPT_Reconfig into Airplane Plus parts…, what I found unusual. All of that patches is about the IntakeAtm, however, so I'm pretty sure OPT_Reconfig is not involved on the problem you are complaining. You are using the latest TweakScale, good. And also S.A.V.E. EXCELLENT. I also found that you need to install ClickThroughBlocker and ToolbarControl due PatchManager. Or perhaps, uninstall PatchManager if you don't plan to use it. [WRN 17:31:29.702] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ClickThroughBlocker' V1.0.0 [WRN 17:31:29.702] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ToolbarController' V1.0.0 [WRN 17:31:29.702] AssemblyLoader: Assembly 'PatchManager' is missing 2 dependencies i also run into your GameData folders: No evidence of anything I know that could be borking the way you say it is - unless someone had injected a rogue patch inside a third party Add'On's folder. But I think it's way to soon to be paranoid at this point. However, you are using SXT. And SXT have, indeed, patches for TweakScale. No SXT patch touched any AirplanePlus part, however. But it worth give it a peek nevertheless. SXT has too some Size2 parts! However… As you can see, no patch is being applied to any Size2 part of SXT (if it have any). So I don't think SXT has a problem neither. The only thing that remotely could be similar to what you describes are slanted fuel tanks: The conical tanks appears listed as one size (Size 2 in this case), but TweakScale lists it on another. This is due these parts has two bulkhead profiles, 2.5 and 3.75 on the ADTP-2-3 - and TweakScale scales them using the bigger size as reference. This is the only hypothesis I could imagine from what you describes and analysing your kSP.log and ModuleManager.ConfigCache files. I found nothing more that could explain what you describes. If you still can reproduce your issue on this environment, I really need a Screenshot of the problem in order to keep going.

Almost. You didn't pushed the changes, they are probably lingering on your HD. They are not on the github yet. Alternatively, you can zip the files and drag and drop them on a comment on the github comments. Github will upload the file somewhere, and them provide a link on post. This is a handy way to publish logs and other artifacts that you don't care to maintain. (other than that, the idea of keeping the log files on a github account can be interesting for some use cases… I'm thinking about) Yep… It is what happened to me too. I can't. Because I don't use anything that is not available from 1.4.0 to nowadays. Not a single feature - so there are no "legacy" to cope with from my side. Recompiling things using the same .NET compiler don't change anything, I got the very same binary (identically) every time I tried. Recompiling it using the .NET 4.x will not change anything, because the CIL don't magically solve coding problems - not to say a mishap happening from a third party DLL. Look on the bright side - Sanity Checks are automatically fixable, and they are fixed on your installment. So you don't have a problem to fix, just a nuisance to be aware (as ideally, these Sanity Checks should not be failing). About 9 to 15 of these ones (depending from what Add'Ons you are using) are TweakScale not supporting a part that someone had patched (as Module Part Variant with mass, a silly change that I didn't had the time to proper develop - ie, check, code, test, validate and then publish). Other are parts that should never be patched at first place, and kerbalEVA is one of them. In all cases, TweakScale us saying: On a side note, you should had a 29 for the counter on the "Unscalable parts". Fixing it for the next release.

What you are getting is something similar to this? (I just got this on one of my "production" installments - damn it. ) [LOG 12:18:28.705] [TweakScale] ERROR: Exception on kerbalEVA.prefab.Modules.Contains: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 [LOG 12:18:34.939] [TweakScale] ERROR: Exception on kerbalEVAfemale.prefab.Modules.Contains: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 For documentation, on ModuleManager.ConfigCache I found: UrlConfig { parentUrl = Squad/Parts/Prebuilt/kerbalEVA.cfg PART { name = kerbalEVA crashTolerance = 50 <lots ot more things> } UrlConfig { parentUrl = SquadExpansion/Serenity/Parts/Prebuilt/kerbalEVA.cfg PART { name = kerbalEVA bulkheadProfiles = srf, missingBulkheadProfiles <lots ot more things> }

Not usual on working days. (I work building bridges between different protocols - kinda a simplified service bus. I got pretty wasted some days). Well, let me try to consolidate the problem. On KSP 1.8.1 with TweakScale and AirplanePlus (and something else that adds TweakScale to it, I'm guessing TMasterson5's , as this is the one linked on Airplane+), there's a Size 2 part that is wrongly default scaled (it should be 2.5, but it's 1.85, and things get messed on scaling it). I'm downloading the latest Airplane+ (new release for 1.8! I missed it!). I will come back here soon. — — POST EDIT — — here, see this: This is my 1.8.1 test bed. It have only a few Add'Ons installed on it, as you can see: In time, I didn't used the Firespitter embedded on AirplanePlus - I downloaded the latest manually, just in case. And as you can see, they are not scalable on my testbed. And the reason is simple: there're no patches for AirplanePlus - nor on TweakScale, neither on AirplanePlus. So there're something more on your KSP installment, and the only way I could further help you is by inspecting the KSP.log (and the ModuleManager.ConfigCache can be useful too!). Otherwise, I just can't know what's happening on your machine.

Upload it to the dropbox. Put also the ModuleManager.ConfigCache, sometimes it helps to cook a fix when needed. If you have a github account, you can zip them and put them on a commend on this issue: https://github.com/net-lisias-ksp/TweakScale/issues/63 copy&paste the URL of your post here to make easier to cross reference.

I just remembered! IIRC, on Making History Squad needed to inject new Suits into the Kerbals. By some reason, they choose to add multiple configs entries for the feature (i.e., more than one Config Section with the same "name=" entry) instead of modifying the existent one. (Don't ask, I don't have enough information to make any judge of value on the matter, I just accepted the change and kept going). I remember KIS (or KAS?) borking due it, because when you do a query for a configname that have more than one entry using a function that returns only one, that function returns the latest one (think on it as an array - the first gets index 0, the second index 1, and so on), but since Module Manager acts before Making History is instantiated, by that time the patches are applied on the index 0 one (the only one alive at patching time!), and after Making History adding the extra entry with its own data, Add'Ons relying on the singleton behaviour started to fetch the second entry where - obviously - none of the patches were applied. Interesting enough, the very second issue on TweakScale (under my management) is about it. I had it also on Issue #38 - but at that time, I had misdiagnosed it. Interesting enough, I also had a situation where TweakScale were blowing up due a config module data misconfigured. It ended up that a rogue patch (apparently) was shoving TweakScale on a Kerbal EVA. What is something interesting to really implement one of these days of boredom - if I manage to get one.

That's my secret, Captain: I don't. i forget everything every time, and had to learnt it again. It happens that I'm a fast learner! Airplane plus never supported, directly, TweakScale. They relied on Tmasterson5's patches for it. Unfortunately, these patches didn't aged well, and I can't fix them as they are ARR. I had thrown the towel on this, someone need to write new and proper patches for AirplanePlus. I can help, but doesn't have the time ti do it myself. What part? Try to reproduce the issue using a clean KSP with just Stock, DLC and TweakScale (and MM). If the problems persists, send me the KSP.log and ModuleManager.ConfigCache (and the name of the part!) So I can fix it.[ Nonsense! If it's reproducible on a clean installment, I don't need all of that! Give me the name of the part, it's enough! ] If you can't reproduce it on a clean installment, you have a rogue patch on it. Well.. send me the files [KSP.log and ModuleManager.ConfigCache] nevertheless. And the name of the part with problems.

So is Lucifer. Where in hell are my wings, by the way???

People borks, dude. It's what we do better. Who borks the borkers? — Watchkermen When I bash my ass out to help someone here, I'm not doing it because I'm masochist or I don't have anything better to do - I do it because every time I help someone here, and explain what I'm doing, at least one guy (but usually a lot more) is watching it too. And learning. And once people enough learn enough, I'll be not the only one knowing that thingy anymore - and so we will have more trained eyes able to detect that specific glitch. And sooner than later, a critical mass is reached and things starts to happen by their own: people will be able to help people without relying on a few enlightened to help them - most of the time, at least. This is the core principle of the Stone Soup Story: one smart guy came on a starving village, start to cook a magical stone soup, and as people gathers in curiosity, he start to ask for small things to make the soup better. And in the end, everybody got a very decent meal. One or another always ends up giving more than others, but since in the end these guys would not be able to make the soup by themselves, it's still a win-win situation the same way. It's what's should be happening here. Now you know a bit more than you knew yesterday. Ok, this didn't solved your core problem - but, look, we now have one less problem to cope (you had two of them, and didn't knew about). And I'm pretty sure that if by some reason you stomp across a fellow Kerbonaut with a stack dump mentioning a File Not Found exception inside the DLL, a small light bulb will bright in your head and you will be able to tell the guy that something is missing or wrong on that specific Add'On, and both of you will be able to call the right guy to fix it - or, at the worst, call someone more experienced to help and giving the dude some work already done. What I did may sound a lot of work (well, it is), but there're a lot of people that did the same in the past and this is the only reason I have KSP to play the way I want nowadays. I may not be able to give back to that guys directly, but I can do it to whoever is around today. And them we can keep this virtuous chain alive and ongoing.

For every complex problem. there's an explanation that is simple… AND WRONG. I reproduced the problem described by @Problemless Mods Wanter. I downloaded KSP-AVC 1.4.0.2 (PRE-RELEASE - i.e., it's still on testing phase). And I got exactly the same Exception our fellow Kerbonaut found on its installment. [LOG 18:56:08.950] KSP-AVC -> System.IO.DirectoryNotFoundException: Could not find a part of the path "/Users/lisias/Workspaces/KSP/runtime/1.8.1/GameData/KSP-AVC/Plugins/Textures/ OverlayBackground.png". at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonym ous, System.IO.FileOptions options) [0x00164] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6 >:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenRead (System.String path) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at KSP_AVC.Utils.GetTexture (System.String file, System.Int32 width, System.Int32 height) [0x00016] in <d05e532f012b47999887e5d33b07d5c6>:0 [LOG 18:56:08.950] KSP-AVC -> LoadCfg I MANAGED TO FIX THIS GLITCH.And it was pretty simple. I moved the Textures folder into the Plugins folder, as the GOD DAMNED EXCEPTION IS COMPLAINING ABOUT, DAMN IT!. cd ~/Workspaces/KSP/runtime/1.8.1/GameData/KSP-AVC mv Textures Plugins And voilà, no more exceptions from KSP-AVC. @linuxgurugamer, I think this information interests you. So, our friend @Problemless Mods Wanter was doing everything right. It was something else in need to be fixed, and this is perfectly OK - we publish things under a PRE-RELEASE tag for a reason, and this is one of them. I'm pretty sure LGG will be able to fix the problem promptly. I don't known if this was borking MechJeb2 however, I didn't bored to verify - I have some more testing to be done for people that are really helping people around here the best they can, I'm not on the mood to waste my scarce free time.

Unusual. The stocks parts fails sanity by lack of proper support on TweakScale (the whole 2.4.x series will be focused only on this!). And the numbers on a vanilla installment is 9, or 15 (or 12? I will check soon) with DLCs. Send me your log. Let me inspect this. — — — POST EDIT — — — [LOG 17:45:33.171] [TweakScale] INFO: WriteDryCost Concluded : 456 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 9 Sanity Check failed; 103 unscalable parts. Yep, the numbers is 9 - to the whole shebang (Stock + the 2 DLCs). There's something more on the installment. Check for any hotfixes or overrules on the __LOCAL (or wherever you stored them), as that stunt would cause some glitches once the problem they aims to fix/overcome is no more.

Since my last post here... … I was wondering how it would look a daVilland Comet on Stock parts. I ended up that Stock doesn't have round fuselage for the task, we have the Mk1 for 2 Kerbals, Mk2 for 4 (but this one is flat) or we have Mk3 for 16 Kerbals (and this one is oval). Well, it ended up that I could live with that - I ended up building a Comet 1 looking craft with the Comet 4 PAX capacity.

Lua is light, fast and portable - but complex things can be a challenge. You end up writing yourself a lot of things that other languages already offer ready to use, and this can be a show stopper. I tried to write a small dynamic dns daemon to be run on my openwrt router once. It worked, but the lua available on openwrt at that time didn't had one library needed for the task, and writting that myself would be 10 times the effort of the damn thing. So I rewrote the shenanigan non python, shoved it on a raspberry pi and called it a day. This will happen too on KSP2 using Lua. It will he really great for automating things that are already there, but for new complex things you will end up coding in C#.

To much to lose, too few to gain. Once you do all the QC on the thing, a change like that will demand a new round of testing. And it's not that useful as you think. More than often, you reuse components from other products and you don't want to use on the new product the name from another. As a example, what's Breaking Ground on KSP1.8 can be called Heavenly Automations on a new game called Human Space Program - so instead of renaming every single artifact all the time, you keep the codename and then work only on the localisation files.