Lisias

Well, I just tested this Companion with TS 2.5 beta and CXA, and by coincidence, on 1.9.1. And I found not problems. So it should be something on your rig. Publish the KSP.log and I will try to find something wrong there. -- post edit -- @Dhruv, please redownload the LivingStyle (completely remove the directory you have on your rig before installing). While double checking due your report, I found some files on the wrong place. (not related to your issue, anyway).

Never, ever, leave the Engineering Team alone on duty in an extended holiday - with the keys of the warehouse and Jebediah around. Safety First! Higher resolution images and craft on my site. Or in Kerbal X.

Geez! How I could forgot this one? A pretty impressive work in progress collection of modern aircrafts!

This is by design. Working with % is cumbersome when you need to match sizes from different bulheads. Having a "hard point" to quick scale to, and then fine tunning is easier to to cope than having to remember the percentage that part have to be scale to match that another one. That said, from TS 2.5.0.20 Beta (and the hopefully near 2.4.4.0), it's possible to change the scaling of living parts again. So you can make a quick&dirty MM patch to replace every scaleType = stack and scaleType = stack_square to free and free_square respectively if you prefer - your crafts will follow suit on the spot,and when exporting them to other installments that didn't applied your patch, they will be converted to the local settings. Shove what follows on someplace in your instalment (I suggest __GameData/__LOCAL/TweakScale/UserCustomizations/I-want-to-break-free.cfg): // Use this **ONLY** on TS 2.5.20 BETA, the future TS 2.4.4.0 or newer! @PART[*]:NEEDS[TweakScale]:FINAL { @MODULE[TweakScale]:HAS[#scaleType[stack]] { @defaultScale = 100 @scaleType = free } } @PART[*]:NEEDS[TweakScale]:FINAL { @MODULE[TweakScale]:HAS[#scaleType[stack_square]] { @defaultScale = 100 @scaleType = free_square } } However, this doesn't means your suggestion has no merit. I'm toying with an widget that would allow you to enter precisely the size you want using the keyboard using absolute values, and there's nothing impeding me to accept percentages on that text widget. And perhaps a sliding bar too. With the worst technical debts on TS being tackled down and new "technologies" (a.k.a. terribly crazy stunts that managed to work without screwing everything! ) developed, I'm just a couple steps from exploring the new KSP U.I. services without sacrificing backwards compatibility (a cornerstone to me as a maintainer, as I don't have time to maintain numerous releases of the same product, at the same time I'm a KSP 1.7.3 user myself and I think it's understandable not be willing to maintain things you can't use). You are not the first that asks for something like this. It's time to proper register it as a Feature Request. Sounds like something wrong on scaling dragCubes.... I will check it. This is on KSP itself. Somewhere in the part (I think this started on KSP 1.4.0), some models started to get their animation pivots handled as they were part of the colliders, and since some complex animations had their pivots displaced from the part, sometimes these pivots ends up under the ground. Since they were intended to be used only as pivots, it was not a problem - and, in fact, until KSP 1.3.1 (if memory serves me right), KSP was smart enough to detect and ignore such vertices. On KSP 1.4 something changed and we have this "Jumping Jack Effect" as I call it. The wheels of Firespitter are another victim of the problem. I was told that using World Stabilizer would fix the issue - but didn't tested it myself yet.

On the other hand, it's not needed. On Linux Distributions, it's not unusual to have two different "Maintainers" on the loop: the guy that develop the thing, and the guy that build the package of the thing to be distributed somewhere. Take Midnight Commander, for example. The guy that packs it on Debian is not the same guy that packs it on Gentoo - not to mention on MacPorts. All different people packing the same thing on different places. But the Developers are the same on every distro. The guy that maintain a netkan metadata file doesn't needs to fork the project. Just need to keep the netkan metadata accurate. CKAN could make things yet more easier by adding a metadata called "packager" that on absence would be defaulted to the author. What ended up hurting both the tool and the users. I'm not opposed (au countrary) to have a "main branch" where only "official forks blessed by the current maintainers" are distributed, but not having an alternate channel for everybody else is a nice shot on the feet I say.

MM is a bit trigger happy while labeling DLLs as "incompatible". Most of the time, the DLL only suffered an Exception on the wrong place, triggering the Exception in a way that MM thinks its due incompatibility - but it can be anything else, from a corrupted or missing file being read while initializing the DLL, to a missing dependency. Unfortunately, MM also masks the error on the output_log.txt - so I will need the KSP.log and most of the time also the files on <KSP>/Logs/ModuleManager in order to check exactly where and why the DLL had borked, so I can try to propose a fix.

