Lisias

Do you want to see something stupid? Our magnificent Mayor, with all his Wisdom, had determined a very harsh car rotation regime: cars with license plates ending on even numbers can travel on Mondays, Wednesdays and Fridays. Odd ones in Tuesdays and Thursdays. After math? People in essential activities that could use their own car are now disputing spaces with carless essential workers (as health professionals, usually badly paid here) on a reduced public transportation system. Go figure out, Forum Policies prevent me to properly publish my opinions about the subject and the Mayor.

I had problems on MM about temporal keywords (or "ordering directives") on root nodes while cooking the Companion for NFS. That will bite us here. Being a bug or a limitation on MM, I think that this ends up ruling the "Stock TweakScale tech tree support" to be a Companion, so you can flag it as incompatible on your Add'On and then use a :NEEDS[!TweakScaleCompanion_TechTree] on your SCALETYPEs definitions. The :NEEDS works on inserting root nodes. I'm also cooking a mechanism easily updated by a remote configuration file that would allow me to implement some checks at runtime for people that don't use CKAN, and this will easily be updated to mark the Compantion for TechTree incompatible with your Add'On, and issue a Houston on user's face. This way, I would have a "Stock Tech Tree" support, and you can rule it out and implement yours - without putting our toes at risk.

Awesome! I will add it to TS 2.5 beta by night, and let's see how things behave!

Well...It's Working For Me ™ From your log, I found that your patch is not being applied at al, because it's not mentioned on the "Applying update" . Follows every single mention of the S2APU part on your log: [LOG 18:35:08.258] Load(Texture): AirplanePlus/Parts/Utility/APU/S2APUtex1 [LOG 18:35:08.266] Load(Texture): AirplanePlus/Parts/Utility/APU/S2APUtex2 [LOG 18:35:25.009] Config(@PART[S2APU]:NEEDS[AirplanePlus]) 002_CommunityPartsTitles/Localization/patch_airplane-plus/@PART[S2APU]:NEEDS[AirplanePlus] [LOG 18:35:25.024] Config(PART) AirplanePlus/Parts/Utility/APU/parts2/S2APU [LOG 18:35:08.493] Applying update 002_CommunityPartsTitles/Localization/patch_airplane-plus/@PART[S2APU]:NEEDS[AirplanePlus] to AirplanePlus/Parts/Utility/APU/parts2.cfg/PART[S2APU] [LOG 18:35:10.227] Applying update PartInfo/PartInfo/@PART[*]:Final to AirplanePlus/Parts/Utility/APU/parts2.cfg/PART[S2APU] [LOG 18:35:32.348] PartLoader: Compiling Part 'AirplanePlus/Parts/Utility/APU/parts2/S2APU' [LOG 18:35:32.366] PartLoader: Part 'AirplanePlus/Parts/Utility/APU/parts2/S2APU' has no database record. Creating. [LOG 18:35:32.371] DragCubeSystem: Creating drag cubes for part 'S2APU' [LOG 18:43:20.299] S2APU added to ship - part count: 7 [LOG 18:43:22.334] deleting part S2APU [LOG 18:43:31.090] S2APU added to ship - part count: 7 [LOG 18:43:33.208] deleting part S2APU Now check with mine (that works): [LOG 02:09:07.296] [ModuleManager] INFO: Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to AirplanePlus/Parts/Utility/APU/parts2.cfg/PART[S2APU] [LOG 02:09:07.440] [ModuleManager] INFO: Applying update __LOCAL/AirplanePlus/tweakscale/@PART[S2APU]:NEEDS[TweakScale&AirplanePlus] to AirplanePlus/Parts/Utility/APU/parts2.cfg/PART[S2APU] [LOG 02:09:20.586] Load(Texture): AirplanePlus/Parts/Utility/APU/S2APUtex1 [LOG 02:09:20.623] Load(Texture): AirplanePlus/Parts/Utility/APU/S2APUtex2 [LOG 02:11:45.377] Config(PART) AirplanePlus/Parts/Utility/APU/parts2/S2APU [LOG 02:11:45.501] Config(@PART[S2APU]:NEEDS[TweakScale&AirplanePlus]) __LOCAL/AirplanePlus/tweakscale/@PART[S2APU]:NEEDS[TweakScale&AirplanePlus] [LOG 02:11:59.476] PartLoader: Compiling Part 'AirplanePlus/Parts/Utility/APU/parts2/S2APU' [LOG 02:11:59.585] PartLoader: Part 'AirplanePlus/Parts/Utility/APU/parts2/S2APU' has no database record. Creating. [LOG 02:11:59.598] DragCubeSystem: Creating drag cubes for part 'S2APU' [LOG 02:17:15.073] S2APU added to ship - part count: 2 [LOG 02:17:57.216] S2APU added to ship - part count: 3 [LOG 02:18:02.310] S2APU added to ship - part count: 4 [LOG 02:18:08.460] S2APU added to ship - part count: 3 Check if you put the file on the right place (perhaps you fired up the wrong KSP?), if it have the right extension (.cfg) or if KSP have read permissions for the directory and file. I tested on KSP 1.8.1, as AirplanePlus thread doesn't mention is compatible with KSP 1.9.x

