Crzyrndm

Why, why, why... 1) part is never "activated" so functions are never called and it just behaves as a normal wheel with no modifications 2) moving functions so as to not require activation breaks the base reaction wheel (presumably because hiding private implementations of the functions) 3) move to a separate module and things don't load tl;dr Random roadblocks...

@Snikersnee That worked for the first handful of small groups I made with stock parts then the drudgery of the system just got too annoying. The constant requirement to update for new mods and those annoying little '+' buttons on each icon only make the problem worse. The back end is acceptable (it lets me do what I want, could possibly use a few improvements but...), but the user interface just isn't up to the task as far as I'm concerned. When stock starts adding custom filters based around functional attributes, then maybe I'll consider using it. Till then, Filter Extensions is just not something I want to be using part mods without

Hit this one already with FE and agree that filtering anything based on Category.none now that the floor has been opened for mods is just a bad idea

Can't help with the image, but the second window won't draw because button is only ever true once and it needs to be called every frame you want the window to be visible in. I would suggest toggling a boolean and drawing the window elsewhere based on the state of that bool bool visible = false; OnGUI() { if (button...) visible = !visible; if (visible) drawWindow... }

1) PartModuleList.Contains I recently ran into an issue with Filter Extensions whereby a part module calling Destroy() on itself during it's awake sequence resulted in exceptions when part.Modules was queried with a string or int parameter. // breaks part.Modules.Contains("PartModule"); part.Modules.Contains("PartModule".getHashCode()); // works part.Modules.Contains<PartModule>(); Which is all well and good, except querying by string/int is rather necessary for non-stock modules My solution currently is to check against PartModule.GetType().Name, but I was wondering if there was any other ways that I should be looking at (particularly since the module type check is probably the most frequently used for FE by a good stretch). I'd be particularly interested in a solution that allows for derived classes like the typed check above (ie. how Contains<ModuleEngines>() also catches ModuleEnginesFX) because it'd be nice to have consistency with the stock modules (and my current method for going from a string to typed check for stock is a PITA to maintain...) 2) Game mode How do we tell when the game is a scenario/training module?

2.5.2 is current version with all fixes and features

cough (I agree totally btw, but in the meantime if you want to make custom categories that survive KSP updates...)

Unable to replicate any mass or menu issues using stock or FAR. Something else is interfering and I need more information as to what...

Filter Extensions v2.5.2 is released, fixing another case where a self destructing module would cause things to explode

CKAN showing or not showing my mod is not my problem as far as I'm concered, and no the current release isn't fully compatible with other mods (see reports of things exploding on the last page) so I'd rather not have a flood of duplicate reports from CKAN right now.

Will investigate shortly

It looks correct, however I see nothing that will refresh the list (IIRC, the stock event doesn't add the buttons unless you actually reset the list). Have you tried switching to a different category and then back to Filter by Function? Realchute has a nice example (FE deals with things far too abstract/invasive to use as an example -.-)

Drop this file in to GameData/000_FilterExtensions: https://github.com/Crzyrndm/FilterExtension/blob/master/GameData/000_FilterExtensions/FilterExtensions.dll?raw=true Release version still has the issue (next release will be after I finish some stuff that isn't working correctly yet) @Papa_Joe The issue for me was Part.Modules.Contains using a string or int input somehow triggers the partmodule awake sequence in which a module was self destructing. If you can, use the typed contains (ie. Contains<ModuleEngines>()) which is safe or, If you can't because the class is not a part of KSP/your mod, this is my "safe" version using string input here: https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/Utility/Extensions.cs#L50

Will fix, it's easy enough to detect scenarios/tutorials (although why would anyone be doing basic tutorials with mods installed...?)

dont bother removing it and setting the reference to null Simple toolbar template: https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/Toolbar/AppLauncherFlight.cs Called from: https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PilotAssistantFlightCore.cs#L61-L64 Note how the button is only ever created once (when the static var is null), even though I can (and do) call create a number of times

Wouldn't it just be easier to generate abbreviations on the fly based on some simple rules. eg. Base abrev. is the capitalised first letter and then any following capitals (LiquidFuel => LF, oxidizer => O) For a conflict, add lowercase characters as required to whichever resource is later when sorted by <alphabetically, order added, ...> (Ore, Oxidizer => O, Ox) Provide yourself and your users with a means of overriding the generated abrev when required

Because one (mine) was started as just a maintenance fork to keep the mod in working order. This one was started with the aim of adding new features and appears to be incorporating fixes from my releases as well. There is no competition, just different aims (stability / features)

Old AeroGUI should still be fine as an example of a simple scripted GUI. There's no change to the Unity implementation of the UI functions from 1 => 1.1. Otherwise...

The only change for setup is that you probably want to add "KSPUtil" to the references (ConfigNode, Vector3d, etc.). .NET version is the same, PartModules are the same, etc, etc. Most UI related classes are now in the namespace KSP.UI.Screens (and child namespaces of...) KSP_Data or KSP_64_Data doesn't matter (they're duplicated on windows, but other OS's only have one set and use symlinks for the other from what I've heard so they're identical)

Yay. 1 more bug down

The difference with my Variable SRB limiter is that it makes that thrust curve editable ingame (yes I do use the thrust curve internally now, and it will *probably* work with SRB's that already use thrust curve...), although only by linear ratios across the burn

Doh, of course a null check would be somewhat useful here... Try again, same link. I'm feeling very hopeful this time given that error

Once I'm not fighting fires all over the place...

That's some error you got there (the joys of generic extensions and recursion in concert...). 1) https://github.com/Crzyrndm/FilterExtension/blob/master/GameData/000_FilterExtensions/FilterExtensions.dll?raw=true I've entirely removed all traces of the problematic function this time and created my own replacement for the one place it's required. Hopefully it doesn't have the same issues 2) If that doesn't work, I need to see your MM cache and know which category you clicked on when things exploded

version bump to 2.5.1, basically the same as what I linked 2 days ago (too many reports of the same thing to hold back any longer...)