Corona688

A little from column A, a little from column B, plus a little from column C: Image hoster panics, "holy cow someone is using our image hoster to host images!" and blocks hotlinking, causing all remote images to be replaced with a kitten and a "pay more to unlock this feature" notice. Only Imgur images seem to have survived the test of time. But Imgur's been getting squirrelier lately. Nowdays links to images get replaced with a link to a webpage so they can serve more ads. But image hotlinks themselves are still honored, for now.

I could picture a phone version of Kerbal Space Program 0.1, the two-dee version. The full game is just too complex to play on a one-button controller.

Oh my goodness I love that lander. It's so crazily asymmetric yet flight-worthy and beautiful, packed with instruments and love and noble gases. It makes me proud.

Perhaps if you set it down wheels first... ...j/k, the wheels look too close together to me, both horizontally and lengthwise.

Huh? I already refuted that! That's not even close to how it works. This, I think, is the point of contention. Your next sentence tells me why you believe this. "You can send ships to fly-by other planets and never touch them again, but still their trajectories are changed by the encounters." Timewarp used to work that way, but was wildly inaccurate, computationally wasteful, and blew ships apart. The game still has it, but calls it "physwarp" and limits you to 4x max for obvious reasons. Parts "on rails" don't do that. They jump from T+0 to T+900,000,000 in one calculation, with fantastic accuracy. They're represented as hyperbolas, parabolas, and ellipses -- that is, conic sections. Classical orbital mechanics. An orbit calculated this way won't go sloppy for a very, very long time. There's just two catches. How good is the data that was fed into it? Garbage in, garbage out. If your orbit was .00001% off, as it inevitably was, the conic section will be at least as wrong. What happens if a moon gets in your way sometime through the third millennium? ...which is why timewarp still does some iterating, just to check if you hit anything. And if something does get in your way, it either has to drop into physics mode - causing a translation from conics back into positions and velocities - or switch to a different SOI, causing two transitions, from and then back to conic sections, with a rescaling inbetween. Barring that, when you drop out of timewarp, it's just one calculation away from the numbers you started with.

You have drastically misread my post. It is all about both. If there's anything wrong with my explanation, either, you haven't bothered to say what. Reread and respond to it, if you like. If you still believe I am wrong, explain why you think so. Or, you know. Don't. Have fun.

No. That's all I get from you for a long detailed explanation. That's all you'll get from me for an unsubstantiated opinion.

If you're looking for a modern one, kerbalx seems popular.

That's nice, but that's not what you said a page ago.

Work out how? "On rails" does not mean "perfect". There's no way to get a perfect orbit in the first place without editing. Squad has done a good job of plumbing the limits possible with 32-bit numbers but these limits still exist. This is not the same thing as "orbits on rails still get less accurate". That is simply wrong. Sources in this very thread contradict you on that. Remember - if you fly a craft or even just approach within several km of it, its perfect orbit is ruined when iterative physics kicks in. Getting and keeping a perfect orbit is tricky.

If you mean the old, old, official one, I think that is gone.

I think I can explain that. Direct3D 9 couldn't guarantee that textures put in video memory would stay there, so the software copies were needed as fallback. Stupid, but not Squad's stupid.

I never said "manual". You certainly don't get manual. You get on, and off. As for instant, the game doesn't consider speed of light delays yet. Either that, or its the tracking station's job. It's a game engine limitation. Objects which aren't being flown have no physics. The game ignores it, too, and is convenient. We may have to come to grips with that someday, but I don't think that is today. No no no -- not "features I like". Just "prearranged signals designed into the probe core". If I was designed to my liking it'd be a bit different. Juno understands that a radio wave on such-and-such a frequency means "reboot myself". The signal doesn't contain a reboot instruction, it just knows what to do when it gets a signal on that band. It's possible to have more than one of those. 2290Mhz might mean "stabilize", 2295Mhz could mean "execute", and 2300Mhz could mean "stop": It'd increase the complexity and power requirements of the probe. That's a good question. I can think of three ways. First, diffraction. Light spreads out when it goes past an edge: The effect is greater for radio waves, especially for long wavelengths. If you have lots and lots of transmitter power, and your probe is in high orbit, you could get a signal around the edges of the moon by brute force. It wouldn't work if your probe were landed, or were on the far side of Pluto. Second, you could reflect the signal off some other stellar body. Same poor signal, same relatively-nearby limits. Not much use on Earth, but we don't have Minmus... Both depend on ridiculous amounts of transmission power but that is a thing. We have radars strong enough to get an echo off of Venus. Just let that sink in a moment. I doubt you'll find my third idea satisfying, but please bear with me: "The power of imagination". Jeb doesn't actually fly the craft, we do. The probe doesn't actually fly the craft either -- we do, within the limits imposed by a simple targeting computer. Perhaps that's what "limited control" means. When it's beyond the reach of ground control, it's up to the "program", i.e. us. Limited control isn't no control. You might say there shouldn't be control but that's a different argument. I think there should be -- what else is a probe core for? I thought they were useless until someone explained how "limited control" worked. But make a node? Are you sure? That has to be a bug.

The problem with pure drop-tank is TWR. You need a monster engine cluster to lift all your fuel, but by the end of the burn, you have way more engines than you need.