I knew this day would come - I was fearing it for years. There's code about integrating TweakScale into the TechTree on the ScaleType (the thingy where we define the defaultScale, scaleFactors, etc). The name of the atribute is techRequired. It's a list of Techs required for each scaleFactor. However... I never had the chance to test it, I barely had read the code about. But... I can try an educated guess, if you have the time to try this stunt. There's a chance that this would work straight from the TweakScale Distribution, saving you the trouble of maintaining this thing yourself - or, on the worst case, keep a patch to adapt the default patches to the Interstellar's needs. So, if you are willing to try, make the following change on the DefaultScales.cfg form the TweakScale folder: SCALETYPE { name = stack freeScale = true defaultScale = 1.25 suffix = m scaleFactors = 0.1 , 0.3 , 0.625 , 1.25 , 1.875 , 2.5 , 3.75 , 5.0 , 7.5 , 10 , 20 incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.05 , 0.05 , 0.1 , 0.1 , 0.2 techRequired = TechUltraMiniaturization, TechUltraMiniaturization, TechMiniaturization, Default, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechHugeParts, TechHugeParts, TechHugeParts } Problem: I don't know how to create Techs on the game - I'm not familiarised even with the current TechTree, so probably one of two of my proposals a above is already there. So I will need you to figure out how to do it and, so, save me a lot of time on figuring out it myself. With that, I can introduce TechTrees on TweakScale on Release 2.5 (that will be a game changer anyway), paving a common ground for TechTrees from where you can build up from. Alternatively... Perhaps a TweakScale Companion for TechTrees would be a better idea? Perhaps - but in a way or another, we need to build the foundations of the solution first!

Yes, this is a already known problem. What's happening is that every time you load a craft into the 1.9.x's Editor (VAB/SPH), the Editor resets some atributes from the craft, undoing changes made my Add'Ons (and not only TweakScale's ones). The Resources reset was solved using KSP Recall. Any Add'On in need to have its resources customisation preserved sends a OnPartResourceChanged event and KSP Recall will register the new Resources and restore it when needed. The Attachments, however, didn't worked exactly how I intended when I tried to reproduce the same stunt - I have some code on the KSP Recall's dev branch that managed to do something on the matter, but I gave up about this approach. Squad didn't did that "just because", they did it for a reason, and the reason is that you can have different attachment rules on a VARIANT - so bluntly reseting the attachment points would create a new bug for some parts. I also realised that the problems are happening on surface attachments, so I essentially accomplished nothing with that stung (other than having a better understanding about attachments, so not necessarily a waste). So I'm afraid I will not be able to correctly solve this problem on KSP Recall - or, at least, only on KSP Recall - I still need to check how Surface Attachments are being managed on the Editor when cloning parts (the issue solved by Recall about Resources) to know if Recall should or should't be involved on the solution. There are some discussion on KSP Recall thread here. There's a dedicated issue for it here. -- -- POST EDIT -- -- This glitch only happens when loading the craft on the Editor after saving. If you launch the craft directly into the runway or launchpad, the problem doesn't happens. if you revert the launch to the editor, the problem is triggered the same way as when you load the craft on the editor. So, this is an Editor specific problem, not something on the game engine.

Had I mentioned before how good these guys are?

