Crzyrndm

Timewarp is basically just a wrapper on Unity's Time class with logic to handle timewarp. Details here: https://docs.unity3d.com/ScriptReference/Time.html deltaTime has absolutely no relation to physics calculations outside of FixedUpdate, except as a coincidence Both delta's are for the previously completed frame (gameplay / physics) and have no relation to the current or future frames. I'm of the understanding fixedDeltaTime should be invariant with the exception of phys warp (and according to Unity docs should be identical to deltaTime inside FixedUpdate calls) By the above, recording two fixed frames back (not just one) and calculating on the stored values in combination with fixedDeltaTime should give the correct answer (but unnecesary since fixed is invariant...) If that still appears to be incorrect, I'd be examining assumptions (are the axes assigned correctly, what units is the output in...) and/or computing your own angular acceleration from vessel.transform.rotation RE: floating origin velocity = part.Rigidbody.velocity + Krakensbane.GetFrameVelocity();

Just a thought, I wonder if you can get the value out of the UI sliders that display control output (in LateUpdate if need be)

There isn't one to my knowledge that can definitively cover all of the above. You can get the value post SAS by hooking into the vessel.OnPostAutopilotUpdate event chain, but that doesn't help with mods that also hook into that event.

You can remove it from any project post 1.2

Oops... (subcats for FbF got updated, but not the other category configs...)

Should be fixed now...

Several actually. // remove the part from the stock categories using the stock categorisation method @PART[*]:HAS[#manufacturer[xyz]]:NEEDS[FilterExtensions] // not entirely sure that's the correct syntax... { @category = none } @SUBCATEGORY[xyz] // again, not sure if this is correct... { @FILTER,* { CHECK { type = subcategory value = xyz invert = true } } } @PART[*]:HAS[#manufacturer[xyz]] { MODULE { name = PartModuleFilter subcategoriesToBlock = xyz //subcategoriesToAdd = } }

The obvious addition to the above, cache anything and everything you can when using reflection, particularly if you need to do something often. PartModule kosModule; Type kosModuleType; FieldInfo kosSharedField; public bool isCPUActive(object module) { if (kosModule == null) // only executed once per part { kosModule = this.kosModules[this.selectedPartIndex]; kosModuleType = kosModule.GetType(); kosSharedField = GetField("shared", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance); } // bare minimum required to be called multiple times var sharedObjects = kosSharedField.GetValue(kosModule); } I would take that even further and make anything I could static and only cache once per KSP instance (eg. type is often either fixed or has a very limited number of options).

part.AddThermalFlux(kilowatts) part.AddSkinThermalFlux(kilowatts) part.AddExposedThermalFlux(kilowatts) ModuleCoreHeat.AddEnergyToCore(double energy) You most likely only want the first of those, but for completeness... (As I understand it: skin / exposed are for aero/reentry, module core heat is for thermal generation where you want to be able to insulate it from the parts around and exhaust the majority direct to radiators)

Since we seem to be doing this already, All relevant procedural wings links are now in this thread On topic: Mirroring is an ongoing fight. Something isn't set up quite right and so KSP doesn't actually mirror those control surfaces at all and I am out of ideas at the moment (the last B9 update was aimed at fixing the shape not mirroring and that atleast appears to have been successful...)

Possibly relevant From 1.2 notes: "If you are setting a vessel's position and/or changing its orbit, call Vessel.IgnoreGForces(framecount) on the vessel for the number of frames that g forces should be ignored (try 1, then 2 if that doesn't work, etc). " The other thing would be that with rails warp, you probably need to be modifying orbital parameters somewhere. It's probably just putting it back where it was when it entered warp because physics doesn't apply

@Jiraiyah I need to check through FE's distributed configs and add some MM conditionals where there is overlap. Far less hassle to do any interop that way

Well that's new... Re: multiplier button, take a look at the scale parameter under base Re: persistence issues. I'm aware. Haven't quite worked out what I'm going to do about it yet

ModuleDockingNode myDockingModule = part.Modules.GetModule<ModuleDockingNode>(); ModuleDockingNode dockedTo = myDockingModule.otherNode; Part partDockedTo = dockedTo.part; I assume "otherNode" will be null when not docked to anything

Compiling against .NET 3.5?

You are using a part module if you're adding it through part configs or the class can trace it's inheritance heirachy through the PartModule class. In that case double vSpeed = vessel.verticalSpeed; // all part modules have a reference to the part and vessel they are part of If you're inheriting from Monobehaviour and using the KSPAddon attribute (a partless plugin), your snippet above will get the vSpeed of the vessel the player is currently controlling

https://github.com/Crzyrndm/pWingsMerged/releases There's fuel switching enabled on the wings that aren't a control surface, the dropdown which selects the fuel loadout is the affected ui element

If you're just querying stock modules or other classes you have a hard reference to ModuleParachute parachute = part.Modules.GetModule<ModuleParachute>(); if (parachute != null) { Debug.Log($"parachute deployment altitude is: {parachute.deployAltitude}"); } as for getting a Part reference from AvailablePart (the thing you normally have in the editor), you want partPrefab

To be clear, the static components of the second prefab containing the dropdown are parented fine, it's only the active/toggleable part of the dropdown that appears behind everything. Not even sure how you get the instance of that dropdown yet (whether it's just the template, or that gets instanced) // expected heirachy primary prefab / main window > secondary prefab >> dropdown button >>> dropdown selections // rendered over everything else // apparent heirachy dropdown selections // is drawn behind everything, only receives clicks when they're outside the main window rect, etc. primary prefab / main window > secondary prefab >> dropdown button

J is for the B9 window, these you modify by holding T to modify tip width/thickness, G to modify length and tip offset, and B to modify base width and thickness. While holding the key, move the mouse along the axis of the wing aligned to the property you wish to modify

For drawing the procedural wing window using the prefab based UI, I have a (unmodified) dropdown with the options filled in by the plugin based on the wing type selected. The current problem is that the dropdown selection is appearing behind the window it's part of and I can't see how the dropdown can be drawn prior to the window In game, The gameobject heirachy, The C# is here (before you ask why it's in two pieces, the fuel panel is a footer, there's normally a bunch of other stuff parented to MainPanel in between)

This is actually it's predecessor. You're thinking of the B9 version which you can get appropriate links for from my signature

Fork updated to fix mirroring behaviour of control surfaces (which just weren't mirroring...)

No longer an issue (and was only ever an issue if using Unity Editor to compile if I understood correctly)

Uh right, I was meant to do a release for that... (now up)