PakledHostage

Notwithstanding what is in the Wiki reference that sal_vager gives above, there seems to be two camps. Units of kilo Newtons (kN) and metric tonnes (t) also work out. In my opinion, it makes more sense to use kN and t because it fits the scale of the parts. Typical Kerbal rockets are on the order of tens of metres tall. It makes sense that rockets of that size would have a mass of several thousand kilograms, rather than several kilos.

Or you could look at the value given in the map view. Hover your mouse over the Pe and Ap icons to see how many seconds you are away from each. The difference is half the orbital period.

I'd do it by calculating the mass of the celestial body and then calculating the surface gravity. This will be trivial if you know the body's radius, but it will only be a little bit more complicated if you don't. If you don't know the body's radius, you'll need to solve for two unknowns (radius and mass) simultaneously. The easiest way to do that within reasonable experimental error would be to enter a circular orbit around the body and record the orbital period (from the map view) and orbital speed (from the navball), then enter the values in the equations for orbital speed and orbital period and solve the system of equations for M and r. Once you know those two values, you can easily calculate the gravity at a given distance from the centre of mass. You can find the equations for orbital speed and orbital period of circular orbits online. You can also readily find the equation for gravitational force at a given distance from the centre of mass. (I’d post the equations myself, but imgur isn’t working for me this evening.) You could achieve higher accuracy by using the equations for elliptical orbits together with data acquired by flying elliptical orbits in the game (because it is very difficult to achieve a nearly circular orbit and a circular orbit may not be a good approximation), but the algebra is more complicated in that case.

You can do it by timing transits in the map view, timing rise and set times of celestial bodies from orbit and the surface, etc. It is an interesting geometry challenge and it works great. I am sure that there are other methods too. I have never held a protractor up to my screen.

But, with all due respect, it is possible to do these things without using the mods we've been discussing and without resorting to trial and error. There are plenty of examples in these forums.

Right, but for a lot of players, they give too much information. Orbiter's MFDs give a lot of information too, but I have read comments from a number of regulars on these forums that they can't get into Orbiter they way they've gotten into KSP. I think that is because Orbiter is a space simulation, while vanilla KSP is more of a physics sandbox. I think it is great that mods like Protractor, Kerbal Engineer and MechJeb exist for people that want to use them, but including their functionality in the vanilla game would only alienate those who don't want to use them. The way it is right now, we've got the best of both worlds.

Clearly MechJeb, Protractor, Kerbal Engineer, etc. are popular, but they are also controversial. I don't see them going away, but I hope the fact that they are controversial keeps them out of the vanilla game. For everyone who enjoys using mods like this, there's someone else who wouldn't touch them. For me, crunching the numbers and planning my flights so that they can be executed precisely, despite the limitations of the vanilla instrumentation, IS the game. I probably spend 2 to 3 times more time planning my missions and designing my rockets than actually flying them. It is what has kept me hooked on this game longer than any other that I've played. I know I am not alone in this either.

Thanks. I'll have a look at those mods. Mr Pwner is making a new heat shield part using his own transparent texture for the bow shock effect. He's making significant progress on it. Once he's got it done, I will have to revise the re-entry heat plugin module to display his model's bow shock at the correct times.

I wonder if your problem isn't actually due to the game bug that HarvestR mentions in his most recent v0.17.1 development Blog? It says there that they "Fixed a problem that could cause parachutes to despawn when travelling at high speeds." Can you post a screenshot showing your assembly? What planet are you trying to land on? How steep is your trajectory? The MK1-2 pod heat shield has a mass of 0.25 mass units. The Mk1-1 pod heat shield has a mass of 0.05 units. Neither shield should affect the opening of your parachute if you open below Mach 2.0. The module doesn't care what speed the chutes fully deploy at. It only destroys the chutes if they initially deploy above Mach 2.0.

Here’s my entry. I landed 3.3 km from the pad. No mods, no retries. I left Jeb in orbit for about 5 hours so that he’d land in daylight. I timed my de-orbit burn off my final over flight of KSC. While I didn't use any mods, I did calculate the timing of my de-orbit burn and my re-entry trajectory in my own spreadsheets and software.