Well, TweakScale works. But it lacks support for the AirPlane Plus. Someone need to write these patches. How many people are willing to have TweakScale support for Airplane Plus? It people enough ask for it (or, better, someone provide me with the patches!! ), it will be added using a Companion. It's a way out. This patch works most of the time, but with "one Scaling to scale them all" way (and on the darkness of the physics engine, crash them - heheh, not true, sorry! Could not resist the joke! ). Sometimes, a hand coded patch ends up doing the work slightly better. True, but only on parts with variants (due something happening on 1.9.x's VAB/SPH Editor messing up the surface attachments). Airplane Plus doesn't have any of these last time I checked, so it would no be a (known, at least) issue for TweakScale. By installing KSP-Recall, you get rid of the problem related to Resources.

Announce Pre Release 0.0.2.1 for TweakScale Companion for NF BETA (with NFS patches) are on the wild. Download on the OP or in https://github.com/net-lisias-ksp/TweakScaleCompanion_NF/releases

That would prevent me to directly compare the slope of the curves. Since the absolute numbers on my country are not reliable, IMHO the only way of getting some sense of the mess id comparing the curve's slopes, and not the amplitude of them. -- POST EDIT -- Thinking is a very healthy habit. I should do that more times. I don't need the total number of confirmed cases on that graph. Removing that line made things better. I will post a update by night.

Got it. [LOG 10:25:17.345] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-2 (#LOC_NFSolar_solarpanel-deploying-2x1-2_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 10:25:17.345] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x3-1 (#LOC_NFSolar_solarpanel-deploying-2x3-1_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). Two FATALities. Both are being patched by the same files: [LOG 10:20:14.425] Applying update FMRS/FMRS_MM/@PART[*] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:16.316] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:19.998] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-deploying-2x1-2] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:21.964] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:24.340] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:24.843] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:32.317] Applying update TweakScaleCompanion/NF/NFS/patches/NFS-Legacy_TweakScale/@PART[solarpanel-deploying-2x1-2]:NEEDS[NearFutureSolar,TweakScale]:FOR[TweakScaleCompanion_NF_NFS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] [LOG 10:20:36.759] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2] -- -- -- [LOG 10:20:14.425] Applying update FMRS/FMRS_MM/@PART[*] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:16.316] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:20.000] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-deploying-2x3-1] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:21.964] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:24.340] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:24.843] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:32.321] Applying update TweakScaleCompanion/NF/NFS/patches/NFS-Legacy_TweakScale/@PART[solarpanel-deploying-2x3-1]:NEEDS[NearFutureSolar,TweakScale]:FOR[TweakScaleCompanion_NF_NFS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] [LOG 10:20:36.759] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1] Humm... Found the problem! I borked! I mistyped a "," on a patch on the cleaning fase: @PART[solarpanel-deploying-2x1-2<I-MISSED-A-COMMA-HERE!>solarpanel-deploying-2x3-1]:BEFORE[TweakScaleCompanion_NF_NFS] { -MODULE[TweakScale],* { } } The good news is that the mishap is inoffensive. You can play the game as is without problems (click on the "Cancel" button on the Houston message). I'm fixing the typo and I will issue a new release in the next few hours. Thanks for the heads up! -- -- -- Fix is available for download on the TweakScale Companion Program thread.

If the defaultScale datum is corrupted, yes. -- -- -- POST EDIT -- -- -- Yep, MM found a patch with a syntax error. You need to file a bug report and get it fixed, otherwise MM will not save the ConfigCache. [ERR 10:20:12.098] Cannot parse node name as tag list: encountered opening bracket in trailer on: ContractPacks/AnomalySurveyor/SCANsat/@CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]],NEEDS[SCANsat],* < I'm working on the KSP.log as time allows, I will get back to this soon>

