Meithan

Thanks for the update. The Earth looks larger than in the last image.

"This visualization is currently only supported on Mac OS and Windows machines." Aaawww

You are quite correct, sir, that is the Moon. Apparently I got carried away by the excitement and didn't look closely. I stand corrected .

The animations don't do justice to the size of the spacecraft. Wow!

Fantastic! Two hours to closest approach! This picture of the Moon from a distance of 206,000 km just came in: By the way, the Juno flyby will be a chance to study the so-called flyby anomaly, which is the observation that some spacecraft have gained slightly more speed than predicted during Earth flybys. Maybe the stations tracking Juno will provide the data to finally explain it. More details at ESA's blog.

^ This. Despite the inaccuracies it might have (many of which only orbital mechanics geeks like us would pick up), I think the movie is still fantastic. Most of the inaccuracies are relatively minor in the sense that it's just something unlikely rather than physically impossible, and I think they can be considered artistic license in this case. What's absolutely superb is the cinematography: the way they've depicted weightlessness and the environment of space. Simply superb. Add to that the extraordinary visuals (jeez, the Sun ... I remember a shot where the Sun is in the background in all its glory not diminished by an atmosphere and I still get goosebumps), that the acting is solid, that the musical score is great ... and you'll quickly forget about whether the orbit of the debris cloud is realistic or not. I highly recommend the movie.

Edit: Meh, I just saw there's a thread about it already. I did search "Gravity film" in the forums and got no results, I swear! Admins: feel free to delete this thread and sorry for the mistake.

From the KSP Wiki FAQ: "Hold the modifier key [alt if you use windows] and right click the two tanks. You can then click In or Out on either tank to specify the direction of fuel flow."

Fantástico, me daré una vuelta el día de su ponencia y me dará gusto conocerlos. El foro se ve muy interesante además.

Al contrario, gracias a ustedes por escribir un juego tan bueno. ¡Es un orgullo que sea mexicano el equipo! ¿Creen que podría un día pasar a saludarlos en persona? Jejeje.

