Starman4308

Considering the utterly strange geometries KSP players come up with, I'm not so confident that it would be an easy task to do automatic parts welding in a coherent way that doesn't create giant exploits. For example, your suggestion about welding a wing together? Might work great for a sensible wing design like a delta wing. Not so if somebody decides the middle of the wing should be very narrow. Without parts welding, that narrow section would be a weak point liable to snap in a turn. With parts welding, that weak section is... not. One of the neat things about the current implementation is that it's reasonably good at treating not only ordinary geometries, but also any insane contraption players come up with. While parts welding would fix some issues like noodly rockets, that should really be addressed by giving part linkages more realistic rigidity. It was cheap, and had a fully functioning rigid-body physics engine. Some of the paid alternatives have "better performance", by which they mean "more ways to optimize graphics calls", which doesn't help for rigid-body physics at all. I don't know offhand of any engines with a significantly higher-performance, well-tested rigid-body physics engine, which is likely at least in part because not many games need it. Most games don't need to handle assemblies of hundreds of linked parts: KSP is very much an exception in that regard.

As you can probably tell, I'm not a sharpshooter. I went out shooting once with my uncle, and it was kinda fun, but hitting the target at 10 yards does not exactly make me a sharpshooter or ballistics expert. Regardless, for most games, it's not an issue. Call of Duty and many other popular shooters occur at such short range I'm not even sure drag is relevant, and certainly not long-range tumbling effects. Something like the ARMA series might want to model it out of utter dedication to simulation realism (as I understand, ARMA is the Realism Overhaul of first-person shooters). However, even then, you're probably looking at pre-computing ballistics under a variety of conditions, and then using lookup tables or curves, rather than trying to do computational fluid dynamics on the fly for every bullet in the air. Even hardcore simulation players generally accept some compromise in the name of performance.

Next few days are likely to be a tad repetitive for me. Each of these Voyager probes takes about 1.3 years to build on either of my KSC production lines, and for maximum redundancy, I'm building 4 of them... which means tying up all of my KSC production for almost 3 years. I have a couple other active facilities, Vandenburg and Palmachim, but due to not having safe eastwards azimuths, they're relegated to routine commsat (Vandenburg) and sounding rocket (Palmachim) launches to farm cash. I suppose maybe I could light up another site like Baikonur or Korou, but I just dropped 3 million funds on getting the R&D building upgraded, so I'm not exactly flush with cash right now to give it any production rate or launchpad upgrades... and that's after a bit of save-file editing to undo the mistake of starting the R&D upgrade from Palmachim with its slow rate instead of KSC. Plus, the next item on my agenda is dropping a half-million to unlock the F1 engines. The only semi-exciting moment from the past two days of launching commsats, sounding rockets, and a couple more Gimel mass demonstrator missions was another E1 engine failure. As you can probably tell, having an engine fail while launch clamps are still attached is not exactly terrifying. Literally just press X, recover vessel, and roll out the backup rocket. I lose about 180 days worth of Vandenburg production and that's it.

It's not necessarily so much a lack of talent, so much as that the talent doesn't have millions of dollars to sink into an R&D project to develop a high-performance rigid-body physics engine capable of handling all the weird geometries KSP players throw at it, plus more money to test it until it's ready for commercial gameplay release. With time and effort, the programmers at Squad might do it. Unfortunately, optimizing the game engine is not something that would pull in enough new customers to justify a multimillion-dollar coding project. Probably the biggest reason Squad chose to go with Unity at the outset was that Unity already had a tested rigid-body physics engine. That logic hasn't changed: it would still be more effort than it's worth for Squad to try to parallelize the physics engine.