yes. But delete the TweakScale patches for it, if you use TweakScale of course. -- -- POST EDIT -- -- If you are a TweakScale user, you should install this.

If you are talking about "stolen mods", it's unavoidable that we end talking about licensing and copyrights. They are mutually inclusive concepts, it's plain impossible to define a "stolen mod" without them.

Dude, there're a lot of weird exceptions scattered on the log: [AddonLoader]: Instantiating addon '_BuildManager' from assembly '_BuildManager' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) Uploading Crash Report NotSupportedException: The invoked member is not supported in a dynamic module. at System.Reflection.Emit.AssemblyBuilder.get_Location () [0x00006] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at _BuildManager._BuildManager+<>c__DisplayClass2_0.<logVersion>b__0 (System.Reflection.Assembly x) [0x00000] in <caa8a9a07bbf48af914d3a76740b33a6>:0 at System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].ToList () [0x00019] in <fbb5ed17eb6e46c680000f8910ebb50c>:0 at System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x0001f] in <fbb5ed17eb6e46c680000f8910ebb50c>:0 at _BuildManager._BuildManager.logVersion () [0x0005c] in <caa8a9a07bbf48af914d3a76740b33a6>:0 at _BuildManager._BuildManager.Awake () [0x00000] in <caa8a9a07bbf48af914d3a76740b33a6>:0 Uploading Crash Report CustomAttributeFormatException: Could not find a field with name guiName at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesInternal(System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inheritedOnly) [0x00013] in <a at System.MonoCustomAttrs.GetCustomAttributes (System.Reflection.ICustomAttributeProvider obj, System.Type attributeType, System.Boolean inherit) [0x00037] in <ad04dee02e7 at System.Reflection.MonoMethod.GetCustomAttributes (System.Type attributeType, System.Boolean inherit) [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at BaseEventList+ReflectedData..ctor (System.Type type) [0x00052] in <c1858a3f77504bd1aaa946fdccf84670>:0 at BaseEventList.GetReflectedAttributes (System.Type type) [0x00026] in <c1858a3f77504bd1aaa946fdccf84670>:0 at BaseEventList.CreateDelegates (System.Object part) [0x0000b] in <c1858a3f77504bd1aaa946fdccf84670>:0 at BaseEventList..ctor (Part part, PartModule module) [0x0003c] in <c1858a3f77504bd1aaa946fdccf84670>:0 at PartModule.ModularSetup () [0x00007] in <c1858a3f77504bd1aaa946fdccf84670>:0 at PartModule.Awake () [0x00023] in <c1858a3f77504bd1aaa946fdccf84670>:0 PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object at PartModule.Load (ConfigNode node) [0x0010d] in <c1858a3f77504bd1aaa946fdccf84670>:0 at Part.AddModule (ConfigNode node, System.Boolean forceAwake) [0x0006f] in <c1858a3f77504bd1aaa946fdccf84670>:0 at PartLoader.ParsePart (UrlDir+UrlConfig urlConfig, ConfigNode node) [0x00f10] in <c1858a3f77504bd1aaa946fdccf84670>:0 at PartLoader+<CompileParts>d__56.MoveNext () [0x005cd] in <c1858a3f77504bd1aaa946fdccf84670>:0 And a lot more repetitions of that pattern. The trigger (but not the culprit, I think) for the the final crash is: Uploading Crash Report StackOverflowException: The requested operation caused a stack overflow. at InterstellarFuelSwitch.InterstellarFuelSwitch.nextTankSetupEvent () [0x00062] in <d01e29ea4c244ea6a8ffa3a0882ff107>:0 at InterstellarFuelSwitch.InterstellarFuelSwitch.nextTankSetupEvent () [0x00062] in <d01e29ea4c244ea6a8ffa3a0882ff107>:0 <repeat the last line ad nauseaum> This sounds as file corruption. Some of that Add'Ons are known to me, and they didn't ever triggered such Exceptions here - so it must be something environmental. Perhaps something truncated or zeroed some of the files? (someone call tell me if crosslinked clusters are possible on NTFS?) Some file system corruption ended up It sounds like the most plausible explanation (but I'm guessing). You will need to brute force your way out of the mess. Remove everything from the game to another directory (remove, not delete). Then reinstall things from scratch - remember to do not fire up your savegames - create new ones for the test, don't allow KSP to touch anything you value on these tests. Use new, fresh downloads of the add'ons - just to be on the safe side of the force. If you manage to rebuilt your installment and get free of errors, copy back the savegames and try them. If not, publish the new Player.log (but add also the KSP.log too - some things are easier to read from it) and let's see what changed. On the worst scenario, perhaps you have a hardware problem, being bad memory the most common of them (otherwise your rig would not even boot up). Doing a memory test would not be a bad idea.

