Starman4308

Corned beef sandwiches, for one. Other than that, I suspect at least one Kerbal fast food place offered Minmus-themed mint ice cream to commemorate the first landing there*. You can also try looking at what astronauts on the ISS eat: you tend to see a lot of focus on non-perishable items which are easy to open and consume in zero-gravity while producing minimal debris. *I personally go for a less cartoony interpretation of how Kerbals work, without this "we thought Minmus was actually dessert" nonsense. Still, you know it would be commercialized, somehow. There's some videos out there about food preparation in space, and how much it's improved since the early days. I'm also now wondering if any astronauts have commemorated an anniversary of the corned-beef-sandwich incident by having a corned beef sandwich... probably on a low-crumb tortilla.

Is your toaster and/or microwave from earlier than 2005? These common household appliances may not have enough graphics processing power to fluently run KSP. Fortunately, Squad has announced support for blender-based hardware acceleration on any blender manufactured later than about Q2 2012. Exaggeration aside, the stock game's graphics are pretty simple, and should run reasonably well on anything even vaguely resembling a modern computer (including El Cheapo laptops). What's usually much more limiting is CPU and/or memory. With a bit more detailed information, I can tell you with much more confidence, but any frame rate drops are probably the fault of A, a weak CPU combined with high part-count vessels, B, you're starting to run out of physical memory and are chugging as you start to move too much to swap, or C, you installed 47 graphics mods with high-resolution textures.

Well, if you don't mind mods, well... I'm pretty sure Necrobones has large landing legs in at least one of his mods, Roverdude's sounding rockets mod has grid fins, and I think SXT might have grid fins. No guarantee that the grid fins work with FAR; I suspect FAR would voxelize them as bricks and not properly handle them.

People talking about a Wii U port does not necessarily imply they actually would have been able to pull an effective Wii U port off. I could maybe buy the Switch, but I'm really skeptical as to whether you could make a decent Wii U port of KSP, at least not without basically tearing the whole thing down and starting from scratch with a more thoroughly optimized game engine. Which is kind of a shame, since I would 100% agree that KSP fits into Nintendo's sense of whimsy, and emphasis on making fun games vs. making "Call Of Duty 50042: Now with 17% more graphical effects you will only notice when bragging about them". There's a reason that, despite being a fan of PC gaming with a mid-upper end rig, I suspect my favorite console would be something from Nintendo. Though, a small postscript: I have no doubts as to the capacity of those consoles to at least handle the graphics of KSP. I'm pretty sure most modern microwaves and toasters can handle KSP's graphics.

I remember rather hilariously flopping around until I learned to shut off the targeting computer and use the Force look at the trackball to figure out where I'm pointing.

Thing is, you're always getting a little bit of wobbling, and while SAS will try to compensate, you will* eventually reach a point where it wobbles just a little bit too far for SAS to correct, and it slips out of control. *Yes, you will. No matter how hard you try. Murphy's Law is stronger than the laws of physics.

"Turning down the settings" won't help. Usually, you see speedups in games from turning down the settings because the GPU isn't rendering frames fast enough, and by reducing the number and quality of effects to render, you can lighten the load on the GPU until it is once again rendering frames with adequate speed. KSP, however, is a very CPU-heavy number-cruncher; on the weak CPU of a Nintendo Switch, it just isn't going to be able to practically keep up with all the physics calculations. In effect, for most video games, there are three sequential bottlenecks: the CPU, the GPU, and the screen. Each "tick" of the game, the CPU runs all* of the physics, takes player inputs, and essentially runs the game forward by one tick. It then sends a package of rendering instructions to the GPU, telling it where all the relevant objects are, what textures they're using, etc. *Unless you are using some sort of OpenCL/CUDA physics acceleration. The GPU then renders the frame, producing the pixels that you will see. This tends to be a lot of very simple but repetitive math, which is why GPUs are basically giant bricks of hundreds to thousands of floating-point arithmetic units. The more complicated the rendering instructions, the higher resolution frames to render, and the more effects you try to run, the more work the GPU has to do. The GPU then sends the frame to the monitor, and tells the CPU "I'm ready for another frame". For most games, turning down the graphics settings works because the physics, AI, etc, are very simple, and are easy to run in 1/60'th of a second (the refresh rate of a typical monitor). What's limiting you is either the speed at which the GPU can render the frame, or the refresh rate of your monitor. KSP, however, is a hardcore physics simulator, with vessels consisting of hundreds of parts interacting by rigid-body physics, plus other fun stuff like aerodynamics, thermodynamics, checking the communication network, checking the orbits of unloaded vessels, etc. The graphics probably wouldn't even need to be turned down to run on a Nintendo Switch; it just doesn't have the sort of CPU that will semi-gracefully handle all the physics calculations coming its way. Even the more powerful CPUs of the Playstation 4 and Xbox One are marginal for running KSP. You could maybe play a limited version of KSP on the Switch with a bit of optimization and strict caps on things like number of parts, but I can tell you this: turning down the graphical glitter won't change the fact that KSP is a very CPU-heavy game that you are hoping will run on what is essentially a smartphone/tablet CPU.