I can't speak for the bugginess, but that comment suggests the reviewer has a poor understanding of computer science and the subtleties that differentiate KSP from most video games from a computer science perspective. The PS4 does not have "power". It has 8 Jaguar cores clocked at 1.6 GHz and 1152 GCN graphics cores clocked at 800 MHz, along with 8 GB of GDDR5 memory. These cores do not Voltron into a mega-core. They do not have a magic wand to magically separate compute problems into numerous compute threads. They do not drive a common shaft to propel a vehicle. They do not combine their spirits to more quickly draw memory out of RAM. They do not benefit from the power of friendship. They execute streams of instructions assigned to them, and if the programmer can't figure out how to efficiently split the problem at hand into multiple instruction streams, you're stuck running on a single 1.6 GHz CPU. This is not necessarily because the programmer is inexperienced, but can potentially just be because it's not a problem that lends itself to being split up. Let's take a space-related example: predicting the trajectories of maybe 5 planets over time. For now, I'll ignore parallelization overhead issues that would make this example really stupid to try to parallelize. You can split that up to some extent. You can assign one thread to each of five planets, that figures out what the force of gravity is from each of the other 4 planets. Instead of one core doing 20 force evaluations, you can have 5 cores doing 4 evaluations per timestep. Ideally, this is a 5x speedup. You can split it up even further: 20 threads, one for each pair of planets (though, really, there are just 10 pairs, but both ends of each pair need the distance). You're at 20x speedup. That's the limit for this problem. In order to calculate the forces of gravity at timestep n+1, you must first have the positions at timestep n. You can't try to do timestep n+1 and n at the same time, because n+1 is dependent on timestep n. This means you have to take timesteps sequentially. There is no point to trying to assign 40, or 400, or 40 million cores to the problem, because you can only split the work up into 20 threads. Rigid-body physics happens to be one of these types of problem where it's really hard to efficiently break it up into multiple chunks of work. Not only that, but each time you try to parallelize something, there's a good chance you make a mistake and introduce a bug that produces incorrect results (this has happened in my lab, multiple times!). Programming a single-threaded rigid-body physics engine is enough of a challenge; attempting efficient parallelization under arbitrary geometries is not a task you should expect a small, indie game studio to handle.

The solution is either a heatshield, heat resistant parts, or reserving some propellant for a reentry burn SpaceX style to reduce thermal loads on the rocket. It's Deadly Reentry, not Nice, Fluffy, and Soft Reentry.

So, I said that if Gimel-4 reached 45 minutes in LEO with at least 6.5 km/sec left in the tanks, I'd use it, instead of the Gimel-6, to launch the Voyager probes. It did. You may ask, "why is this so exciting that he would begin writing this post about a simple mass demonstrator mission a mere hour after his previous post?" To understand this, we must first look to the performance of the first stage boosters. Just to the right of the delta-V panel, the panel with the red "E-1"? That means one of the four E-1 booster engines completely failed, with a substantial amount of propellant still left in that tank. Soyuz-Agena launches cannot survive such an event: the RD-107 boosters they use simply cannot gimbal enough to compensate for complete loss of thrust on one engine. This meant very difficult flying, as well as the depressing realization that I'd need to run another test just to be absolutely sure, and the time to the Grand Tour window is getting gobbled up. Nevertheless, I perservered, jettisoning the now-deadweight booster. It was at about this point, igniting the Centaur final stage, that I realized it might just make it to orbit with enough delta-V to spare, despite losing a booster. Needless to say, the Gimel-4 booster has been authorized to carry the Voyager probes. Though... let me double-check the NASA's Eyes program to double-check at what velocity the Voyager probes left Earth. Looks like 43 km/sec Sun-relative at Aug. 20, 1977, 10:33:42 AM, vs. 29.8 km/sec of Earth's relative velocity, so about 13 km/sec, which is pretty reasonable for a direct Earth-Jupiter injection. I think, then, the Voyager window doesn't require any weird higher-than-normal-energy Jupiter transfer.

