Jump to content

[1.3.0] Filter Extensions 3.0.4 (Jul 11)


Crzyrndm

Recommended Posts

With the stock editor now supporting custom filters in a reasonable way, creating more and better filters is the next logical step. However, the requirement for categories to be managed via code is just a terrible idea. Not to mention that there is no easy way to be compatible with anyone else. Filter Extensions allows the usage of .cfg files to create, edit, or delete all categories and sub-categories. It uses standard config files allowing for patches to be applied and dependencies allowed for using Module Manager.

Github - Source

License:
Icons and configs distributed with FE are under CC-BY-SA 4.0
Plugin is covered by GPLv3.

sBqMgMx.jpg
 

Configs and Icons

Configs and icons contributed by users are distributed with the download. Think something is missing and you can fill the gap? Just send the cfg's or icons my way :wink:

Spoiler

CATEGORY:NEEDS[B9_Aerospace]
{
    // Normal stuff: name, icon, colour, etc.
    name = B9 Aerospace
    icon = B9_Aerospace
    colour = #FFF0F0F0
    all = true
    // 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
    // This is the template to be added to subcategories in this category. Subcategories in this category require parts to match one of the category Filters as well as their own unless using the "dont template" key
    FILTER
    {
        CHECK
        {
            type = folder
            value = B9_Aerospace
        }
    }
      // This is the subcategories listed by name. The number is the order they will appear in
    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
        list = Undefined // subcategories listed without an index will be added after all other subcategories are accounted for
        list = Undefined, dont template // the key "dont template" as the final element tells the subcategory to not use any of the category filters
	}
}
 

CATEGORY
{
	name = Filter by Function
	type = stock // If this isn't present it will go and make a new category
	value = replace
	// 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. Refer to the first spoiler for details on templating and addressing subcategories.
	// It's all the same
}

 


SUBCATEGORY
{
	// Same stuff as v1.x, but the category is no longer specified
	name = Air Intake
	icon = AirIntake
	FILTER
	{
		CHECK
		{
			type = moduleName
			value = ModuleResourceIntake
		}
	}
}

 


FilterRename
{
	name = LiquidFuel/Oxidizer, Rockets // name = <originalName>, <newName>
	name = ElectricCharge/XenonGas, Ions
	name = IntakeAir/LiquidFuel, Jets
	name = SolidFuel, SRBs
	name = MonoPropellant, MonoProp
}
FilterSetIcon
{
	icon = Rockets, EngineLFO // icon = <subCategoryName>, <iconName>
	icon = Ions, EngineIon
	icon = Jets, EngineJet
	icon = SRBs, EngineSolid
	icon = MonoProp, EngineMono
}
FilterRemove
{
	remove = subcategoryName
}

Defining subcategories

SUBCATEGORY nodes define the title and icon of the tab, and contain the logic elements. FILTER nodes are used to AND together a series of boolean checks. The results of multiple Filter nodes are OR'd together (A part only needs to match one Filter to be added to the subcategory) CHECK nodes are the actual boolean checks to be performed. At the time of writing there are 15 check types.

The logic of the nodes can be expressed quite simply as: A part must pass all check's in any of the filter's to be accepted into the subcategory

Module title: The name of a module as seen ingame in the right click menu of a part (key : "moduleTitle")


CHECK
{
	type = moduleTitle
	value = Command
}

Matches the "Command" module listed in the expanded part info panel

Spoiler

UQZSkJa.jpg

 

Module name: The name of a module as used in cfg files (key: "moduleName")


CHECK
{
	type = moduleName
	value = ModuleCommand
}

Matches the "ModuleCommand" module in the part's cfg file


MODULE
{
	name = ModuleCommand
	minimumCrew = 1
}

 

Part name: The part name as defined in it's cfg. This requires an exact match to return true. (key: "name")


CHECK
{
	type = name
	value = Mark1Cockpit // <== No kidding, that's it's name in the cfg file...
}

Matches the part with the "name = Mark1Cockpit" line in it's cfg

Part title: The name of a part as seen ingame. This only requires a partial match to return true (so the value: "Cargo Bay" will return true on all stock Cargo Bays) (key: "title")


CHECK
{
	type = title
    value = Mk1 Cockpit
}

Matches the part that is called "Mk1 Cockpit" ingame

Spoiler

UQZSkJa.jpg

