PakledHostage

And what if all you have to do in order to survive launch is equip your spacecraft with MOAR boosters, point your ship in the right direction and raise your periapsis above 70 km? The point is that getting to orbit is one of the central challenges of the game. There is currently no challenge to returning from orbit, even though (much like with reaching orbit) there is such a challenge in real life. Depending on how re-entry is eventually implemented, there could be more to it than just setting your periapsis at 40 km and waiting for the pretty "flames" to subside. For example, here's a plot of the re-entry corridor for my old re-entry heat mod: Notice that the survivable corridor was a function of re-entry interface angle and speed, not just periapsis altitude? Even re-entering from hyperbolic trajectories was possible using that mod, you just had to be precise in setting up your approach. Unfortunately, I had to retire that mod because the game's current visual effects aren't consistent with the real-world physics that the mod was based on; there would have been too many complaints about the inconsistencies if I'd left it up. Fortunately, r4m0n filled the void with his deadly re-entry mod, but hopefully the game's visual effects will be improved along with the physical effects when re-entry is finally implemented. It will add meaningful challenge to the game.

Sadly I have to disagree with you. I soak up everything I can about past, present & future space missions, and I love to talk about it with anyone who even so much as feigns interest. In my experience, people imagine the realities of space travel are more like a Hollywood movie than reality. One example that springs to mind is a university classmate of mine. We were both studying mechanical engineering, yet he asked me "what planet the [space shuttle crew] was on" when we saw a story about them on the news. He got mad when I laughed at him, telling me he had no interest in space flight so how should he know. He's since graduated and works as a professional engineer, so he's obviously a smart guy with a strong technical background... If it is possible for someone like that to have such misconceptions, then how bad is it among the majority of people who have no interest in space flight?

I like the t-shirts and bumper stickers, but you know what I always thought would be a good t- shirt or bumper sticker? As a matter of fact, I am a rocket scientist! - Kerbal Space Program I even thought of making one up for myself at one of those T-shirt printing places... Edit: I thought I should add, for the benefit of those who's first language is not English, that the term rocket scientist is sometimes used derogatorily.

Yes, but you obviously need different numbers... You could use 7:8 orbital resonance to space four satellites out around an orbit. In that case you'd use a 147.6 km x 300.0 km transfer orbit to reach your 300 km circular working orbit. You'd just have to wait two orbits between releasing your satellites. It might be difficult to build a 4-satellite launcher that isn't wobbly though, so you might have to do it in two separate launches. The challenge when using more than one launch, as legoheli mentioned, would be spacing the first two satellites and the second two satellites equally. You could use one of the clock mods to help you out. One option may be the Figaro receiver in my GPS mod; it displays UT on its UI so you don't have to switch back and forth between the tracking station and launch pad while waiting for your launch window.

Why not launch 3 satellites at a time as shown in the video below, but use a 1225.35 km x 2868.35 km transfer orbit instead?: The 1225.35 km x 2868.35 has a 2:3 orbital resonance with the geosynchronous orbit. If you release one satellite each time you reach apoapsis and then burn the engines on that satellite to circularise at the 2868.35 km Ap, they'll automatically be in a geosyncronous orbit and spaced at 120 degrees. Circularisation at Ap requires a bit over 170 m/s delta-V, so your satellites don't need a lot of fuel.

This was discussed a fair bit in my Kerbal GPS mod's thread. There's even a video. You can find the thread by clicking on the links in my signature.

About that, maybe a smidge less. It does take some patience to achieve, but some of us like that sort of challenge...

Yes, exactly. Use the first munar gravitational assist to insert into an orbit about Kerbin having a periapsis as high as possible, with an apoapsis that sets up for subsequent Munar encounters. Those subsequent Munar encounters are then used to match orbits with the Mun, thereby reducing delta-V required to enter Munar orbit.

There was a challenge, which unfortunately was eaten by the Kraken, that resulted in the development of a few innovative ways of reaching the Mun efficiently. The objective of the challenge was to reach the Mun's surface from a 100 km orbit about Kerbin using the least Delta-V. Stochasty pioneered the use of a Munar gravitational assist to minimise delta-V required to reach the Mun's surface (yes, you read that right). Other contributors refined the method to improve on Stochasty's result by using multiple Munar gravitational assists. The manoeuvre node system made planning those gravitational assist manoeuvres practical.

Oh, and did I mention we also had to walk uphill through the snow to get to and from school? You kids don't know how good you've got it!

There was a challenge to do just that about a year and a half ago. The challenge required that players jettison everything but the command pod after completing their TMI burn and then coast around the Mun and return to a safe landing on Kerbin. Timing your TMI burn off Mun rise is actually a very accurate method if you put some thought into it. That is how I timed the burn for my entry in the free-return trajectory challenge I mentioned above. Such rudimentary celestial navigation was all we had back then; we didn't have MechJeb, Protractor or manoeuvre nodes. You can easily calculate the angle to Kerbin's horizon from any given orbital altitude, so you can also readily pick a parking orbit altitude that results in the Mun, while just cresting the horizon, to be at the perfect location for you to start your burn.

I'll assume you were joking and forgive the cultural insensitivity of your response... The point is that range safety conditions were imposed on Curiosity's launch that were specific to the RTGs. That is consistent with CoriW's self-imposed requirement for additional contingencies on launches that carry RTGs.

I recall reading in the list of launch window criteria for the Curiosity rover that the launch had to be timed to allow sufficient daylight in Africa for the RTG to be recovered before nightfall, in the event of a launch failure. The trajectory was also not allowed to overfly populations above a certain threshold. I don't have the link handy, but it was in a NASA mission design overview paper.