@Tommygun: MrPwner sent me a PM about the work he's been doing to create a transparent bow shock effect. It is a complex problem because he needs to develop a custom transparent texture. As far as I know, the work he's doing has never been done on any other KSP addon. He has made significant progress on it, so we should be able to add the effect soon. @Nibb31 and Togfox: I will be flying a mission to Duna this week coming up. Probably on Wednesday when I next have some time to play the game. I have characterised Duna's orbit, built a rocket to carry my atmospheric probe there and calculated the launch window. I'll test the heat shield in Duna's atmosphere after I fly that mission.

I suspect that it actually does work (i.e. glow and display a plasma trail) if it is attached to a vessel made of stock parts. For that matter, the bug may even be in the addon part that you had it attached to, Togfox... In my module, I check the game's built-in "vessel.isCommandable" flag to decide if certain things should happen. Maybe that flag isn't being set correctly in the unmanned part mod that you are using? This would explain what you're reporting. Has anyone used the heat shield for a Duna landing using stock parts? And about setting different heat transfer coefficients for atmospheres other than Kerbin's: This actually does have some basis in reality. For example in the case of Mars atmospheric entry, I've read that radiation heat transfer causes heating of the re-entry vehicle, while it causes cooling of an Earth re-entry vehicle. This would make a significant difference on the amount that the re-entry vehicle heats up.

Thanks. I'll look into it. What if you try it without jettisoning the heat shield? It could also very well be because you are using an unmanned pod. I do a check in the program for whether or not the heild is connected to a commandable vessel. That may not work properly when used with an unmanned part. It may also be because Duna's atmosphere is very thin. I have never actually flown there myself so I don't know anything about it. (I set myself the goal of reaching each of the new planets NASA style... That is, the first time I try, no pressing f9, and with the smallest rocket possible. That requires a bit of planning.) If it is because Duna's air is thin, then I will have to tweak the atmosphere specific constants for Duna. I will also look into how hard it will be to add simple sound effects. And I'll add the effect that I discussed above. It won't be for a week or two though.

Sorry, I've been avoiding answering this question... Sound effects can be tricky because you need a believable recording that you can then "play" and distort according to some physics model. I have only done it once in another application that I developed, but it was a royal pain in the rear to do... It isn't my highest priority at the moment, but I would be happy to integrate someone else's sound effects class library if they wanted to collaborate on this project.

The problem is that the vector sum of the lift and drag components shown in the "Earth Re-entry and Landing" figure above should be collinear with the velocity vector, unless real lift is being generated. I would have to experiment because I don't know how the game's physics engine simulates these forces. My knowledge of hypersonic aerodynamics is limited but clearly, in real life, the asymmetric supersonic/hypersonic flow and shock pattern around the re-entry vehicle generates a significant lift force on the re-entry vehicle when it is given an angle of attack. I have no idea how this supersonic/hypersonic lift force compares to forces on a subsonic re-entry vehicle flown at the same angle of attack, however. If someone reading this has expertise in this area, I'd be happy to read an explanation! Below is a plot produced by the Hypersonics CFD Group at the Indian Institute of Technology, Bombay. The plot shows a CFD prediction of Mach number distribution in the pitch plane of an Apollo-shaped capsule at Mach 4.9 and angle of attack of 14 deg.

Thanks, everyone for your input. Having thought about it a bit more, I think I'm going to add a lift effect. I will make it so that it can be enabled with a "hardcore" flag in the part.cfg file. The default will be off, but people who want it can turn it on. I haven't implemented it yet so I don't know how it will work, but I expect that the lift force will affect the map view trajectory in real time. That should give an indication of where you'll end up as a result of the steering. I won't make any promises as to when I'll get it done though. I think I've used up my quota of tolerance for my Kerbal addiction... And it is Canadian thanksgiving this weekend so I won't have a chance to work on it until next week at the earliest.

I can't speculate what they are composed of but I always liked the fact that, much like our beloved kerbals, they are kind of dense...