Announce TweakScale Companion for KIS was updated, fixing a pretty stupid mishap on handling dependencies... Other than that, nothing changed. In time, the lastest TweakScale Beta 2.5 is now handling Parts with Variants with Mass and Cost! -- -- TweakScale Companion Living Style was also updated and promoted to Release Candidate! It addes support for CxAerospace Station Parts. -- -- Cheers!

Got it! [LOG 04:08:31.475] [TweakScale] INFO: WriteDryCost Concluded : 2193 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 38 Show Stoppers found; 9 Sanity Check failed; 1045 unscalable parts. [LOG 04:08:31.500] [TweakScale] "Houston, we have a Problem!" about show stoppers on patching was displayed Yeah, 38 FATALities. Let's check one of them: [LOG 03:56:04.614] Applying update KerbalReusabilityExpansion/TweakScale 2/@PART[KRE-AeroLeg-L]:NEEDS[TweakScale]:FOR[KerbalReusabilityExpansion] to KerbalReusabilityExpansion/AeroLandingLegs/AeroLandingLeg-L.cfg/PART[KRE-AeroLeg-L] [LOG 03:56:05.140] Applying update KerbalReusabilityExpansion/TweakScale/@PART[KRE-AeroLeg-L]:NEEDS[TweakScale]:FOR[KerbalReusabilityExpansion] to KerbalReusabilityExpansion/AeroLandingLegs/AeroLandingLeg-L.cfg/PART[KRE-AeroLeg-L] Gotcha. There're TWO config files patching the same parts! KerbalReusabilityExpansion/TweakScale 2 and KerbalReusabilityExpansion/TweakScale. And since there're exacts 38 issues of this patch on the log, the same amount of FATALities, we can say we solved the case: macmini62:3 lisias$ cat KSPTrue.log | grep "KerbalReusabilityExpansion\/TweakScale 2" | grep "Applying" | wc -l 38 However, it does not appears to be a problem with KRE, as I just checked their github and there's only one copy of TweakScale.cfg there. I think somehow you accidentaly duplicated the file on your rig. Please delete GameData/KerbalReusabilityExpansion/TweakScale 2.cfg and you will be ok. The problem is that, probably, MediaFire will outlive the ad-free competition. You get what you pays for.

Announce TweakScale 2.5.0.21 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens. Finally Parts with variants with Mass and Cost are being scaled! ( all the 9 of them ) #HURRAY However... I found a bug on TweakScale when scaling parts that change attachment nodes on the Variants. See Issue #139 for details. I didn't detected it before because parts with "changing nodes" are just now hitting the mainstream (see Rhyno), and the ones I knew had Mass and/or Cost and wasn't scalable until now. I will postpone this one, as it was already happening before and it's easily worked around (switch to the variant you want before scaling, or descale before switching variants and scale again). Annoying, I agree, but I will not postpone 2.4.4.0 for this (already spent half my week on it). Unless something else blows up, there're only two minor issues about patches on the backlog for 2.4.4.0 - but I will not talk about deadlines. Historically, it's a receipt for disaster. Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user! Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!). (link to previous announce)

Same thing. Only Squad is installed on your GameData. You are running 1.7.0, by the way. Apparently, the link you have on the Desktop is not pinpointing to the KSP installment you think it is.

Its' KolonyTools [Nope! See below, I forgot this line when I hit "Save"!] AssemblyLoader: Exception loading 'KolonyTools': 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 <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <55ba45dc3a43403382024deac8dcd0be>:0 There're some of these exceptions on the log, usually meaning you forgot to install some dependency. However, I also found: TypeLoadException: Could not load type 'ModuleManager.CustomConfigsManager' from assembly 'ModuleManager, Version=4.1.3.0, Culture=neutral, PublicKeyToken=null'. at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x00000] in <filename unknown>:0 at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) [0x00000] in <filename unknown>:0 at UnityEngine.AttributeHelperEngine.GetParentTypeDisallowingMultipleInclusion (System.Type type) [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelLoaded(GameScenes) AddonLoader:OnSceneLoaded(Scene, LoadSceneMode) UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode) What appears to mean your installment is really botched! And there're many, many, many exceptions scattered on the log. And then I found this: [KSP Version]: 1.7.3.2594 (WindowsPlayer x64) (x64) en-us ============================== You probably installed KSP 1.7.3 by accident, and this explains the incredible avalanche of Exceptions everywhere - most Add'Ons nowadays are compiled on C# 4, and can be only used on KSP 1.8 and newer, and this includes Module Manager. Since you thought you are on KSP 1.10.1, I think you had setup Steam to use KSP 1.7.3 on the Beta program and forgot about. Open your Steam Client, look for the KSP there, right click on it and opt out from the Beta program. -- -- POST EDIT -- -- Better: select KSP 1.10.1 in the Beta Program, so you don't risk being (badly) surprised when KSP 1.10.2, I mean, KSP 1.11.0 is released!

