Crzyrndm

The patch does two things: 1) Changes the category of all parts that would only end up in the subcat created by the relevant plugin to one FE doesn't filter out. 2) Removes those parts from displaying in the Utility subcat created by FE. This keeps the layout of parts in stock subcats exactly the same as when FE isn't installed, but allows those parts to appear in any other category created by FE. If you want to let them show in Utility as well, just remove the @SUBCATEGORY section

No problem. If anyone else does this as well just let me know (should only be for mods that add their own subcat to Filter by Function). I don't tend to see them due to limited time and very tight part mod selection (I have just 2 small part packs in my modded install) but it only takes a few minutes browsing the repository of the affected mod to whip up the required configs (although IR took a bit longer because their structure was a bit odd)

They will be in any category that wasn't made by FE (by module and tech with the distributed configs) and subcats made by other mods (this is why they're using the none category I assume, like real chutes they made their own) - - - Updated - - - This should fix the IR Rework and KIS parts not showing @SUBCATEGORY[Utility]:FOR[FilterExtension] { @FILTER,0 { CHECK { type = moduleName value = MuMechToggle, ModuleKISItem invert = true } } } @PART [*]:HAS[MODULE[@MuMechToggle]]:FOR[FilterExtension] { @category = Utility } @PART [*]:HAS[MODULE[@ModuleKISItem]]:FOR[FilterExtension] { @category = Utility }

No I didn't, and yes that is the issue (or rather, it's an intentional limitation). Fix will be included in the next release.

It's only on windows the KSP 64 bit .exe gets locked out, linux is fine

Even for non-atmospherics, all engine burns would have to be done inside that small zone and you'd still have to switch to your drone once it reached its target before it could take any actions. There are mods which alter the size of the physics zone, but that comes with it's own bag of surprises (maybe less so post KSP-1.0 as Squad are going to be making changes to it as well)

Making a single drone fly to a preset point: Relatively easy Making multiple drones fly to multiple preset points: Difficult Your problem is going to be the physics zone. Only the active vessel and vessels within 2.5km of it are actively simulated. Anything outside that zone is in a state known as "On Rails", which in essence means no forces are simulated except gravity, which treats the vessel as a single point. If while in this "On Rails" state, the atmospheric pressure would be >0.1, the vessel is instantly destroyed.

Logs please. I've not seen this one before. The only culprit I can think of is having two .dll's present (effects unknown, haven't exactly tested that) EDIT Stock CoL position now matches the geometry of the main wing (sweep, edges, and wing tip/root ratio had no effect on the position previously). NOTE: this also means they can create anhedral/dihedral stability effects properly in stock, and will probably increase wing flex (Lift force is no longer being exerted at wing root).

It's one way, the other being directly using OnGUI (the queue is just an array of Callbacks each called inside OnGUI). OnPostDraw has the advantage of syncing with KSP's show/hide UI without any extra effort (otherwise you have to listen to the show/hide events), but does suffer from style interaction and is probably more vulnerable to exceptions in others also using the same queue

Considering how the CoP moves, I'm wondering if the position FAR sees the trailing edge of the wing at is the back edge of the main/core wing section (so extending the trailing edge is moving the entire wing forward). I don't have a clue how to check that though, nvm fix it (EDIT: actually I may have a way to check that experimentally) EDIT Matching CoP positions with a stock board 1x4 PWing with 1m trailing edge 2x4 (approx.) stock wing 3x4 Pwing with 1m trailing edge 4x4 (approx.) stock wing

That's a bug in RF (MFT?). NathanKell has already commited a fix by the looks for real fuels (utilisation clamped to a minimum of 1%) I take it you're talking about when the CoP moved back rather than forward after removing the trailing edge? I'll take a look right after I get it updating in the editor again (I done goofed somewhere: FIXED) EDIT Center of Mass is not moving in a manner I would consider correct when it comes to the edges either (it doesn't move forward/back at all). This is very wierd

RF or MFT? Heh, didn't even know you had a repo (didn't see a link in the OP and the DL had source so I assumed there wasn't a public one at least ). Probably best to just keep it to a link though, the likelyhood of me not making actual functional changes at some point is rather low. EDIT Updated again, fixes the fuel not staying at the correct amount on reloading the flight scene and refilling on reverting to the editor. Geometry changes now retain the current % fuel rather than refilling completely (NOTE: I haven't tested the RF/MFT support yet, may prove troublesome as I just ripped large chunks of apparently unused fuel code out)