Another consideration is that a lot of commercial aircraft are leased, and a lot of lease contracts require aircraft to be painted white at the end of the lease. If your livery is white then you can just strip your airline's fuselage and tail markings at the end of the contract and repaint just those areas white. That's a lot cheaper than stripping the whole fuselage and repainting it. And as to the weight issue, it is also significant: So significant that in some circumstances the control surfaces (i.e. rudder, elevator, ailerons) need to be removed and rebalanced after painting. It depends on the aircraft type and the degree of certainty required.

I hosted a “Minimum Delta-V to Duna†challenge thread this past winter that, unfortunately, was lost along with so many good threads. There was a diagram floating around that indicated that the minimum delta-V required for a direct transfer from a 100 km high circular orbit around Kerbin to Duna is about 1040 m/s. One entrant in the challenge managed about 1100 m/s using a direct transfer. I managed to save about 60 m/s off the theoretical minimum for a direct transfer to reach Duna’s surface from a 100 km high circlular orbit about Kerbin using a gravitational assist off the Mun. I managed to get from a 100 km orbit about Kerbin to Duna's surface using just 980 m/s. I could have maybe saved a dozen m/s or so more delta-V had I been a bit more precise, but not much more than that. I still have the screen shots: Starting Fuel Starting Orbit Post transfer burn fuel Planned Munar slingshot trajectory Actual Munar slingshot trajectory Munar periapsis Transfer trajectory – Post gravitational assist Transfer trajectory – Duna arrival Arrival fuel Landed on Duna Math

A couple of threads for reference: Closette's Mini-challenge: max altitude with this supplied spacecraft My Optimal Ascent Profile for this spacecraft Both challenges are old enough that the configurations used will no longer work the same way if built using the game’s current parts, but the findings are still valid. To my knowledge, Kerbin's mass, the drag model and Kerbin's atmospheric properties haven't changed since those experiments were undertaken. Many forum members made exceptional contributions to these two challenges. Indeed, if I remember correctly, some of the analysis and programming that was done by TheDuck, et al in Closette’s challenge was even incorporated into MechJeb’s ascent autopilot.

Dual frequency GPS receivers can detect and compensate for atmospheric/ionospheric effects on the GPS signal in real-time. Otherwise, as Yourself mentions, more generic corrections must be broadcast along with the almanac data.

Stochasty's method also involved Munar gravitational assist to minimise delta-V required to reach the Mun from LKO. Too bad that and so many other good threads were lost...

I don't have a reference but you can work it out with a bit of high school trigonometry and algebra. That's how I did it. The angle to the horizon from a given orbital altitude can be computed with simple trig. That value gives you the height of the spherical cap that forms the visible surface. The percentage area of Kerbin's surface that you can see, from horizon to horizon, is just the surface area of that spherical cap divided by the surface area of the entire sphere. There are lots of references online that will give you the equations for the surface area of a sphere and the surface area of a spherical cap. Ialdabaoth's idea is a good one, but I don't see any point in implementing it just yet. It is his idea and I'd need his permission, plus it adds computational overhead to the module. This game already runs slow on lots of people's computers. Every straw, on its own, isn't a significant load but together they all add to the burden. For now, I figure players can self-regulate. If they want to launch GNSS satellites that don't have any antennas, they are only cheating themselves. It is a single player game, after all...

It means an object in one orbit goes around 6 times for every 5 times that an object in the final orbit goes around. Please see this post for more about this.

Write one equation for orbital period in terms of your circular orbit ( i.e. altp and alta = altitude of your circular orbit ). Write another equation for orbital period in terms of your unknown Pe. Ap (i.e. alta ) in this second equation is equal to the altitude of your circular orbit. The orbital period of the second equation is 1/3 of the orbital period for the first. Therefore three times the second equals the first. Multiply the second equation by 3 and equate the two equations, then solve for Pe.

There's no "right answer". You can put them wherever you want, but putting them into higher orbits means that fewer satellites are required to maintain complete coverage. The equation for the percentage of Kerbin's surface that is visible to a satellite at a given orbital altitude reduces to quite a simple relationship: Here's a table of percentage of Kerbin's surface over which a satellite can be seen, at different orbital altitudes: 3000 km altitude -> 41.7% 1500 km altitude -> 35.7% 1000 km altitude -> 31.3% 500 km altitude -> 22.7% 100 km altitude -> 7.1% 70 km altitude -> 5.2% Note: Visible in this case = at or above the horizon, not taking into account atmospheric refraction. Clearly there's an advantage to placing your satellites in higher orbits but as discussed on the previous page, other factors also come into consideration when choosing a service altitude for your satellites. Some real-world considerations are cost of the launch vehicles, ability to track and update the satellite's orbital elements on a regular basis, the geometry of the resulting constellation, etc.

I'd rather you didn't, but you can go ahead if it is for your own use only. Do not post your modification on SpacePort or otherwise distribute it, however. What you are talking about amounts to adding a few lines of code and maybe adding a 3D model for the transmitter part. That isn't enough to justify having two versions of this mod floating around. If there's enough interest in your suggestion, then maybe I will add it to the plugin. In that case, I will of course credit you for the idea. Thank you for asking.

I forgot about TERCOM and DSMAC... Thanks for the reminder. There's a good article on JPL's Cassini site that describes how Cassini probe is navigated. Among the methods that they use are doppler shift, ranging tones and optical navigation (celestial navigation) to verify and correct accumulated error in the inertial navigation systems.