Xyphos

Thud fits snugly along the walls of a Mk3 cargo bay or even a size-2 service bay, and can give you some VTOL capabilities, but certainly not for long-term use. you can do the same thing with Twitch inside a Mk2 cargo bay. ant is better suited for very small probes. spider is great for low-gravity landers, I've slapped 6 of them on a Minmus lander and it worked well.

I'll argue that you really should not load entire planets and all their contents at once; I don't think there's any game engine out there that can handle that. instead, you have to use tricks and methods to fake it. you know that planet that you're too far away to see and it's just a dot? yeah, that dot should be a low-res terrain-map image scaled appropriately to the distance of your craft, and not a full-blown model. the planet's model shouldn't be loaded until you're close enough for it to actually matter and even then, only parts of the model you can see should be loaded; why do you need to render the other side of the planet every game frame if you're not going to be able to even see it? map view? no model, again, a terrain-map image would suffice.

Watch the first half of this, and I hope you can learn from it. the second half is optional and irrelevant.

@The_Rocketeer - THIS is what was taught to me in school, so this is all I have to go by. https://en.wikipedia.org/wiki/Lift_(force)#False_explanation_based_on_equal_transit-time but I thank you, because you've made me do research on the subject, only to find out that my high-school science teacher is a babbling idiot, and taught me nothing worth using.

real-world, it's correct. in KSP, a cardboard box will fly to minmus if you find a big enough rubber band to hurl it with.

build a puller-type because they're simple to build and easier to handle, just be sure to have enough distance between the engine exhaust and the asteroid; that shouldn't be a problem if you stick 3x Mk3 Liquid Fuselages end-to-end. attach 6 or 8 nerva engines with radiators on the end opposite to the claw, pointed slightly outward. after attaching to the asteroid and centering the claw, point radial-in and lower your PE to about 38km inside kerbins' atmosphere; directly altering your PE is more effective than just pointing retrograde and slowing down. perform an aerocapture in kerbin's atmosphere while using the asteroid as a heat shield. adjust your AP to about 255km (this enables 1000x time warp for faster refueling) circulurize and enjoy. please note that you'll need a Class-D or Class-E to make this profitable, anything smaller and you're just better off landing it on kerbin as a trophy or something.

Actually, I wouldn't mind having KSP as a cell-shaded game ran in Unreal 4 - the cartoonish graphics would perfectly fit the comedy that KSP really is, and still look good while doing it at a lower graphics requirement.

don't do that. your horizontal speed is what is keeping you aloft. a plane's wing is flat on the bottom and curved on the top, this creates more surface area on the top of the wing than under it, this makes it so that that horizontal air flowing over the wing takes longer to travel than under it, and that means there's less air pressure on the top of the wing than under it, which gives you lift and keeps you up. since your problem is your craft slamming into whatever and exploding, you want to bleed off your vertical speed but keep your horizontal above 80 m/s. as you're landing, set your navball to surface mode, get below 2000 meters on your final approach, lower your landing gear, throttle down to 15% (powered landings only, gliders skip this step) then nose-up to about 10 degrees or less and watch your navball. you want to keep your prograde marker just under the horizon but not too much that you're falling like a rock. if you're gaining speed, continue to throttle down until your speed starts to bleed off, but not too rapidly, just enough to give the ground a soft tender kiss with your wheels. after you've landed, stopping your vessel is an entirely different story; in KSP the brakes system doesn't work too well and has varying effect on different celestial bodies, in conjunction with the new friction control system, the brakes are next to worthless, just put some chutes on a stage and deploy when you want to stop. optionally re-pack and add them to a new stage if you're going to re-use the vessel.

technically, it's a new third type; a pushing puller. perhaps it can be called a hybrid? (needs a new name, I know.) the diagram is a bit inaccurate; the engines should be near the asteroid's equator, close to the center of mass. the engines are in fact pushing the asteroid, but the position of the grapple makes it a pulling effect and since it's near the center of mass, it should generate less rotational torque.

