KSP is not "an hour" of time. KSP is "Oh, hey, I'll sit down for a quick Eve mission at 8PM, hrm, that didn't work, ... ugh, more struts ... right, I'll solve that with a few more boosters ... oh bleep how can that be a relay sat blackout NOW? ... how can it possibly be 6AM? Is that the sunrise?"
Wonderful game, absolutely worth spending money on if you have any interest at all in space. But "an hour," you will not spend on it.
Had a summer job at a web-dev shop some years ago already where the boss had a burn-out, but then to get back to a nice work/life balance he played ksp the entire afternoon at work and let all the devs play too :p
Way more, since a space mission takes many hours it's really hard to suspend. Then it depends how to play. My goal was to visit each planet with a manned spaceship that would land and get back to orbit without drilling for fuel. Some places, but going to Eve required a multi week preparation with multiple giant space stations, engineering an enormous landing ship that almost required a new gpu and cpu and a 3 days full time mission (like, 12 hours per day).
And in 1 hour without ever having played in KSP you probably can lift of the ground and maybe go straight vertically out of the atmosphere.
If you do have a human being teaching you the first hour you can go to orbit definitely. Something as stupid as "you don't go to orbit by going vertically" is very helpful for an inexperienced player.
I've found KSP to have a lot less "one more thing" than Factorio. There's not as much opportunity for "I set out to do this, but first, I need this other thing, which I can almost get if I just add one machine over there and then reroute a few conveyors..."
If you want a slightly less time-sucky orbital mechanics game, then Space Flight Simulator (on Android and iPhone) is really good. It's limited to 2D, but you will still learn a huge amount about orbital mechanics. And it is possible to build and launch a rocket to the moon and back in about ten minutes, once you know what you're doing.
I installed it last weekend out of nostalgia. Turns out you're automatically opted in to analytics that includes identifying information about your specific machine. Opting out is not possible; the game shows you a button which is apparently supposed to open a web page where you can delete the information collected so far but not opt out. (I say "supposedly" because the button didn't do anything for me when I clicked it. It's what I gathered from reading about it on forums.)
So you have to discover that you have to edit two config files to suppress some of the analytics, then download some fan-made Unity Analytics DLLs, that were reverse-engineered from the originals but are no-ops, to suppress the rest.
Yeah. I'm definitely interested in what KSP used to be, but I was late to the party and now these changes make it repugnant.
I wonder if you can still get an uninfested copy somewhere and control patch levels manually.
I took a spacecraft mission design class in college. Every time I tried to search for information, the first 6 google results were from KSP before I got to something based on a real spacecraft.
I wonder if pilots encounter this with VATSIM (searching for real charts or ATC resources and first encountering web pages for the simulation versions).
Not for charts because they are on a company iPad that's way easier than Googling. But absolutely if you just quickly Google something on a procedure or little fact, you get the IVAO (I think V for Virtual aviation organisation?) instead of ICAO and they have lots of docs on it. They seem to be pretty accurate but written in a much more accessible way, and unfortunately have some big mistakes sprinkled across them where whoever wrote it doesn't seem to know why things are done the way they are.
Another one that ranks very well is skybrary.aero on things like de-icing procedures, safety regulations etc.. It's created by Eurocontrol so somewhat official and the information seems very accurate, but they are not really an official source you should use for actual flight planning.
Seconded. Principia is amazing; first thing I did after installing it was set up a Kerbin-Mun L4 orbit.
Another thing I found, due to the full n-body integration Principia adds, is that I was able to correctly guess which side of Kerbin the Mun was on due to tiny perturbations in my craft's equatorial orbit.
Orbiter is underrated compared to KSP, which is recommended nearly always when the topic of orbital mechanics comes up. Orbiter is not only free(ware) but also a fairly realistic space flight simulator.
I came here to leave this comment exact comment. KSP just gives you a better... can I call this "feeling"? of all these mechanics than any theoretical explanation ever could.
If you'd like to try out some of these concepts on your phone, I've been working on a side project -- an iOS mobile game called Solar Express [1]. You can launch a rocket, rendezvous and dock in orbit, transfer between moons and planets, and land. It's a bit like a mini-KSP with real orbital mechanics, but more casual - no rocket building, and lots of delta-V to play with.
Recently my kids had to suffer through 4 Star Wars movies with their parents complaining every time any "spaceship in space" scene appeared, and learned more than they wanted about orbital mechanics, WWII war movies, and why explosions are not heard in space.
> To decrease the orbit radius the exact same procedure, but instead of burning thrust retrograde, you will need to burn prograde.
While I get it, corresponding to the way you explained it a few paragraphs earlier, you mean that in order to slow down you need to burn the engine so that the fire goes out in the prograde direction, this is not how we normally describe it. This is a retrograde burn, because the force acting on the spacecraft is in the retrograde direction.
There are a few points where I feel the author might have been taking force/velocity diagrams a bit too literally (and is a bit sloppy with the difference between force and velocity).
> the following main velocity vectors acting on it:
> gravity acceleration
> thrust
> rocket's velocity
and
> Once in orbit, the spacecraft will have two main forces exerting their grab onto it: the tangential velocity and the gravitational pull.
I'm not sure whether someone new to those concepts would notice, but it's a potential source of confusion.
> Gravity Turn or Pitchover is the second maneuver that is executed as early as possible by using the gimbal of the engines or by using cold gas thrusters on the nose of the rocket or a combination of the both.
Honest question here: do any rockets use their cold gas/RCS thrusters for the initial pitchover? I feel like they wouldn't be powerful enough in most cases to pull it off.
> The velocity vectors are similar to the vertical flight phase but because the gravity acts on the same vertical plane it makes the spacecraft change it's pitch without additional input from the engines, tasking them with the only job of increasing the speed of the spacecraft.
Technically, it's a combination of gravity and aerodynamic forces that cause the pitch to change. Gravity causes the velocity vector to turn, but doesn't exert a (noticeable) torque. It's aerodynamic forces that work on the rocket to (hopefully) keep it aligned with the velocity vector.
This is why some rockets have fins at their base - additional drag at the base ensures that the aerodynamic forces keep the rocket pointed the right way. Rockets without enough drag near their base or too much drag at their nose will tend to flip right around with interesting consequences.
----
That being said, it's one thing to read about orbital mechanics, but it's hard to beat hands-on experience for really wrapping your head around things.
As mentioned in the article, Kerbal Space Program is one frequently-recommended way to go about this, and does a fairly good job with the basics. Not to say that the basics aren't much; you can get quite far with "just the basics", and arguably they'll work just fine for the most common mission profiles.
KSP does use a simplified gravitational model, though, taking into account the gravitational forces of only a single body at a time, which means it's missing some more interesting features of full n-body dynamics, such as Lagrange points and low-energy transfers. If you're interested in those, consider trying the Principia mod, which adds n-body dynamics, non-uniform gravitational fields, and more [0]. There's also the Realism Overhaul mod if you wish to work with more realistic rockets and celestial bodies [1].
Hey, I am the original author, I know I made some simplifications, that blog was meant to attract new people to a STEM group written on a blockchain, and to promote science and tech for everyone. It was a few years ago, I found this thru a friend of mine who reads ycombinator daily and I thank you for the clarifications and for the time dedicated to write it.
What a lovely surprise, have a great week!
Hello, and welcome to Hacker News! Glad to see you here, and thank you for taking the time to respond!
I hope I didn't come off badly there; I'm good at nitpicking, but that's small potatoes compared to taking the time to write out a full blog post.
Simplifications were perfectly understandable given the subject matter, but I think that care should be taken to try to minimize the potential for future confusion. The force/velocity-related stuff in particular I think is important to get right, since those are foundational to understanding the physics. Much of the rest, I think is understandable and a good place to start.
At least one thing you say, to me, is not just a simplification, it's wrong. You are clearly working in an inertial frame throughout the post (which I agree with since it is simpler); but in an inertial frame, what you call "tangential velocity" (it would usually be called "centrifugal force"; you incorrectly use the term "centripetal force" at one point) is not a force. A spacecraft in a free-fall orbit (i.e., rocket engine not firing) has only one force acting on it: gravity. That's why it moves in an ellipse and not a straight line.
> Steemit is a blockchain-based blogging and social media website, which rewards its users with the cryptocurrency STEEM for publishing and curating content, and is owned by Steemit Inc., a privately held company based in New York City and a headquarters in Virginia.
I found their welcome guide (https://steemit.com/guide/@steemitblog/steemit-a-guide-for-n...) and while it's great to see new, alternative social media platforms, it seems a bit complicated. Hopefully they find a way to make all this easier so that new users give it a chance.
In my experience astrodynamics was always taught (undergrad) by ignoring the mass of the spacecraft entirely, since when calculating the forces the mass of the spacecraft and fuel was negligible compared to the mass of the planets.
The mass of the spacecraft, and how it changes as fuel is burned, can of course be ignored when computing gravitational forces, yes. But it can't be ignored when computing things like how much fuel is required for a particular burn to achieve a desired delta-v.
The article touches only on Hohmann transfer orbits apparently. I was hoping it would also cover space rendezvous techniques (v-bar, r-bar, z-bar) [0] and ion thruster brachistochrones [1].
The rocket knows where it is at all times. It knows this because it knows where it isn't. By subtracting where it is from where it isn't, or where it isn't from where it is (whichever is greater), it obtains a difference, or deviation. The guidance subsystem uses deviations to generate corrective commands to drive the rocket from a position where it is to a position where it isn't, and arriving at a position where it wasn't, it now is. Consequently, the position where it is, is now the position that it wasn't, and it follows that the position that it was, is now the position that it isn't.
In the event that the position that it is in is not the position that it wasn't, the system has acquired a variation, the variation being the difference between where the rocket is, and where it wasn't. If variation is considered to be a significant factor, it too may be corrected by the GEA. However, the rocket must also know where it was.
The rocket guidance computer scenario works as follows. Because a variation has modified some of the information the rocket has obtained, it is not sure just where it is. However, it is sure where it isn't, within reason, and it knows where it was. It now subtracts where it should be from where it wasn't, or vice-versa, and by differentiating this from the algebraic sum of where it shouldn't be, and where it was, it is able to obtain the deviation and its variation, which is called error.
Many years ago I worked on a space-flight game. The idea was to create something like Elite, but with a little more cartoony graphics and a strictly 2d flight model.
The physics behind it was fairly accurately modeled; you can ignore the 3rd dimension for a lot of orbital mechanics. The scales were unrealistic, the gravitational constant was tweaked for more fun, but the actual Newtonian formulas were correct. Orbits behaved properly and so forth.
The hard problem was adding NPC space ships. I had simple requirements: Have a spaceship at location X and velocity vector Y, accelerate and move to location X2, slowing to a stop as they reached it, taking into account intervening gravitational wells. I naively thought that was a simple solved problem that I could find the answer to with a little googling.
Well, it's not, at least at my level of mathematical knowledge.
I made it work, though. Not by exactly solving a god-like deterministic formula, as Newton himself would have, but by tweaking an algorithm I found from the early days of guided missiles.
It's an interesting algorithm. It basically worked this way: Ping your target, and figure out by what angle you're going to miss it at your current heading. Point your rocket at double that angle delta. So, if you're going to miss the target by 10 degrees to the left at your current heading, point your rocket 10 degrees to the right of your target. Continue thrusting.
Repeat, many times a second, and the angle you're missing by becomes smaller and smaller, until BANG. And, because it's really a fly-by-the-seat-of-your-pants heuristic, if gravity is pulling you off course, the correction automatically increases.
I had to do a little addition, like chopping the trajectory into chunks if there was a major gravitational body in the way, because the algorithm broke if you got too close to a planet.
Oh, and guided missiles accelerate until they hit. I had to have ships accelerate to the halfway point, turn around, and then decelerate until they stopped at the destination. It was fairly simple to find the point at which they would need to begin decelerating in order to hit zero speed at their destination. The fun part is that the guided missile algorithm still worked, but you just had to change it so you maneuvered based on the point exactly opposite of the target.
The takeaway is that the exact 'correct' solution to the problem was hard; practically unsolvable, at my expertise. But it was easily managed by implementing a few simple behaviors into the NPC ships, which were really not very different than how a player with a little learned intuition would pilot. As a bonus, I think they were more believable that way. They flew more naturally.
