Crzyrndm

connection factor would be set by the cfg so it shouldn't matter which wing was edited (you can check the .craft to see if it is in both wing modules to verify if you want) The only thing I can think of is to look in the log and see what it says about why the joint broke. It's obviously loading it somehow, but I've seen much higher wing loadings operate without issue before

you just add the line of text to the part.cfg file inside the pwing module. It's not there at the moment because everything just uses the default of 150 PART { ... MODULE { ... connectionFactor = 150 // just add this line } }

Yes. There are some issues that I don't have a solution for yet though so nothing for release BreakingTorque/Force are overriden by the plugin so no, changing that will have no effect on the issue (and they should already be scaled up significantly by the plugin). The variable you want to set is "connectionFactor" in the wing module (default is 150, higher == stronger) which scales that connection force

Or if you want to do it in code yourself, primary category creation is here and deletion is here

B9 PWings uses whatever the game has decided is 1m along all axes

Which download did you use? The one from first post of the B9 PWings thread is not currently actively maintained so make sure you get it from here If that still doesn't work, you need to post your output_log.txt so we have some chance at debugging your issue

A log would be nice (sometimes the error shows up quite a way before the symptoms), even better if FE debug option was enabled (in the custom game settings menu). If it is caused by FE (not present in stock), I'd be very interested in seeing if it still occurs on the latest development build (KSP pre-release only, so no rush on that),

I don't think there's a built in KSP version check in any version of this plugin (I rely on KSP AVC for that sort of stuff, and I dont recall that in the original either). You sure that's not from one of the core B9 procedural plugins?

With a new KSP release imminent, I'm kicking back into development gear. FE is first up on the block with a major refactor into what's likely to be a version 3.0 (primary feature: speed). The first part of that refactor is now on Github (KSP pre-release compatible only) and is mostly focused on cleaning up the last couple of years of growth (awkward code tends to accumulate over time, and I've learn't quite a bit in the intervening 2.5 years as well...) in preparation for the shift. Now is a really good time to be feature requesting, bug reporting, etc. so fire away Notes on planned speed improvement You might be wondering how I'm going to get an improvement worth a major version. Well currently, FE runs its checks every time you switch the selected category. Early checks were very lightweight and this never caused any issues. Jump forward to present day, and we've picked up a couple of checks that can really make a noticeable delay in that switch (worst offender being the "field" type, which I've had to play games with to make run at a usable speed, but it's not alone). There's no reason for this to be computed every time in 99% of cases, so the intention is to move it all back to a single point (probably first main menu entry). tl;dr => lack of foresight (I'll blame that one on lack of experience <.<) leading to bad core design decision.

The latter. I presume when MM clones a part, it's also just cloning the base directory (hence the issue) and there's not a reasonable indication that I'm aware of that would mark the part as cloned (nvm extracting the patch directory)

Most likely, this would have to change through MM. MM patches and their effects are not particularly visible to other mods to the point where it's likely I'd have to reload/parse all the MM patches just for FE. If the part is coming up as "squad", then the game is under the impression that part was loaded from the Squad folder.

You want this.

A short explanation of purpose would have been somewhat useful, and generally it helps if the code for review compiles to begin with (assigning from a void function being one among many that would prevent that). Folder structure I would put only the compiled .dll inside GameData, not the source file (.cs). GameData to me is more like the "Release" folder which only contains the necessary components. NOTE: ^^ Purely my personal opinion Data Structure You've artificially limited your plugin to two fuel types and aren't grouping information about each fuel type together. using System.Collections.Generic; public class FuelType { public string Name; public float MaxQuantity; public float LastQuantity; // other members... } // 0, 1, ... N types List<FuelType> fuels; Again, a little personal style coming through on the use of the List<>, but it prevents errors where you make a change for item1 but not item2 and sure beats having to copy it all out later if you do need another type. It does take a little more effort to load (override OnLoad to get the fuels in...) NOTE: reading the comments up top, definitely need a collection... Possible bug "Just a little" suspicious of this logic: https://github.com/Darknesshas1/DK-BHTanks/blob/master/DK-BHTanks/GameData/BlackHoleTanks/Plugins/BHStorageCfg.cs#L80-L83 Even if it's not a bug because of some side effect in GetMaxResourceAmount (definition where?), that looks likely to catch you out at some point in the future Bug https://github.com/Darknesshas1/DK-BHTanks/blob/master/DK-BHTanks/GameData/BlackHoleTanks/Plugins/BHStorageCfg.cs#L138 1) You're calling catchup on the lower warp rates (<= 5x multiplier), not the higher rates 2) You probably want to be checking TimeWarp.WarpMode instead of the multiplier (there are mods which fiddle with the rates, the >5 already is a logical error with the lowest time warp rate getting paired with phys warp, and is a magic number that doesn't express your intent). 3) Pulling all available EC in a single frame 4) if (Ec <= BHECCost || Ec == 0.0f), avoid repeating yourself to save yourself headaches later (add brackets or newlines to suit taste if wanted) 5) If you're not going to do anything with it, don't create the variable, and definitely don't just list it in an empty statement (if it does compile, it still makes me question whether something got screwed up in a formatting shenanigan)

The top level folder is mostly(all?) definitions of subcategories, it won't create anything. The "Default" folder contains category definitions. These reference subcategory definitions through their SUBCATEGORY node and control what does get created. // A SUBCATEGORY defn. By itself will do nothing, but can be referenced from categories SUBCATEGORY { name = Parachutes icon = Chutes FILTER { CHECK { type = moduleName value = ModuleParachute, RealChuteModule, RealChuteFAR } } } // A category defn. This is a root element for creation CATEGORY { name = Landing Parts icon = LandingParts colour = #FF90F090 all = true SUBCATEGORIES { list = 0, Landing Gear list = 1, Landing Legs list = 2, Parachutes // Parachutes subcategory will be instanced in this category list = 3, Rover Wheels and Tracks } } The reason for the numbering on the categories is that categories get created in the order they get loaded (It's awkward and should really be fixed...)

