Crzyrndm

@PART[PartName] { category = none } Insert part name field and drop in any .cfg

KSP 1.0.x - Patch v2 has been packaged. Fixes: Material index exception Nullrefs caused by reverting to the editor Significantly reduced logging in flight for control surfaces Requires Module Manager Requires Bac9's files downloaded from the OP

Just explicitly add it to the category. There's nothing particularly special about the procedural categories, they just get a number of hidden subcategories added to them automatically.

Probably the same thing as the person before you. The controllers have operational limits (mostly for sanity so it doesn't try and climb with a 40+ degree angle of attack or something silly like that) and some strange behaviour will appear if you push those limits.

You want to add something that doesn't contain Exotic Matter to the Exotic Matter containment category? That will require three things. 1) A subcategory definition. In this case, it sounds like you need a second filter (the first filter to catch parts containing EM that aren't engines, the second for parts matching the new criteria) 2) An explicit addition to the filter by resources category 3) The removal of the generated EM category. It will detect that there is a Subcategory by the same name that has multiple filters and assume it has a different purpose. To get around this it will add res_ to the name. Just add the following to a cfg somewhere to get rid of it. FilterRemove { remove = res_Exotic Matter }

@mark7 1) Install all files from here 2) Download the patch here, allow files to be overwritten when requested (and make sure you also have Module Manager installed)

Oh, it would seem I misunderstood your issue (it sounds similar to the one reported earlier that the above version fixes) You get a storage category that has all the parts that can store Exotic Matter, and the engines also have storage for Exotic Matter. See here how I've overridden the EC behaviour to remove all the extra EC carrying parts. Match the name, and make sure the first Check is the resource one (may need to add it explicitly to the category as well)

Version 2.1.1 Fixed no "default" icon causing categories without valid icons to not be created Fixed unresolvable conflict between generated fuel and propellant categories Fixed some engine types not being properly excluded from engine categories Moved rename step such that multiple different subcategories can present the same name

It's an issue with how the resources and engine categories are being generated where they both end up with the same name (Warp engines use Antimatter exclusively I take it). I have a fix for it, but there isn't a way around it at the moment

Install orginal Bac9 files => Overwrite with files from the link in my sig => Further fixes from the location I linked earlier (which will eventually make it to step 2) E: Ninja'd

Don't play career anymore' date=' strategies aren't completely off the wall anymore, there's no point in me making it That would be nice, but it's also not something I plan on doing.

This is the one used by the ISRU category, not sure if that's the one he's referring to

Physics warp can do some weird things on occasion. Possibly all you need to do is give PA a little bit more authority. Options => Show Control Surfaces & Show Limits If the elevator is deflected upwards ~40% constantly => Open the Elevator Controller and increase the "I Clamp" by 0.2-0.4 If the plane sits at about 10 degrees of AoA => Open the Vertical Speed Controller and increase the "I Clamp" and "Max Out" by 5 Alternatively, sometimes it gets the shakes at higher warps. If so, reduce the Kd on the vertical speed controller slowly (it should fix itself pretty quick, if you don't see any change by the time you've halved the value try the same on the elevator controller)

@PART [*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[RWSaturatable]]:Before[RWSaturatable] { @MODULE[ModuleReactionWheel] { @PitchTorque /= 3.25 @YawTorque /= 3.25 @RollTorque /= 3.25 ecMult = #$PitchTorque$ @ecMult /= 10 @RESOURCE[ElectricCharge] { @rate = #$[B][COLOR=#ff0000]..[/COLOR][/B]/ecMult$ } } } ecMult is defined in the node one step out, I think that's all you were missing No, if it isn't defined in a .cfg (and/or the cfg isn't loaded in the typical way) Module Manager can't do anything about it. Buildings are plugin territory

https://github.com/Crzyrndm/B9-PWings-Fork/releases

@Kvantovy You need Module Manager installed as well. Also, current updates to the .dll you can grab here: https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/GameData/B9_Aerospace/Plugins/B9_Aerospace_WingStuff.dll?raw=true The release is a package that has all the extra compatibility files in one place, but it doesn't get updated as often. @Hodo I'm not having any major issues with the dev FAR build from about 6 hours ago. There's a couple of niggles when reverting to editor that insist on being persistent little annoyances, but I haven't encountered anything game breaking. Assuming you have both the necesary dependancies (MM, Modular Flight Integrator for FAR), I need a log and steps to produce your issue.

aight, sounds like something changed with nuFAR recently that I'll have to check up on

Actually, if you read back through the devnotes a bit, Harvester apparently did fix the root cause of the SOI bug (when it detects an SOI shift, it backtracks to find the exact crossover point to create the new orbital parameters from). The warp throttling was added to 1.0 as well, but shouldn't actually be required.

Version 1.6.0 Added tuning for the new vector tracking SAS modes Overhauled preset system (please back up presets.cfg in case any errors slipped through)

Shouldn't be too hard. One way to do it 1) Class inheriting from Module Engines (FX) that has one public Float Curve tagged as a KSP Field (so it can be loaded from the part cfg) 2) Override OnFixedUpdate, set heat production (inherited from the engine module) = originalHeatProduction * curve.Evaluate(parameter) 3) Use a MM patch to rename the engine module you inherited from to your new module name and add the interpolation data Alternatively, you can add a separate module that inherits from partModule to affected parts, and use (part.Modules["ModuleEngines"] as ModuleEngines).heatVariable to set the heat production value. If all you're doing is altering the heat value, this way is probably better for mod compatibility

I'll have to add a tag to duplicated procedural categories to avoid the override (and I may change the way rename works so they can use the same name). The reason Mono doesn't get caught by this is that a space is inserted before every capital letter in the resource name to better present multi-word resources (eg. LiquidFuel automatically becomes Liquid Fuel)

I need logs from those that aren't working as I can not replicate any errors

IIRC you would need to tag Manageable with [KSPField] and it needs to be public (see this simple example). Alternatively, since you are likely doing this from inside the same plugin, you can cast it to the correct type and access values that way (it still needs to be public) ((KSP_Manager)currentPart.Modules["KSP_Manager"]).Manageable

This is what you're after. square brackets after the node name (ie. PART) are shorthand for the #HAS[#NAME[]]. Since you want to edit the value if it exists, or add it if it doesn't, you use the % operator @PART[USI_WarpDrive]:Final { %TechRequired=ftl } @PART[USI_WarpDrive_625]:Final { %TechRequired=ftl }

1) The resources tab is being auto-generated from all the resources it can find now, so all it should need is being pointed to the correct icons and a few renames (ie. updates to the NamesAndIcons.cfg), or did I miss something? 2) I need to look into this, the engines are only meant to match to the exact combination, but some of them obviously aren't 3) Roverdude may be adding his own subcategories to that tab. If he is, it's probably better to add the autogenerated UmbraSpaceIndustries one to the delete list ugh, looks like I broke the icon loader again... EDIT Can you try with this version please