There's nothing installed on this KSP! No TweakScale, no Module Manager, no nothing! Not even the DLCs. [LOG 10:05:54.188] ************************************************************************ Environment Info Unix 7FFFFFFFFFFFFFFF Args: KSP Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Folders and files in GameData: Stock folder: Squad Stock file: .DS_Store ************************************************************************ I think you fired up the wrong KSP, or perhaps had deleted all the Add'Ons by accident?

That's the magic: MM does not loads configs. KSP does that, all at once and on startup, and then MM takes control and walks all the GameDatabase looking for patches, applying them (or not, see :NEEDS) and then declutter the GameDatabase from them. The difference is subtle, but terribly relevant: MM is not a pre-processor as we are used to use on ANSI-C. By the time MM starts it magic, every config file (being a patch or not) is already loaded, and by the time MM had done its job, it's not possible to redo the process as the patches are not there anymore.

I didn't knew about the Prometheus version - pretty nice (but it lacks something from the Basil's version).

You are not looking at all. I had read the source, I had backported MM to 1.3.1 (1.2.2 in progress). And I had wrote a well documented Proof of Concept. It works exactly as I say it does. Additionally, I strongly suggest you read the material you link yourself. The very page you linked says: Where "this page" is the page I linked above, and you claimed it's the wrong page to read. It's a step away from the current Comfort Zone, no double. But yet, there are plenty evidences above proving that you are wrong about the way you think things work on MM. It's time to reassess the situation. Go to the github repo I linked. Test it. Try to prove me wrong. Try to find a situation where that stunt could be harmful. I'm not asking you to believe in me, I'm inviting you to check what I'm saying.

