Shadow86

Noticed a minor bug during a very early career launch, the kind you go straight up, run out of fuel and come back down. I detached the first stage once it was spent, and the parachutes on it opened, slowing the descent. The capsule stage landed first, and when I activated time compression to accelerate the first stage's descent, it disappeared and I got a notification that it was recovered. The small bug is that it said the stage had been recovered over 700 km away from the KSC, when it truth it would've been a helluva lot closer to 700 metres.

That started happening because the city lights textures were TGA files. The problem goes away if you convert them to PNG.

Great work! Is it 1.0.2-compatible?

Blast! You just ruined my Kerbal Teeth Overhaul Pack! A fair solution.

Thanks for your hard work! Can I assume the update works for 1.0.2 too? Might be wise to update the main topic title to reflect that and draw people's attention.

Don't forget about physical time compression, guys. I suppose it can be dangerous in some environments, but it allows you to run at 4x speed. I ran two kerbals a total of 30 km across Duna with it, and it took me about an hour. It's preferable to have a TV nearby.

I really think this sounds exactly the problem I'm having. I have no idea how to get those nodes in the right place, exactly what they are, how to even get them to where I see them. All I know is my orbit many times is like an elliptical and the orbit of the Mun is another elliptical and they never meet. And I'm sometimes lucky enough that they come close enough that I can get an Mun proximity event. Doing that, I have orbited the Mun about 3 times. Once I crashed escaping the orbit and I reverted, so really only two Mun orbits. The ascending and descending nodes are the spots where the orbital planes of your vessel and your target cross, and it's my understanding they're the best points to burn normal/anti-normal to correct relative inclinations. I don't think the original bit of advice you quoted is all that sound. I mean, if the two planes only cross in two occasions, as opposed to many times the closer your inclination gets relative to the target, you'll get a lot fewer opportunities for intercepts. If the two spacecraft can only possibly meet twice along their orbit, you might spend many revolutions trying to get their positions to match precisely in time for those two tiny windows. It's also likely you'll have to burn a lot more fuel equalizing relative velocities when the rendezvous does come, since your trajectory would be markedly different than if you had matched inclinations.

Kerbal Engineer. Flying the spacecraft I build is half the game, so I don't use MechJeb.

I play mostly vanilla. The only mods I use are either graphics/experience-enhancing like Texture Replacer and Chatterer, or informational, like Raster Prop Monitor and Kerbal Engineer Redux.

Yes, the same can be said about other mods, and I don't consider it a positive trait. I don't mod my game to hell and back, and when it comes to parts, if I want them at all, I prefer packs which expand the selection of combinable components as opposed to those that simply add their own isolated group of things which only work well with themselves. Anyway, thanks for the customization tips and all. But it's a shame the shuttle itself is such an inflexible design, regardless of how much you can tweak its boosters. The pack looks great, though, so I might give it a spin sometime.

I'm conflicted about this. I mean, the orbiter looks really cool, but... I don't know, I suppose I wish it were more stock-friendly and less self-contained, so to speak. Like, say, B9, it feels isolated from the rest of the parts and nigh-unusable with them. And while the shuttle's made of several parts, they're all almost exclusively designed to work with each other in a very specific fashion, making the group a self-contained jigsaw puzzle that might as well just be three parts (shuttle, main tank and booster). Is there any significant design leeway or does it all just break apart if the parts aren't assembled in 90% the 'correct' way?

It's easy to dock small craft together. But it becomes more and more time-consuming the more complex they get, once performance issues and wobbling start complicating things. I always play manually, of course.

Excellent! I've started using the plugin, and had no issues so far. Here's a peek of the space suits my Kerbals are using at the moment. It's a personally modified variant of the Pimp My Kerbals high-res default KSP suit.

I'm a bit puzzled by this, and why it needs to be constantly running while you play the game, and potentially impact performance. How does this work? Does it actively fudge texture calls within the game whenever the code makes them? Are the textures packed and encrypted so that replacement can't be done outside the game, without the necessity to have anything extra running when you play?

Where exactly? I'm gonna need some context, since the file is pretty big. EDIT: Oh, wait. Found this: DIFFICULTY { MissingCrewsRespawn = True AllowStockVessels = False }

Sorry about the necroposting. It seems all Kerbals respawn as of 0.23.5. Not just the famous trio. Any way to disable that? Or is the Kerbal name generator practically finite?

Awesome mod! Kerbin looks so much better! But I've a question about Eve. At least on the tracking screen, it looks like a barely-detailed purple ball. Is that normal? Some kind of really thick cloud cover?

That sounds more like a collision map issue, which could be modelled without calculating the full physics of a given part. I'm just pondering possible optimization paths, since I believe physics representation needn't be 100% accurate at all times.

I think it'd help to reduce the fidelity of the representation of physics under certain circumstances, such as when the object in question isn't the active vessel and/or that object isn't too close to the active one. The physics of certain parts could also be merged together with that of bigger ones they're securely bolted to. For instance, there should be no processing difference between rendering the physics of a fuel tank and those of a fuel tank with ladders, lights and batteries attached. Within the same spacecraft, it would probably be worth pondering just modelling the physical interaction between the largest parts. But I get the feeling the game has a huge processing overhead dealing with the physical representation of every last bit onboard a rocket, 90-95% of it practically wasteful given that many parts are likely securely attached to the point modelling how they might wobble is utterly unnecessary.

Looks like a lot of work went into this mod, but I feel I've to point out a couple of things. While the detail of some parts is fantastic, many others (if the inspiration albums are anything to go by) seem extremely plain and barely textured. Even if the models themselves seem to be just fine. And I feel that clash of detail consequently makes those parts less than compatible with existing stock material. It just wouldn't look very good to mix and match, and such compatibility should be a primary objective for any parts mod.

Chill, fellas. It's a great update. Resources might not be included in it this time, but they will likely be implemented sooner than later.

It's a bit of a no-brainer. Laythe's the only Joolian moon that really stands out. Now, if Tylo had vicious kerbal-eating alien creatures, or Bop a crashed extrakerbinean (human?) spacecraft, then they might be serious contenders.

Wait a minute. I was mistaken. 712 is the sum of the parts of all the sections including the sizeable launch vehicles. Which is more depressing given the actual station is probably less than half that, and still makes my computer struggle.

This is mine, Frontier Station, product of five launches and four dockings, in a stable 100/100 orbit around Kerbin. Not nearly as big as other examples on this thread, but at 712 parts it sinks my framerate to pretty appalling levels whenever I'm nearby.

I've started getting very noticeable framerate issues when exceeding 500 parts. I just finished building a space station which sports just over 700 parts, and I believe my framerate in its proximity sinks all the way down to low teens. RAM has probably little to do with it unless you have 4 gigs or less, given the game can't use more than that, being a 32bit application. The engine being single-core also further strains performance. It's a real shame that, even ten years after their introduction to the mainstream market, multi-core processors and 64bit operating systems aren't fully utilized by many (most?) applications. I realize the game is far from finished, and that performance optimization is not a top priority right now. I just hope the Unity engine doesn't ultimately put a significant damper on how much KSP can be optimized later. For the record, I'm running Windows 7 Home Premium 64bit, have a Phenom II X4 955 processor, an AMD Radeon 5850 graphics card, and 8 gigs of RAM.