Lunaran

press f3 presssss efff threeeeee

I'd hate to be the PR manager for the Kerbal space program. "Landing legs operated perfectly but we put them on upside down, so, uh. Questions?"

A little home improvement: I'm not playing with FAR, so there's no aerodynamic reason I couldn't have launched with all those KAS containers just stuck on the outside already, but it's just fun to have work to do in space. I wound up with more work to do than I'd expected. The delivery stage for what I just now decided to call the Crow's Nest module had a probe core, battery, and RemoteTech antenna so I could deorbit it after delivery, but I underestimated d/V requirements to get to a 250km orbit. Frank and Camski had to take the Albion crew shuttle, rendezvous with it, bring it back and dock both, leaving Burlong all alone aboard the station. Then it was refuel, swap Camski for Burlong, grab some Pipe Ends that I'm now glad I decided to pack, barnacle them onto the bottom of the Albion somewhere, then rendezvous again with the empty delivery stage to pump enough fuel into it that it could deorbit itself as planned. Not a bad afternoon of distraction for a save I had planned on using for putting a flag on every world.

Typing this in the form of a question made me figure out how to answer it (yay for rubber duck programming) so I'll leave it here in the form of a Hot Tip so that it might help someone else out in the future: I had registered a delegate to GameEvents.onEditorShipModified to call that code in the first place, thus (apparently) creating a reference that prevented the partModule from being destroyed along with the part, thus leaving leftover gameObject-less partmodules in memory somewhere complaining about not having a gameobject to access every time I made another change in the editor. Properly unregistering the event in OnDestroy() fixed it up good. thus ends today's lesson.

Here's a bit more detail on why everyone is saying what they're saying: When you have a triad of docking ports approaching another triad of docking ports, every frame the game is checking one at a time. They get closer and closer, and when a facing pair are close enough, it starts to apply magnetic force to both of them to help encourage them together. When it finds that a pair of them is close enough to be within a certain tolerance, they're snapped together and the vessels are joined. The game then stops caring about the other ones in the same way, immediately, during that frame. They're not on separate vessels anymore so clearly you aren't docking them, so why test them? Docking ports on the same vessel can be joined, in an operation that's a different code path than above. The tolerance for joinder is a lot more strict - it has to be pretty much exact. The reason for this is that this code path only really exists for two docking ports that have been already placed face-to-face in the VAB, to catch them at vessel initialization and make sure that their state is changed to "docked" and not "just welded together like any old fuel tanks." This means that when you bring your fancy triple-clampotrons together, in order to get all three to lock together and form a physical joint, you have to be VAB-snap-precise. This takes many many tries, and 19 times out of 20 you're gonna get one docked pair and two that are noticeably sliiiightly cockeyed. Once that first pair is joined and the vessels dock officially, no 'roll' happens around that axis any longer, so you are stuck with whatever slight misalignment you still had at the time on the other two. It's still possible, though. One good tip is to point your ships normal/antinormal (north/south) so that your docking adapters are meeting up and down. This will eliminate the need to always be gently compensating for (ie, fighting) the libration effect of the rotating reference frame. But it still takes forever.

Thought about it, but a helmetless IVA in that capsule seems ... wrong.

I used some software to rip a ton of models out of the game. I wanted to look at the 3-seat MK1-2 pod and explore what a clean, stock-alike remake would look like with the hatch aligned with the ladders on every other part and the 3 kerbals all sitting side by side the way God and James Webb intended. Why aren't they already side by side, I asked? Why does one guy have to sit down in the basement? I then learned that Kerbals don't sit side by side in the existing Mk1-2 pod because their helmets are too big. :| This is also why IVA visibility out of each forward rendezvous window blows so hard - the pod only tapers by 50% from one end to the other, and it's just not possible to seat a Kerbal far enough to one side that his he can face straight out that window without his helmet protruding right out of the craft.