They should work as expected in flight and engineers report data is not used for flight characteristics. IIRC, the engineers report doesn't seem to allow for shrinking parts which leads to errors when small winglets are used

B9 uses the UI and has configurable appearance (also allows use of the T/G/B drag scheme).

@HadrianRomulus Apologies for the (very) late reply. Hectic few months and a bit of burnout have not kept KSP at the top of my todo list. Latest release of dynamic deflection should resolve the roll issues and I will be looking into the vessel management code shortly (in the meantime, you can probably fix this issue by switching away from the seperated vessel and then back quickly. The core issue is that it's giving you the UI for the incorrect vessel after separation)

B9 PWings are 1.2.2 compatible (as of today anyway) with some known issues that shouldn't be obvious unless you use one as a flap (don't...) I need to check the originals don't have the same issue that was just fixed (and port Boris's stock patch) when I get the chance so they may not be compatible with stock aero (FAR shouldn't be affected)

https://github.com/Crzyrndm/FilterExtension/blob/master/FE_Testing/FE_Test_Script.cs#L10-L27 Just a copy of the template that most other plugins adding to the part menu use. If everything is working ok, I get a blank icon as the last one in the list (I thought the plugin under it verified that it did get put in, but it seems there is still room for improvement there ). Post build script copies it to my testing KSP instance so it never hits the directory I package for releases

Timing issues are "fun" (I have a similar issue with FE needing to act before any other mod to avoid stepping on any toes). What I found with FE is that the function registered last gets called first, so I ended up registering to the gameevent in the Awake of the scene that I required it. Definitely not something I'd recomend doing lightly but so is everything else when playing with timing dependant functionality Whatever you do get working, I highly recommend that you find a way to ensure it continues working (this is the sort of stuff that can break really easily and quietly). In my case, a seperate plugin that uses the normal route of adding a subcategory and verifies that it didn't get squashed

If you could establish which module caused the exception to be thrown then I can take a look. Without knowing how to replicate, I can't do anything

The replaced/extended stock functional categories have been shelved for the time being since 1.2 added a number of new stock subcategories (basically, it isn't everything in Utility anymore, and it's easier for people when the stock categories play the same), which included a "thermal" tab which from memory is just radiators and heatshields There doesn't appear to be a dedicated radiators subcategory in any of the extended categories (the green ones). You could quickly add them somewhere using this @CATEGORY[<I cant decide where they should go...>] // could be in ISRU, Aero, Electrical... { @SUBCATEGORIES { list = Radiators } } SUBCATEGORY { name = Radiators icon = stockIcon_thermal FILTER { CHECK { type = moduleName value = ModuleActiveRadiator } } }

New version is up. Fingers are crossed...

These just get wierder by the day... (fingers crossed I'll have a fix tonight

That's changing parts so that they show up in an existing FE category (the "size 0.325m" category in bulkhead profiles). From my simple test categories, this is a good example of how to create a subcategory for all parts in a GameData folder. Change #1: Your GameData folder name Change #2, #3: Your subcategory name Change #4: Replace with @CATEGORY[Filter?by?Function] (Assuming that's where you want it to show up) Definitely require a log