Crzyrndm

B9 wings include a GUI, appearance customization, can hold fuels, and allow separate edge shaping. Original Pwings (these) can not be precisely edited to a size (no GUI / numeric interface), but are not dimensionally limited. B9 wings were at the very least inspired by this codebase so there are a lot of similarities (a good portion of my changes that weren't to do with the wing manipulation were directly ported from my work with the B9 wings, and I have ported the revamped manipulation from these wings into the dev version of the B9 wings with minimal changes). There is no incompatibility, although getting them to match up can be somewhat tedious. EDIT The 0.90 version was endlessly tedious to shape so B9's wings were a huge advance in that regard. I would say the new system puts them about on par for ease of use (but then I am slightly biased...)

Cause of jittering has been found and removed by v1.11.6

If you're just getting started, you can use the normal KSP.exe with no changes and it'll probably be easier (less work to build a new version). It does sound like you haven't run the patcher which is probably your problem

Version 0.10.0 for KSP 1.0.4 KSP 1.0 compatibility FAR v15.4+ compatibility Taniwha - Corrected transform for collider, NRE fixes, FAR and KSP compatibility CrzyRndm - Overhauled manipulation logic, optimisations for aero calculations, KSP compatibility Kerbas_ad_astra - added bulkhead profiles Wing manipulation is now part relative! If you want to swing the wing forwards, you move the mouse in the direction the wing is facing. If you want to move it faster, zoom out. (thickness is towards the top of the part, width is towards the rear of the part) Wing manipulation doesn't require the mouse to remain inside the bounds of the part! No more tap-drag-tap-drag-tap-drag to get to the length you need, the wing will continue to change shape even if your cursor is no longer hovering over it for some reason. Wing Manipulation wont turn the editor into a slideshow KSP v1.0 Aero for both FAR and stock require complex (and therefore time consuming) calculations to determine part shape. To ensure a smooth framerate, these calculations are delayed until after wing manipulation is no longer occuring Send it taniwha's way

New thread here.

Procedural Dynamics - Procedural Wing (Download) B9 Procedural Wings Thread - (Download)

1) If engines are showing up in the air intakes subcategory, they must also have a ModuleResourceIntake in the part. You could add an invertedd check to that looking for ModuleEngines and that would stop it (no need to check for EnginesFX any more as it respects inheritance and EnginesFX inherits from Engines) 2) Only if you set them to show up elsewhere. 99% of parts (everything that uses a "category =" field that doesn't end up as none) don't care if they are never seen and are available for any subcategory in any category. Parts that wouldn't normally show in the stock Filter by Function categories ("category = none") it must show up in a subcategory created through code to be visible (the idea being that you change the subcategory definition, not the part to move things around) I will see about including these in future versions

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 SUBCATEGORY CATEGORY 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 subcategories SUBCATEGORY 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" || "ModuleEnginesFX" || "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)

If you added the BDArmoury folder name to the MM patch and copied the USI category and replaced the USI references, yes you would move all BDArmoury parts from the Filter by Function Category into its own category. 100x this. Just a simple "add this subcategory to this category with this icon" and allowing custom values for the part category field would go a long way to making their system usable by general populace. No need for FE levels of filtering... The other change I really want to see is a third (or more) level of selection so we can have "Filter by Function" => "Utility" => "Wheels" (=> "Rover Wheels"). FE is expanding sideways, but a depth based layout would be so much better

Module Manager patch to exclude USI parts from the Filter by Function subcategories when using Filter Extensions (note: this is from all of them, not just the stock ones) @CATEGORY[Filter?by?Function] { Filter { CHECK { type = folder value = UmbraSpaceIndustries,ART invert = true } } } If you want to add categories for other mods, this .cfg sets up a new category for the USI parts. Copy it, change the folders listed (any folder in GameData root is valid) and the Category name to add a new listing. Add any exclusions to the value line above above to remove them from the default category.

I take it this is he bouncing in question. I have absolutely no idea what I've done to cause that, but I guess I'm going to find out...

I wasn't really intending to release a version just because of the uneditable field, but since everyone seems to be running into it... (and the next set of features being pushed back due to other constraints)

Version 1.11.5 (by popular demand) Fixed: Uneditable heading target while control was not active Added: "Level" button to the bank control, sets target bank to zero Added: Pitch mode to the vertical control (NOTE: switching to this mode is not smoothed at this point in time) Fixed: Heading value control now takes input again

To my knowledge there are two minor/non-critical changes that have been posted. The conductivity increase listed above and the deletion of the file Patch.cfg (the first of which is just a quick value pulled out of thin air, and the second of which only affects stock users).

No, in this case it was a random if statement that has since been removed causing the heading input field to become uneditable while the control system was deactivated. You just have to turn it on before entering any values to avoid it

So they are determined from the part shape/drag cube, that simplifies things. Should make bumping up the skin<->internal conduction rate the only required change.

Code changes or use Modular Fuel Tanks

A module manager patch to improve the situation. It's not perfect, the skin mass probably needs to increase a bit as well (wings have more surface area per mass unit than a typical cylindrical part), but that would require knowing what the default value was. @PART[B9_Aero_Wing_Procedural_*] { skinInternalConductionMult = 5 }

It would appear there is an issue with the part heating. Specifically, heat isn't being transferred from the skin to the internals at a useful rate which leaves the skin temperature extremely unstable. Looks like they could do with a better thermal setup

That is really odd since I have an override in to force it to always say it has valid parts (it even shows up in sandbox locally). Is it possible the category you're adding it to is adding some extra filtering? Working test case SUBCATEGORY { name = Unpurchased showUnpurchased = true FILTER { CHECK { type = custom value = purchased invert = true } } } @CATEGORY[Filter?by?Function] { @SUBCATEGORIES { list = Unpurchased } }

Read my last comment. I forgot to add the override field to the internal copy function and so nothing seemed to ever happen when it should. The line should read "showUnpurchased = true" - - - Updated - - - Version 2.4.1 Quick patch for missing subcategories Fix for unpurchased override not being copied and therefore not functioning

No, this one is my problem. I made one too many assumptions

Capitalise the P in showUnPurchased, I made a typo in the release notes (I should say in the code, that shouldn't be capitalised. It will be lower case for future releases)

Can I get a copy of the log file and the configuration files you are using (all your ones, and which (if any) of the distributed set that have been kept if you're still deleting them). I think I know what's happening, but I still don't know exactly why and I want a hard repro case for it.

Are you checking the logs (ksp.log or output_log.txt) to get the full stack trace? That'll tell you which function the exception is occurring in which *can* narrow things down tremendously