I was actually thinking of maybe changing the inherent stability function to give the re-entering command pod a slight angle of attack and adding a small lift force component. That way Apollo style re-entry trajectories could be flown: The Apollo capsules' centre of mass wasn't located on the capsule's axis of symmetry, so they would naturally re-enter at a slight angle of attack. That slight angle gave them a bit of lift. I figure I could simulate this by offsetting the reference vector that I use in the inherent stability routines. The reference vector is fixed to the spacecraft and is always held in alignment with the retrograde vector by the inherent stability functions. The reference vector is currently pointed straight out the top of the capsule. I could rotate it so that it is still coming out of the top of the capsule, but adjusted a few degrees away from the hatch. I could then simulate a lift force, which would be oriented perpendicular to the direction of travel and towards the hatch. You could steer the capsule slightly during re-entry by rotating the crew hatch towards the direction you want to deflect your trajectory. What do people think? Would that complicate things too much? Would it make re-entry too difficult? You could end up skipping and then burning up on the second re-entry (because you used up some of your shield integrity during the first dip into thicker atmosphere), and you wouldn't be able to "turn off" the lift force if you wanted a straight-in ballistic trajectory. Having said all of this, part of me wants to leave things the way they are because I want this mod to add something to the Kerbal experience, but I don’t want it to make things so challenging that nobody uses it.

For what it is worth, just because nobody has submitted an entry doesn't mean that nobody is working on your challenge. I think it is a great challenge and I will probably give this a go over the winter. For the time being, I'm characterising the orbits of the new planets. Accurate orbital elements will be required if I am to succeed at your challenge and at the challenge that I have also set for myself (to send a probe to each planet, at minimal cost, the first time I try, no do-overs).

These might be two of the ones you're thinking of: Closette's Mini-challenge: max altitude with this supplied spacecraft. The conclusion there seemed to be that climbing at terminal velocity is about optimal (at least in the vertical ascent case). Achieving this profile requires a fair bit of throttle modulation during the climb. There's also the Optimal Ascent Profile for this spacecraft challenge. These challenges pre-date v0.16 so the performance of the test spacecraft configurations have changed. The designs were intended to be easy to fly, rather than to have peak efficiency. It is also interesting that the human pilots did better than MechJeb in the Optimal Ascent Profile for this spacecraft challenge.

Nice job! You're well ahead of me. I'm currently working out all of the details that I need in advance of my first mission to Duna. My first mission will be a one-way unmanned lander. I'll wait with sending Kerbals until I know more about the planet.

I can't see the image you posted (it shows as a broken link on my computer), but why not try to limp home to Kerbin if you can? Live to fly another day...

You could also build a little lander to practice hovering and landing at home before you fly to the Mun, like they did during the Apollo program. I spent a lot of time practicing hovering and landing at KSC before I ever attempted a Mun landing.

Yup, it was intentional.

The physics model that I use in this module estimates the temperature of the atmosphere behind the supersonic shock that the command pod creates as it re-enters. It is a compressibility effect rather than a friction effect (much like how the bottom of your bike pump heats up when you pump up your bike tire). The model assumes that the supersonic shock is detached from the spacecraft (i.e. a normal or strong shock) rather than a weaker oblique shock. The equations that I use for this are really only valid for air and up to about Mach 5.0, but this is a game not a physics simulation so I'm taking some liberties. The results are in the right ballpark, relative to the expected values. I then calculate the temperature of the heat shield due to convective heating effects, again making some gross simplifications because this is after all just a game. You can read more about the physics model that I use here if you are interested. As for why coming in more steeply causes less heating than coming in at a shallow angle: You are exposed to the highest temperatures for less time when you re-enter steeply, as compared to when you enter at a shallow angle. Think of it like fried ice cream or waving your hand through a flame. You can expose objects to very high temperatures for short periods without appreciable heating. When you do a very steep re-entry, the spacecraft slows down so fast due to atmospheric drag that it doesn't have time to heat up. In that case, the spacecraft is destroyed by g-forces, rather than heating. I regard this effect as another piece of evidence that the re-entry heating physics model is actually working the way it should. In the case of the Duna entry, maybe try going for a more shallow entry angle? The limit for the parachute is Mach 2.0, so you can open it at greater than 400 m/s. Maybe I need to expose the parachute Mach limit in the part.cfg file? That way it could be set higher if it needs to be. That being said, I referenced Curiosity's parachute's Mach limit when I chose the Mach 2.0 value. In real life Mars entry, speeds are considerably lower than for Earth, but the heat shield still needs to be very well designed. According to Table 1 in the JPL paper "2011 Mars Science Laboratory Mission Design Overview", Curiosity reached Mars with an atmosphere relative entry speed of about 5.5 km/s. That is roughly 2 km/s less than the shuttle's re-entry speed. Even so, radiation heat transfer effects are more significant during Mars entry than for Earth entry. My best guess as to why is that Mars' atmosphere (mostly CO2) is a strong greenhouse gas that reflects heat rather than transmitting it.