Crzyrndm

That would be the capacity. Except KSP fuels don't have an explicit units => volume conversion, the cfg density was wrong, and I'd used the wrong variable for wing thickness when I posted that (rubbish in => rubbish out...)

That's normally how I work, but not when I'm only halfway through implementing a new feature

The exception being thrown there during UpdateMaterials is a little concerning as that would prevent any update of the mesh geometry if it persisted (but if that was the case I'd expect the wings to look really funky...). I would start with a clean manual (not CKAN) install of this and FAR + dependencies to make sure its not a third mod interfering. If it persists, enable all the logging options from the window in the Space Center scene and upload the log from that, the craft file, and the module manager cache. If it doesn't persist then you have the fun job of working out what the conflict was

Just a guess (had a similar issue with PWings and FAR), those with the issue may have previously installed KIS through CKAN and CKAN often doesn't remove folders in Gamedata. Those folders then trip the MM needs statements Since it's a plugin that's causing the issues, you can make the check in C# instead using something like this or the [KSPAssemblyDependency(...)] attribute (probably a better way to do it, but I don't know of any examples...)

^^ Max Temps fixed on github ready for whenever next release is Also, the github version now gives the wings fuel carrying capabilities. The major advantage over the B9 version (currently. I intend to port this improvement to B9 as well once its tested) is the configurability. All tank setups come from a cfg instead of being hardcoded (want a LqdHydrogen wing? Just add a LqdHydrogen tank). Just note that the fuel carrying is still in testing, I only just got to the point of launching to the runway with fuel (and carrying capacity is extremely dubiously calculated atm...)

The little code comment is probably totally worthless now that I think about it (since it uses KSPs controller bindings while this seems to be something else entirely...). What's probably happening is that the SAS updates the ctrlstate before you do, and then even when manual override is false its output no longer exists. Simple fix, when you don't want control from this plugin, don't fiddle with the ctrlState at all (ie. if (manualOverride) UpdateCtrlState();)

You might want to check that manual override (still?) does what you expect it to. It might be easier to run your control inputs in PostAutoPilotUpdate and just not put anything through if input is not detected. public static bool IsNeutral(AxisBinding axis) { return axis.IsNeutral() && Math.Abs(axis.GetAxis()) < VesselSAS.controlDetectionThreshold; }

If you grab the .dll from my github, it includes a fix for the period/underscore switch now