Orbits aren't done iteratively, not unless you're actively flying the craft. When an orbit is "on rails", its defined by a fixed equation which should stay as accurate as it started for 24 million game ticks or so. Even when you are flying a craft, the motion of the SOI is not considered at all. No. There's a third way to calculate these things. You can calculate orbits around each SOI independently, as if each body were motionless at the center of the universe. Then it no longer matters which order you calculate them in. So, when you're landing on the mun, Kerbin's motion is not factored into your own. Your own SOI couldn't care less where Kerbin is. That's not even the real Kerbin in the sky, just a miniature placeholder fudged and downscaled to fit your own SOI. Timewarp is not iterative. Just to make that clear. Ahem. Some inaccuracy is caused from going into and out of timewarp, from translating between iterative motion and fixed equations and back. Some inaccuracy also happens when switching SOI's. It has to rescale your motion into a new reference, and when one reference is big and the other is small, accuracy is lost. And even a fixed equation is not perfect. It doesn't accumulate error in the same sense as iterative calculation, but an orbit that's off 10m per day will be off 3km in a year. And a fixed equation is only as accurate as the place it started from. You will never get an orbit quite perfect during iterative physics, therefore it will never bet quite perfect on rails either - not unless you edit it into perfection with alt-F12 or save-file meddling and leave it untouched thereafter.

The "undock" bug is well-known. Its been fixed repeatedly and every few versions somehow crops up again. Its one of the few things which can actually induce me to install a mod This one:

Stuff on the ground has to deal with hitboxes and landscape colliders. It's difficult to align stuff in space precisely enough. Your instruments can't tell you when an orbit is correct -- they have floating point errors too. And even if you get it perfect, the orbit will probably stop being perfect a few game ticks later. Physics and rails are always computed relative to the local sphere-of-influence, to make that dragging irrelevant. Squad did that quite intentionally, as 32-bit floats just aren't precise enough to model a mun landing with Kerbin as the center of the universe. In pre-Mun versions of KSP, you could tear your ship apart by flying far enough away that floating point errors nudged different bits of your ship different directions. That was the original Kraken, which they "slayed" by adding references of different scales. Timewarp doesn't have incremental errors, it puts your ship on rails. (Physwarp does, though.) The jumpiness can be many other things, but often means other things switching SOI.

60,000 and up is way too high. 35,000 is where it's at, IMO. At 40,000 you'll chew through your heat shield without substantially slowing down. At 20,000 you'll implode.

Compression is not helpful for in-game textures. It reduces quality, and in the end, the game has to decompress them to use them anyway, so they still take the same amount of video memory. KSP's choice of png for screenshots is regrettable though. Almost nobody takes the time to convert to jpg, so threads of screenshots can take many minutes to load.

My Juno example illustrated using a special frequency for a special function which can be accomplished at great distance even under poor radio conditions. Why, given that, could there not be special frequencies for special functions which can be accomplished at great distance even under poor radio conditions? They can only convey one bit of information: "On". Limited. Control. Given a special frequency for "reboot", could there not be a special frequency for "engine on"? And how, exactly, is the craft going to get the information for a new maneuver node through a one-bit transmission? "Delete", I'd believe. You can encode "delete" in a one bit prearranged command. Rejoice, for today you get your wish. Advanced probe cores can follow maneuver nodes, even under limited control! That's what they're for. Not completely what you asked for, but a solid 99% of it, about as close as they can get without radically changing the core of the game. You mean, it isn't? Why? Do you not understand the difference between a one-bit signal and a datagram? Do you not understand the difference between executing a prearranged command and transmitting new instructions? If you're not using commnet, this topic is pointless of course.

My first fully-recoverable SSTO: Because sometimes you want to send empty orange marshmallows to minmus.

Define "not much at all". Why are you trying to use an ion engine in atmosphere? That's like trying to use a jet engine in space. It just doesn't work.

Why not? You will have SOME CONTROL. Limited control is more than no control. With a little planning it could easily be enough. If you left your probe facing the manuever, Z/X is all you need for a rough burn. An Octo can do all that plus stability assist, even under limited control. A HECS has prograde/retrograde, which is enough for some simple ad-hoc manuevers to fine-tune after. And a HECS2 can actually rendevous under limited control! But then, how would you utilize limited control?

If you want full control all the time despite accidents or mistakes, why not turn off commnet?

Let me put it this way. When Juno arrived in space near Jupiter, it announced its success with a radio wave Juno didn't align its good antennas for this - something they didn't want to depend on - so the signal contained no information. They received the radio tone at the right time via radio telescope, therefore they know Juno was still operating, still on course, and had finished its burn. That is all. Until Juno's antennas align to Earth, that's the best it can do. If Juno failed to send that signal, NASA might have tried sending a powerful beam of a frequency which Juno would interpret as a request to reboot itself, at which point the first thing it would do is re-orient itself to Earth so NASA can regain control. (Juno actually did that by itself, later, for reasons unknown. It worked. Hooray for contingency plans.) At that great a distance without Juno's proper antennas aimed at them, that's the best they can do. That's the level you're operating at, when you have "limited probe control". You're reduced to the electronic equivalent of a dog-whistle.