Your cross-sectional area of 1m^2 looks to be way too small for a 16.7 tonnes craft. This would produce an aerodynamic drag acceleration that is 134 times smaller than the one the stock game would calculate (the stock aeordynamics assume a cross-sectional area of 8 m^2 per tonne). It just doesn't look right. The cross-sectional area used by FAR must be larger. Without knowing the correct number it'll be very hard to get a prediction that applies to FAR aerodynamics. So, what I did was running a test using the stock aerodynamics, using your Cd of 0.36. I simulated starting on a 200 km circular prograde orbit over Kerbin and lowering the periapsis to 35 km. This is how the trajectory looks like: The blue circle is Kerbin, the green one is the atmosphere, and the simulated trajectory is shown as the black and thick magenta lines (the magenta line starts at atmosphere contact; that's the part actually simulated through numerical integration). The black diamond is the predicted landing site position when your craft is at apoapsis (indicated by the blue dot). The landing site leads the apoapsis by about 164 degrees. This accounts for Kerbin's rotation. The landing site and orbit are assumed to be equatorial. My program does not yet have the capability to simulate non-equatorial orbits. Fortunately, KSC is (almost) on the equator so this could be useful for landing at KSC. In order to use this prediction, do the following: 1) Start on a 200 km prograde equatorial circular orbit. 2) Wait until your intended landing site is 164 degrees ahead of you (this can be estimated by comparing your current longitude to that of the landing site). 3) Burn retrograde until your periapsis is 35 km (as usual, you'll have to lead the exact burn point by about half your burn time to get best results). The trajectory should then follow the one indicated in the plot, and your landing site will be below you once you reach low altitudes.

Thanks a bunch, I'll try them both. They appear to do what I need.

Hi. I was wondering what mod provides the ability so save flight data (such as altitude, speed, drag, etc.) to a text file (in whatever format) on my hard drive. I'm asking because I'd like to compare actual ingame data with the results of a simulator I'm writing, and having to take screenshots with MechJeb's info windows open and then copying the data manually to a text file is rather tedious. I know that Telemachus can show the data in the browser, but I'm not sure whether you can save that to disk as well. Thanks.

dlrk: I haven't had much time to run your test but I'll get to it when I can in the next coming days.

Hola Zaryulenko!

Assuming that's the area that's going into the drag calculation, then if you tell me the mass of the ship I can run the simulator. This would assume constant coefficient of drag and constant cross-sectional area. If you want to simulate the parachutes, we'd need to know if opening them changes the cross-sectional area FAR uses (is it computed in a part by part basis?) to compute drag. If they don't, but only change the drag coefficient, then I could simulate them by changing the ship's overall drag coefficient at a specified altitude, and using that new constant value subsequently. To be honest I have no idea whether this will capture FAR's aerodynamics at all, but I can certainly try. What kind of initial orbit do you have initially? I could do the following. Assuming that the craft is initially in a circular orbit of given altitude, I can play around setting the periapsis to several values within the atmosphere, simulating the descent, and reporting how short the actual landing site was of the impact site predicted by the game. That could function as a rule of thumb in the game: set up a maneuver node, lower the periapsis to the one specified by the simulation, and move the node until the predicted impact site in the game is X km ahead of your intended landing site.

Ah, I see. I didn't mean to say that the drag coefficient depends on mass. What I was saying is that if I'm to simulate dlrk's craft path through the atmosphere I'll need to know the mass of the ship too (unlike with stock drag, in which case the ratio A/m is assumed to be a fixed constant and thus the trajectory becomes independent of the mass of the craft -- which is unrealistic of course).

Doesn't FAR report it? I can't run the "real" drag formula without the cross-sectional area. About the coefficient of lift, if it's nearly zero for your craft then I can probably disregard lift, so my calculations should work.

To be honest I'd have to look first at how FAR computes aerodynamic forces to be sure it's what I think it is. Does far compute lift for parts other than wings? Or is there only drag in that case, like in stock KSP? I guess I could try inputting the drag coefficient, cross-sectional area and mass of your ship into the simulator just to see what it outputs. Uhm, please correct me if I'm wrong, but while the drag force is indeed independent of mass (depending only on object geometry and flow conditions), in order to integrate the equations of motion I need the acceleration, and since a=F/m, the mass does matter in the simulation. Picture two ships with exactly the same size and geometry, moving at the same speed in the same air, but with different masses. The drag force will be the same, but the lighter one will experience a higher acceleration, and thus its trajectory will be different.

Only if that's FAR's only change to the aerodynamics. I suspect that FAR also corrects the aerodynamic drag formula to account for mass and cross-sectional area. If such were the case, and assuming your craft's mass doesn't change during the reentry (probably true), we'd need to make sure the cross-sectional area isn't changing, which could again be achieved by maintaining the same orientation relative to the airflow (keeping your craft always pointed in the direction of motion, for instance). If that could also be guaranteed, and assuming those are the only differences in FAR's aerodynamic model, we could use the simulator if we knew the cross-sectional area of your craft. It's a lot of IFs, to be honest.

Have you tried MechJeb2's landing autopilot? I haven't personally, and I hear people say it's still a bit buggy. But that's an autopilot, perhaps you just want a way to predict the landing site to do things "manually". Well, Specialist290 and I have been working on a piece of code that was originally meant to simulate aerobraking, but recently we've also made it work with a promising level of accuracy to predict surface impacts. It wouldn't be complicated to include the option of simulating the deployment of parachutes at a given altitude and have the program include the additional drag. However, at the moment the simulation is 2D, so that would restrict its usability to close to equatorial (zero inclination) trajectories. It would have to be expanded to full 3D for inclined trajectories. I can imagine that one way in which it could work is this: 1) You input your current orbital parameters (your current speed, altitude and periapsis are sufficient) while out of the atmosphere but on a reentry trajectory, and you gauge (by eyeballing) how far your current orbit's predicted impact point (shown ingame by the blue line, which doesn't account for atmosphere) is from your desired landing site, inputting this distance as perhaps an angular distance (something like: "my current orbit would impact 10° ahead of my intended landing site"). 2) The program then simulates the reentry a few times and tries to determine the periapsis that would minimize the actual impact point distance to the desired landing site. This would account for planetary rotation. 3) With this information, you change your current periapsis to what the program reported by means of a burn perpendicular to your current trajectory. However, this would be feasible right now using the stock aerodynamics. Using FAR the problem is much more complicated, as drag coefficient (edit:) and cross-sectional area depend on ship orientation and geometry I believe. That would require calculating the torques produced on the aircraft, which is a whole different ballgame. Also, the process I just described, while feasible, is rather cumbersome in that you have to pause the game and switch to a different program (or use a second computer). What would be awesome would be writing a mod that can show the aerodynamic prediction ingame. If anyone has some mod-writing experience (I have none) and believe it's possible to have the game display arbitrary trajectories calculated by a mod, I'd be happy to collaborate to adapt the simulator for that task. I imagine activating the mod and have the game display the predicted airborne trajectory as a dashed line or something, in addition to the current orbit already displayed. Then, as you applied thrust, it could re-compute the prediction in real-time and show it to you.

tavert already solved this problem in the most general way using optimization software. His analysis blows mine out of the water completely: tavert's fantastic (and very complete) engine efficiency analysis The first half of the graphs are for vacuum applications, and each graph has a different TWR restrictions. Just pick your TWR restriction, look up the payload mass and your desired delta-v on the axes, and the color of the intersection point on the graph will tell you which engine is more efficient for those parameters. His analysis was done in full detail so he's including as many engines of each type to meet the TWR restriction and he's considering the fact that fuel comes in discrete lumps (individual fuel tanks). In the graphs I've shown I'm assuming fuel amount can be increased continuously, which is unrealistic.

Oh, I have no problem with using mods, and I'm aware that MechJeb gives this information. My question was more out of interest and to see what clever methods players have devised. See? This kind of clever method is exactly what I meant! Makes a lot of sense, thanks for the tip. But then this would be just like the Earth, whose rotation axis is not perpendicular to the orbital plane. So planets in KSP that have an inclined orbit do have seasons after all (unlike Kerbin).

About the alleged second stage explosion, Mashable quoted Elon Musk's written response to their article:

By the way, the fact that fuel tanks do have mass also means there is a maximum delta-v for any engine: The 9 here has the same origin as in my previous formula: it's because fuel tanks have a full mass that is 9 times their empty mass. As you keep adding fuel mass to the rocket, the mass of the engines and payload (which is fixed) becomes negligible, but the tank mass keeps increasing (proportionally to the fuel mass). So in the high-mass limit the rocket is just fuel and tanks to contain it, and the total-to-dry mass ratio becomes constant, thus resulting in a maximum delta-v value. For the LV-909, the maximum value is 8406.4 m/s. For the LV-N, it is 17244 m/s.