I'm pretty sure that's incorrect. KSP uses the 2-body Keplerian approximation. This means: Your vessel is acted on by only one body's gravity at any given time. This means no Lagrange points, ITN, etc, but is a reasonable approximation for most conditions. As a side effect, this means that explicit spheres of influence must be defined, where there is a sharp boundary between the gravity of two major bodies. When you go from Kerbin's SOI to Mun's SOI, you instantly stop being affected by Kerbin and become affected only by the Mun. During physics, orbits are essentially a byproduct of your current velocity and position relative to the body whose SOI you are in. Your vessel is propagated using Newton's laws of motion. Were you to run this with perfect accuracy and infinitely short timesteps, this would perfectly reproduce the on-rails orbits. However, the integration schemes used for off-rails physics are designed to deal with accelerations not caused by gravity, and quickly become inaccurate over time once you start to factor in finite timesteps and machine precision. With on-rails orbits, KSP essentially takes your position and velocity, and calculates the six primary orbital elements: SMA, eccentricity, inclination, longitude of the ascending node, argument of periapsis, and mean anomaly at epoch. Given the simplicity of the 2-body Keplerian approximation, it is trivial to predict where your position will be at any arbitrary point in the future or past, so that is what KSP does*. The only semi-complication is when you have either SOI changes or sudden, unexpected lithobraking events, and KSP's patched-conics integrator does a reasonable job of patching those conics. *Under the 2-body Keplerian approximation, except during SOI changes, the shape of your orbit (SMA + eccentricity), period of your orbit (SMA), and orientation of that orbit relative to the parent body (inclination, LAN, AP) cannot possibly change unless you have some non-gravitational force (such as an engine) acting on your vessel. The only two things that need to be specified from there are: what time it is right now, and how far along in the orbit you were at some arbitrary point of time in the past. I'm pretty sure @eggrobin has made sure the projected orbits in Principia are reasonably accurate out to a fairly long time in the future. Unlike the Keplerian approximation, the shape and orientation of your orbit can change, and so there's no simple, analytic equation to tell you where an object will be after X time; he had to effectively use some advanced mathematical techniques similar to (if not outright identical to) what NASA and other space agencies use to estimate their orbits. Fast-forward a billion years in stock KSP, your satellite will be exactly where you left it (assuming it doesn't cross the SOI of any other major body). Fast-forward a billion years in Principia, you can't even be sure it's still orbiting the same object. EDIT: Also, to clarify why 2-body is a reasonable approximation: imagine Kerbin, the Sun, and a satellite. While the Sun has a not-insubstantial effect on the satellite's orbit, it has an almost identical effect on Kerbin's orbit. As such, if you're looking at position/veocity/acceleration of your satellite relative to Kerbin, you can simply ignore the Sun's gravity, because Kerbin is being accelerated at (almost) the same rate too. EDIT 2: As a demonstration of that: it's entirely possible to have a satellite orbiting Gilly that is feeling more gravity from Eve than Gilly. Assume Gilly is at periapsis, and you have a satellite 10 km from the edge of Gilly's SOI, towards Eve. It's getting 0.0376 m/sec^2 of acceleration from Eve, and just 0.00050 m/sec^2 of acceleration from Gilly. The reason why Gilly is the "major body" is that Gilly itself is being accelerated at 0.0369 m/sec^2 by Eve. Subtract it out, and the "missed" acceleration is just 0.00065 m/sec^2 under 2-body Keplerian mechanics, and this is a rather worst-case scenario.