I've gotten a couple things done. A new, much more sophisticated GEO network is in place with synodic periods measured in millenia. These all used the Titan-Centaur booster: the satellite itself is almost absurdly small on top of the Centaur upper stage used for GTO insertion. The Bet 4 booster was tested, and found lacking. The primary issue is simply that the upper Centaur stage and core RD-108 stage are underpowered, resulting in excessively high pitch to maintain altitude. With a higher-thrust core, perhaps a 3-engine Centaur would have been enough; with a higher-thrust Centaur stage, perhaps the RD-108 core stage would have been enough, but both combined simply took too long to burn through their fuel. A competitor design has been proposed for the very important Voyager probes: the Gimel-2/4/6 series (yes, I'm now blatantly using the Hebrew alphabet in series). Each uses a quad-engine Centaur upper with a 6'30" burntime (as opposed to the 7'50" triple-engine Centaur of the Bet series), and 2-6 E-1 kerolox boosters. The primary difference is in the core stage, which replaces a single RD-108 kerolox engine with a pair of LR87 hydrolox engines, producing more thrust at a higher specific impulse than the old RD-108... unfortunately also at a much higher cost. To be absolutely confident in the critical Voyager missions, coming up in five years, the first Gimel-4 mass demonstrator will use a 2.6-ton mass simulator, similar to the Voyager probes. If it cannot provide a 6.5 km/sec ejection burn after half an orbit, the Gimel-6, despite its 33,000-funds cost, will be used. If I had a level 3 launchpad at KSC, I might try instead for just an even bigger mostly-kerolox booster to save on costs, but right now, I'm limited to 800 tons, which is just enough for either the Bet-6 or Gimel-6 boosters. Past that, Mariner VI was sent on a mission to orbit Venus. While once again the S1.5400 second stage failed, there was enough margin in the Agena stage to not only finish the injection burn, but also have some left over for maneuvers all the way to Venus.

Improbable. KSP runs on Mono/C#, which has its own memory management. It's not impossible to have a memory leak, I've seen them before in Java which has similarly managed memory, but you have to be doing something unusual in a managed-memory language to get a leak. Usually, memory leaks occur when somebody allocates a block of memory and forgets to later de-allocate it. Managed memory programs generally don't have that issue because Mono, or the JVM, or whatever, actively looks for unused pieces of memory to reclaim them. The only way to get a leak in a managed-memory language is if some 3rd party API holds outdated references in some ridiculous chain, or they are something like an infinite-loop thread, which is a GC root and thus not subject to garbage collection, or some other bad behavior. Most of it is either the rigid-body physics, which is just a really difficult computational problem, or people running KSP into the ground by modding or huge part counts.

It's been looked at, and found to be utterly ridiculous.

I sent a repeat lander to the Moon, this time landing near the poles. Except, I lie, it's not a repeat lander: it had 30 kg more science, and replaced the hydrazine monopropellant system with an MMH-MON3 bipropellant system, increasing both thrust and delta-V despite having more science onboard. Between the improved lander propulsion, the S1.5400 not failing this time, and replacing the Soyuz 1 booster with Soyuz 1.1, there was a stupendous excess of delta-V remaining aboard the craft, so it was decided to attempt a suborbital hop northwards. The last transmission indicated the lander had run out of propellant with significant altitude and vertical speed remaining. It is clear that, while relatively efficient for landing from orbital velocities, the landing program sent to the probe is horribly inefficient for high-arc suborbital hops. After that, I launched the first Titan-Centaur with a mass simulator. While significantly more capable than the similar Agena E thanks to wonderfully high-performance hydrolox, significant boiloff occurs within a single orbit (150 m/sec of 691 m/sec remaining once in orbit), suggesting that launch windows be carefully planned to minimize boiloff. After that, I have authorized construction of the first Aleph-Centaur 402, based on the 2/2/2 RL-10/LR-105/E-1 architecture I talked about yesterday. This will likely be used for preliminary long-range manned Gemini missions. Finally, I designed an unmanned LOR mission with fully 49 kilograms of scientific equipment, including two biological samples. When all is said and done, almost 7 tons will need to be sent to lunar injection. Even the recently designed Aleph-Centaur 402 can barely carry that to LEO, nevermind lunar injection. To handle this payload, the Bet-4 and Bet-6 boosters have been designed. These use a 3-engine Centaur upper stage. The core stage uses a single RD-108 sustainer engine ignited on the ground alongside 4 or 6 E-1 boosters. The Bet 6, with LEO payloads, barely scrapes inside the 800-ton launchpad safety limit, but has an estimated LEO payload of 27 tonnes, with a preliminary estimate of 8.5 tons to lunar injection. And yes, the Bet 4 looks a bit like a supersized Soyuz. It's also the first time I've used the Saturn 1 avionics; everything else needs at most the early 3m core with 300 tons capacity. EDIT: Also, 6 years to the Grand Tour window, with improved electrics (and truly long-range antennas) coming off the stack soon. Methinks I'll be be using at least quartet of Bet 6 launchers to set that up.