While there is no "best" or "worst" engine, because each is better suited for different tasks, I will actually defend Thud's honor by mentioning that it's better suited for short VTOL flight operation and is small enough to fit inside a cargo bay, along it's walls and still have enough room to drop off a size-1 payload. but in my most humblest opinion, the Rhino is the worst - sure it has the second (or third?) best ISP in game, but it's size, weight and relative lack of power negates any real benefits to using it; I'd rather slap on some mammoths and/or vectors and just muscle my way to orbit. who needs all that fancy efficiency when you can just use raw power? I mean, once it's in orbit, you won't ever need the darn thing again, because it's nukes all the way from here. save yourself some effort and skip the middle stage entirely.

only if it were so simple. more rapier engines = more fuel consumed = more fuel required = more weight = ineffective results. it won't even get to sub-orbit, it'll just hang at 350 m/s and refuse to climb past 6000 meters. even if you dive to sea-level, and manage to pitch back up, it'll lose all that velocity to the angular drag.

well that explains it then.

I'm trying to come up with an SSTO rocket with a 225 ton payload that would be able to land on minmus, refuel and return (or go interplanetary) initial design was an SSTO spaceplane but the payload required too many air-breathing engines to make it a viable solution so I opted for a rocket instead. but it seems that no matter how many fuel tanks and engines I add, I just can't get enough Delta-V to get the thing into orbit. any advise?

mods can't run without a function call from the main program to execute the mod's code, but the devs didn't bother to trap external function calls in a try...catch...finally block, which is the very basic form of error and exception handling.

yeah, timewarp would be the biggest problem, but I think DMP handles that in a reasonable way.

Two counter words: lag compensation. it's a technique used to sync up all the clients within a reasonable margin. it's unlikely to lag on localhost, which is your own loopback device on your computer, however, for multiplayer, if anyone is attempting to play with a 600 ping, it's not the server's fault, now is it?

no, during SSTO sub-orbit launch. I get it up to 1200 m/s orbital speed in the atmosphere, which is about 450 m/s short of my usual exit speed before switching to rockets, but everything explodes in the bays around 1300 m/s

No, actually... KSP should run on a custom engine, based as an internet server using the P2P network protocol, single player would connect to that server locally, and other players could join via lobby listings with optional passwords, if the host allows multiplayer. since it's a server design, it doesn't need any graphics programming, only the client-sided part would need a graphics engine, to display the information being relayed by the server. this frees up resources since the server doesn't have to draw every game frame, only track physics and tell the client what's going on in the universe. ...but then again, what do I know about game programming?

it's because the developers are extremely lazy. instead of building a custom-tailored and optimized game engine specifically for KSP, they've duct-taped and bubble gummed KSP around someone else's buggy game engine called "Unity." I can't say I agree with this approach, it's like sticking $10,000 rims on an old, beat-up ugly car that barely runs, but you have to start it with a screwdriver. Unity tries to be a one-size-fits-all game engine for almost every platform, including consoles. the problem with that is, there is no such thing as "one-size-fits-all" and what works on one platform, might not work at all on another. we're constantly seeing KSP crash because of incompatible code execution, and to make matters worse, Squad can't do much of anything to fix the problem aside from sending the developers of Unity a bug report and hope it gets fixed within a few months. In my previous software engineering experience, before I decided to change careers, I know for a fact that creating a multi-threaded game engine specifically for KSP would be a very trivial task if planned out properly with flow charts and diagrams, so the excuse "making a game engine is hard work" is total bull and I'm not buying it. lazyness aside, Squad also lacks direction, as most indy devs do.

AW MAN, what a PITA. okay, thanks.

1.1.3 is nice, they fixed a lot of bugs, but now I'm noticing that parts stowed in cargo bays still take heat damage, does anyone have a work-around to keep them from exploding?

(Poking @Porkjet then.)

Suggestion to add to stock. (poking @RoverDude)