Crzyrndm

v1.11.9 is a quick fix for things completely breaking. I haven't actually fixed the problem though, just shoved it under a rug for when I have some time to deal with it No hope of tracking that down without a full log (There's a very good chance the .update error is only a symptom of the thing that needs fixing)

Reproduction successful, bug squishing after work tonight

It would appear these have developed fat mirrored wing syndrome when used with FAR. ferram4 has fixed this before, so I guess w/e he changed in the latest version didn't only affect the B9 PWings PWings: Unrestricted dimensions (whether that is a good or bad thing I don't really want to weigh in on.) Simplicity B9 PWings Appearance customisation Granular shape customisation Repeatability Fueled

The next time this occurs to anyone, could you please get a screenshot with as many PID fields visible as possible (options => show control surfaces, show limits => open them all up, maximise the drag size, etc.). Fingers crossed that it's what I think it is

And do you have a log file from when this happened?

Try with this version. There was a small error in the setpoint smoothing logic which I think was causing your issue

I believe I've finally managed to track down the cause of the wings not being reloaded correctly. Download is here, overwrite the .dll in the plugins folder with it Logs...

SUBCATEGORY { name = [COLOR=#ff0000]<the name of the category>[/COLOR] icon = [COLOR=#ff0000]<the name of your icon file>[/COLOR] FILTER { CHECK { type = profile value = [COLOR=#ff0000]<the profile id used on the part>[/COLOR] } } } @CATEGORY[Filter?by?Cross-Section?Profile] { @SUBCATEGORIES { list = 26,[COLOR=#ff0000]<name of your subcategory>[/COLOR] } } If you want to change the subcategory ordering, the category is in Configs\Default\StockCategories.cfg

There is a mesh on the end panels/frames identical to all the other surfaces, just the end pieces (the ignored sections in the above picture) are the only parts that also have colliders (used for part attachment) hence why I was suggesting that as a possible cause of the issue. On further investigation, this doesn't appear to be the issue at hand. With colliders removed the end frames are still being ignored.

@ferram4 If it helps, the voxels aren't being created on the faces that have a MeshCollider attached (The wings use the mesh to create the voxels since the collider is incomplete) @PART[B9_Aero_Wing_Procedural*]:AFTER[FerramAerospaceResearch] { @MODULE[GeometryPartModule] { %forceUseMeshes = True } }

It gets called in flight (used for dumping info to the log in the above case). Editor only functions are hidden behind a HighLogic.LoadedSceneIsEditor check. The only way? Probably not but I don't know of any others off the top of my head.

If you have a module on the part in question, OnMouseOver is called continuously while the part is highlighted

Because "safe... ish" depends a whole lot on the flight behaviours of the plane. From what you're describing, I would guess that the plane has a very strong nose down tendency (a lot of pitch up trim in level flight) at that speed/altitude and the required level of trim isn't getting passed through the setpoint change in full. Would you mind putting the craft file somewhere? There might be a bug involved or it could just be one of those planes that doesn't like the defaults and it can be difficult to tell the difference.

It will keep that heading. You can also switch between active vessels using the numbers on the main panel, so you don't even need to be in control of the other vessel to activate PA functionality

By what is possibly a bug in Squads code, that already exists. 1) Select your first subcategory 2) Right Click on additional categories and subcategories to overlay more The subcategory list can get very long if you need more than two categories though

Saturatable Reaction Wheels v1.10.2 with torque throttle field released

I haven't been able to replicate the error. Could I get a full log and any other possibly relevant information

Is this the main vessel entering timewarp or a secondary vessel leaving physics range?

Can't do anything without atleast a log...

Adding "strut" would only work if the leg uses the Firespitter animation module as well. I'll need to check the .cfg when I get the chance later to advise how best to add them. This is a stock issue with nothing to do with FE. I can't fix things I didn't break

So 1.11.7 still jitters? (*Insert annoyed muttering*)

My apologies for the delay on this one, I've been out for a few weeks Pilot Assistant v1.11.7 Fixing the jittering EVA (Mk2)

It's an oversight in the label. For the other control modes, it is actually angle of attack. When the mode is pitch control is it meant to read pitch...

The GameSettings class has all the keybindings in it by action (eg. Gamesettings.PITCH_DOWN.GetKey() to see if the user is currently holding the pitch down key)

Contains exists, but has the limitation of being an exact match (Contains("ModuleEngines") won't find ModuleEnginesFX or other derivatives but FindModulesImplementing<ModuleEngines>() will)