Crzyrndm

@ferram I've managed to get FAR to voxelise B9 P-wings correctly in any orientation (without breaking them visually) by double siding the meshes. Only inverting the meshes when they would cause the oversized voxelisation makes surfaces transparent when they shouldn't be (as expected). Is the double siding likely to break anything for FAR?

Temporary fix for the FAR voxelisation issue can be downloaded here: https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/GameData/B9_Aerospace/Plugins/B9_Aerospace_WingStuff.dll?raw=true It may break the material selection in a few places / cause colourisation issues but it will function correctly (or atleast it has so far). EDIT Only breakage seems to be material selection for the top / bottom surfaces. Colouring works fine, edges are fine, top/bottom just has no texture at all...

I just checked with a stock + FAR (aero failures enabled) with that rocket and had no issues (even without throttling back, which given the first and third stage TWR's I normally would have). Your problem is coming from somewhere else

Hdg direction/value: Well now we have both (The recent overhaul of mode selection paid off big time here. Less than 5 minutes to add the alternate "Heading #" lock) Blizzy toolbar: It's already in. You do need to enable it in the settings file though (Pilot Assistant/PluginData/Pilot Assistant/config.xml => useStockToolbar = 0)

Won't help, still haven't been able to identify why the inversion has occurred (The plugin does move vertices but it's all done relative to the part orientation) RE: Crowded overlay Toggles for what is being displayed? EDIT RE: Pwings, I have found a (very hacky) fix that will sort things out for now.

Latest Github version includes a heading value lock (and some tweaks to the resizing code for a really minimal view).No smarts for crossing the poles on this one though

Well it'll be easy enough to stick the heading (number) lock back in as an option next to the heading (direction) lock. The reason it was changed to direction lock is that it fits better with any "heading to target" readout (eg. waypoint manager). The wing leveller just isn't even close to being accurate enough for things like that.

Why are you uninstalling it...? EDIT Previous releases are still available on Github

Yes it changes when heading north/south to try take planetary rotation into account (or not as the case may be). Slower vessels (and fast ones that can't turn) may not be able to stay aligned with this and small errors will accumulate causing you to not go directly over the polar regions. Probably shouldn't be happening as everything else works on surface relative measurements, I'll have a poke around and see if it can be changed. Rapidly changing when going East/West near poles is because it is following a direction and a constant East/West heading is only a constant direction when following the equator.

Version 2.2.1 should fix this Fixed Liquid Fuel only engines not showing up in the Engines category Fixed multimode engines not always showing up in the Engines category That took a painfully long time to track down...

Hrm, looks like multi-mode engines aren't being dealt with correctly.

is squads system case sensitive or do HX and hx end up in the same place? (I ask because FE should match Squad in this behaviour and it's trivial to change)

From those numbers: origin + position = (-283.5, -3.1, -347.9) or (-283.5, -3.2, -348.0) I find it likely the slight difference would disappear if you printed the result after adding the two Vectors together (much less rounding involved) I believe FloatingOrigin.Offset gives the location of the origin relative to the last origin (other than after scene load, the magnitude is always 6000 which is the distance the origin shifts while krackensbane is not engaged) when it is shifted. All the difference demonstrates is that the origin initialises differently depending on how you enter the scene which is why the part position is slightly different

That's because the origin point (0,0,0) isn't fixed in space. From what you're saying, it initialises slightly differently depending on how you transition to the scene (and is constantly shifting in flight) This may help FloatingOrigin.Offset

Version 2.2.0 Parts checked for visibility in subcategories by other mods, exception patches for mods using custom subcategories is no longer required Checks updated to deal with parts that aren't complete / meant to to be visible / are using category = none Subcategories can be added to a category without an index/position. Unindexed subcategories will be appended to the end of the list (useful for mods wanting to add a subcategory using FE)

Thermal monitor updated to v1.1 Removed thermal mass and flux readouts Added a degrees/s readout (flux / thermal mass) Better formatting to temperature/rate readouts

Dynamic Deflection goes amazingly well with Pilot Assistant. Without Dynamic Deflection, all static control systems (SAS, all systems provided by PA) have no automatic response to changing flight conditions and so will tend to have a rather narrow band of flight situations any given setup will suit. Dynamic Deflection provides an automated response to a changing situation meaning you don't need to be constantly making adjustments to PA/SAS setup Pilot Assistant/SAS PID Tuning: Altering control response to better suit the vessel Dynamic Deflection: Altering control response to better suit the current flight situation NOTE: DD doesn't help with the transonic drag spike so you may get a few wobbles as you pass through that regime even if it's perfectly suited to everywhere else

Static analysis graph, run it from 0-180 degrees (E: 0-90, flip the vessel to look at 90-180), look at Cm (yellow). Peaks (local maxima) indicate stable angles, troughs (local minima) indicate angles from which it switches from one stable position to another. The Cm slope into the peaks indicates how stable each position is (steeper slope == greater stability). E: IIRC, when peaks become +ve the stable locations are the points where Cm becomes +ve (eg. deploying flaps typically makes Cm +ve at zero degrees and 0 at 2-3 degrees, vessel will stabilise at that 2-3 degree point, not the peak at zero). I should ammend what I said above based on that. The stable positions (0 torque, deviation causing torque that applies torque back towards the point) will be 0 crossings with a -ve slope. Peaks with a -ve magnitude will be the most stable locally (lowest torque) but may not actually be stable. Troughs are the points with the highest torque Ignore me, listen to ferram >.>

Incase anyone else ever needs this public static HashSet<string> blackListedParts; void Init() { /// if (blackListedParts == null) findPartsToBlock(); /// } void findPartsToBlock() { [COLOR=#008000] // all parts that may not be visible[/COLOR] List<AvailablePart> partsToCheck = PartLoader.Instance.parts.FindAll(ap => ap.category == PartCategories.none); [COLOR=#008000] // Only checking the category which should be Filter by Function[/COLOR] PartCategorizer.Category mainCat = PartCategorizer.Instance.filters[0]; [COLOR=#008000] // has a reference to all the subcats that FE added to the category[/COLOR] customCategory customMainCat = Core.Instance.Categories.Find(C => C.categoryName == mainCat.button.categoryName); [COLOR=#008000] // loop through the subcategories. Mark FE ones as seen incase of duplication and check the parts in mod categories for visibility[/COLOR] HashSet<string> subCatsSeen = new HashSet<string>(); for (int i = 0; i < mainCat.subcategories.Count; i++) { PartCategorizer.Category subCat = mainCat.subcategories[i]; [COLOR=#008000] // if the name is an FE subcat and the category should have that FE subcat and it's not the duplicate of one already seen created by another mod, mark it seen and move on[/COLOR] if (Core.Instance.subCategoriesDict.ContainsKey(subCat.button.categoryName) && customMainCat.subCategories.Contains(subCat.button.categoryName) && !subCatsSeen.Contains(subCat.button.categoryName)) subCatsSeen.Add(subCat.button.categoryName); else[COLOR=#008000] // subcat created by another mod[/COLOR] { [COLOR=#008000] // can't remove parts from a collection being looped over, need to remember the visible parts[/COLOR] List<AvailablePart> visibleParts = new List<AvailablePart>(); for (int j = 0; j < partsToCheck.Count; j++) { AvailablePart AP = partsToCheck[j]; if (subCat.exclusionFilter.FilterCriteria.Invoke(AP)) // if visible visibleParts.Add(AP); // add to visible list } [COLOR=#008000] // remove all visible parts from the list to block[/COLOR] foreach (AvailablePart ap in visibleParts) partsToCheck.Remove(ap); } } [COLOR=#008000] // add the blocked parts to a hashset for later lookup[/COLOR] blackListedParts = new HashSet<string>(); foreach (AvailablePart ap in partsToCheck) blackListedParts.Add(ap.name); } parts that are not visible can then be filtered out by if (part.category == PartCategories.none && blackListedParts.Contains(part.name)) The faults I see in the above method would be that it assumes all parts will show up in the first category (Filter by Function by default) if they should be visible, or if they create a subcat before FE that duplicates the name of the FE subcat to be added it will assume the mod one to be the FE subcat and break horribly on the FE subcat. NOTE: findPartsToBlock has to be delayed significantly to ensure all categories are created. FE creates categories between 1 and 4 frames after the categorizer is initialised, the event used by most mods fires somewhere between 5 and 8 frames after categorizer init. The search needs to be delayed atleast that much

Oops, didn't update the KS download...

That means they are using the default value. You only need to include it if your parts do not want to use the defaults.

Version 2.1.4 Some compatibility changes for the addon linked above Fixed category checks when multiple were listed Split install structure into .cfgs and "plugin + icons" NOTE: users installing via. CKAN will probably have the typical filters disappear on them for a few hours due to the new install structure EDIT CKAN has caught up, to get previous behaviour you need "Filter Extensions - Plugin" and "Filter Extensions - Default Configuration"

1) Fuel switch is at the bottom of the custom UI (right at the bottom, defaults to: "STR(0) | Next Tank Setup") 2) Patched or just the 0.90 folder from the OP? If patched, logs. If not, drop the files from here on top of it

That's not going to be helped by the low sub/tran-sonic thrust of the rapiers. Get it up to 10-15km and then level off/dive slightly until you are above ~Mach 1.5. From there you may have to throttle back as the rapiers build up thrust The same as always. Area governs the flow / second, amount is just temporary storage required by KSP's resource system to function. Area may not factor into FAR's drag calculations since it does everything off part geometry.

Same place it always was, Squad just dropped the permanent link they had to it before so I had to specify it by name (stockIcon_fallback) EDIT If nothing else, this will serve as an amazing testing/bug hunting tool for FE. Adding multiple selection of part categories to the UI and oh look it broke. Turns out I'd been using the list of values (eg. "Pods,Engines") instead of individual sets (eg "Pods" or "Engines") for that one...