Shadowmage

And even fewer people actually file stuff on the tracker. (still waiting for that one to show up) File a bug report on one of the repositories, that will ensure that it doesn't get forgotten about, and infinitely increases the likelihood of it getting fixed. https://github.com/shadowmage45/KSPWheel/issues/24 Wouldn't be just dust/sounds (those are quite integrated into KSPWheel), but would be a complete overhaul/conversion of the stock parts to use KSPWheel. There is a patch set floating around somewhere that you can try if you want ( https://github.com/shadowmage45/KSPWheel/tree/master/GameDataDisabled/Patches/Stock ), but it hasn't been worked on in awhile, and I'm not sure if it was updated with either sound or dust.

[snip] The second best alternative would be to make your own textures that are 'stock-alike'. There are many guides on the forum of how to do stock-looking textures, and quite a few forum members have it down to a science (art form?).

My solution to long ejection burns -- start from a much higher orbit. You'll have a longer orbital period, and plenty of time to complete the burn. I think for a 1hr burn, you might want to try a 1000km (1,000,000m) circular orbit. I've had good luck with ~750km for 30-40m burns. You lose a bit of effiency/oberth... but it is better than missing the x-fer window or massive post-ejection correction burns.

I'm hoping to be able to put the wraps on the SC/pods recoloring support later this week/weekend and pack up the next release. Should also include a few other fixes from the past month, and a few feature enhancements (repackable parachutes). Will be holding off on releasing the upper-stage SRB for a bit, as there is still both code work and texturing work that needs to be done for those parts. I believe I have the code mostly working, but I'm sure it'll need a bit of cleanup/bugfixing/refinement. Yeah, still insanely busy at work (and working late most nights), so my free-time and motivation are... less than usual.

Thanks for the ping Sadly, @blackheart612 has stated that Airplane Plus is a 'single dependency' mod; as such, he has ruled out using/using/distributing KSPWheel as far as I know. As the stock wheel implementation/system does not support multiple wheel colliders within a single part... I don't see any good options for implementation of really large landing gear (split them up so each wheel is its own part?). Now if anyone else (or even @blackheart612) is interested in creating landing gear like that, I'm more than willing to offer assistance on how to get it all setup (modeling/transforms) and working in-game (configs) using KSPWheel. ... and now back to your regularly scheduled Airplane Plus thread....

Neither; that is a new and as-of-yet unreported bug. File it on the bug tracker please (otherwise I'll forget about it and it'll never get fixed)

Looks like I'm a couple 100 miles north of the path; so I might get a partial eclipse? Also.... (Upper-stage SRB nozzles with built-in RCS thrusters for roll/etc -- yes, the textures are.. not in place yet.... working on the plugin code to make it all work) As @blowfish stated, it isn't exactly a 'drop-in' solution. For every part that needs recoloring support added, you pretty much have to recreate the textures. Its more than just the mask texture -- you also have to setup your diffuse and specular textures properly, as well as split the AO off into its own separate texture. In short: probably more work than most people would want to invest; and that is just the texturing end. There is also a ton of plugin code needed to make it all work (load shaders, assign shaders to models, handle persistence of data, GUI code), as well as the corresponding configs to define all of that stuff (texture files, model and mesh names, etc).

Re: release -- Not really, too much stuff in-flux at the moment. But.... if you wanted the feature you could download the updated .dll from the dev branch. Can't guarantee it doesn't break other things, but at least the parachute stuff is working/tested I'm aiming to get the next release packed up/finished as soon as I can finish the recoloring work for the rest of the pods. Got the SC-C and SC-B done, and started on the SC-A. Since it obviously won't be this weekend, and I'm camping next weekend; seems like the earliest I could get the next release published would be ~2 weeks out.

Hmm.. I wonder what this 'Repack Chute' button does? Oh... heh...I guess it does what it says on the tin. (currently requires a lvl2 engineer in career mode, but can change to w/e level, or even a per-part config for repair skill needed; perhaps some can be repaired by anyone?)

While its not in stock, Kerbal Foundries has a side-deploying landing gear (for use in wings/etc). As it is one of the ALG parts, it is highly configurable for various setups.

Ehh... since nobody else bothered to post with info, I managed to kludge my way through a re-implementation of said shader. What it does: Clips the rendering bounds into a specific area based on screen-space. E.g. only render within a specific sub-window. Analogous to openGL scissor function Why it exists: As a very hacky workaround to only rendering editor-part-list part-icons within the bounds of the editor-part-list scroll area. Probably could have been handled more properly by a separate camera and render-texture. How it does it: Uses a couple of shader properties to setup the clip bounds. In the shader, checks if the output coordinate is within the desired bounds, else discards the fragment without rendering it. Links to working implementation -- note the explicit handling of directX vs. openGL screen-space coordinates in the shader. Without this the clip space will have inverted Y coordinates between the two rendering systems. https://github.com/shadowmage45/SSTULabs/blob/master/CustomShaders/SSTUMaskedIcon.shader Mods -- if reading, you can probably close this thread. It has served its purpose, and the information sought has been figured out.

Indeed, in KF steering has both high- and low- speed limits capable of being set in the part action window. 'Low' is the overall limiter (in case you just want to reduce max steering), while 'High' is an additional limiter that takes into account vessel speed (simulating a bit of a steering...uhh..linear curve).

Import the Mk1-2 pods .mu model file into blender (using the .mu import/export plugin). That -should- give you very exact measurements.

Hmm... Kerbal Foundries... why does that sound familiar? Man... I really seem to remember seeing somewhere that the mod was updated recently. Oh, wait.... that's right. Now I know why it seems familiar Re: sliding when landed -- yep, still a problem, though from my testing, less so than the stock wheels/legs. KF landing legs do include a 'lock suspension' that should remove the sliding, though it is still a problem with wheels/etc. Feel free to take discussion regarding that problem over to the KF or KSPWheel threads (or, more properly, open an issue ticket on it....what a concept!).

Adding more ratios for those models is not something I will be doing in the foreseeable future. Each new ratio (or perhaps 3-4 models) requires a new AO texture, which adds ~4mb of textures. That really starts to add up quickly. It also takes many hours to make up each of those models, more time to setup configs, etc. Additionally, the ratios are making less and less sense when used with SSTU, as they are only applicable for a specific sizes, and are useless when using non-stock-KSP-sized parts. TL;DR -- use the procedural fairing parts as adapters; that is one of the major reasons for their existence.