Resource: Check for resources contained within the part. The name to check by is again in the ingame right click menu of a part (key: "resource")


CHECK
{
	type = resource
	value = Electric Charge
}

Matches parts containing the EC resource

Spoiler

UQZSkJa.jpg

Propellant: Check for the propellant used by any engine type (key: "propellant")


CHECK
{
	type = propellant
	value = LiquidFuel
}

Matches engines using Liquid Fuel as one of its propellants

Spoiler

McZzDns.jpg

 

Technology: Check the technology required to access the part (key: "tech")


CHECK
{
	type = tech
	value = veryHeavyRocketry
}

Matches to parts using the "veryHeavyRocketry" tech node

Manufacturer: Check the part manufacturer (key: "manufacturer")


CHECK
{
	type = manufacturer
	value = Kerbodyne
}

Matches to parts manufactured by Kerbodyne

Spoiler

McZzDns.jpg

 

Folder: Checks against the root folder of a part in the gamedata directory, AKA by mod (key: "folder")


CHECK
{
	type = folder
	value = NASAMission
}
Matches to all parts located in the NASAMission directory in GameData

Path: Checks any length of the part path from the GameData folder (key: path; eg. Squad\Parts\A)


CHECK
{
	type = path
	value = Squad/Parts/Com
}

Matches all parts in the Squad/Parts/Command and Squad/Parts/CompoundParts directories

Category: Check against the part category as defined in the cfg (key: "category")


CHECK
{
	type = category
	value = engine
}

Matches all parts with the category defined as engine

Size: Check against the largest stack node in a part. -1 is radial, 0 is 0.625m parts, 1/2/3/* correspond to (val*1.25)m parts (key: "size")


CHECK
{
	type = size
	value = 3
}

Matches all parts with a size 3 (3.75m) attach node

Crew: Check against the crew capacity of a part


CHECK
{
	type = crew
	value = 0
}

Matches all parts that can't take any crew

Check: Used to group several different check types with OR logic


CHECK
{
	type = check
	CHECK
	{
		type = moduleName
		value = ModuleCommand
	}
	CHECK
	{
		type = crew
		value = 1
	}
}

Matches all parts that have a command module OR a crew capacity of 1

Custom: These are checks I have implemented in code which would be difficult or impossible with the other check types


CHECK
{
	type = custom
	value = 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
}
CHECK
{
	type = custom
	value = 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
}

 

Some additional explanation of the cfg structure

Spoiler

All the things that make changes are in subdirectories of this folder. The "default" subdirectory is the one containing all the additions to Filter by Function, the rework folder has a different setup for the stock subcategories. All of the extra categories are individual .cfg's inside the "default" subdirectory. If you don't want it, delete it. The additional subcategories in Filter by Function are in the StockCategories.cfg (along with the improved cross section and resources categories) The replacement subcategories in Filter by Function are here. Just remove that folder if you want the stock layout

Filter Extensions uses two root config node types, CATEGORY and SUBCATEGORYCATEGORY nodes set category name, icon, colour of its subcategories, which subcategories are present and in what order, and can restrict what parts show up in their subcategories using the same syntax as the FE subcategoriesSUBCATEGORY nodes do most of the work wrt which parts are actually visible. They only have 4 possible entries: name and icon, "showUnpurchased" to override the plugin setting, and a set of FILTER nodes which decide which parts are visible. The subcategories are referenced by name when setting up a category and can be added to as many categories as you like.

tl;dr Once you have the name of a subcategory, just add it to the category of choice with a unique position (between 0 and 999. Duplicates will overwrite each other) and enjoy (NOTE: No position also works, it just gets added to the end of the list)

Writing a set of FILTER nodes to get the parts you want: Using the Electric Charge subcategory as an example, what I was aiming to do was improve on the stock Filter by Resource EC category by removing all the parts that often have a capacity of no significance (eg. engines with an alternator have one because of how the stock resource generation works, but that doesn't help the player looking for a battery)

The parts I wanted must have storage for the resource Electric Charge and must not be a part that only has EC storage as buffer (through experimentation this was determined to be engines, command modules, and generators) If you're familiar with any programming languages, that would typically be expressed something like this


result = hasResource("ElectricCharge") && !hasModule("ModuleCommand" || "ModuleEngines" || "ModuleGenerator");

Each CHECK node contains a single condition a part must pass to be visible. Each FILTER contains one set of conditions. If a part passes all the conditions in a FILTER, it will be visible.
Multiple FILTER nodes can be used when required (eg. Manned Command, the KerbalSeat module doesn't have a crew capacity of one or more so it needs to be checked for separately), although the comma separated lists have made that quite rare now

The majority of check types are listed in the first post, and I'll probably get some time this weekend to put together atleast a full listing of them (alternatively, check the code that handles the type)

Acknowledgements
stupid_chris
through RealChute which I originally used as a template. Getting started would have been much more difficult without that reference.
Nertea for the idea of the icon auto-loader
KaiserSoze - Adapting many icons, sharing configs, and reporting bugs

Mod icons are mostly adaptions of:

  • Part Catalog icons - originally by BlackNecro
  • Flags, manufacturer icons, and toolbar icons included with a mod. You can find links to the mods for all included icons here

To everyone that has contributed icons and/or cfg's to make others life easier - Your generosity is sincerely appreciated

Reporting Bugs

There are two types of bugs, so depending on what your problem is, there are different steps you may need to follow

Exceptions: Red text in the alt+f2 log, functionality breaks down completely, etc.
I need the information specified here

Functional issues: If the log shows no errors, then I need

  • The config you were trying to use
  • The mod that this applies to
  • A description of the expected behaviour
  • A description of the behaviour experienced

Feature Requests
Fire away. I won't always be able to include the request, but if I can and there is a good reason to (ie. it's not duplicating existing functionality for no reason), I will.

Edited by Crzyrndm
Link to comment
Share on other sites

Now using .cfg files to make everything work so much easier. Testing the other filter types (tech, resource, etc.) and extending the custom filters and this should be ready for full release shortly ;)

Edited by Crzyrndm
Link to comment
Share on other sites

Support added for the categories that are already procedural (resource, manufacturer, tech, module)

Using Near Future Propulsion's Argon Gas resource as an example

To remove a subcategory that you don't want to show, only specify the category (Filter by /*Insert here*/) and the title shown ingame for the offending subcategory