Just so that's clear. Also, there's a little re-arrangement that can be done if gravity is the only force acting on your vessel. m1*a(tot) = F(tot) = F(grav) = G*m1*m2/r^2 m1*a(tot) = G*m1*m2/r^2 Divide out m1: a(tot) = G*m2/r^2 Therefore, under Keplerian 2-body mechanics, the acceleration of a satellite is dependent only on G and the mass of the body it is orbiting*, and the distance. The "on-rails" approximation is that your satellite does not affect a planet's or moon's trajectory, an approximation that is quite valid when Gilly is still 100 billion times more massive than even a 1000-ton uber-lifter. *This is usually combined into the standard gravitational parameter, mu. That's not going to be easy to do, and I'm pretty sure this becomes some sort of nasty differential equation for which no trivial analytical solution exists, requiring numerical solution: effectively a simulation (such as KSP). And if you're wondering: yes, this is basically math-speak for "abandon all hope, ye who enter here". Pretty sure you still get the differential equations, since you incur gravitational losses, etc.

There's Stratenblitz75's Youtube channel, which has a lot of all-SRB missions (Eeloo, RSS Moon, etc). For my own craft, my first stages are almost always liquid (kerolox/methalox) cores with solid boosters attached radially, so as to give those expensive liquid engines an extra kick up during the first 30-60 seconds of launch.

I assure you, you are far from the only coder to make similar mistakes. It's particularly unfun when there are two of something, often by definition, where it's not enough to justify having a list or similar, so you just explicitly reference both.

It's relatively common for my larger boosters in a 6.4x/Real Fuels installation; with propellant (particularly liquid hydrogen) so much less dense than magic LF/Ox, plus expanded dV requirements, stuff gets big in a hurry. It doesn't help that I tend to build overly tall and narrow due to interstage decoupling width tech limits. Also, to OP, Hangar Extender is what you're looking for. By default, it activates by pressing the keypad *.

It's hard to find anything to like in this mess. I dislike the dishonesty in that video; you try to accurately represent what you've done, and that was clearly dishonest. On the other hand, there's been some substantial over-reactions; while in general he betrayed a community's expectations with these videos... in the end, it's some Youtube videos about a game. I suspect the pressure of coming out with fresh content on such a rapid schedule just got to him, and he got trapped in a stressful feedback loop. My recommendation there would be just to step away from it for a bit, and maybe come back later if he wound up doing any cool things in KSP, treating it as a "I'll share the things I've done" instead of trying to be a consistent entertainment channel.

You might try asking @NathanKell or the other RO folks directly, but my suspicion is that "rated burn time" is purely a real-world thing, where engines are only rated to run for a certain length of time before problems start to occur, such as excessive coking in the feed lines or injector*. *Engines which burn hydrocarbons, particularly kerosene-based fuels like RP-1, don't burn clean; they tend to coke, and produce solid deposits that can clog up the works. As to why it would be a good idea to match that rated burn time: those engines were designed for a specific purpose, and are rated for that specific purpose. If you're burning, say, an RD103 for less than the rated burn time, there's a good chance you could get more delta-V out of the system by adding more propellant and letting that RD103 burn longer. If you're burning longer, you probably over-loaded the stage with propellant. It'd be a rough rule of thumb to match that engine's real-world applications, not a hard requirement. EDIT: Alternately, look up real-world engines on the Internet; rated burn times are probably out there somewhere.

So, it's hardly game-breaking, but I noticed a small bug: with a relatively long build queue, when I changed scenes to the tracking station, it would begin to make some progress on vessels that are waiting in the queue (not enough build rates available to start them); this would cease when I moved out of the tracking station. So: Problem: Progress is made on vessels without an available build rate when in the tracking station (and possibly other scenes where time passes). Version: Latest 1.2.2, 64-bit Windows Mods: An absurd number. Let me know if you want me to try to reproduce on a clean build with just KCT. Logs (I think these are the right files: KSP.log and KSP_Data/output_log): https://www.dropbox.com/s/qfdzw3gtaicgsry/KSP.log?dl=0 https://www.dropbox.com/s/x5hnlsvmkw9xo35/output_log.txt?dl=0 Severity: Not much, it's just slightly cheaty. EDIT: By "long queue", I think I have 5 rates, and 9 vessels queued.

