Crzyrndm

The same issue is present in the base pack, my suspicion (haven't had a chance to test) is that it's the negative scaling of mirrored parts that's causing this and that is no longer supported in the stock implementation of control surfaces. Only other thing I can think of is that the rotation axis is wrong now (because they pitch for roll and roll for pitch...) which will require messing around in unity and exporting with the new Part tools. PS When I briefly tested this, it appeared to be visual only with the plane still pitching up with minimal roll (and rolling instead of pitching) PPS Unlikely to be caused by the plugin itself, there is nothing in there that deals with control inputs

Don't suppose that would be related to how it was being called with atleast two different input values over 4 calls each resize in 1.0.x (? Probably..., can't remember exactly which version I looked at it and then decided it was bonkers) and/or the negative vessel sizes... Anyway just to make sure I understand this, can you confirm when you say rendered size that is the actual size of the visible mesh for that part instance. Then the (un)staged responses are still the prefab diffs?

That would be because I've not published a working version until now. Testing versions can be grabbed from Github if you're so inclined Be aware you are using a development version that is not completely tested and still doesn't have any "new" features yet. If you see a subcategory that is not working as expected, I would appreciate a bug report (bug report requires a log, MM cache, subcat and category definitions, and a description of expected behaviour vs actual behaviour. Incomplete reports will be ignored) Please log all reports to Github

I have for a very basic application, converted my SRB thrust limiting module over to it and it works ok (well, once I realised that time = 0 is the end of the burn...). Do note that I haven't actually tested that code with an SRB already using a thrust curve, so I'm waiting for something wierd and wonderful to pop out there

Working is a very relative term. That "working" was just that the plugin compiled, from memory the wings were completely broken (couldn't be selected once added to the craft)

Just feel the motivation pouring off it...

erps, .FirstOrDefault() is what you want, and yea a null check in case there isn't one present

Aya_Solar_Test myModule = solarPanel.part.Modules.OfType<AYA_Solar_Test>()[0]; Assuming your module is always on the same part as the solar panel

That's just saying there needs to be a yield statement in the function (if there isn't, you'll get that indefinite freeze :P) while(/*extending*/) yield return new WaitForSeconds(1.0);

Yes. I was just getting a reference to work with because I wasn't looking at how you'd done it. You can get that reference however you like // inside the extend loop // existing code StartCoroutine(checkState(panel)); // one for each panel we're extending // end loop // and the check state function IEnumerator checkState(ModuleDeployableSolarPanel panel) { while (panel.panelState...) // change button visibility on this panel }

1) You need to use the first method. Your class is not a solar panel, it operates on objects that are solar panels 2) The "StartCoroutine" and second function in my first answer is extremely important. The structure you have there will freeze the game indefinitely because KSP can't do anything while you're in that while loop. When a Coroutine "yields", the function gets paused and lets KSP continue until some condition is met (the 1 second time period in my example) and then it unpauses the function again (repeat until it reaches the end of the function).

Module is one of the things (Part Modules...) you just called extend on, probably the one on the same part as your module. Using solar panels as an example // if your module is running alongside the solar panel module (extends PartModule) // get a solar panel module to work on ModuleDeployableSolarPanel solarPanel = part.Modules.OfType<ModuleDeployableSolarPanel>().FirstOrDefault(); if (solarPanel == null) return; // incase we don't find any (which is stupid, but w/e) // wait for it to finish extending while (solarPanel.panelState == ModuleDeployableSolarPanel.panelStates.Extending) // blah blah blah... Much easier if you are already running inside the solar panel though because the solarPanel reference above is the object running the code. Objects can access their own properties without all the fuss // if your module extends ModuleDeployableSolarPanel while (panelState == panelStates.Extending) // blah

void ExtendAll() { // stuff StartCoroutine(waitForExtended()); } System.Collections.IEnumerator waitForExtended() { while (module.State != extended) // replace with actual state checks obviously... yield return new WaitForSeconds(1.0); // check once per second whether the tate change has finished // set retract event visible } If it doesn't have an event, you can always just poll it until it is where you want it

That was removed in the current commit (was me trying to track down some errors, wasn't meant to be committed). The problems are a lot more insidious than just some leftover logging, There are a rather large number of subcategories that should be showing up that aren't (because they're being removed because they have no parts which shouldn't be the case). I haven't yet had the time to track down the culprit(s)

will investigate, might be an incompatibility with some of the other plugins RO uses

Slower actuator speeds just mean retuning the lower level controllers if required. I can always add a :NEEDS[FerramAerospaceResearch] to the defaults if they get too different Dynamic Deflection. It exists to get around exactly this problem Not in the current state. That would end up with no derivative control if you did that right at the moment. Adjusting it for continuous input shouldn't be an issue though

Under altitude, set the limit parameter to the climb rate you want (to see the limit parameters, click on the "L" toggle at the top of the window). Yes its terrible, but that's just how it happens at the moment The UI is not my favourite bit of this mod and.I've been planning a complete rehash for quite a while now (but with 1.1 being the UI overhaul it was a wait and see thing)

I am, slowly (there's actually a 1.1 compile on Github, I just broke a few things to get that far). I'm definitely not not working on things because of difficulty or because of repeated builds, it's just constraints on my time currently are much tighter than I need to properly work on the mods I maintain

Bug reports can wait till after the plugin is updated please.

ConfigNode[] nodes = GameDatabase.Instance.GetConfigNodes("MyModule"); Example usage: https://github.com/Crzyrndm/Pilot-Assistant/blob/master/PilotAssistant/PresetManager.cs#L104

I haven't even DL'd 1.1 myself yet

Testing versions may start surfacing on github this weekend depending on how busy I am and how much breakage is present but ^^ is my official modding stance currently

It's a tweakable everything addition (not stock) hence why it isn't a part of SSRW currently. I was intending to add it at some point in the past, but it would appear I got a little distracted and it never made it. Added to the 1.1 update feature list

To add some code examples: // inheriting from partModule public class SolarSwitch : PartModule { [KSPEvent (/* fill in params here to give it a UI name, select when it's active (flight/editor), etc. */)] public void OpenAll() { // outer loop is over vessel.parts to get each part on the vessel // inner loop is over p.Modules where p is the part selected in the outer loop // ModuleDeployableSolarPanel is the type you're looking for and it has functions "Extend" and "Retract" } }

The stockalike one is here: https://github.com/Crzyrndm/FilterExtension/blob/master/GameData/000_FilterExtensions%20Configs/SubCategories_Stock.cfg#L29-L42 If you mean the subcategories that go into the engines category, those are generated each run based on what engine parts are installed. They look like: SUBCATEGORY { // standard name/icon/options stuff here FILTER { // must have <prop_1> as a propellant CHECK { type = propellant value = <prop_1> } // must have <prop_2> as a propellant CHECK { type = propellant value = <prop_2> } // must not have any propellants other than <prop_1> or <prop_2> CHECK { type = propellant value = <prop_1>,<prop_2> invert = true contains = false } } } One check per propellant, plus one more to ensure an exact match. Also, although the subcategories are procedurally generated, you can still use them by name in other categories and "subcategory" checks. No need to duplicate