Yes, this is the idea. However, Kerbal proposes, Kraken disposes. With the SMCE and now NF support on the go, and with the scarce time to real handle the boilerplate for each one of that Add'Ons, packing similar Add'Ons together ended up being a better idea , including from the user point of view: Add'Ons of the same "family" are likely to be used together (as The Mark IV with the Near Future Aeronautics). 1) Nice question. To the moment, I was "lucky" as almost all of the ones I did already had a very known and accepted acronym. But life is not expected to get easy with us every day, I think I need to maintain a table for acronyms on the TweakScale Companion Program repo. 2) Not exactly sure I understood (not being sarcastic neither, I'm currently unable to drink Coffee, making my days a lot more difficult. ). I think you are asking why I'm using :FOR[TweakScaleCompanion_NF_NFS] (see the revised patches) instead of :FOR[TweakScaleCompanion_NF] ? I'll answer this one in the hope of being useful. The thing is that I'm packing them on the same Companion by practical reasons, not due technical ones. I'm essentially zipping many Companions together to save me some boilerplate but, technically, that things are still separated Companions - they only share the same repo and package due some pointed egg head's decision. So, it's perfectly possible that some of that embedded Add'On's cousins (or even third parties willing to second guess my patches) would need to be patched :BEFORE or :AFTER some of the others, or even have conditional patches using :NEEDS. So prudence recommends that they should be handled as separated Companions (besides being shoved on a single one). I have a personal policy of avoiding trimming down technical decisions due political issues. Packing everything on the same Companion was a political decision, not a technical one. So I developed the technical solution as the political issue was not existent, and delegated any problem due it to be handled by the politician that decided the matter (ok, both ones are me - but Software Development is an exercise of Schizophrenia, do you know? ). 3) I do not fully know every bit of the Module Manager (yet ), so take what follows with a small grain of salt. There're two patching models on MM: the modern one (with the temporal keywords :FIRST, :LAST, :FINAL, :FOR, :AFTER and :BEFORE and the conditional :NEEDS. And the LEGACY one, where patching are executed by the alphanumerical ordering of the directories and filenames, and so you need to control the patching using the operators (&, %, etc). We use both at the same time on our daily patching, and the order of the patching is: What I found, additionally, is that MM includes the subdirectory of the Add'On on the "FOR DATABASE" when it finishes that directory (or when it enters it? Another thing to be digged out from the code). So, if I have a patch with the temporal keyword :FOR[FOOBAR] on a file on GameData/Foo/Bar/patch.cfg, I will end up with two entries on that "FOR DATABASE": FOOBAR and Foo (I don't know if we will have a Foo/Bar entry too, need to dig on that code to be sure). In time, on the NFS you will find a "FIX ME" about not being possible to delete a root node with a temporal keyword. This had bitten my SAS horribly - I need to find some time to dig on that code and see what is happening and try to figure out a way to implement it if possible....

Every help is more than welcome, thank you. Post any bugs on the Companion Thread (or on the issue tracker of the respective Companion), and I will tackle it down. About the flagged problem, it's this one that I already fixed, right? (just to be sure, now and then I miss a post somewhere)

Well, now we have a problem. Publish your (new) KSP.log so I can check what's happening - it's usually something silly. About risks, as long nothing on the savegame is using these two parts, nothing bad happens. But if you use them on a new craft, or launch a craft that uses them, things can play havoc or not - it depends on what is wrong on the patch. The real problem is not knowing, so usually it's best to check the thing on the spot. Make a backup of the savegame before loading it just in case. Since we have a potentially new problem, publishing the ModuleManager.ConfigCache too can speed up the diagnosing. Not sure I understood - if I did, it's not exactly about TweakScale, but a limitation on the Editor. If I'm right, you can work around the limitation by using the move tool while pressing shift. This will displace the part disregarding any restriction imposed by the Editor. Editor Extensions Redux also allows some interesting tricks too, it worths a try.

I'm registering things here on Brazil since March. The Red line are the count of confirmed cases per day (we are not testing enough here - better stay out of the reasons due Forum Policies). The Yellow and Green lines are the deaths on the whole Country and on the State where I live. The two lines are almost a flat line - doesn't matters how many people are confirmed to have the virus, the body count almost doesn't changes the slope. Here in Brazil, the ICU mean time is 18 days - so, probably, you need to find a correlation between the body count with the read line from 2 weeks before.

Get rid of "TweakScale Configs for Making History". They were incorporated into TweakScale even before my time on TweakScale - and they are deprecated (the original author even deleted it from SpaceDock, I found a link to it but it gave me a 404). In time, can you send me the TweakScale Configs for Making History original ZIPfile? I want to code a safety net for it, and also give proper credit to the original author of the patches (and so I need hard evidence of the authorship)! -- -- -- POST EDIT -- -- -- Install the TweakScale Companion for Near Future . Besides being in "beta", it appears to be pretty stable and adds decent support for the new parts introduced recently - to tell you the true, it's only in beta yet because I have little to no time to play KSP these days, and so I didn't gave ir a real try myself. TweakScale 2.4.4 will detect the need and suggest the new Companions, but the old patches will be still available. TweakScale 2.5 will be free of deprecated patches, and so you will need to install a Companion when needed (and this is the reason I need to first issue an intermediary release, the 2.4.4 series). After doing that, any FATALity is a real, new one. If it still happens, please report a new KSP.log.

Tough year, no?

Hi! Please install the TweakScale Companion for SMCE, where Large Boats (and futurely all the SMCE Add'Ons) are being supported. What's happening is that some patches from this release of Large Boats are terribly outdated, and I fixed them all on that Companion. About the savegames, as long you don't load any savegame after being Houston'ed, nothing bad happens. Things get hairy when you load a savegme because KSP will "update" the living crafts on the game with the current GameDatabase (a place where KSP stores information for your parts and modules), and once the savegame is "fixed" on memory using a Houston'ed GameDatabase, saving the game will save a corrupted game. And yes, you did the right thing: deleted the offending Add'On before anything, and then called for help. About this Companion, it's still on Beta because it's possible I had made a mishap or two (as I didn't had the time to full test the whole shebang yet). However, what's working will not be changed - so unless you find a part misbehaving (and then just don't use it until I fix them), this thing is OK to go. Good scaling!

TL;DR : Guatemala's Army seized a Hawk 800 from some... non law abiding "merchants". And then took of on it from the place to a main airport. What's impressive on this jet is how it can operate from terrible runways. The bad conditions of the runway made me remember of me landing on some less than plane gound on Kerbin after running out of fuel. Impressive indeed.

Thank you! In time, KSP 1.9 had, indeed, changed some things that played havoc on some Add'Ons (as TweakScale, but not only - Fuel Switches are expected to be problematic too). If you choose to test on KSP 1.9, be prepared for some problems with that Modules, and also with surface attachments on Parts with Variants (this is precisely what's bitting my SAS on TweakScale).

Sure thing! It may take a bit, but it will not be forgotten! https://github.com/net-lisias-ksp/TweakScaleCompanion/issues/1 -- -- -- POST EDIT -- -- -- This was implemented on the TweakScale Companion for Rockets. See announce here.

On KSP 1.8 it was working fine, any trouble I had with it came from something else (as Firespitter or TweakScale). BUT... I didn't really tested it (I'm not even playing KSP anymore these months, all my free time is on handling KSP 1.9 new issues on TweakScale), so I choose not to state it works fine on KSP 1.8 besides not facing any problems on the few test sessions exactly because of it: it was only a few test sessions, no real playing where the real problems sparks. If you can spend some time testing it in a myriad of ways using a disposable KSP instalment (just in case, "sheet happens"), I would be grateful for any bug reports you find on it (being on the parts, being on the dependencies).

This one? Nope. But you can ask for a new Companion for it here. There will be not more Third Party support directly on TweakScale for strategic reasons - all (but Stock and DLC support) will be handled on the Companions.

Props are meant to be used on IVAs, I don't think TweakScale is useful (or desirable) on them. This one is already implemented. I have a regex script that build a list of parts from configs inside a directly hierarchy and sort them into a ALL_PARTS. Them I diff the ALL_PARTS from the previous version with the current to see what's new. This way, I don't need to care about prefixes - mainly because I don't use wildcards on my patches to prevent disasters (TweakScale can be a rancorous beach when bad patched), so in the end the lack of prefixes doesn't bothers me.. But a new part is always eye balled manually for any change that could bite me, or for some opportunities for improvement. The new way to scale Containers on KIS was born this way. Most parts from this one came from Mark IV Spaceplane, that was "skimmed" some time ago. The fuselage remained on MKIV, but the parts that could be used on other fuselages were moved to NFSC. Oh, yeah. This is a potential trouble maker. But not the only one, I got my SAS utterly bitten once by a patch that used the Author as a criteria of patching, and when the original Author gave the meshes to another Add'On, Hell broke loose on TweakScale.