On real planes: helps ensure that the wing generates lift all the way out to the tip by providing a little 'wall' to block wingtip vortices from forming. In KSP: looks cool. [ http://en.wikipedia.org/wiki/Wingtip_device ]

Do you have any mirrored or backwards UVs on your model? An inverted UV space will lead to an inverted tangent frame, which causes normals to be interpreted backwards by the shader.

T-shirts with stuff on the back are the dad-jokes of clothing.

Mercury would make a nice moon for Venus. Its oddly strong magnetic field would help to make up for Venus' total lack of one, and if you put it in a tight orbit with a lot of spin, tidal forces would eventually move it to a more reasonably moony orbit while transferring enough angular momentum to Venus to give it something resembling a day-night cycle. As long as we're driving Mercury around like a school bus and taking the long view, why not take it a step further and test the Theia hypothesis? Smack it right into Venus at a steep angle. Get that disco ball spinning extra-fast. Throw a debris ring into orbit and let a new moon form. See if an inner-mantle dynamo forms the way we think it would. Liquify its insides to within a few dozen miles of the surface, and fragment the remaining crust to kickstart plate tectonics and a carbon cycle. Then see what the atmosphere is like, and go from there. I mean, you know, priorities.

Wondering what the benefits of a Joolian slingshot would be for saving dV ... it would certainly save you that 35 year round trip.

The only resource in KSP that is still unlimited is time: you can send Jeb anywhere cheaply if you're willing to wait decades for slingshots and encounters, and he'll spend those decades happily strapped in his pod. Life support mods all go about limiting that resource in various ways, some with more complexity than others, but the core change to the game is still nothing more than imposing a time limit on Kerbals. You can mitigate it and stretch your limit by trading weight or electricity or other resources, but mechanically you don't need more than one green resource bar for it, because the bar is just a timer. The main strength of snacks is still that it's one resource, period. At least, the thing I like about Snacks is that it's just one resource.

A great way to save launch costs: SRBs. Put a pod on top of an LVT45 and tall fuel tank, then throw that away and put it on top of a Rockomax BACC SRB instead. Note how much cheaper it is.

I tried making an angled torus-part once also and had the same trouble. Attaching something with an angled attachment node is really really finicky, and I couldn't get it to work correctly at all without changing-the-root-part shenanigans. I never released it. I guess while you can technically specify any vector for an attach node, since no stock part ever had one that wasn't axial they didn't notice how poorly part attachment works in those cases. Maybe it'll get better with the promised editor upgrades in 0.90?

Going out of town for a week so I'm posting what I have and calling it 0.13. Hope it ain't broken. - Built against 0.25 - Support for ConnectedLivingSpace - First pass IVA for the AKWW-16 - Fixed divide-by-zero behavior with TAC Fuel Balancer after conversion - Visual tweaks OP updated. (MechJeb might also be fixed but I haven't tested it yet.)

Not everyone has a beefy desktop. Egalitarianism is the better approach when it comes to writing a shader that will be used on every part in the game.

Awesome, that's perfect. Separate the light contributions into the red, green, and blue channels and just feed color constants in per body. That makes them a lot easier to tweak for sunrise/set hours as well, and since you'd probably have to set these terms per RenderObject (admittedly a wee bit of a pain) you could set them separately for faraway things rendered by DistantObjects.

http://alexmoon.github.io/ksp/ Tell it where you're going, when you want to leave, and click anywhere on the graph it generates. It'll tell you what it costs and what your ejection angle should be.

The thing stopping me, of course, is that I'd have to replace (and therefore debug) every single shader with a diffuse component, of which there are several. But, it's doable. They're all pretty similar.

I hadn't looked into it at all yet but this was actually something I was going to try soon. My theory was use this trick and some code from the Reflective Surfaces mod to replace the base KSP shaders with versions that include an extra texture lookup for shine contribution. I was going to use a 2D LUT with one axis as altitude and the other as (surfacenormal dot localgravityup) for the light contribution. That would let me spread it around the model proportional to how large the apparent angular size of the planet was, and how much atmosphere, if any, was around the ship. (since a dot product gives you a result from -1 to 1 if both vectors are normalized, you have information on light angle all the way around the model. shaders almost always throw away anything less than 0 because that's assumed to be in shadow, but we can exploit it for a cheap directional-area light effect.) I knocked up a rough example for Kerbin: Vertical axis is altitude, not to scale. The white tick at the midpoint represents 69km, the point at which ambient light would start to come from both below and above. Bottom of the image would be sea level, and the top of the image would be some arbitrary altitude (you use 4x planet radius which seems good). Horizontal axis is just the contour of the model. Above the atmosphere, light only comes from below (left side of image), but the closer you get to sea level/the ground, the blue light would begin to come from above (farther to the right of center) and the light from below would become more earthy. I picked brown, but for most of Kerbin I guess it would either be green or dark ocean blue.

I want you to know, I love you. I'm not sure I've ever really loved anyone appropriately. Just the way they made me feel, you know? Never a kind of true, selfless devotion to the total wellbeing of another person love. But you, I want you to have everything in life you want and always be happy. I love you. (downloading now)

Reorienting the model won't fix it in all cases, because it also involves how transformations are inherited through the part chain from the root. I got the sun to appear at different angles in the cockpit, with the cockpit always upright and pointed west, by attaching it to the vessel differently. Porkjet suggested I just put an alpha'd window pane in each window and mark them as shadowcasters. I might just do that, although I like the way you can sometimes see the sun on the Kerbals' faces in the Mk2 Pod crew thumbnails (even though it's apparently wrong). hey look: Needs more props - conduits, hooks and rungs, more visibly stored equipment and supplies instead of just labeled lockers. Some of those wacky post-it notes. You know. The lower tank is too small for anything other than storage, so once the tank is empty I'm saying that the magic invisible conversion process involves screwing in equipment locker doors. I'd leave it sealed and just say it's a poop tank like Skylab but I have to explain vertical passability if you stack two 16s or put a 16 on top of a 32 or whatever. and everyone knows kerbals don't poop anyway. It needs to look a little more constructed-in-space, too, because right now I don't think I'm selling the fiction that this used to be an empty fuel tank that Kerbals just moved into. The big snack lockers could be collapsible? and I guess the chairs would be okay just being immersed in LOX for the trip. It's a bit of a shame that all the neat stored stuff is only visible in the VAB on the top of the part, right before you stick something else on top of it, but most of that stuff wouldn't be stored IN the tank while there's fuel in it ... I'm trying to keep the supernerds content, but I also want each wetworks self-contained as one part.

How did you rip a skybox from EVE Online? I must know. For science.

Well, "solved" one problem. The sun transposition is actually a stock bug: THIS GAME, MAN. \o/