Crzyrndm

it's only wing parts (add my vote for them over the original P-wings. They're apparently not working for some people, but they're so much more user friendly when they do work)

Documentation update (more like rewrite, most of that is still from ~1.4)? Sounds like a good idea. On your specific requests: isEngine: is shorthand for a module check looking for (ModuleEngines OR ModuleEnginesFX OR MultiModeEngine). Not recommended for use, was implemented before multiple or'd variables per Check node was added (needed two/three seperate Filters to achieve originally) isCommand: is shorthand for a module check looking for (ModuleCommand OR KerbalSeat). Not recommended for use, was implemented before multiple or'd variables per Check node was added adapter: Returns true if the part has exactly 2 stack nodes, the nodes are of different sizes, and there is no ModuleCommand on the part multicoupler: Returns true if there are multiple stack nodes at the same 'y' offset as the "last" stack node AND there is atleast one node in another y location AND the part doesn't register as a cargo bay crewcabin: is shorthand for No ModuleCommand AND a non-zero crew capacity. Not recommended for use. Can be done with a combined module and crew check now (IIRC, the crew check wasn't implemented at that point) Custom checks are implemented for logic that can't be easily achieved with the functionality that existed when they were introduced. There's no way to write the adapter/multi-coupler checks as it stands, but everything else has the required functionality now folder: Matches parts based on their root GameData folder. "Squad" gets all parts in the Squad directory, "NASAMission" gets all the ARM parts, "" gets all parts located in GameData itself (or it should, I haven't actually checked that one). path: Matches the start of the part path. "S" gets all parts in folders in Gamedata starting with an S, "Squad/" hits only the Squad folder, "Squad/Parts/Com" gets all the parts in the command and CompundParts folders in the Squad/Parts directory Subcategory could be done (or rather anything written into a part cfg can be used), but that would require people actively using it in their part configs. Functional filters don't rely on anything other than being able to recognise the purpose of a given part.

Not really, definitely not if there's no issues with xEvilReeperx maintaining the plugin. 1) Not a fan of directly duplicating functionality of others (hence no active search or scroll functionality here) 2) Not familiar with the issue the plugin resolves 3) Not familiar with the system the plugin is fixing 4) Want to keep feature creep to a minimum here because of how fragile the part list is

You may want to correct the example here then. It makes it look like everything is processed in order of appearance, but if values and nodes are processed seperately that won't work

What happens if you don't delete the values at the end? MM may processes all values and then all nodes rather than doing it in order E: nvm, the examples show it being used like that too. I'm out of ideas

maxVolume = #$[COLOR=#ff0000]../[/COLOR]mvar$ The variable address is from your current node, not the root node

Another silly mistake (atleast the stacktrace points right to it...), and yes any error at all normally ends up with the part selection UI being totally dead. It's the reason I had to move to my own initialisation method v2.0.3 I wonder which part it failed to resolve a path for though...

That window is only going to display for a single frame (or maybe not even that since the event probably doesn't count as a GUI function). You need to set a flag in the event handler and display your window based on the flag state EDIT Don't know if you can interrupt the stock window.

Strangely how? - - - Updated - - - Version 2.0.2 Integrated pull request from dak180 integrating support for several mods and adding the ISRU category I forgot Fixed a number of minor errors Fixed a typo in the Lights subcategory

For a control plugin, you probably only need Start and OnDestroy. In start you can register a function to enact all your control like this (3 versions. onpre-, on-, onpost-), which does away with the need for FixedUpdate, and you don't need the rest if it's being handled by hardware

Useful references for starting out (including setting up the required references and making a simple part module) To get gui elements to show at the space center scene, which I assume is what you meant by the KSC screen //using statements, namespace, etc. [KSPAddon(KSPAddon.Startup.SpaceCenter, false)] // this plugin will be run every time we enter the space center scene public class IDrawABox : Monobehaviour { public void OnGUI { GUI.Box(new Rect(100,100,100,100), "I'm a Box"); } } Look up the Unity GUI / GUILayout documentation for how to make a useful GUI

Nada, they aren't there (I just checked) PS It's not overriding per se. Functions with those names are added to the list to be called at certain events (frame, physics update, etc.), they don't replace anything

Awake, Start, Update, FixedUpdate, LateUpdate, OnGUI, OnDestroy, etc. are inherited from Unity's Monobehaviour (see the flowchart here for details on when each one executes). PartModule also inherits from Monobehaviour, but also has it's own extra versions of those (eg. OnFixedUpdate) which only run when the part is active

Having a look at how sarbian's Research them all works is probably your best bet

The duplicated messages should only happen if two parts have the exact same name, which shouldn't be possible in the first place. What happened there? The nullref I'll just fix and make 2.0.1

VERSION 2.0 RELEASE Subcategories are now requested from the category and have order control. This is a breaking change. v1.x configs will need editing to work with v2.0 (distributed configs are updated obviously) Added Path type Check, an extension of the folder check that matches any length of the part path from GameData Editing and deleting subcategories is removed, all categories and subcategories are now exposed to configs directly Redefining stock categories is done the same as any other category. Add: (type = stock) and your category will address the stock category of the same name. If you include: (value = replace) it will clear the existing subcategories before adding new ones Added Category templates. Any subcategory added to a category has the template Checks added to it. Replaces mod type categories Added a default category/subcategory to be selected upon opening the editor Added option to not replace the manufacturers with the GameData folders in the Filter by Manufaturer Category Added a way to edit the names and icons of procedural subcategories (Filter by Manufacturer, Resources, Engines) v2.0 examples { [COLOR=#0000ff]// Normal stuff: name, icon, colour, etc.[/COLOR] name = B9 Aerospace icon = B9_Aerospace colour = #FFF0F0F0 all = true [COLOR=#0000ff] // type = engine, stock <-- valid types. Engine will add subcategories of all engine variants (based on propellant combinations). stock must be specified to edit stock categories // value = replace <-- only valid value, only used with stock types[/COLOR] [COLOR=#0000ff]// This is the template to be added to subcategories in this category. All CHECK nodes contained by the first FILTER node will be added to all Filters in all subcategories that are added[/COLOR] FILTER { CHECK { type = folder value = B9_Aerospace } } [COLOR=#0000ff]// This is the subcategories listed by name. The number is the order they will appear in[/COLOR] SUBCATEGORIES { list = 0,Pods list = 1,Fuel Tanks list = 2,Engines list = 3,Command and Control list = 4,Structural list = 5,Aerodynamics list = 6,Utility list = 7,Science } }CATEGORY:NEEDS[B9_Aerospace] { name = Filter by Function type = stock [COLOR=#0000ff]// If this isn't present it will go and make a new category[/COLOR] value = replace [COLOR=#0000ff]// Tells it to clear all existing subcategories and completely redefine the subcategories present. If not used, the listed subcategories will just be added to the end of the list[/COLOR] [COLOR=#0000ff]// Refer to the first spoiler for details on templating and addressing subcategories. It's all the same[/COLOR] }CATEGORY [COLOR=#0000ff]// Same stuff as v1.x, but the category is no longer specified[/COLOR] name = Air Intake icon = AirIntake FILTER { CHECK { type = moduleName value = ModuleResourceIntake } } }SUBCATEGORY{ Settings file located at: 000_FilterExtensions\PluginData\FilterExtensions\config.xml <bool name="replaceFbM">1</bool> [COLOR=#0000ff]// 1 = Use mod folders in Filter by Manufacturer, 0 = Leave as Stock[/COLOR] <string name="categoryDefault">Filter by Function</string> [COLOR=#0000ff]// The category to select on entering the editor (by name)[/COLOR] <string name="subCategoryDefault">none</string> [COLOR=#0000ff]// The subcategory to select on entering the editor (by name)[/COLOR] </config><config> { name = LiquidFuel/Oxidizer, Rockets [COLOR=#0000ff]// name = <originalName>, <newName>[/COLOR] name = ElectricCharge/XenonGas, Ions name = IntakeAir/LiquidFuel, Jets name = SolidFuel, SRBs name = MonoPropellant, MonoProp } PROCICONS [COLOR=#0000FF]// Replacing the target icons of subcategories generated by Filter Extensions. If the name is also redefined, use the new name to target the change[/COLOR] { icon = Rockets, EngineLFO [COLOR=#0000FF]// icon = <subCategoryName>, <iconName>[/COLOR] icon = Ions, EngineIon icon = Jets, EngineJet icon = SRBs, EngineSolid icon = MonoProp, EngineMono }PROCNAMES [COLOR=#0000ff]// Replacing the names of subcategories generated by Filter Extensions[/COLOR] type = path value = Squad/Parts\Ae [COLOR=#0000ff]// Both / & \ are valid directory seperators. Can cut off at any point[/COLOR] }CHECK{ NOTE: The placement number for the subcategories allows any value between 0 and 999. You do not need to specify them in order (eg. you can have 0, 3, 10, and 837). Specifying the same number twice will overwrite the earlier entry with the later one. NOTE: Procedural categories will always list everything they generate. However you can specify any number of those categories like normal and the order of the specified categories will be respected. Anything not specified will be added to the end in random order

There shouldn't be any conflict with any other mod. As far as I know, Filter Extensions loading method is unique and shouldn't interfere with or be interfered with by any other mod *unless* the other mod specifically tries to interact (editing or removing existing categories). It's independent like that because I got sick of minor exceptions in other mods killing it off (The part categorizer is stupidly fragile and flakes out way too often) Any exceptions logged?

Should do so long as you stick to using forward slashes for folders (not Windows default backslash). I forgot about that, will be either in the next version SubCategories from other mods: I'm still getting an "EVA items" category created by KIS, a Parachutes category defined by RealChute, and a Hangar category defined by the Hangar mod. They will all sit below FE's subcategories in Filter by Function, but they are there just fine. Empty subcategories: *doh*. Empty check reactivated

IIRC, the original snap was just using a stock function and it dissapeared in 0.90

FILTER{ CHECK { type = folder value = B9_Aerospace invert = true } } Would get you all parts that don't exist in the B9 folder. With the new templating system (you need the 2.0 version), you can very easily set up a category that is exactly the opposite of the current B9 category so you don't get entirely drowned in parts CATEGORY:NEEDS[B9_Aerospace] { name = Not B9 Aerospace icon = B9_Aerospace colour = #FF0047AB all = true FILTER { CHECK { type = folder value = B9_Aerospace invert = true } } SUBCATEGORIES { list = 0,Pods list = 1,Fuel Tanks list = 2,Engines list = 3,Command and Control list = 4,Structural list = 5,Aerodynamics list = 6,Utility list = 7,Science } }

v2.0 Alpha 3 includes: all the conflict checking present in 1.17 now working in 2.0 a default category/subCategory setting (to be selected on entering the editor) Replacing Filter by Manufacturer with the modlist is optional I believe the only missing v1.17 feature now is the procedural generation of engine type subCategories. I'm not having any luck at all with the part sorting so that may have to be delayed beyond v2 (indefinitely at this stage) If you want anything else, now would be the time to ask

So other than a few minor niggles, working with the part filtering system has been a rather pleasant experience. The 0.90 update also included a part sorting mechanism, but it seems to be much less open. Being able to alter the sorting system would be very useful so any insight into how the sorting is enacted would be useful

And if that doesn't work for you, try Filter Extensions. The actual "part sorting" is locked away somewhere in a deep dark hole, so the best we can do is make a decent filtering system at the moment.

I stumbled onto that a few hours back when I found the EditorPartsList.Refresh method was overloaded with an IComparer<AvailablePart> which is, I am assuming for lack of an alternative, how the sorting is being done. Still haven't got it working but I can't see any other way in E: Any ideas why this isn't working (other than that I'm totally barking up the wrong tree). The log entry for the sort call comes through fine, but the refresh either does nothing or silently fails

Because then you have to get the cost right for your mod which: A) makes the CRP pointless KSP handles part costs in a really terrible way (dry cost = part cost - resource cost) so that has a lot of potential to end really badly if two mods conflict over it