Lisias

Hi. An user just report me a duplicate patch on the SpaceY-Lifters/Patches/SpaceY_TweakScale.cfg patch. A "rogue" wildcard is patching a part twice, with two completely different patches. [LOG 13:07:36.605] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYtank5m3mAdapter]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/FuelTanks/tank5m3mAdapter.cfg/PART[SYtank5m3mAdapter] [LOG 13:07:36.609] Applying update SpaceY-Lifters/Patches/SpaceY_TweakScale/@PART[SYtank5m*]:NEEDS[TweakScale] to SpaceY-Lifters/Parts/FuelTanks/tank5m3mAdapter.cfg/PART[SYtank5m3mAdapter] What renders the ModuleManager.ConfigCache with this duplicated entry for TweakScale: MODULE { name = TweakScale type = adapter_4_3 defaultScale = 5.0 } MODULE { name = TweakScale type = stack defaultScale = 5.0 } I don't know what patch is the correct one, however. Apparently no harm is being done, but TweakScale "fix" for this problem induces am annoying warning from KSP every time the craft is being loaded. Cheers!

"This one?" *click*

I believe him.

So, that's the history. I have been working hard on fixing every single glitch that have the bad luck of happening under my nose. I didn't cared about who was the maintainer, if I could fix it, I did. And published a pull request when possible so everybody else could have the thing fixed too. I tested. I diagnosed. I borked some times. But yet, as times goes by, the problems started to be rarer. No more crashes. No more misbehaviours. No more loosing savegames. One or two glitches are still there, but these ones I know by name and they are harmless - only nuisances that were caught due being similar to real nasty problems, and it's too much of an effort to code yet more Safeties to try to sort them out of the bad ones (and then risking a bad one pass through). Sometimes, it's cheaper to just take the hit. So I thought it's finally the time to rescue my stalled savegames since the late 2018 (including that one that started it all). Let's begin with the more recent one, from April 2019 (I'm starting to name the savegemes using the current year, by Kraken's sake!). I had some very good work, exploiting some very interesting concepts on that savegame - things that I want to be developed again, things that I spend as many hours on it as I did on maintaining my Add'Ons (not a small figure, believe me). So I did the migration. Being cautious, I choose to migrate the 1.7.0 one into 1.7.3 (before the 1.8 leap!). Work on it the whole WeekEnd, sorting out the Add'Ons that should be updated from the ones that should not. Most updates worked fine by the way - at least, to the moment. Well spent 2 days, I thought. Now, finally, some playing! Or not. On the very first savegame, on the very first craft, there were missing parts. But how? I was upgrading the thing, not downgrading - and even that, almost every Add'On updated were just little incremental versions with bug fixes or simple recompiles (whatever be the usefulness of this). (sigh). Everything was too good to be true. Let's debug the thing again. And then I figured out the problem. A very important Add'On to me, on a build release (not even a minor one) had dropped support for some parts, as the maintainer choose to replace them with new versions of it. Newparts are good news, losing very used parts? Not that much. Well, let's rollback that Add'On, right? But I have a problem - it have a very serious bug when used with some newer Add'Ons. The really nasty kind of bug. So I have to decide to take my chances with the bug, or plain forget about a considerable amount of crafts on my savegames. Or to stick with the older KSP version forever. One may argue that I could fork myself the thing and "fix it" myself. I do that already every other day, so why not? Perhaps the maintainer would notice that it was a bad move and then he would merge back the changes and everybody would benefit from this. Sounds like a good idea - but I can't. The authors choose to change the licensing terms of the thing, I can't (legally) fork and fix it myself anymore. Our hands are tied on the matter. (sigh) It's hugely frustrating. KSP is not a disposable game. We keep playing it for years - not rarely, the very same savegame!! Right now I just gave a hand to a fellow Kerbonaut looking for the best version of some Add'On he like for… KSP 1.2.2 . Yeah, 1.2.2. That one from December 2016, three years ago. And I perfectly understand him, I feel his pain. Because if me, with a 1.7.0 savegame and very good coding and debugging skills, have my hands tied on a migration to 1.7.3 KSP (mere 3 minor releases), what we can tell about the average user? And now we have two guys tied to older KSP versions and so, there's no chance to try to sell us a DLC and with the money help to fund the Development Team (that guys that have bills to pay, mouths to feed and that spend all their time coding things for KSP). It's hugely frustrating. Users spend a huge amount of their scarce time doing things and then they get emotionally attached to that creations. They create, they love to create - and then they love their creations. And so they want their creations to thrive, not be thrown away and forgotten! You want the users to move on to newer things? You need to provide them a path, so they can bring their stuff with them - otherwise, they just won't: they will stick with the older stuff, or they will get fed up and ditch the whole thing (including you). And then the ones that choose to stay will fight to protect their creations. I know I will - it's essentially what I'm doing for an year already. You may be doing it for free, but this does not make their creations worthless for them (and they are paying for that, even if you don't get any money from it!). And doing things for free don't grant you the right to impose them what you want neither - even giving people biscuits for free can give you some jail time, you know… On the bottom line, you just can't force their hand into doing what you think is right - even if doing it for free. You need to convince them, you need to talk to them, you need to listen to them - i.e., you need to work with them. Even by doing the right thing, they will complain to you if they get hurt on the process - and so you need to work out that hurt too. Or you can just let them go, it's also an option - you don't have to do it if you don't want neither. But then, just don't go scorched earth, please? Let us keep things going. Users are our clients, not our subjects. Users will work with you or they will work around you to get what they want. Don't put yourself on a place where they may choose to work over you.

