Crzyrndm

That'd probably be because most parts can just use the default one (which I can't remember off the top of my head)

https://github.com/Crzyrndm/B9-PWings-Fork/blob/master/GameData/B9_Aerospace_ProceduralWings/Parts/Aero_Wing_Procedural/wing_procedural_typeA.cfg#L42 Basically, a unit vector that tells KSP which axis to rotate the model around (and in this case, to turn it inside out by applying a negative scale factor)

@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[fuelSwitch]]] Probably (NOTE, it's advisable to ask these questions in the mod thread)

A few bug fixes (mainly, wings not initialising correctly on vessels that aren't the primary vessel coming into loaded range), probably not stuff everyone will see (although, may be more of a concern for BDA). If you use the unpackaged github stuff, you can also configure the fuel load outs to be stuff other than LF, Oxidiser, and mono prop

KER also does this, looks like the relevant function here

Time permitting, I'm planning on having another go at an editing UI once the dust has settled on 1.1 (meaning after all of my mods are fully functional and any new ones are settled in). FE has only one new feature planned for post-1.1 release (a part module for filtering purposes. At this stage I'm thinking I'll just keep it simple and have one field for inclusions and one for exclusions. That'll hopefully make things like adding bulkheads and working with difficult parts easier) So while we wait, anyone feel like suggesting a mockup UI for editing filters? My previous attempt is here, and quite frankly that UI is a complete mess (even ignoring the lack of polish, the layout just doesn't work for me...).

oh, if its just the names being wrong from ConfigNode.name, its probably because.name isn't actually the name field in a confignode (guessing here, never actually used the .name field). what you probably want is Debug.Log("TMS ORBITAL MECHANICS - Stargate Name " + stargateList[0].GetValue("name")); EDIT And that wont work because the vessel node doesn't have a name. Try: Debug.Log("TMS ORBITAL MECHANICS - Stargate Name " + stargateList[0].GetValue("description")); Debug.Log("TMS ORBITAL MECHANICS - Stargate Name " + stargateList[0].GetValue("ship"));

My first question would be: what does the node stargateList[0] look like? Print it to the log and you can see exactly what is / isn't there. The other thing would be what behaviour are you actually getting, vs. expecting EDIT Also, if you have a github (or similar) repository, it's much easier to read larger blocks of code vs. the small forum code blocks (for example: https://github.com/Crzyrndm/FilterExtension/blob/master/FilterExtension/Core.cs#L58-L69)

I would be looking through Real Plume to work out how they do it (EDIT looks like the plugin may actually be smokescreen)

There's your problem, PluginData is a special directory that KSP doesn't autoload on start. Move it out of there

Does it have to be your own plugin or will Filter Extensions suffice? It already adds a number of bulkhead profiles from a range of mods here (describes what parts go into each profile) and here (describes how to arrange the profiles in a category). The configs in the main download are rather extensive, but there's nothing preventing you from removing all the category definitions you dont need (and I have no issues with someone distributing a stripped down version if this is for a mod) If you do need to go the plugin route for w/e reason this (FE makes for a terrble example >.>) covers the basic requirements fairly well

This turned into a bit of a ramble combining thoughts as both an author and user, so reader beware... (NOTE: I use Github almost exclusively for mod hosting and rely on the forum for "spreading the word") Primarily I see alternative hosting solutions as just another place to download the mod. I provide a link to the forum thread and maintain any required documentation in one place, the place where I see it as actually possible for someone to stumble across without any prior knowledge of the mod. With discovery via curse (and kerbalstuff/spacedock) unlikely, I don't see the point in maintaining an extensive description. Now, if the UI and categorisation was such that you could actually find plugins other than Mechjeb, K(A/I)S, and KER via browsing, I would reconsider that stance. My major issue at the moment is that its annoyingly difficult to find plugins (this applied to KS as well). For example, I would look in command and control first for vessel control plugins like MJ, kOS, RPM, Pilot Assistant, Atmosphere Autopilot, ... (assuming they were all on curse, which I know not all are). Instead, I find every part pack that includes parts of that editor type with a scattering of plugins (at which point I would probably just hit google, which was much more interesting than searching curse. Particularly if I limit results to the forums). In short: Plugins are interesting (and we can use lots of them). Plugins are hard to find. Why should a plugin author use curse? (download speed is a non-issue for pure plugins since size is so small)

I would have said "bac9 is inactive and I have just continued fixing bugs". There was no handover per se (there's a reason I label the download as unofficial ;)) That's the one. Good to hear you got it working

If it's glitchy then I'd like to see logs, because it's meant to be fixing problems, not creating them. General update I have just committed (no release, testing only) a number of requested changes and fixes to github including the configurable fuel tankage and a unique folder (B9_Aerospace_ProceduralWings). If you're feeling a little daring, gates are open for bug reports

I prefer if (ActiveVessel.holdPhysics) return; ... I find FlightGlobals.ready sets true just a little too early in some cases (just have to be aware holdphysics goes true when using time warp)

Another must have from @nightingale. Grats on the release and Modding Mondays feature

That's down to me not including the alternative textures in the download (by accident. I completely forgot about them :/). I'll just quietly fix that for next time...

Make sure it's this download: https://github.com/Crzyrndm/B9-PWings-Fork/releases/tag/2.1 Other than that, what Nathan said

ugh, yea that ^^. Not exactly my favourite implementation

It is an IFS bug. IFS is setting part mass here, and telling KSP that the module itself weighs that amount again here (should use one or the other, not both). Got bitten with this one myself with B9PWings

The problem is that you're trying to initialise a value with something that isn't a constant. What you really want to do is constantly set the value of vSpeed to match the vessel speed, so you need to do that inside one of the functions that are called regularly by Unity (in this case, Update) public class ModuleStukaSiren : PartModule { double vspeed; public void Update() { vSpeed = vessel.srfSpeed } }

That was used prior to the update for 1.0 when the wing mass calculation was aligned with the stock version where mass is 10% of the lift coefficient which is only dependant on area.

That would require a plugin recompile since the mass is currently calculated based on a set of fixed factors

Dynamic Deflection v1.2.0 (the lazy update) --- Added a new module: ModuleDynamicGimbal - intended for use with the panther and other high gimbal jet engines, it varies the gimbal angle based on the current nominal thrust percentage. There is all sorts of issues with this since I basically ended up making a copy of the DD module and associated bits and pieces after KSP threw its toys out of the cot and decided it wouldn't load (so the toys got thrown right back...). Hopefully the oddities in the UI is the worst of the copy pasta issues.

Another option would be to go back to using MM, and then just have a small VesselModule which just checks if its a Kerbal, adds the module(s) if yes, and then destroys itself // blah blah, VM declarations... public void Awake() // Might have to wait until start, can't remember { Vessel v = GetComponent<Vessel>(); if (v.isEVA) v.rootPart.AddModules(); Destroy(this); }