Fork updated with a fix for the nullref that was originally destroying my vessels. NRE occurred when Mirrored parts where hovering over an attach location (green highlight) and then mirroring was disabled before attaching. No other functional changes, this one was rather persistent... That's the only two exceptions I had logged encounters with dealt to, so I'll be back to vessel designing unless there's anything else. No problem at all. The mod is somewhat interesting to understand so bug hunting is not a total bore for a change This is the fix for the first issue (fuel setup wasn't being run for symmetry counterparts created on a re-attach) This is the fix for today's issue (disabling mirror apparently didn't clear the list of symmetry counterparts so there were null parts in the list) The remainder of the changes is mostly just me grouping like minded functions together and adding linebreaks between the if () and the action (single line if's just don't get read properly when I'm skimming over the code) Oh, and I worked out how the IPartSizeModifier interface works. It's completely bonkers (and utterly useless), the numbers you return are just added to the vessel dimensions (the input also appears to be the current vessel dimensions...), no checks for sanity or occlusion as far as I could tell (vessel size: -10m). You would need some way of telling how much of the part is not occluded and how much it changes the vessel dimensions in the first place before it would be of any use.

For anyone interested, I've forked this to start looking into some of the NRE's that are plaguing it (having 3 craft get NRE'd into oblivion is a great motivator...). So far I've only fixed this one which occurred when you gave a wing part fuel and then tried to reattach it with symmetry. The only other change is making the fuel tanks fill up after increasing the wing volume so they always default to being full (I found the carried volume not matching the max volume to be quite irritating). No promises that this won't cause other issues, I'm still getting my head around how this works.

To my knowledge, no, you can only add a bunch of your own monitoring code. Even if you could, there isn't much/any chance of it being simpler than the first snippet above. If the issue is making it configurable, yes, you're going to have to write your own save/load method to remember which KeyCode was needed.

If you want to tie it to a KSP binding (yaw left, brakes, etc.) instead of a specific key, you use if (GameSettings.*Action*.GetKeyDown()) // where action would probably be brakes in your case // do things

Write your own code to monitor for the keypress and toggle the action group // put this in Update if (Input.GetKeyDown(KeyCode.Key)) // put your KeyCode here { vessel.ActionGroups.ToggleGroup(KSPActionGroup.Brakes) }

Could be partially down to the cross-section ferram uses for modelling (which is optimised for supersonic flight IIRC), or you could just be not introducing enough separation (there needs to be A LOT of vertical separation) The stagger on this is a bit exaggerated, but it makes only a slight difference here. This is just duplicating the wing and sticking it on a girder segment. That is a 22% increase in lifting capability if I understand Cl correctly (~0.8 for single wing, ~0.5x2 for the biplane)

Sounds like you got it all worked out now . PA overrides input from pretty much everything actually, and with the version I just pushed to github, it should be smooth taking over from other sources as well. PS I finally got to the root of that heading control freaking out around the 0/360 boundary, so that's also fixed.

Instead of a wing loading, I'd go with the level flight AoA in the static analysis being reasonable

I would like to see something like this, but I think it lies fair and square in mod territory at this point Just maybe, you're doing something wierd here. Mass is measured in kg and is an inherent property of an object (and is the number we use in KSP and in everyday earth conversation). Weight is the force exerted on that object by gravity and is measured in Newtons (eg. you need 10kN of thrust to lift 1t off the surface of earth/kerbin). You're multiplying the mass of an object by Kerbin/Earth surface gravity and getting it's surface weight in Newtons and then trying to compare that with the mass of the earth equivalent. An unloaded F-16 weighs 85.8kN on the Earth's surface by your numbers (whether the engine weighing 9.8kN (1t mass) is appropriate I have no idea)

Only for very low speeds (low sub-sonic) do biplanes help IIRC. The interference with the airflow outweighs the increase in lifting area for anything that moves at KSP speeds

Those 4 are exposed by default, the altitude controller appears if you change from vertical speed control to altitude control, and the remaining three appear if you toggle on "Show Control Surfaces" under the options (they're hidden by default to make things a bit more manageable). +/- 100% control output in all cases. Limits are needed in Pilot Assistant to prevent it trying to do something silly like fly at 40 degrees AoA if you tell it to climb at 400m/s suddenly, but since the control outputs are already fixed, the limits are fixed (plus I can't actually affect limits on the stock SAS...) Small note here, the spreadsheet/graph is what you might call a perfect simulation. Flying a plane you have things that prevent that perfect result from happening like the mass/inertia of the vessel, aerodynamic forces, etc. I made it more for learning what each of the inputs was and a bit on the effects it has. So, coming back to your problem, with SAS on you get pitch oscillations about your target? Generally that is a response to high dynamic pressure increasing control authority and causing it to over-react. The simple solution is to slowly increase "scalar" until the oscillations dampen out. Scalar is your "I want everything to happen faster/slower" tool (increasing it slows things down)

Urgh, Github being wierd. I've fixed that...

If you just want tabs with a specific set of parts, it's stock. Click the arrows above the tab list to open advanced mode, click the grey button with the plus symbol, start adding parts to your own category. If you want something a bit more automated, Filter Extensions is your friend