Crzyrndm

... Right. AvailablePart.title (somewhat misleading code on my part...)

part.title It's really that simple (KSP rule of thumb: name == internal ID, title == user level ID)

FlightGlobals.ActiveVessel is the players current vessel PS This doesn't sound like it needs to be in FixedUpdate, therefore you should be using Update (if it doesn't affect physics, avoid FixedUpdate)

Does the category right click bug/feature still exist in 1.1? It used to not close the existing category so you could select a filter from each category

logs please...

I think Fengist is on the correct path. My understanding now is that you have two seperate instances, one of the base class, and one of the extended class. The extended class inherits the default value of the base class (true) but that is a seperate instance of the "show" variable than the one in missionList. Static might work, but seems like it could introduce more complication than its worth (3+ windows). I would prefer to have a reference that could be used to say "extended.show = true". However, with all classes being instanced by KSPAddon, it makes that approach more than a little difficult (I prefer to have a root object in a scene that creates and calls functions in other classes for exactly this reason) Following example being my preferred approach [KSPAddon(...)] public class Root : MonoBehaviourExtended { public BaseClass baseInstance; public ExtendedClass exInstance; public void Start() { baseInstance = new BaseClass(); baseInstance.Start(); exInstance = new ExtendedClass(); exInstance.Start(); baseInstance.exList.add(exInstance); // give the base class knowledge of the extended class. I've used a list since it sounds like something I'd use more than one of } public void OnGUI() { baseInstance.OnGUI(); exInstance.OnGUI(); } } Another alternative being something very similar where baseclass is the root and creates the instance of the extended class. In short: Minimise use of KSPAddon where you need objects to know about each other.

Slight correction to your understanding of inheritance, the extended class is the base class with some more stuff wrapped around it. The functions, variables, and properties of the base class are still a part of the new extended class so "drawadmission" is completely owned by the extending class. There is no passing between two classes because you only have one (it just "inherits" the property and variable) Some basic notes Since you have a property to get/set drawadmission, it should really be protected or private instead of public (private => no other class can see it, protected => inheriting classes can see it, public => any class can use it. I would be using protected and skipping the property for inherited classes. ) The "AddMissionWindow" class above is very incomplete and doesn't help much. From what you've shown it should only be able to run once because there's nothing to set DrawAdmission true again. tl;dr I see no reason for the property access to break. I'm more inclined to believe there's a logic error around it thats preventing you resetting it from what you've shown here

New release up on github for purpose of CKAN indexing with 1.1.3 compatibility

Be aware with your elevation that it assumes that the ground is flat (ie. the flying vessel is relatively close to the grounded vessel). If you wanted the elevation with respect to the grounded vessel, it would be more accurate to find the angle between a vector pointing straight up, and one pointing to the active vessel Vector3 ToFlyingVect = (FlightGlobals.ActiveVessel.transform.position - this.vessel.transform.position).normalised; // A vector pointing toward the flying vessel with length 1 Vector3 UpVect = (this.vessel.transform.position - this.vessel.mainbody.transform.position).normalised; // A vector from the center of the current planet through the root part of your vessel with length 1 float elevation = 90 - Vector3.Angle(upVect, toFlyingVect); // 90 (vertical) less angle from vertical Bearing is a little more complex. We need a vector pointing north that is parallel to the ground at this.vessel, and a vector pointing towards the other vessel also parallel to the ground at this.vessel // using up and east (assumed direction of planetary rotation) I can calculate a north vector Vector3 UpVect = (this.vessel.transform.position - this.vessel.mainBody.position).normalized; Vector3 EastVect = this.vessel.mainBody.getRFrmVel(this.vessel.findWorldCenterOfMass()).normalized; Vector3 NorthVect = Vector3.Cross(EastVect, UpVect).normalized; // projecting a vector that points at the active vessel so its parallel with the ground Vector3 TargetVect = ActiveVessel.transform.position - this.vessel.transform.position; Vector3 SurfTargetVect = TargetVect - Vector3.Dot(UpVect, TargetVect) * UpVect; // removing the vertical component float heading = Vector3.Angle(SurfTargetVect, NorthVect); if (Math.Sign(Vector3.Dot(SurfTargetVect, EastVect)) < 0) { heading = 360 - heading; // westward headings become angles greater than 180 } I'm fairly confident I wrote this down all correctly, but if anyone spots an error...

Filter Extensions also uses PartModelPurchased successfully. Looking at that guard statement, it may only work as expected inside the editor but that shouldn't be an issue here

(If category created by FE) It shouldn't be visible if its not in any category under filter by function. (If category created by Stock) category = none I haven't seen any issues during testing today with 1.1.3, so no patching required (yet... )

Remove MFT temporarily. If that fixes it, make sure you are completely up to date there, otherwise I will investigate when I do get time.

Category type check goes for FuelTank/Fuel Tanks (and Pods, Engine/Engines, Control, Structural, Aero/Aerodynamics, Utility, Science, None) I'll check out the manufacturer filter when I get back, but it looks like it should work... (or if it doesn't, a while lot of other things shouldn't be working either) Post up an example and I can take a quick look to make sure there isn't something silly there (and it'll make a good test case when I can do so)

Wing mass is directly proportional to lifting power in stock aero. The same should be true for the stock wings (mass = 10% of lift coefficient for fixed wings, 20% for control surfaces). Possibly you have fuel in these wings? Otherwise example plane/logs/etc.

Are those parts from mods which have heir own categories *without* FE. If yes, then that's a failing in how SQUAD setup the search algorithim and there's not a lot I can do about it

You need to implement the IPartMassModifier interface. (currently commented out at the top of the wing class...)

I believe this was previously attributed to RF, so please confirm the issue remains without MFT (and that you have the latest version). If the issue persists, logs

I presume @Ziw was referring to using a KSPAddon to programatically add your data module to the root part of the vessel (ie. SortedShipList[0].Modules.Add(...);). Don't know if the fact it isn't in the prefab is going to cause issues when the flight vessel is created since I've never done anything of the like

Loading assuming nodes are in GameData but not PluginData (ie. preloaded by KSP): https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PresetManager.cs#L99 Loading direct from file (eg. files inside PluginData that aren't preloaded): https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/Settings.cs#L58-L60 Saving: https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/Settings.cs#L89-L91 Or: https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PresetManager.cs#L157

Should all be functional now. It helps when you reference the vessel name correctly, and it helps even more when you aren't loading from the wrong place

Well I guess the first thing to note is that PA was designed purely for atmospheric flight: It works best with a pitch closer to zero (something I'm very aware of and will revise at some point) This is a consequence of the primary control system being the very first thing I designed, and the bit that's not changed notably since the very first release of PA. I didn't know enough about how KSP/Unity functioned at that point to do it how I would now, and wasn't aware of the limitations that the system would experience to know that it should be done differently. Its primary method of changing heading is to roll into a turn and let aerodynamics do the rest. It's not at all suited to rocketry applications because how you do things with a plane is so totally different. You don't just roll into a turn, you can't just turn the engine off to slow down, etc., etc. MJ works exceptionally well in these situations, why reinvent the wheel when a suitable solution already exists. PS https://obsproject.com/index EDIT The reason pitch failed to work intermittently is probably because your vessel was very close to 90 degrees of bank at the time. By default PA minimises yaw angle and rotational speed aboout that axis to increase stability of the planes it flies. Almost irrespective of design, a plane is always least stable on that axis and a few degrees of deviation can lead to a loss of control (think ascent of a rocket and how going outside the prograde marker almost always leads to flips)

Part of that will be the auto vs. manual tuning bit I noted in that post. It does take a bit of knowledge/tweaking to make PA wok with many vessels, and there are a small number of cases I never did manage to get PA to fly quite how I'd like it to (primarily, not having a fit when the target changes without making the change glacially slowly). MJ on the other hand, knows approximately how your craft will behave and moderates itself on that. The very basic control system is still a PID controller, you just don't need to play with it. If we all wanted the same stuff... Is irrevocably tied into the control system of that mod. It's not doing vessel tuning in the same sense that PA/MJ do. Also a huge performance hog from what I've read. I'll have a poke around, I did make some significant changes to that section recently.

1) MJ operates on the same basis (PID controller(s)) as Pilot Assistant. PA just uses a few more of them (because 18 months ago I found that a single controller didn't give the smooth & precise behaviour I wanted) and is manually tuned (I prefer to have some interaction with the control setup, even if flight is automated) 2) Neither MJ (AFAIK) or PA interact directly with any part that controls vessel orientation. They just give control inputs to the vessel which are then interpreted appropriately by control surfaces/gimbals/RCS/reaction wheels.

Should be fixed now. I forgot to commit the version change to git

A different symmetry issue to the fat wing syndrome that was being caused by the -ve mirror scaling (the line I removed in the last commit since neither stock or FAR support it)? I can't find any mirroring issues with that gone