SUBCATEGORY
{
category = Filter by Resource
oldTitle = Argon Gas
}

To change the icon and title displayed, use the keys title and icon.


SUBCATEGORY
{
category = Filter by Resource
title = Wheels
oldTitle = Argon Gas
icon = R&D_node_icon_fieldscience

}

Nice and simple

Link to comment
Share on other sites

hm, some copy pasted code from RealChute in that source :P at least I'm cool with it heh.

My only concern is that there is no crosschecking going on in this. You could end up with eight "Engines" filters in the Filter by Function category if one isnt checking. You really need to keep a dictionary of all the categories and subcategories, and make sure there is none with the same filter, and probably checking there is none with the same name would be good too. Else this could get extremely messy, and criss crossing modding schemes like that are not something cool to have around.

Edited by stupid_chris
Link to comment
Share on other sites

hm, some copy pasted code from RealChute in that source :P at least I'm cool with it heh.

My only concern is that there is no crosschecking going on in this. You could end up with eight "Engines" filters in the Filter by Function category if one is ont checking. You really need to keep a dictionary of all the categories and subcategories, and make sure there is none with the same filter, and probably checking there is none with the same name would be good too. Else this could get extremely messy, and criss crossing modding schemes like that are not something cool to have around.

Known and being worked on (as is the lack of any order control, it's just by cfg order at the moment which I find rather annoying).

RE: Realchute source

Yes, I did use it as a template, and I did have an acknowledgement written up that seems to have been lost to my flaky internet :mad: (I'll just fix that...). It certainly made development a whole lot faster than it otherwise would have been.

Edited by Crzyrndm
Link to comment
Share on other sites

Known and being worked on (as is the lack of any order control, it's just by cfg order at the moment which I find rather annoying).

RE: Realchute source

Yes, I did use it as a template, and I did have an acknowledgement written up that seems to have been lost to my flaky internet :mad: (I'll just fix that...).

As I said, it's alright, there's really just one way to do this. There's not ten thousand ways to add filters to the PartCategorizer. But a little credit would be very welcome ^^

P.S.: you only need to do button.SetFalse/button.SetTrue if filters are being added to the Filter by Function category. It's a terrible hack, but all it does is refresh the Filter by Function list, else it won't include any added filters until you deselect it and reselect it manually in game.

Link to comment
Share on other sites

As I said, it's alright, there's really just one way to do this. There's not ten thousand ways to add filters to the PartCategorizer. But a little credit would be very welcome ^^

P.S.: you only need to do button.SetFalse/button.SetTrue if filters are being added to the Filter by Function category. It's a terrible hack, but all it does is refresh the Filter by Function list, else it won't include any added filters until you deselect it and reselect it manually in game.

It is currently only being done for filter by function (or more correctly, for cfg's that include a filter node, which only makes sense for Filter by Function). That reminds me, I need to check and see what happens to filters on other categories...

Credit now added, and my apologies again for misplacing it initially :sealed:

Link to comment
Share on other sites

It is currently only being done for filter by function (or more correctly, for cfg's that include a filter node, which only makes sense for Filter by Function). That reminds me, I need to check and see what happens to filters on other categories...

Credit now added, and my apologies again for misplacing it initially :sealed:

From what I understood, it's being done to anything that adds a subcategory, and it resets the button each time, when you really just need to do it once, which might be a little expansive on the long run.

Link to comment
Share on other sites

Not the nicest piece of code ever, but the Github version is now doing collision detection by subCategory name and/or it's filters if two definitions are using the same category. Using the same name results in the filters being combined, using the same filters uses the name/icon of whichever is processed first.

I want to have some form of icon order control before I "officially" update, but I'm a little unsure as to how such a system should work.

The basic idea I'm toying with at the moment is that you define a subCategory that you want a subCategory to follow in the list. Multiple subcategories defining the same target are resolved by load order (same as now, just on a localised scale). It was the most modular soltion I have come up with, but I'm open for suggestions.

Link to comment
Share on other sites

Would it be possible to arrange by mod folder?

You could effectively do this by duplicating a manufacturer tab in filter by function (have a seperate filter node for each manufacturer used by the mod)


SUBCATEGORY
{
category = Filter by Function
title = mod Name Here
icon = the name of the icon you want

FILTER
{
CHECK
{
type = manufacturer
value = modManufacturer1
pass = true
}
}
FILTER
{
CHECK
{
type = manufacturer
value = modManufacturer2
pass = true
}
}
}

etc.

EDIT

Alternatively, you could also remove all of the SQUAD manufacturers for the filter by manufacturer tab (and thus actually use it for what it is intended for...) which would take a little longer to set up, but means you only have to do it once

Edited by Crzyrndm
Link to comment
Share on other sites

1.1 is live

  • Checks for duplicated filters, combining and rejecting where appropriate
  • Adds an automatic icon loader. No configs required to set the icon for any subcategory created by stock KSP (anything on resources/modules/tech/manufacturer tabs, and stock function icons). Send some thanks the way of Nertea for this idea
  • Adds support for new categories

Duplication Checks

subCategories for the same category with the same name will have their filters combined (all parts from both will show). The first title/icon processed will be the icon/title used

subCategories with the same filter set (independent of CHECK/FILTER order) will have all but the first match discarded

Automated Icon loader

Include a folder named "filterIcon"and place all the icons you want to use inside of it (this is true for any icons you want to use, auto loader or not). Match the name of the icon to the title of the button you want to change the icon for (eg. to change the Xenon Gas Resource icon, include a "Xenon Gas" image). If you want a two state icon, include a second image with "_selected" appended to the name, if it is not included KSP will create it's own selected state. Icons are around the 35x35px size.

Create new Categories

Intended for use by large part mods (looking at you Roverdude/USI) or end users, to avoid creating a mess of the subcategories, section them off in their own category.

MBKq3AB.png

Category config details:


CATEGORY
{
title = TestCategory
icon = R&D_node_icon_experimentalmotors
colour = #FF0000FF
}

SUBCATEGORY
{
category = TestCategory
title = TestTitle
icon = R&D_node_icon_experimentalmotors
FILTER
{
CHECK
{
type = title
value = Cargo Bay
pass = true
}
}
}

Documentation

Currently adding a wiki to github in addition to the example configs already available on github

Category/Subcategory ordering

Still to come. I'm not happy with the solutions I've tried so far.

A Category that lists parts by folder under GameData

Now that I have categories working, this shouldn't be too hard to add a little extra functionality for :) (EDIT: or not. somehow parts don't appear to reference their file location ANYWHERE :mad:)

Edited by Crzyrndm
Link to comment
Share on other sites

v1.2 removes the need to have the icons in a specific folder.It will now be able to address any image with width/height dimensions of less than 40 pixels.

No other changes (the folder name was just too annoying to wait :sealed:)

Link to comment
Share on other sites

Maybe it's something I'm doing wrong, but the last couple versions of this I've downloaded don't seem to contain all the folders that the first couple did. Upon unzipping it, all I get is a folder titled Filter.Extensions-1-x. None of the icons and definitions and such like before. And when I drop that folder into Gamedata I'm not seeing the new categories in the editors. Let me know what I'm doing wrong?

Link to comment
Share on other sites

Maybe it's something I'm doing wrong, but the last couple versions of this I've downloaded don't seem to contain all the folders that the first couple did. Upon unzipping it, all I get is a folder titled Filter.Extensions-1-x. None of the icons and definitions and such like before. And when I drop that folder into Gamedata I'm not seeing the new categories in the editors. Let me know what I'm doing wrong?
NOTE: This comes with no extra filters itself, the idea is that mod authors can bundle relevant cfg's and/or users can just define their own as appropriate. The filters I want will be different to the filters you want.

It is intentional for above reasons. All the configs that were initially packaged where the ones I was using for testing various functionality (or more specifically, what functionality I needed).

It would probably be better to have a seperate folder just containing all the cfg's that you want to use for filtering so that you dont end up removing them by mistake.

Once the functionality is expanded to a reasonable level, I'll start making some configs for common things (control surfaces, wings, batteries, mod X, etc.). In the meantime, if you need help writing up some filters, just let me know ;)

link to Examples and doc link is in OP

Edited by Crzyrndm
Link to comment
Share on other sites

v1.3 released

  • Added "folder" filter type. Matches against the root folder of a mod (eg. Squad & NASAmission for stock parts)
  • Added auto-generated "Filter by Mod" category
  • Category duplication check fixed
  • Created categories no longer intermittently show with the non-functional custom category UI (parts with delete buttons, drop zone)

Filter by mod category uses the same icon as the "Filter by Manufacturer", and all the sub-icons are using the default question mark (;.;). To fix this, you currently need to have a cfg specifying the icon name (subCategories are being created after the auto-loader pass. Will fix this shortly).

Any opinions on whether I should just outright replace "Filter by Manufacturer" with "Filter by Mod"? With all the stock manufacturers I find the first to be entirely unusable.

I've also found a way to have a filter by function running *on top of* another subcategory (eg. all engines in mod X) using the same GUI. Opinions on usefulness?

Edited by Crzyrndm
Link to comment
Share on other sites

v1.3 released

  • Added "folder" filter type. Matches against the root folder of a mod (eg. Squad & NASAmission for stock parts)
  • Added auto-generated "Filter by Mod" category
  • Category duplication check fixed
  • Created categories no longer intermittently show with the non-functional custom category UI (parts with delete buttons, drop zone)

Filter by mod category uses the same icon as the "Filter by Manufacturer", and all the sub-icons are using the default question mark (;.;). To fix this, you currently need to have a cfg specifying the icon name (subCategories are being created after the auto-loader pass. Will fix this shortly).

Any opinions on whether I should just outright replace "Filter by Manufacturer" with "Filter by Mod"? With all the stock manufacturers I find the first to be entirely unusable.

I've also found a way to have a filter by function running *on top of* another subcategory (eg. all engines in mod X) using the same GUI. Opinions on usefulness?

Please replace the manufacturer tab its useless imo.

Edited by BrutalRIP
and the subcatogory's would be usefull to me at least
Link to comment
Share on other sites

If you can automate to \Mod\StandardSubCategoriesFromFunction that would be fricking awesome.

The only issue I have with this at the moment is that they will either be placed in with all the other automated categories (no seperate space of their own) or marked as custom categories (which creates non-functional GUI elements for adding and removing parts). I think the best option will be if I can dump it into the same group as the sub-assemblies, but I'll have to go searching to see how that can be achieved.

Making a category of "Mod X" at the same level as al the "Filter by X" and giving it all the "Filter by Function" subcategories is absolutely no problem. It's making the GUI in a sensible fashion thats a little annoying.

EDIT

I guess I could also just colour code them...

Edited by Crzyrndm
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...