6.4x stock system is best, man. I don't know how you came to such an absurd conclusion! On a less blatantly trollish note: Gaarst's advice is mostly correct, although my intuition is that you'll want > 1.0 TWRs on anything short of an "almost in orbit" upper stage. I did a systematic examination of landing/ascent from airless bodies a while back, and generally speaking, it doesn't cost you all that much to increase your thrust, since engines are so light. *Cost efficiency may be a different matter, as fuel is definitely cheaper than engines, although if you add more fuel, your first stage gets bigger, which means bigger first-stage engines, etc. My typical strategy (from before I ran that examination) was to build a half-solid-half-kerolox first stage to get ~4 km/sec dV and 1.4-1.6 TWR, and then a restartable hydrolox upper (with a few linear RCS thrusters and some hydrazine for ullage) with 6 km/sec and 0.8 TWR. While intended to get me to Kerbin escape in 6.4x, it should fall right into the zone of RSS/RO launches. I'm refining that a bit with my new career; if I decide to continue designing my boosters for Kerbin escape velocity, I'll probably do a similar 4/5.5 km/sec dV split, with 1.4-1.6 and 1-1.2 TWR, respectively. I may, though, start going for 2-3 stage designs, with the goal of 2 stages to LKO and an optional 3'rd stage for Kerbin escape. If you're wondering why Kerbin/Earth escape velocity is such a big thing: if you set a dV target around there, you can pretty trivially inject towards a GEO orbit, lunar injection, out to the other planets, etc. Real-world rockets tend to go for, at most, GEO, because there's not much money outside GEO.

Almost certainly not. While the clock rate on the One's CPU is significantly diminished vs. the 360, the One has almost a decade's worth of improvements in IPC behind it, plus a larger cache, AVX vector instructions, faster main memory, etc. While a large fraction of KSP is, indeed, bloat caused by baffling decisions like "let's load textures straight to RAM, lol", a substantial fraction of it is legitimately based on being a heavy-duty physics simulator with numerous complicated behaviors. I would be very surprised if you could cut KSP down to fit in 512 MB without eliminating some of KSP. And this is all assuming somebody is willing to throw enormous amounts of money to micro-optimize a game for an obsolete platform.

I'll hold you up here a sec. By some standards, Skyrim is a very simple game; maybe a few dozen actors at once (in cities), very few interacting bodies (no giant tree structure of mutually-interacting parts such as a KSP vessel), a few projectiles going around here and there, possibly sneak calculations to evaluate; really, not much. What makes it look impressive is graphical glitter, and that's really a separate discussion, because you can to an almost arbitrary extent turn graphics up or down. Not enough VRAM? Use smaller textures. Not enough rendering units? Use fewer polygons. KSP, though, is a hardcore physics simulator where the game must, each physics tick: Calculate aerodynamic forces on each and every part. Calculate gravitational forces on each and every part. Calculate the forces exerted between connected parts. Calculate thermal flux between parts. Handle PartModules. For example, it's got to figure out where to rotate the solar panels, it's got to generate thrust from engines (if applicable), it has to draw fuel from the correct tanks, etc. If CommNet is installed, calculate a path back to Kerbin (probably an A* graph search). Propagate the orbits of all non-loaded vessels (some non-trivial math). Check to make sure that each Vessel is still a Vessel, and that you haven't had any decoupling, planned or otherwise. Calculate the fraction of fuel left to each engine for display. Check all existing contracts to see if any conditions have been fulfilled. Mono says we're out of memory? Time for a GC sweep! And there's almost certainly things I'm forgetting. Even on modern machines, even with vector instructions, KSP can be very badly CPU-limited, and old consoles will scream trying to keep up.

Not really, probably not even if we threw whatever resources it took to make it happen. In terms of a simple port: no. Both of these are written in high-level, partially-interpreted languages, that would require you to write a reasonably modern JVM (Minecraft) or .NET framework implementation (KSP) for the respective platforms. Then, you're still stuck, because they simply don't have the memory or computational firepower to handle what's being asked of them. Even stock KSP takes upwards of 2 GB, probably 3 GB, compared to the 512 MB of the Xbox 360 and 32 MB of the Playstation 2. In terms of something that might possibly run on those ancient machines: only if you basically re-wrote both games from scratch, with a lot of effort put into manually micro-optimizing the respective code-bases... and by the time that got done, I'm not sure those games would look anything like what they do now. Just because games look simple does not mean they are simple once you start digging into the code. For example, with Minecraft, assuming a very generous data structure (1x 8-bit integer for "what block is this", 3x 16-bit integers for "where am I"), the PS2 could barely put a 2000x2000 square grid of tiles (1-deep) into its memory. The 360... maybe, but it would be hard-pressed to do anything else while it was at it.