2.0.8, says Spacedock. https://spacedock.info/mod/793/Buffalo- Explore In Style

I think I need a new definition for "few hours". That's this history: I toyed a bit with scaling up parts with crew capacity. Again. This time on 1.8.1 to see if something had changed. TL;DR : No, it's no possible to scale up CrewCapacity due some hardcoded limits on KSP - some heavy hacking will be needed. Default Behaviour - no scaling up. Previously, I had postulated that probably the UI was borking because it was coded using the Part's prefab CrewCapacity value, instead of the part's CrewCapacity. This was confirmed for 1.7.x and 1.8.x (almost certain for every KSP in the past, but I didn't bored to confirm this - yet). I had confirmed this by trying a stunt: I scaled the prefab's CrewCapacity too (while saving the original value in another place). By doing that, the UI started to behave as I intended - but, of course, mangling with the prefab caused collateral effects. The Part capacity for new parts started to have more crew seats, no matter it was scaled or not - what's expected, after all, I was mangling the prefab! By mangling the prefab, things kinda works. More or less.. You can at least populate the part now. But we have this glitch on the Part List now… (due the prefab mangling) In 1.8.x I run trough a new behaviour, however. Now there's a check on launching the craft to prevent it to be launched with more crew than available seats - on prefab. Previously I could hand code a craft file with the crew capacity expanded and crew allocated, and the craft was being launched all right. But now a Exception is being thrown - of course, the check is looking the prefab CrewCapacity, not the living part's one. Damn. [EXC 02:35:05.426] IndexOutOfRangeException: [PartCrewManifest Error]: seat index out of range: i = 4 while mk1-3pod has 3 seats PartCrewManifest.AddCrewToSeat (ProtoCrewMember crew, System.Int32 seatIndex) (at <394a98b9c7624adc895c04290da62640>:0) KSP.UI.BaseCrewAssignmentDialog.GetManifest (System.Boolean createClone) (at <394a98b9c7624adc895c04290da62640>:0) KSP.UI.BaseCrewAssignmentDialog.Refresh () (at <394a98b9c7624adc895c04290da62640>:0) KSP.UI.CrewAssignmentDialog.MoveCrewToEmptySeat (KSP.UI.UIList fromlist, KSP.UI.UIList tolist, KSP.UI.UIListItem itemToMove, S KSP.UI.BaseCrewAssignmentDialog.ListItemButtonClick (KSP.UI.CrewListItem+ButtonTypes type, KSP.UI.CrewListItem clickItem) (at UnityEngine.Events.InvokableCall`2[T1,T2].Invoke (T1 args0, T2 args1) (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.Events.UnityEvent`2[T0,T1].Invoke (T0 arg0, T1 arg1) (at <7d9ec060e791409ab3eb85c61e312ed6>:0) KSP.UI.CrewListItem.<Awake>b__26_0 () (at <394a98b9c7624adc895c04290da62640>:0) UnityEngine.Events.InvokableCall.Invoke () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.Events.UnityEvent.Invoke () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) KSP.UI.UIStateButton.<Awake>b__24_0 () (at <394a98b9c7624adc895c04290da62640>:0) UnityEngine.Events.InvokableCall.Invoke () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.Events.UnityEvent.Invoke () (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.UI.Button.Press () (at <6b3e52a3b1e042958be60434d0f24ce7>:0) UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <6b3e52a3b1e042958be60434d0f24c UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystem UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData event UnityEngine.EventSystems.EventSystem:Update() So, besides being able to hack my way into the UI (even by relying on dirty tricks), apparently on 1.8.x they had shut tighter the door for this feature. I can't edit or launch the craft anymore after forcing my way into scaling up the Crew Capacity - unless I mangle the prefab, with undesirable collateral effects. So the following screenshot will be still a dream for some time yet. At least we still have our dreams! If you want to give a shot on this, you need to checkout this branch and then define the symbols CREW_SCALE_UP and, if you are feeling adventurous, PREFAB_SCALE_HACK. Symbols to be defined to compile the hack. I think the only way out for this feature will be patching KSP code using Harmony. It's something I prefer not to do dure the potential collateral effects this can incur, but as it looks, will be the only possible way for this. Historic of the feature: 2019-0517 2019-0531 2019-0605 Also available on my site.

BOTH!!!

Trucks!

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.