Corona688

In theory. Remember the console release? Yea... it's really not that easy. There's always corners and issues the computer can't fix for you. Porting to Linux is relatively easy, because (ironically) it's one of the least forgiving software environments - it will make a 30-page list of your programming flaws and staple it to your forehead. 30 years of being ported to every toaster gave Linux devs practice at porting. I was heavily involved back when home computers went 64-bit. That ripped the floor out from under a lot of old software, when lazy assumptions that worked for 30 years straight suddenly didn't.

The list of things a standard PC possesses and a Switch/android/phone lacks includes, but is not limited to: Memory size Memory speed Disk size Disk speed CPU cache size CPU speed I/O capacity They trade everything of value to make these portable devices fit in a tiny case. So, if a standard PC struggles to run it, a stripped-down portable is going to be hilarious to watch try.

Take it from someone who has actually ported software to strange architectures: The day you can program for one without the assistance of a real computer is the day you can call them equivalent. They have the right parts, but they're not connected the same way, and the only OS they have to speak of is mostly concerned with preventing access to anything. Programming for them is therefore a real pain in the ass. Who said anything about C++? i'm talking architecture and operating system. The test release crashed? Better post the logs LOL there aren't any because you're on console. Et cetera. Lacking a true operating system and being incredibly restricted in access of all sorts makes programming for console environments an incredible pain in the ass, so much so that the programming isn't done on the console, but specialized software on an actual computer attached to it. And if only it were as easy as Unity doing all the porting for you, then the console port would have been perfect first try.

They do that anyway, so I don't think that's a good argument against it.

Then you end up with the "Windows Taskbar Problem": You screwed it up and there's no undo. Now what? Covering 99% of use cases without pain seems a good compromise. Fully customizable UI exists to bite you in the ass. If you must make it stateful, a reset button is a must!

Forthe ISRU, that makes sense. For extracting it from Jool's atmosphere, not so much. Gas giants have almost the same composition as stars -- 99.9% pure hydrogen.

I'm actually kind of worried. People keep going on about how terrible KSP's graphics are and they're already barely tolerable for most mortal computers. I hope the system requirements aren't ridiculous

It's been their policy to not promise dates for a long time now. We're not supposed to discuss them either, as cudgeling them does nothing.

I don't think there's ever been a version without. There's only so much 32-bit accuracy can do in a 64-bit sized solar system. It helps a LOT, both in accuracy and in remembering, to put a maneuver node near your encounter. Because that encounter hasn't "vanished", you're still a hair's away from SOI.

Encountering minmus is just about worst-case for encounter nodes, because it's a tiny gravity well orbiting just a hair away from escape velocity. One floating point error is the difference between an encounter and the eternal void. It also means you're only a hair away from capture when you're there if it disappears. It helps to make your encounter a close one to minmus, rather than 400,000km or something.

By longstanding tradition, they don't publish hard dates and it's against the rules to beg for them. Console is much harder to program for than PC.

Asteroids. I've never had much luck with asteroids.

There's still dedicated communities for games from 1992 - and especially obsessive puzzle creation games from 1992. I think some people will stay with ksp1. Not everyone.

Yes, a pun on "twin bore", you know, a shotgun.

Time and time again we get asked, and time and time again, these toys are not computers.

I think this speaks for itself.

Do you know how timewarp works? It puts parts on rails. No rails -- no timewarp. We have now come full circle.

Don't forget Gilly's own orbital speed.

Parts "on rails" follow a perfect ellipse. Their position 5 years from now is just 1 calculation. True N-body physics are calculated the hard way, incrementally, 18-millisecond tick by 18-millisecond tick. So the answer is not N-body, but some sort of kludge to specially handle a lagrange point.

A ship in Kerbal Space Program is not one mesh, but quite a few pasted together. This works fine on a graphics card. This does not work well when the object has to be computationally cut into slices and printed.

Your mun lander does not need to be large. Building small will save you so much delta-v. And throw away as much weight as you can before you leave. This thing throws away an empty fuel tank and the science jr to save even more delta-v. (too bad I forgot the heat shield. oh well)

OH! Now I understand what you're asking finally. Depending what time you burn to leave the Mun's orbit, you either get a speed boost or a braking effect relative to kerbin. This is because your velocity relative to Kerbin is high in one half of your orbit and low in the other. Imagine watching, from Earth, a satellite orbiting the moon. Sometimes it will be move to the right in the sky, sometimes it will move to the left. Pick the right time and your orbital speed around the mun will partly cancel, getting you a lower periapsis for free. Pick the wrong time and that velocity adds to the mun's own orbital velocity instead. You can pick the right time by making a manuever node and dragging it around to change the time of the burn, watching your projected periapsis around Kerbin.

They work fine unless you're using a browser plugin that forces them all to https. Or perhaps there's some network problem between you and my host.

I've found a peculiar sweet spot of cost-effectiveness with the Thud engine: A $30K rocket which carries 20 tons total mass to LKO. That 20 tons includes the thuds, which help at lift-off and in orbit. This reduction in dead weight makes a very nice combination. Also, a pair of thuds on top of your rocket can control almost anything. And 17 tons of fuel stuck to a pair of thuds can go pretty far.

So, there's a mod for it, and it's coming to stock KSP2. What, exactly, is your remaining need?