I have to pick only one? Anyways, I'd have to say my greatest moment in recent history was installing Test Flight to simulate my launches before actually building them with KCT. Test Flight does not actually let you do test flights. It's a part failures mod. One rocket going sideways later due to asymmetric engine flameout, I discover the part failures issue. It took at least one more launch for me to figure out it also introduces a rated burn time feature, and that it's a really bad idea to burn an engine for longer than that.

Part of it is potentially craft size. The smaller you are, the more affected by aerodynamics you are, thanks to the square-cube law working against you (until you size up). For dynamic stability, ensure your center-of-pressure (center of drag) is behind your center of mass. You can still get to orbit with a mildly dynamically unstable rocket, it just means constant corrections because aerodynamics is always trying to pull you off surface-prograde. While IMO it's cheaty (real-world tanks drain from the top!), it can be productive to set fuel priority so that the bottom tanks drain first.

If you cannot reproduce this behavior in a clean-room environment with no mods and minimal background processes, you have no reason to blame Squad. If you cannot reproduce it with minimal background processes, you don't even have reason to blame the modders.

No. You quite clearly don't know how it works. By saying "I've built PCs for 10 years!", that means you can pick some parts off a shelf and slot them into place. You haven't worried about cache latency. You haven't worried about thread interference. You haven't uncovered decade-old bugs in code your PI wrote when he was a grad student. You haven't had a very thorough and practical grounding in the difference between O(n*ln(n)) vs. O(n^2) as your less important simulations run O(n*ln(n)), but your thesis work requires an O(n^2) algorithm. You haven't cursed as you used dozens of server-grade supercomputer nodes and wished you had more. You haven't made slides to show the newer students what parallelism and GPU acceleration are. You haven't wondered why a certain, ordinarily super-quick, part of the code was running like molasses until you figured out your PI added an O(n^3) debugging check that worked fine for him but slowed the whole program to a crawl on the still-modestly-sized system you were working on. You haven't idly changed divisions to multiplies-by-reciprocal as a micro-optimization. No, you're not even remotely as qualified as other people on this thread are to comment on KSP's performance.

It's very hard to compare performance based on anecdotes. One person may be running < 100-part vessels, another person might be trying to make 1000+ part monstrosities. I peg the probability that he has driver issues as very low, and the probability that he's trying to either run a heavily-modded game, or large part-count vessels, as much higher. Other games have significantly less resemblance to high-performance computing. Have you listened to a single thing said in this thread by people with actual computer science backgrounds and degrees? Your sense of entitlement does not outweigh the fact that KSP is trying to do something far more ambitious physics-wise than other video games: full-on, rigid-body physics simulations of hundreds of linked parts.

