Crzyrndm

v1.16 released Added contains key to Check nodes, default is true. Only applicable to moduleName/Title, resource, propellant, and size type Checks. If contains is false, the Check will return true when there is a value that is not listed present Added "check" type Check node. Check nodes can be grouped inside a check type Fixed bug with filters containing only inverted checks causing hidden parts to be shown (Issue #24 on github) Fixed bug which was preventing the correct icons being shown initially in the "engines" type category Details on contains behaviour can be found here (still looking for a better name...) "check" type Checks (regretting that choice of type name already...) should be used to group several Checks together. Use together with invert to get NAND logic (eg. the following returns false only when both condition 1 and 2 are true). CHECK { type = check invert = true CHECK { //condition1 } CHECK { //condition2 } } Nesting is not restricted at all (ie. you can have a check type inside a check type inside a check...) but I wouldn't recommend going too crazy with it...

I see how that could be an issue. You want to do this: (A || B || C) && !(X && Y && Z) Currently the best a single filter could achieve is this: (A || B || C) && !(X || Y || Z), or this: (A || B || C) && !X && !Y && !Z (which are actually equivalent statements, see De Morgans laws). I think the solution is going to be allowing Checks inside Checks. That would allow quite a bit more freedom in terms of boolean expressions FE is capable of without complicating things too much. NAND logic (what you're trying to achieve) isn't the only thing that would result. There's a folder that I included for all the stock propellant combinations. See that for an example.

Your example already exists. FILTER{ CHECK { type = PartModule value = A,B,C } CHECK { type = PartModule value = X,Y,Z invert = true } } This would be has any of A/B/C and not any of X/Y/Z What you wrote evaluates to: has any of A/B/C and has anything not X/Y/Z (which has to be true since A/B/C is present). Contains is going to be most useful when inverted FILTER{ CHECK { type = PartModule value = A,B,C } CHECK { type = PartModule value = A,B,C invert = true contains = false } } Returns true only when no modules other than A/B/C are present. Without invert, it can be used to find all exceptions to a rule CHECK { type = resource value = LiquidFuel contains = false } Returns true for any part that has a resource other than LiquidFuel (good for those catch-all unfiltered categories). When contains is true, the Check is for values which are explicitly listed. When contains is false the Check is for values which aren't explicitly listed. That will be because the filter you have defined has the exact same filters as the procedural version. Remove the filters, add the "oldTitle" field and it will be as you expect. Procedural subcategories are initialised at the same time as the categories they belong to, which is prior to config subcategories EDIT I found the problem with the lights subcategory. It's looking for moduleCommand, when it should be looking for not moduleCommand

I just checked, all parts without an explicit crew capacity report it as zero as expected. There's a slight oversight on my part in that it doesn't sanity check anything less than zero as equal to zero, but that shouldn't be a problem in this case. I need a specific part or parts that isn't behaving as expected, and the related configs. If you mean the icons not showing up right in the engines category, that was the bit I had to remove to get everything working again. EDIT Just spitballing on how I want the new CHECK state to behave, I haven't really come up with a good name for the key. This is my "documentation" of how I want CHECK to work (using the key "contains" here for the new variable, default is true). If you have a better name for it, I would like to hear it Props1: LiquidFuel,Oxidiser Props2: LiquidFuel,Oxidiser,ElectricCharge CHECK { type = propellant value = LiquidFuel,Oxidiser } results: Both pass, both contain atleast one listed value CHECK { type = propellant value = LiquidFuel,Oxidiser invert = true } results: Both fail, both contain atleast one listed value, result inverted CHECK { type = propellant value = LiquidFuel,Oxidiser contains = false } results: Props1 fails, doesn't contain any values not in the list. Props 2 passes, ElectricCharge is not listed CHECK { type = propellant value = LiquidFuel,Oxidiser invert = true contains = false } results: Props1 passes, doesn't contain any values not in the list. Props 2 fails, ElectricCharge is not listed The advantage of this state will be useful mainly when invert is also true because it allows you to limit against any extra values without having to list each one individually eg. Match engines with Liquid Fuel and Oxidiser only FILTER { CHECK { type = propellant value = LiquidFuel } CHECK { type = propellant value = Oxidiser } CHECK { type = propellant value = LiquidFuel,Oxidiser invert = true contains = false } } Obviously this is a value that only makes a difference when a part has multiple values to be applied (currently: modules, propellants, resources, and part size)

Value to me implies whatever follows an '=' sign (ie. One "field" == "key = value"). Using it to refer to the full entry would be rather confusing

I think I need to know which mods are causing problems to track that one down. The problems aren't apparent on my dev install (which is almost entirely stock)

v1.15.1 released Fixed critical bug with icon editing that was removing most parts from the editor Fixed initialisation check only running on first editor entry - - - Updated - - - Alright, v1.15.2 is out. The only change is that I completely disabled the culprit of this entire mess. Subcategories in the "Engines" category will all show up with the wrong icon until you first click on them because of this, but feature wise everything is functional.

*Most* of the categories from the 1.15 download will work just fine with 1.14 (the exception being the engines category, which changed to being procedural with 1.15), it's just the .dll that needs replacing. EDIT Ok, I can reproduce the issue locally. Hopefully it won't take much to track down and fix

So, does anyone have a functional v1.15 or is it well and truly borked?

That on the other hand is a 5 second fix (I think I know exactly what's happened there...). Yay for easy bugs (or is it boo for forgetting the little things. I forgot to reset the status once the checking was done...)

This one might take a while to pin down (nothing useful in the log...) and I can't do anything about that until much later tonight. Please revert to 1.14 if you are experiencing issues

!(1-20+) should be the same as (==0), the non crew/command/w/e parts have to be filtered out another way (eg. module command) which I believe was done. Atleast, I didn't see any issues while I was cleaning.

Filter Extensions v1.15 Released Added "engine" type category. Will automatically generate subcategories for all available combinations of propellants (no value key used, only the type key) Improvements to Filter Extensions internal structure to better support being used as a reference Added "multicoupler" custom type CHECK. Matches to parts with >2 stack nodes Numerous icons and configs thanks once again to KaiserSoze RemoteTech config additions thanks to Gribbleshnibit8 Fixed "All Parts in Category" type subcategories not including parts from procedural subcategories Fixed subcategory edit configs being removed as duplicates Fixed subcategory icon edits not refreshing until clicked on The next thing on my list of things to do is going to be a second CHECK configuration option (bringing the total possible states from 2 to 4). This will be a does not contain type CHECK (which gives a slightly different result to invert which causes the Check to return false if it does contain a listed value). The current two state Check has no easy way of eliminating parts which match the required condiions but have more variables (eg. to find tanks witn only LiquidFuel, you need an inverted Check for every other resource option, which is less than ideal).

Old releases are all on github https://github.com/ferram4/Ferram-Aerospace-Research/releases

Filter Extensions v1.14 Released Added auto-generated "All Parts in Category" sub-category option for new categories Resolved ongoing issues with other mods preventing Filter Extensions from initialising Category and Sub-category "title" key has been deprecated in favour of the "name" key to better support Module Manager patches. Existing configs remain functional, all distributed configs have been updated to reflect this change. Resolved bug with non-procedural sub-categories in "mod" type categories that was causing only the parts from the first listed mod to be displayed (Issue #21 on github) Resolved bug with propellant check to account for engines with multiple engine modules. A single propellant type CHECK will now be run against every propellant from all engine modules (Issue #20 on github) "All Parts in Category" subCategories To use, add an "all = true" entry to a category config Changes to propellant type CHECK Some existing configs may break because of this change. I had to change over the "Engines - Jet" subcategory to specifically checking for intake air instead of not having liquid fuel so that the RAPIER remains in the category Other Mod's preventing Filter Extensions from initialising There's about a 5 second delay on initialisation if it runs into problems (see video for the expected behaviour).

It *should* apply the bonus to any change in an affected currency.

So, some good news. I have a workaround for the issues where FE would fail to work due to problems in other mods (eg. NF Solar with DDS'ified textures). Unless the issue is related to FE there is not much chance of it failing to initialise once this particular fix is public. Now, hopefully that's the end of that particular annoyance. Being vulnerable to something I couldn't control was bugging me to no end.

Oh yea, the collision checker will handle a purposeful merge just as well as a random one (why am I the one that gets reminded about this stuff...) A subcategory with the duplicate title/name and target category will have it's filters merged by FE. I'll still make the change to syntax so that other edits are possible, but adding filters to a subcategory works as-is

Plugins don't actually take any noteable memory unless they are instanced (read: active), and KAE will only be instancing the most up to date (and it doesn't store any data either, so the memory footprint of the instanced version is an inconsequential handful of bytes).

Next update will use name or title keys for labeling categories and subcategories (with name being the preferred option going forward and title remaining as a fallback for compatibility). That will make those MM indexable, and Filter/Check nodes can then be accessed by index for editing (or I can add a dummy name variable to those as well) If you add a name field now it will work with MM fine (FE will just ignore it)

And you always want the autopilot to try force it's way back to whatever it was doing when you unpause? I'm not likely to change that because I can just tap it to reset the SAS mode (instead of having to toggle it off and then on again). Probably, but a quick google search turned up no solutions so I just wrote my own (~5 lines of code + some copy paste to handle vessel switching. Sometimes it's just easier to do it yourself). The coding method has some slight differences (looking for a keypress event rather than comparing states, only finding the UI object once, etc.) but the overall effect is the same EDIT: In my case, mods which only enable/disable SAS without changing the mode would not cause a state reset (which one of my other mods, Pilot Assistant, does do), but I'm not particularly concerned about that since I don't use stock SAS and mods which would affect SAS at the same time.

oh, I see the problem ([] indexing requires a "name" entry). I might have to revise the syntax to accomodate that better... (or I could just add a name key just for MM...)

All my minor mods are going into a single thread post-1.0 release. Please check my signature for the new thread Simple plugin which adds the function to reset the SAS mode to stability assist after either SAS keybind is used (toggle/hold) or on landing. Settings file allows any of the above to be disabled (so you could have it rest only on touchdown for example) Drop the .dll anywhere in GameData to use Download here License is CC0 1.0 Universal Version 1.1 * Added config options * Added option for reset to activate on touchdown

All filters and icons in any folder (except those inside a folder labelled PluginData IIRC, those are exempt from KSP's loading cycle) are picked up, and infact I would highly recommend having your personal ones seperated from the distributed ones to avoid updating issues. Any .cfg file is MM compatible (see the use of :NEEDS[] for mod folders), assuming you use standard syntax, which FE does since MM is a great way to avoid conflicts

Near future solar depends on a specific icon being in the right place. Removing or changing that icon breaks the event which FE attaches to. Most common cause so far has been DDS'ifying all your textures (which changes the icon NF Solar looks for). That icon MUST be in PNG format (curvedsolarpanel.png from memory) EDIT NF Solar pull request submitted that will resolve this issue (well, shove a bandaid over it anyway, no time for recoding it) I'm also looking into an internal verification step (so if it doesn't complete, there's a possibility of reattempting the initialisation depending on what stopped it)