It's not a problem on MM neither TweakScale. To tell you the true, it's not a problem at all. It's a fix being applied to what something inside KSP thinks it's a.. "inconvenience" (because it's not a problem neither). It's about the order of patching, as well the adding or removing of Add'Ons on a game instalment. Consider the following scenario: You have ModA, ModB and ModC installed. Each one adds something into a partname called RandomStockPart. The prefab for this part, after patching is: PART { name = RandomStockPart foo = bar bar = foo MODULE { name = ModuleA foo = bar bar = foo } MODULE { name = ModuleB foo = bar bar = foo } MODULE { name = ModuleC foo = bar bar = foo } } In the prefab, the RandomStockPart will have a thingy called moduleList with [ModuleA, ModuleB, ModuleC] - where each "Module" is not a string, but a thingy we, programmers, call "instance of an object". Now, consider that you removed ModB, and installed ModD. You will have now what follows on prefab: PART { name = RandomStockPart foo = bar bar = foo MODULE { name = ModuleA foo = bar bar = foo } MODULE { name = ModuleC foo = bar bar = foo } MODULE { name = ModuleD foo = bar bar = foo } } ModuleB is absent, ModuleC took its place, and ModuleD is the new kid on the block and it's now sitting where ModuleC used to be. So you will have this on that moduleList thingy: [ModuleA, ModuleC, ModuleD] . Apparently, something inside KSP depends highly on the order in which these objects appears on that list, because every time a Module switches places, you see that messages you described being issued. Besides annoying, I don't consider that messages bad. To tell you the true, without that messages I would probably still be chasing my tail on a lot of weird things I got with TweakScale lately. These messages hinted me about how KSP internal process works while migrating things (and, most importantly, when). The ModuleManagerWatchDog is just what it names says it is: a watch dog. It checks if Module Manager is correctly installed on your rig, because since KSP 1.8 some very critical thingies inside KSP guts had changed, and this screwed up royally Module Manager, rendering it unable to detect itself the problem. So an external tool, without the MM limitations (and legacy behaviour) was needed to check these borderline situations and bark on them when detected. It does not interferes on MM in any way, it just watches its back and barks when needed. You are already on it. It only happened that this direction is a bit noisier than usual.

Nope. From the very MM documentation: So, :FOR[AirplanePlus]:NEEDS[AirplanePlus,UnkerballedStart] will be plain removed if AirplanePlus or UnkerballedStart is not present, and will never have the change to create the tag on MM's data structures used on :FOR, :BEFORE, :AFTER and :LAST. This can be easily verified using 3 simple configs: And the results: And from ConfigCache: UrlConfig { parentUrl = ModA/config.cfg PART { name = ModA-Part title = This is the title of ModA. And ModC was here! } } However, now we need a counter-proof. Let's remove ModB from GameData and see what we get: And on the ConfigCache: UrlConfig { parentUrl = ModA/config.cfg PART { name = ModA-Part title = This is the title of ModA. } } So, yeah. The stunt works fine. As we can easily verify, there're no real dependencies between :FOR and :NEEDS. All we have is a clever sequence of well defined actions taken on well defined phases of the patching process. "Source Code" and evidences of the thing working as I say it does on KSP 1.3.1 and 1.10.1 (I considered testing on more KSP versions unneeded) are on my github - so anyone can easily check him/herself . @R-T-B, I think this will interest you.

Wow. Publish the Player.log instead. The OP has instructions about where to get it. -- -- POST EDIT -- -- Nah... I think I found a suspect. On the very last line of the log, I found: [ERR 13:16:56.438] ADDON BINDER: Cannot resolve assembly: MiniAVC.XmlSerializers, Culture=neutral, PublicKeyToken=null Since 1.8.0, when KSP changed something on a thingy called AssemblyResolver, MiniAVC is getting a lot of heat because it cannot negotiate anymore the best or newer DLL to be used. There's no other fix but to install ZeroMiniAVC. Try this before anything else!

Wow. The crash is not related to this for sure. The code detects the problem and use defaults instead, no harm is done. You have something else borking on you. I will check the KSP.log now. The Log was truncated and it's useless. Pastebin does this kind of stunt, unfortunately. Please upload it on DropBox, GoogleDrive or something that allows big files to be shared. -- -- POST EDIT -- -- Just for records, about the HUD5 from NMB. Yeah, it's crashing KSP 1.10. BUT - It was not crashing KSP < 1.8.0 . I tried it on 1.4.4 and on 1.7.3, with no problems other that a Exception on loading it: That said, I can't say it's a problem on KSP >= 1.8. It looks more like a bug on Unity 2019, due this crash dump:

I'm an idiot. Sorry. [More forgetful than idiot on this case, but the concepts are not mutually exclusive! ) This file is used to configure some niceties on a Add'On by Add'On basis (i.e., you can configure TweakScale to be full ubber verbose on logging, but all the others could be shut up to only warnings - this is interesting for debugging things you know is happening only on one of them), but I forgot to tell the code this thing is optional (as reasonable defaults exists on the code). Copy this file from github into <KSP_ROOT>/PluginData to workaround this problem, I'm fixing KSPe to survive the absence of this file. About the NMB prop, can you please pinpoint me to where to download it and that are the prop? I need to assess this situation, you may have found something in order to be fixed! -- -- POST EDIT -- -- Don't bother copying the file. I made things right on the code, I just forgot to remove the Error log, as it should be an warning only. Just ignore the error message for now. A proper one is being compiled now and I will issue a new release is being issue in the next hour.

Got it. [LOG 17:23:01.502] [TweakScale] ERROR: **FATAL** Part S2Structural (Structural Fuselage S2) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 17:23:01.505] [TweakScale] ERROR: **FATAL** Part awacsRadar (AWACS Detection Radar) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Well, it's our old friend again, TMasteson5TweakScalePatches: [LOG 17:21:04.135] Applying update TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch/@PART[S2Structural] to AirplanePlus/Parts/Structure and Fuel/size2structural/part.cfg/PART[S2Structural] [LOG 17:21:04.144] Applying update TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch/@PART[S2Structural] to AirplanePlus/Parts/Structure and Fuel/size2structural/part.cfg/PART[S2Structural] & [LOG 17:21:04.025] Applying update BDArmory/MMPatches/BDA_TweakScale/@PART[awacsRadar] to BDArmory/Parts/awacsRadar/awacsRadar.cfg/PART[awacsRadar] [LOG 17:21:04.187] Applying update TMasterson5TweakscalePatches/BDArmoryTweakscale/tweakscaleConfigPatch/@PART[awacsRadar] to BDArmory/Parts/awacsRadar/awacsRadar.cfg/PART[awacsRadar] Remove TMasterson5TweakScalePatches from your installment. They are terribly outdated, and didn't aged very well. The licensing terms are also terribly restrictive, so it's not possible to fix it neither. The Awacs are already being patched by BDArmory, and the AirplanePlus parts are carefully patched by TweakScale Companion for AirplanePlus. By carefully patched, I mean I inspected every AirplanePlus part before patching it.

MIG-105 лапоть. Don't fly with untied shoes! (Magnificent landing skids, no?)