Progress was made on the auto-lander script! Shortly thereafter: The issue on that run is that I had final landing set to initiate burn if vertical velocity got above 4 m/sec... but I should have checked if it was below negative 4 m/sec. That run still somehow landed with antenna intact. But no more shall I talk of developing that script! Instead, have a Soyuz-Agena launch! Here is the S1.5400 engine burning. It was subsequently reprimanded for stopping in the middle of lunar injection. Agena-lander separation, after Agena used its last 300 m/sec to begin descent: High-gate took a long time to complete, since I hadn't very carefully checked the descent stage thrust, which provided a mere 1.2 lunar TWR at engine ignition. By the time high gate completed, I was at 13.4 km altitude, such that I gained 100 m/sec before the first low-gate engine ignition. And success! Note that the RCS thrusters firing is because I completely forgot to disable MechJeb steering beforehand. Mariner V managed another Venus flyby, discovering 2 biomes it hadn't found on the prior flyby. Unfortunately I don't think I'm going to be able to get it into Venus orbit: it's down to just a few hundred m/sec of delta-V, and this polar flyby affected inclination a fair bit. I also designed a new vehicle I'm calling the Aleph-Centaur 402/442/482, based on a dual-engine Centaur, a 2x LR105 sustainer stage, and a 2x E-1 first stage with 0, 4, or 8 Castors, though I'm going to wait about 300 days before I test it. I'll have to compare that design to "slap a single F1 engine under that Centaur", because I'm about to get the F1 from heavy rocketry.

Don't forget that empty KSP tanks and KSP engines are way heavier than they should be. By the time the F9/FH boosters/FH core hits the boostback burn, they've lost so much mass that even a small burn produces a large change in velocity. For perspective, one of my RP-0 boosters has a 2.5 ton payload capacity, and an Agena upper stage of maybe 8 tons tops. The E-1 stage beneath it starts at 1.4 TWR... and hits 13 at MECO, delivering 6000 m/sec of delta V. By MECO, that first stage is basically a tin can with a giant engine on it.

I really, really liked that ARMA video. Never played the game, but some of the elements resonate for a lot of sandbox games. KSP, people will build ships bigger until the engine cracks like an egg. EVE Online, alliances will cram ships into a system until the servers groan and collapse. ARMA, apparently they build gigantic maps until the engine decides to go on strike. I forgot to address this one earlier. I think part of why I've been arguing from the angle of "this is actually a really hard problem" instead of "an indie developer shouldn't need to address this" is that I'm familiar with the limits of high-performance computing: I'm not familiar with the limits of a small indie game developer. I don't want to run my mouth on something I'm not familiar with, so I argue things based on my experience in HPC and physics-based simulations (albeit at the molecular scale, not the macroscopic scale). Nice to see another HPC guy on the forums! Unfortunately I have no idea whether rigid-body physics is 100%, full-stop non-parallelizable, or just really difficult to parallelize because of the need to access shared fields.

Multithreaded physics libraries mostly deal with non-interacting objects. You can calculate the flight of a thousand bullets in parallel, but ensuring consistent rigid-body linkages on a single assembly of 1000 parts is a different story entirely. Dynamic welding of might sort-of work, but then you have to come up with criteria for the welding and de-welding, and then come up with a way to tell Unity's rigid-body physics engine that they are welded, and then figure out when they need to be de-welded. Much simpler just to pass everything along to Unity's rigid-body physics engine. Remember: stuff breaking for reasons such as high aerodynamic loads is very much an intended feature of KSP. If you're going 600 m/sec, and then decide to point your rocket 90 degrees east, your rocket should break apart. Also, physicsless parts aren't. Their physics now just get added to the parent part. I think there are some experimental efforts to do highly parallelized rigid-body physics, but they sure haven't trickled down to the Unity engine. The limiting step is and was calculating rigid-body physics. Optimizations to things like heat transfer are fine, dandy, and worthless for the purpose of speeding the game up. Things like stable, landed bases are, on the whole, rather edge cases. Most of the time, you have to have the rigid-body physics running. Your ship's spinning at 0.1 degrees/second? Great: now you need to keep the ship from flying apart. Again, maybe you could do dynamic welding, but that would be a complicated and tricky bit of coding that's likely to create bugs for unforeseen edge cases. For example, your stable, landed base: what happens if you crash a rover into it? Does the whole, welded base blow up, or can you be sure that you'll detect that event in time to de-weld the parts? Leaving the rigid-body engine running is guaranteed to handle almost all situations well in terms of maintaining consistent Newtonian physics, whereas shortcuts are almost certain Kraken bait.