There's a significant chance your old Dell laptop is more powerful than the 360, anyways. The Xbox 360 is over a decade old by now, and its hardware is creakingly slow by modern standards. Magnemoe's point about the memory is a complete game-stopper; there is no way KSP will fit onto half a gigabyte, quite possibly even if you stripped it down to the bare minimum of parts, removed some of the planets, etc.

Well, there's always my new favorite solid propellant, with a short name of hexanitrohexaazaisowurtzitane, and a full IUPAC name of octahydro-1,3,4,7,8,10-hexanitro-5,2,6-(iminomethenimino)-1H-imidazo[4,5-b]pyrazine.

My two cents on this issue: while it's true that most of these features are already implemented by mods, there are a few things to consider. #1: If we were to list the things that aren't already mods, it would be a very, very short list. #2: By putting it into a DLC, Squad is guaranteeing professional support for that feature for the lifetime of KSP. No more waiting five months and counting for Ferram to release; anything that's in the stock game will be fully supported from day 1 of any given release. #3: Console players, stock players, etc. #4: Features will have input from more people, and probably will be better balanced for relatively casual players; most mods are implemented by enthusiasts, without necessarily much thought about casual players. A good example of this is (once again) FAR vs. stock aero: FAR was made by Ferram for Ferram, with the attitude of "I don't care if your plane doesn't fly well; it's not my problem that the basic cockpit weighs more than a Cessna", versus Squad, whose approach (while substantially less realistic), is reasonably good about letting people fly around on Kerbin. #5: The DLC, while possibly not addressing various bugs and a long-overdue aesthetic revamp, helps pay not just for developing the DLC, but also working on bugs and said aesthetic revamp. I don't think Squad is giving up on improving the core game, although they have certainly devoted a lot of time to the DLC. Personally, while I have no interest in personal parachutes, and only minimal interest in the new parts (I already have way too many mod parts), I'll probably get the expansion for the mission maker, to give that a whirl.

For Mars: mostly water ice, with a thin layer of CO2 permafrost. From what Wikipedia says, there should be about 2.4*10^15 kg of CO2 locked up in the ice caps, which gets you 16.6 kg of CO2 per square meter of Mars. Convert that to O2, it's down to 12.1 kg/m^2. Seeing as how a 1 m^2 column of Earth atmosphere masses ~10200 kg, of which ~2150 kg is oxygen... the Martian ice caps are not nearly enough, nor is the Martian atmosphere (which is far, far thinner than Earth's). For Duna... maybe. Duna's ice caps are significantly larger, and its atmosphere incomparably thicker than Mars's. I was thinking exclusively of Mars when I made that comment, but there's probably enough available CO2 to support life when provided with enough water and temperature. Of course, right up until real-world physics kicks in, and everything explodes because it's way too dense, but I think we're all ignoring that one out of non-explodey convenience. EDIT: Also, still with the caveat that it would take an absurdly long time to convert enough O2 to support metazoan (animal) life.

For the record: that is one of the least correct statements ever uttered about evolution. There have been experiments directly testing for evolution. Numerous techniques in biological research depend on evolution. Antibiotic resistance is a consequence of evolution. Theodosius Dobzhansky summed it up well: nothing in biology makes sense except when viewed in the light of evolution. Now, if you're thinking about the origin of life, that's abiogenesis. Abiogenesis is fuzzier, with a lot less known about how life may naturally have come about; it doesn't help that the vast majority of the original physical evidence has long since been destroyed by plate tectonics. Still, when it comes purely to evolution, you either have to assume it's correct, or that somebody went through a staggering amount of effort to make sure it looked like it's correct. Back to terraforming: Not practical. Certainly not within the frame of a human life. Even given ridiculously optimistic assumptions, it'd still take on the order of a thousand years for algae to produce the same amount of oxygen as is present in Earth's atmosphere... and Mars/Duna doesn't even have enough CO2 in the atmosphere to convert to O2. Also, while probably possible from a coding standpoint... possible does not mean "practical" or "I would want to be the one to do all that hard work".

Hello Sigma. If I'm given to understand correctly, the Atmosphere multiplier basically just changes the scale of the atmosphere curve x-axis (if it's, say, 2, then the pressure at 40 km is what it was at 20 km), while the atmoTopLayer effect extends the atmosphere curve, such that atmospheric effects start more gently. I'm wondering if it's worthwhile for you to A, explain that more thoroughly on the first page, and B, perhaps put in an example, annotated Settings.cfg to explain the typical logic. An example of what I'm talking about is below...