Starwaster

Ok so the whole solar system is the stock Kerbol system just larger to match RSS scales???

Cake and grief counseling will be made available upon return.

I'm confused as to how you're lifting even 1mm off the pad at 0.88. Let alone generating enough Gs to harm one hair on your Kerbal's heads. In short.... I got nothing.

Or increase update rate Sometimes I feel that 'winning' the space race damaged our space program. If the Russians had beat us to the moon, maybe we'd be on Mars by now. After the end of the moon missions, neither we or the Russians have left LEO with any manned missions. I hope someone sets foot on Mars in my lifetime. I don't even care much who it is anymore. I'd like it to be us, but I'll cheer just as loudly no matter what the nationality is of the first human to set foot on Mars is.

Multiple files adding different items do not affect each other at all. If they add the same thing then order might matters Or if one adds something that the other is checking for. Depends on how the config is constructed. Config nodes are processed in two passes btw. First pass is anything without the :Final tag. Second pass is for configs with the :Final tag.

What's your TWR???

By giving it two collision meshes leaving a gap where it needs to intersect with the other part.

lol I sent it to you earlier. Check your inbox.

that's only valid if PhysicsSignificance is boolean which it is not. IIRC its used by an enumerator but I might be misremembering. But it is not boolean. as with the majority of Squad parts TT70 uses the default as it has no breakingForce or breakingTorque (variables). You dont need to increase the multiplier especially not if its global. you need to increase the minimum value. Thats why I made that config file for (breakingForcefix). I still use it and I use KJR 2.0 and Galanes test craft is just fine for me. Struts and all.

It's possible, yes. It's probably also possible just to check and see what their graphics settings are at and change configuration based on that. That's assuming that the game graphics settings don't already affect the the reflection shader to begin with. (which it might not if its KSP specific settings vs stock Unity shader...)

I had it happen yesterday when cancelling a Maneuver Planner execution. Remote Tech is not installed.

Yeah, Duna is not a fun place to land. Though having a recreation of Curiosity's hypersonic chute is a big help, especially on RSS Duna (or 'Mars' if you prefer)

Wow that does not look at all safe to fly. I can't wait to try making one just like it!

Something like that could work but it would need to take into account speed.... otherwise you could end up with a high refresh rate when nothing's really changing? So share the config Better yet do it as a ModuleManager config so you don't even have to distribute part files. In addition to the answers given I would try playing around with the alpha channel and/or normal map. (bump map) But probably more alpha technique as using the normal map approach would probably leave it too lumpy looking. What you do is have a brushed looking texture using higher values of alpha combined with more brushed texture using lower values. Give something like that a try. Combine two such images and copy it into the alpha channel. I actually have something working right now using EmbeddedResources and StreamReader. But if I get some spare time today I'll hit you up in IRC and see if that's where you were going or if you had something else in mind. I'll see your crash and raise you MOAR BOOSTERS. (remember, when all you have is boosters, everything looks like gravity...)

You are 1000 years too early for my ninja posting skills.

it's in the SDHI pack

I use a modified version of the parachute IACBM with the chute stripped out. Of course that means no hatch access but I use the crew manifest plugin for that combined with an airlock.

missed this because I was replying when you were posting. yes it's possible, that's one of the things I was talking about earlier. Having the option to base update rate on how much of your orbit you've covered in a given period.

I have not been successful in getting KSP to load cube maps. I thought of that and actually experimented with it before implementing update rates. But the cube map texture didn't register in the log at all. I decided to put it off in favor of the current scheme. TBH it probably would not matter because you could set updateRate so high (maxInt) that it effectively only updates on scene change. The only time it would really contribute to lag is when the cameras update. It probably could but you would definitely need alpha to mask the parts you want less reflectivity on (or no reflectivity at all). Also unless Unity has a translucent shader that does reflections, you would have to choose one over the other. Or write a new shader. I have done some shader work in HLSL for Crysis but it's been while. Also after the next update when I fix the missing reflection shaders, I'm going to resume full work on Copernicus to get the first few parts out the door. That was what actually motivated me to update RP, was the desire to have reflective shaders for the MTV fuel tanks that didn't lag me.

If you use it on enough parts then it can affect performance. The original version (by Razchek) was realtime reflections. The way it works is by incorporating a camera into the part. Each frame the camera would update either all faces or a single face of the cubemap depending on how it was configured. If you're not familiar with a cube map, think of it like a skybox except that it's used for simulating reflections. This version however allows you to set an update rate. By default it's still real time which means every single frame the camera is updating the cube map. However if you set the variables realTimeReflections to false and updateRate to a positive value then it will only update periodically. The number of seconds between updates is whatever you set updateRate to. When I say seconds I'm referring to game seconds and not real time seconds. The reason I did that is because the frequency with which the scenery changes is dependent on the passage of game time as your ship orbits around a planet. In a later update I'll think about maybe basing it on how many degrees (or would radians be better?) you've passed through your orbit as that is a truer indicator of how much your environment has changed visibly. When testing, I find that a value of 300 seconds (5 minutes) works well. When set up that way performance is hardly impaired at all. In addition to the update rate, the camera will fully update automatically every time the scene changes. So even if you were to use hyperedit to move your ship from Kerbin to Duna, the cubemap texture will update. Also, as far as future updates, I'm working on an update to restore the missing reflection shaders. Originally there were a variety of reflection based shaders that were actually stock Unity3D shaders that KSP does not use. Starting in 0.23 however, most of those were removed. Only VertexLit (fastest but least realistic) and Bumped Diffuse reflection shaders remain. Specular reflective shaders were missing. The next version should have those restored by incorporating the shaders directly into the plugin.

duplicate post...

looks good!

You could enable surface attachment in the part file easily enough but you'd have to police yourself and not try to attach things where the inflatable part is because they won't animate with the inflation. With Bad Thingsâ„¢ possibly happening if you do. Maybe. I think this would do it.... haven't verified and I sometimes mix up which is which attachRules = 1,0,1,1,0

Currently none, control from here wont work until control transforms are in place on the model and minor changes made to the part file.

I abandoned them a long time ago but try strutting them to the orbiter. SHORT struts. Only long enough to reach the nearest orbiter surface.