You may wind up eating Falcon 9, Tater. Congress might find a scrap of integrity and cancel EM-2.

Not all that much, except for writing a 158-line kOS script to perform an automated lunar descent, and testing it (oh so many times!) in a sandbox game. At 1.2 light-seconds' delay, I could probably do it manually with some practice, but it would be invaluable for, say, Pluto. Not that I've gotten anything anywhere near Pluto. And when I do, I'll probably be careful to ensure my probes have > 5 kB of script storage space. It's not even fully finished yet, and I've started removing comments and old methods to keep it within 5 kB. I've had some amusing discoveries along the way though. After writing Rube Goldberg methods involving getting the topvector to get horizontal and vertical velocities, I then discover there's SHIP:GROUNDSPEED and SHIP:VERTICALSPEED. In a similar vein, I struggled with ALT:RADAR's limitations and wrote a script to granny the altitude estimates until that became meaningful... and then discovered a code snippet that gets the terrain height. In general, my approach is: Burn surface-retrograde until vertical velocity exceeds a threshold. This is Powered Descent Initiation. Then, pitch up to an attitude that should give 0 vertical acceleration. Use Baby's First PID Loop to help keep vertical velocity at that threshold with an error offset to pitch. This is the High Gate logic. If altitude drops below a threshold, re-run the high-gate method with a target vertical velocity of 0. The high-gate method completes once horizontal velocity drops below 10 m/sec. This is "Low Gate" (terminology 100% stolen from the Apollo missions). The low-gate method locks steering to surface-retrograde. It then keeps track of the estimated altitude that would be reached by a suicide burn: if this goes above 15% of current altitude-above-ground, engines are set to min throttle (often 0% thanks to Realism Overhaul!), if it goes below 5%, engines are set to max throttle. This continues until altitude < 100 meters, at which point I throttle up when speed dips below 2 m/sec, and throttle down when it goes above 4 m/sec. That continues until altitude reaches 5 meters, at which point the throttle is cut. The high-gate method is tested: if nothing throws a nut, I should proceed to first test of the low-gate method. Once that's reached, it'll either land or not land. Either way, it'll be exciting to watch.

Indeed. NASA is doing nothing whatsoever. They're not, for example, managing: Juno, Kepler, ASTER, AIRS, ASE, Cloudsat, Dawn, DRS, DLRE, GRACE, Jason 2, Jason 3, the Opportunity and Curiosity rovers, Mars Odyssey, the Mars Reconnaissance Orbiter, MLS, the Spitzer space telescope, construction of JWST, the Space VLBI, WISE, and the Voyagers. Absolutely. Nothing. Once Musk actually delivers on a very-low-cost SHLV and the plethora of systems that would be needed for a Mars trip, plus extensive tests of that equipment, then I might believe him. Not before. Too many broken promises, and too many unrealistically optimistic plans.

Personally, I'll count SpaceX lucky if they manage a BFR launch by then, nevermind a Mars mission. Musk is no superman: just a charismatic man with some money to sink into reusable orbital rocketry right as compute hardware became powerful enough to support precision landings, and before the established companies had gotten over their conservatism enough to try it.

You could probably do that just by storing a precomputed ballistic coefficient for the bullet, which saves on the cost of ever having to actually worry about the bullet's shape. Sure, it would change a bit as speed decreased, and if a smoothbore round began to tumble, that would have a huge effect on ballistic coefficient, but you could either have a precomputed lookup table/curve for ballistic coefficient vs. speed, or, more likely, ask yourself exactly how important this is to gameplay and just store a single ballistic coefficient.