Starwaster

It doesnt matter too much but it depends on what specific reflective shader you configure the plugin for. If you're going for bumped specular then make sure the original shader you set the part up with has a diffuse map with alpha (controls reflective strength) and normal map. I'm noticing problems still with some of the other reflective shaders such as Bumped Parallax which makes parts look translucent and I dont know why. So best to stick with diffuse, bumped or bumped specular reflective shaders when configuring the plugin.

That's not a number.

Download updated. 10m tank translucency eliminated. Additional tank textures. Firespitter Texture Switcher enabled.

These shots are bad examples because of the high amount of reflectivity, but main texture replacement works fine with FSTextureSwitcher when I tried it. I don't know what else to tell you. (first picture texture is plain. second is more textured) Depends on the shader. In specular shaders it controls the strength of specularity. Or masks it off entirely. Take for example a texture that's meant to have letters painted onto a fuel tank. Copy the main texture over to the alpha channel (which will desaturate it in the process). Maybe invert it. Adjust contrast. And suddenly your fuel tank is a little less flat and more painted on. Or use it on shiny surfaces that are meant to appear dirty. Shiny parts could be white and dirty parts dark gray or black. In general, use it as a mask.

"Let's take the fort!"

Is it a nuclear stage? try ammonia. That's why Discovery still had fuel in 2010

sadly. I had a hell of a time with it and the Munox parts. Wild cards didn't help back then either.

what was your Available RCS delta V? also.... docking ships wobbling and oscillating when they get close... you sure that wasnt just the magnets kicking in?

OOooooooh ho..... I think I just realized what the gel comment is about. The 10 meter tank looks a little translucent. Which is strange because the other three don't and they all use the same textures and the same model.... sigh, I think I know why.

No, node size does increase past three. However, the extra joints created invisibly do not number more than three. at least not that I've seen and I've tested up to size 24 nodes. DO NOT TRY THAT AT HOME! at least up to size 8 is ok and I use that on my 10m parts but size 24 seems to cause weird physics issues so dont mKe any nodes that large. unless you like watching your SRBs oscillate in and out of of your core stage as though on rubber bands. in which case be my guest those joints (introduced only in this latest update) exist to stiffen connections and reduce wobbliness When you see people saying that it doesnt work, and that rockets are just as wobbly they're probably using parts that dont have attach nodes sufficiently large enough to take advantage of the new system. I've built some monsters with no KJR and theyre pretty solid.

blackheart, you may need to reevaluate how you're setting up your textures or the FSTextureSwitch module. I am successfully able to switch textures. Or at least normal maps. I havent actually tried switching the main texture because I ddidnt have any suitable to test with. (was testing it out on my Copernicus droptank. so thanks for spurring me to test this because now I can allow for texure switching on ypthe droptank)

I only use a single connection and docking node on each of tank and truss. no other has ever proven necessary in my testing and keep in mind these are 10 meter parts we are talking about. (10m ID on the truss) No struts on the tank or truss either. The attach node size is 8. (in 0.23.5, additional attach joints are created based on node size. It seems to max at 3 but each joint also has breakForce /breakTorque that continues to scale up as the node size increases even past 3. based on emperical observation using a plugin to provide feedback) yes, multiple docking ports are possible. it requires one ModuleDockingPort for each plus a uniquely named transform for each. I've also experimented with giving each one their own unique control reference and I've had them share a single control reference (set in the center of the cluster of docking transforms but on their shared common plane) typing on ipad so ifnyou require fuether details it will have to wait until I'm on my PC

If you make the drop tank stack mountable, with the attachment node on the side, another attachment node on the inside of the truss then it will have a much stiffer connection with little to no movement. Assuming you give the attachment nodes sufficient size. (1 * (diameter / 2.5)) (rounded up). Put a ModuleDecouple on the truss with its explosiveNodeID set to the node the tank attaches to. Or, on mine I actually gave it a docking node instead of a decoupler to prevent its accidental staging. And to make the drop tank and truss docking compatible without additional parts. (that requires additional transforms on both the tank and the truss for the control reference and docking port orientation)

I want you to try something. Try to switch texture on something that is reflective. Assume that it worked even if you didn't see anything happen. Launch. Then come back here and tell me if the texture at launch is what you expected it to have been switched to. Edit: Some clarification. Be sure you are switching it in the VAB / SPH before launch. Do not try to switch after launch. Switch in VAB, then launch.

There seems to be some miscommunications. lets go over some basics: reflectivity is not a texture, it is a shader. if you apply it to something, that something will always be reflective no matter what the texure is but masked by the texure's alpha channel. the plugin exercises little control over the texures themselves. it doesn't do anything to the base texture or the normal texture so it shouldnt be preventing texure changes unless the shader has to be a ksp shader but I'm unaware of such limitations. I cant say more without knowing a lot more specifics about what you tried to change including whether you tried to change the normal texture and whether any aspect of the texture change succeeded at all (ie did main texture change at all? did normal change at all? were there any errors at all) just telling me you think its not compatible without providing some details, I cant do much except shrug. then you say it shouldnt be a problem because alpha works.... what?

I'm not sure it makes sense that it would be compatible. Are you trying to force a texture change to something non-reflective? Or just trying to switch texture itself? Is the normal map being changed too? Are there logged errors?

sometimes I feel like I'm in groundhogs day. A tech supporty sort of groundhogs day...

shouldn't be too hard.

btw, re the click bug, one thing I think is worth looking into is resetting the space center camera. theree's a function for doing so on the class. since at some point the bug corrects itself after entering and exiting, I figure resetting must be involved...

that shouldnt happen. if it's true then it's a bug because DREC treats deployed and partially deployed chutes as unshielded. they should then burn fairly quickly if youve got a reentry situation happening Edit: eh wait... that's just the DREC side of things. I see what you're saying.... would have to have code RC side setting max temp depending on deploy condition, is that what you mean?

I request the option to reduce the quantity of logged messages, to restrict them to actual failure errors. easiest way would be via config file.

Stock drag isn't good enough for you to flare the nose up to slow down properly. You need FAR for that. (not sure if to this day any decent FAR configs exist for the wings for proper compatibility) However, there's also Real Chute and there's a small stack point nestled in with the main engines that you could mount a cone or stack chute on. Configure the chute as a drag chute set to deploy on ground contact. With the chute thus configured there is no need for you to arm it or deploy it; it will go off as soon as you touch down so you can concentrate on flying and landing.

Search a few pages back; this popped up before along with suggestions and probable cause. IIRC it was some kind of known issue interaction with another mod.

Wow really? I don't know what time it is where you are but it's 6:30am here and you're bumping after only half an hour? That's pretty rude. If it's a Real Chute radial then try this MM config @PART[RC_radial] { MODULE { name = ModuleAeroReentry adjustCollider = -0.015 } }

If you have clicked on any MJ window then most keyboard commands will not work unless you click outside that window.