Crzyrndm

Please do a clean install of FE. There is a lot of extra stuff from older versions being loaded there (including 3 of each icon? ) and 1.2 parts aren't wholly compatible with earlier distributions

if (p is CompountPart) // true if it is the derived type { CompoundPart cp = (CompoundPart)p; // exception on fail // } // or CompoundPart cp = p as CompoundPart; // as cast returns null when it fails if (cp != null) { // }

2.7.2 is up with a fix for the parts not being visible

Looks like the part->folder mapper is having some issues. Will have a fix ASAP UPDATE Issue found, working on a fix

Will have to be tomorrow for a release. There's a build of PA and Dynamic Controls on github, but both have a few minor things I'd still like to fix

Filter Extensions v2.7.1 KSP 1.2 compatibility Can now parse stock subcategories Fix Ore tanks never showing up Move settings into the stock settings window Fix icon name collisions breaking the loader subcategory updates by Kerbas-ad-astra Download from github NOTE on using stock to generate subcategories. Stock categories look like the block below and can be located at GameData / Squad / PartsList / PartCategories.cfg CATEGORY { categoryName = foo icon = bar SUBCATEGORY { categoryName = ping icon = pong PARTS { ... } } } Everything enclosed by the SUBCATEGORY block is now a valid subcategory definition for FE. This means you can use the stock UI to pick a name, icon, and all the parts and then just copy that out somewhere just like any other FE subcategory for inclusion into categories

I'm moving all the settings panels into the stock menu anyway so that'll just fix itself...

I'll have a 1.2 release out either tonight or tomorrow so you don't have too long to wait

With the integrated settings using GameParameters.CustomParameterNode, is there any way to refresh an IList parameter? (I want to use the value of one setting to restrict the list values)

Not malfunctioning per se, just I haven't got some things 1.2 ready yet (eg. moving the settings into the stock game parameters) plus a thorough shakedown (testing). I'll have a release packaged up this weekend

I will note that all the functions requested since my last post (unlimited categories per part, culling of empty categories, MM compatibility) are already features of Filter Extensions

Not entirely sure what I'm bringing to the table other than I'm always open for more functionality requests FE can currently create subcategories in two very distinct ways By apparent function. Characterising parts by part modules included being the most common By specific inclusion of parts into a category FE has a part module which can list both the categories in which to include it and anything it needs to be excluded from You can also check from the category definitions, similar to how the stock custom cateogries store parts (although slightly different syntax currently. I should match them up at some point...)

I'm going to need a better description of the issue and a log to help. I'm not understanding what the link is between the settings window not showing up and a custom group not displaying?

There is an update for 1.2 on my github, but it's not been extensively tested as yet

There is a functional/testing build available on github for KSP 1.2. There are a number of things I want to fix before making it an official release but it's there (just expect some bugs)

Not sure what KOS syntax is, but the operation you're looking for is a vector dot product Assuming the vectors are normalised. ie. length of 1: 1.0 == perfect alignment 0 == perpendicular (90 degrees) -1.0 == perfect opposition >0.999 = <2.5 degrees of seperation More generically: cos-1(result) = angle

Base class (inheriting part module) with specialty subclasses (you dont have to directly inherit from Part Module) sharing common logic Configurable parameters (mod name, resource, etc.)?

What I meant by "flag" is that I could then search for parts with it in the vesselmodule. ie. the presence of the module in a part acts as my condition for a behaviour The logic for the vessel module: ActiveAndEnabled: Checked part has been staged (That was the intention anyway. I can't recall if that's exactyly what the property means) Modules.Contains<LockHeadingModule>(): Checked part contains the flag module (that I'm using to trigger the behaviour) The foreach loop goes through every part on the vessel, so it's not just the root part that gets checked The activation condition of the vesselmodule indicates that it will run on any vessel spawned in the physics bubble (this is why I used the vessel module. You automatically get 1 per vessel instead of trying to synchronise part modules)

You can't "call" anything from a config file. A config file sets variables (and only a limited group of types at that), it doesn't drive any logic Unless I'm very much mistaken, ModuleSAS doesn't know anything about how to control the vessel. It's most likely just a data wrapper for telling module command what level of SAS this part is allowed without a pilot present VS is freaking out because it doesn't understand what you're writing. Line 5: You can't declare a function with "class" in it's specifier. You can't have parameters in a class declaration. Line 10: Function names can't have "." characters in them. Nowhere is there any implementation for any of these functions/classes The following is something like how I would envisage the plugin working (note: before you say it doesn't work, it's the start of a module for syntax demonstration since that's the bit you're missing entirely) class LockHeadingModule : PartModule { // add to parts to trigger locked heading mode when staged // module only used as a flag for the vessel module } class LockAutoPilot : VesselModule { public override Activation GetActivation() { return Activation.LoadedVessels; } public override bool ShouldBeActive() { return vessel.loaded; } protected override void OnStart() { foreach (Part p in vessel.Parts) { if (p.isActiveAndEnabled && p.Modules.Contains<LockHeadingModule>()) { vessel.Autopilot.Enable(VesselAutopilot.AutopilotMode.Retrograde); break; } } } } Please, atleast read through a C# tutorial and follow through the KSP wiki tutorial I linked earlier

Yea, that's never going to work. The short version is that your knowledge of basic C# syntax is missing Some possibly helpful links http://www.learncs.org/ - You can't write anything if you don't understand the basics http://wiki.kerbalspaceprogram.com/wiki/Tutorial:Creating_your_first_module - Start with something that actually works in KSP

Since it is a wing, the plugin has an implicit dependency on there being a lifting module present. Removing it will cause problems

The problem with 2 year old posts is that they're generally old info. Blizzy's toolbar has been supported for quite a while (it just has to be enabled in the settings file) Re colour scheme: Red = Go, Green = Stop. Obviously I'm a genius... (more seriously, now that you point it out it's ever so slightly irritating )

For dragging, you need to assign the result of GuiLayout.Window back to your position rect For text dimming, that's because the window is being drawn on top of your other stuff. You want to put everything inside "drawGUI" into the top of "Drag" (probably lose the area code too)

Stock way: create a custom category with the stock icons that dont show up in the PartsList/SimpleIcons folder and then look in PartsList/PartCategories.cfg for the icon names. It would be useful for FE to be able to export a list of every icon it found (with a location too I guess) so I can add that... RE: ore Investigating. It does look like it should work...

The end result would be a single code base that supports both types of existing pwings parts and allows all possible common features to be shared (ie. original pwings with an editing UI, and when the edge angles from this get added it works for *every* Pwing part). Basically, while I'm converting to the U5 UI system, I also merged the two plugins so I don't have to keep doing the same work twice... Development thread is here for a more detailed explanation @Papa_Joe Contributions are always welcome, whether to the seperate plugins, or the in development merger (it'll all get pasted around anyway until the merger supercedes the existing plugins...)