Crzyrndm

And how am I supposed to help you...

Download from here: https://github.com/Crzyrndm/B9-PWings-Fork/releases Merge GameData folders like any other mod Play

part.Modules.OfType<ModuleEngines>().Count or is it length, I always forget which one is for arrays and which one is for the rest...

oh that's right, I didn't make any release. Sorry about that. Yes, the 1 .dll on the previous page will fix your issue

Still in firefighting mode edit @Svm420 I may have already done so. Multiple discharge resources is def supported (the default cfg has 2 after all), and I think the setting "dischargeTorque" in the config.xml file should create torque when using resources to discharge (I don't recall testing it though, so could be interesting)

Because apparently it wasn't obvious enough the first time... LOGS PLEASE.....

You don't have the latest version. If you find any like that I can revert icons easy enough. There was a few other odd things I had to fix in the zip I was given as well

I'm getting closer. The plugin effectively exploded (nothing worked, and I really do mean nothing) when I tried it in pre-release so I've been trying to stabilise my other mods before spending some proper debugging time with this one. Has taken a little longer than expected with B9PW and FE issues taking a bit of unanticipated work, but they seem to be fixed now so... (tl;dr I have a number of plugins to work through and something has to be at the back of the queue...)

Welp, I stand corrected

v1.10.4 of SSRW is up, fixing resource drain breaking and the invisible editor editable torque edit field...

Oops, forgot to make the editor bar visible in the editor...

Fix for the fuel volume is in 0.40.7, missing NOT in a safeguard creates mayhem again...

That's most likely the viewpoint that all those UI elements were drawn for. I doubt you'll find an equivalent in the new UI since it doesn't use cameras to create unique UI layers, or atleast not externally

Sounds like one of the 3 tools that was being used for UI prior to 1.1. What do you need it for?

Looks like a typo or something similar slipped through in all the texturing fuss. Now that that seems to be working I can pay attention to other things...

ModuleEnginesFX inherits ModuleEngines now, Multimode is an additional module that just handles switching between other modules(ie not an actual engine itself), and I'm not aware of a mod engine that is entirely from scratch. For Filter Extensions, I use this shorthand function here (actually a remnant from when FX was an entirely separate module). Even the warp drives, I believe, inherit off ModuleEngines

No info, no help... Thanks, will try a few things to see if can improve the situation You say that like ferram ever liked CKAN. As far as it not updating, poke the CKAN people. Most likely its pointing at bac9's releases not mine, but that's their problem to sort out as far as I'm concerned (also, I forgot to update my dev version to 1.1.2 so forgot to update the version file so it'll still be seen as incompatible >.>)

Because I did something silly apparently. Will take a look tonight. @Flashblade How far away do you have to get and what does this look like?

SSRW will get attention tonight. Working through things in order of which blows up more obviously currently To clarify completely, when FAR is installed the plugin is looking for the FAR control surface module "FARControllableSurface". When I installed KWR (although I only dropped the gamedata folder in, nothing else...?) and then opened the MMcache file after observing the errors (text editor, ModuleManage.ConfigCache), the part KWFin still had the stock module "ModuleControlSurface". Since the plugin couldn't find a valid control surface module it spat nullrefs everywhere (a problem in and of itself, but the root cause is incorrect part setup)

Ok, I think I fixed both the issue with disappearing bulkhead profiles and this random crash with the self destructing part module (blame stock for that one...). If I could get some verifications... Note to self, avoid PartModuleList.Contains(string moduleName / int id) like the plague

Fix for flag exceptions can be downloaded here (more things to fix prior to an actual release)

Anything particularly unusual about those parts? Stock control surfaces + FAR seems to be fine which makes this really odd because there shouldn't be anything about a part that should break it (currently waiting for KWR to download so I can test myself) EDIT @linuxgurugamer Seems like a missing MM patch, FAR is installed but I'm still only seeing the stock control surface module in the MM cache

I believe I've resolved this now so no worries about the regression (I believe PWings were the only mods using the -ve scaling in the first place, certainly the only one where control inputs would matter). It's actually kinda nice having it more standard since it has caused a few issues with FAR in the past. Would be nice if the part.mirrored property wasn't always false though... @01010101lzy See: https://github.com/Crzyrndm/B9-PWings-Fork/commit/801b3703e78c6d9a23b3dc684d6a33af6c0a4a42 Ignore the KSPField attribute at the top, it gets forced into symmetery counterparts and so is useless and has to be saved/loaded manually (I thought I removed the attribute...)

v0.40.6 is up, and I think I fixed both the inverted control surfaces and surface texturing together this time. Please make sure to do a clean install and be aware that wings will probably have to be reattached in the editor to know whether they are top/bottom correctly (ie. all new vessels should be ok, old ones may need to have their wings reassembled) PS Anyone still getting texturing issues after this? I'm fairly sure it was primarily caused by the obsolete shader loading method but...

Well spotted and completely correct. I wasn't aware that you couldn't share an instance of a material and everything works correctly when things are duplicated. Now just to find a rock solid solution for the reversed texturing and I can leave this alone for a while...