I think I found your issue with the names @Helmut. If I'm right, every part which it doesn't work for has underscores in its name field (KSP pulled a fast one and did a little extra processing I didn't notice...). Any parts that failed that don't have underscores? PS It should work if you replace underscores with a period in the check. eg. Mk3.Akademy

Any chance you can provide some examples where it has failed. I can't think of any reason it shouldn't work for some parts so I'll need to replicate it myself

You are using the actual part name field (name = " " in the .cfg), not the ingame title? Also name type is an exact match, it'll only pick up one part. The title type uses the ingame name and works on partial matches so it may be more suited to what you're doing.

In the space centre scene, there is a rather non-descript black rectangular window like icon in the applauncher. There is a toggle in there to hide/show the unpurchased parts. Filter by Module is unaffected because it's still built by the stock system while Function is outright replaced by FE for maximum ease of use After 1.1, FE features are going to be heavily re-evaluated with changes really depending on how much KSP changes. I would like to bring back the removal functionality, but only if I can make a more stable implementation (and if it does come back, it will be much more tightly controlled...)

Possibly the extra categories are created by the USI mods rather than FE (either through code or an FE .cfg in the USI directory). If it's in code (quite likely), then FE is not able to do anything about them (It did at one point, but removing non-stock additions was a buggy nightmare...) As for removing USI parts from Utility, try basing the filtering on the folder, not the name @SUBCATEGORY[Utility] { @FILTER,* { CHECK { type = folder value = USI invert = true } } }

I just checked, the only joint modification these do is the breaking force/torque. The actual strength of the joint is not modified (should probably fix that), unless it's tied to that property. Original PWings is the same deal (no surprises there since this was largely lifted straight from the original...)

Right click will give you smaller steps There may be a conflict. There is some attachment point configuring as part of the resizing, but I don't know exactly how KJR works

I don't believe so but such a mod would be very very simple to make [KSPAddon(KSPAddon.Startup.Flight, false] AClass : MonoBehaviour { Update() { // repeat this for each autopilot mode if (Input.GetKeyDown(KeyCode)) // replace KeyCode with appropriate key FlightGlobals.ActiveVessel.Autopilot.SetMode(mode) // replace mode with appropriate mode } }

Note the wildcard (*) after the ModuleEngines in my HAS block. Module manager is working with the text files before KSP compiles them into parts, so you won't catch derived classes unless you specifically allow for that (ModuleEngines catches only ModuleEngines, ModuleEngines* catches any module that has a name starting with ModuleEngines. ie. ModuleEngines and ModuleEnginesFX) PS You should direct MM syntax questions to the MM thread, you'll get better answers faster because more people will see it

You won't get much/any further, landed vessels aren't completely physics simulated outside ~250m from the active vessel (the exact distance depends on which side of the limit you are approaching it from) which means you can't move them outside that radius

Module Manager is a mod built just for that purpose. You write patches in a text document with the .cfg extension and MM applies the changes to all the parts that you specify @PART[*]:HAS[@MODULE[ModuleEngines*]] // all parts that have a module where the module name field starts with "ModuleEngines" { MODULE { name = myModule } }

The fields you probably want are "EngineIgnited" and "allowRestart". The method "Shutdown()" (normally triggered from the right click menu) might be better to use than the ignited property

See what I'm doing here in Thermal Monitor. (should note that the same method applies to "Events")

First off, thank this guy. it wasn't any idea of mine, I just thought the concept was good (and it was all of 5 minutes to make). Second, I think a more advanced editor will spoil the plugin. One of its most attractive points is that it takes just one easy to understand input and no time at all to make use of (glance at KER end of stage TWR, set to percentage that gives desired end of stage TWR. Done).

Any plugin will inherit either directly or indirectly from Monobehaviour. PartModules, VesselModules, and ScenarioModules (as well as the KSPAddon type you're using) are just classes extending from Monobehaviour with some extra KSP interfacing. You really don't want to be working in fixed update at all for this. Fixed Update should be limited to anything physics related that needs to be updated every physics frame. Renaming a vessel is a one time event so you either want it running from Start() or in an event callback. Additionally, because you're going to need save file access (which a KSPAddon doesn't have), you'll want to shift to a ScenarioModule which gives you OnLoad and OnSave. [KSPScenario(ScenarioCreationOptions.AddToAllGames, new GameScenes[] { GameScenes.SPACECENTER, GameScenes.EDITOR })] // places you can launch from class VesselRenamer : ScenarioModule { public override void OnSave(ConfigNode node) { // save stuff } public override void OnLoad(ConfigNode node) { // load stuff } public void Start() { GameEvents.OnVesselRollout.Add(RenameVessel); } public void OnDestroy() { GameEvents.OnVesselRollout.Remove(RenameVessel); } public void RenameVessel(ShipConstruct sc) { // rename vessel if name is part of series } } ^^ Event based framework. I'm assuming OnRollout is called for each new vessel from the launching scene (not once flight starts. Mainly because it uses ShipConstruct, not vessel), just change the scene if its wrong

Pilot Assistant Development Currently making some plans for development leading into 1.1, if you have any issues or suggestions now is the time to throw them out. My plans so far: SSAS and the stock SAS tuner are being split off into separate mods living in my Plugin Workshop thread (it bugs me to no end that I have three totally different things in this one mod). Will still share data and systems where appropriate so there's no unnecessary extra overhead for having multiple installed. UI is not going to receive major attention until post KSP 1.1 (post 1.1 UI activity depends on how much work the shift requires in general and what, if any, additional script support for the new UI system is present) Current tuning automatically saved to each individual vessel, regardless of preset status Speaking of presets, I really think that system needs improving, but I'm not quite sure how. Maybe add support for blending multiple together based on alt/Q/mach, although I have no idea what the GUI to edit that would look like. ... (more time than plans at the moment )

The throttle limiter is the easy one which is like throttlePct from memory