AceMgy

I picked up a hard sci-fi book about Mars in the library way back in highschool and loved it. Been meaning to re-read it but couldn't remember the name. Is this the one with a big mission to mars with near technology, then a long convoy across the surface in vehicles? The plot on wikipedia about this trilogy doesn't sound all that familiar.

That is what I was looking for. I knew there was a good way to approximate it but I had a total brainfart and couldn't get past it. The good thing about that method is that it's always an overestimate as the TWR would increase as fuel is burned and Mun's gravity is lower as you go higher. I'd still add 10% for safety at least. That does sound very interesting as it's the limit towards total fuel efficiency and potentially safer if done right, however I can't imagine getting my timing down good enough to land perfectly on target like I have been practicing. Plus on Minmus where most of my operations take place the mountains would make that a little too perilous. It's a vertical approach for me, thank you.

I ask this because I seem to be unable to land on a target on the Mun while saving fuel. I just put down a lander with 2000 delta-v and 3.1 TWR on the Mun's surface (yes I know it's over-engineered, but it had to carry two rovers and five kerbals). I landed on target but ended up with 449 dv, not enough to get back to orbit. Now I know my flying isn't perfect and this will probably get better with practice, but I think the descent profile I'm using is bad. Here it is: @ 20km: -200 m/s vertical @ 15km: -100 m/s vertical @ 5km: -50 m/s vertical @ 1km: -20 m/s vertical @ 500m: -10 m/s vertical @ 50m: -1 m/s vertical Thing is, that was just a guess which has a ton of safety room built in. I'd be very interested to know how to calculate the most fuel-efficient descent profile based on the body and the craft's TWR. I'm trying to think how to calculate that, must be something simple, but it's not coming to me... Till then I'll try to get an emergency refueling mission together.

Alright. I decided to do the math and see if burning when a moon rises over the horizon worked in general or just for Earth/Kerbin. I got this: where r_1 is the radius of the spacecraft's orbit r_2 is the radius of the moon's orbit and R is the radius of the planet they orbit. All assuming circular orbits and an instantaneous transfer burn. If that equation is satisfied, then burning exactly when the moon rises over the horizon will get you into a perfect Hohmann transfer to that moon. If my math is correct, then this certainly isn't true for any arbitrary planet / moon system. Do with that what you will.

Yeah I was assuming, as there was no way for me to see the how much it cost for the burn or how high the periapsis was from that image. I think I might be wrong about it pulling you into a faster / slower orbit, that only really works if the periapsis is in front of or behind the Mun (prograde or retrograde the Mun's orbit). If the periapsis is on the Kerbin side or dark side of the Mun (Radial + or -) then it would mostly just change the argument of periapsis instead of adding/subtracting energy to the orbit. That's why the return path has approximately the same eccentricity and semi-major axis but just appears rotated around Kerbin relative to the incoming orbit. I'm by no means an expert and trying to remember this from my astrophysics course, somebody more knowledgeable correct me if I'm wrong, please. If that's the case then you should be able to get the periapsis as low as you want. I see what you're doing now, trying to reach the Mun without maneuver nodes. In orbiter I used to always just burn prograde with the delta glider when the Moon crossed the horizon, just like you're doing. It got me there every time, as the Moon's SoI is large enough to allow for some inaccuracy. So I can tell you it works with the Earth/Moon system too if your thrust to weight ratio is pretty good (the delta glider had stupidly good TWR). My guess is that this "burn when it crosses the horizon" strategy wouldn't work in general for other systems. This is because the phase angle you would get from burning at the horizon would change depending on the planet's radius. For very large planets the phase angle doing this would approach 90 degrees, and for very small planets and/or very high orbits it'd approach 180 degrees. The phase angle to get to the Mun from a 90km parking orbit is about 110 degrees, so this strategy would give you something a little over 90 degrees. That sounds about right. Edit: Just realized I had some errors in my trig when I drew out the situation. Trying to do the math to get you a definite answer if this horizon-burning strategy works everywhere.

Well yeah, for atmospheric drag all you have to do is reduce the magnitude of the velocity vector by a certain factor dependent on atmospheric pressure. It's direction wouldn't change as there's no torque involved. The orbital parameters would fix themselves... And now I realize that the persistence file might save the orbital parameters and not the velocity vectors of each craft. I'm at work so I can't check it, but it would simply be a matter of calculation if that's the case. I can look into it deeper when I get home, but it would be the same as burning a little bit retrograde. Your apoapsis / periapsis drop a bit and the arguement of periapsis moves if you're not at either the apoapsis or periapsis. Gonna have to get my old textbook out.

Well, I typically put all my manned missions in a circumlunar free return just in case something happens in route and they're aren't able to make any big burns. That looks like what you're getting there, although you're encountering the Mun on your return leg. This is more costly both time / delta-v wise, so it'd be best to adjust your burn time to slightly earlier to compensate, you wouldn't need such a high apoapsis to encounter it. It looks like you're coming in from behind the Mun to encounter it, with your Munar periapsis pointed towards Kerbin, then continuing on your free trajectory. Since you're behind the Mun it pulls you forward, flings you out higher, then you fall back to Kerbin. I'm assuming your periapsis around the Mun is pretty high, if it were low you'd be flung way out of Kerbin's SoI which is not what you want. I wouldn't try to lower the periapsis of this orbit for that reason. A better way would be to plan a maneuver like this: You come in ahead of the Mun instead of behind it (meaning you burn before the target indicator hits your prograde marker), and it pulls you into a slower orbit back to Kerbin. Here I have the periapsis at 15 km on the opposite side of the Mun from Kerbin, and it only costs 867 delta-v, much less than what you burned for your trajectory, and only a little more than the 850 delta-v you need to just hit the Mun. Do you know how to use the maneuver nodes? You're gonna want to use them if you want to do free returns with any accuracy.

So your plan would be to periodically check all orbiting craft, calculate the amount of orbital decay based on mission time, then teleport them to their new location? Sounds good but I hope it doesn't overload the game with those calculations: we don't want the game to stutter every time this is done. Shouldn't cause too much problem with rendezvous unless you're planning one way in advance. And I'm assuming it'd be easy to modify the craft's propellant reserves every time this is done? My rough idea for doing my orbital correction module (in horrible, sloppy pseudo-code) was: Player initiates timewarp / changes focus -> Calculate difference from target orbit -> Calculate theoretical delta-v needed to correct if propellant sufficient: -> Subtract amount of propellant required for delta-v -> Teleport craft to proper orbit -> Resume timewarp / change of focus else: -> Cancel orbital correction -> Warning message: "Your station is out of propellant!" But that's assuming you can't teleport a craft when it isn't focused or the game is in timewarp. So could I just wrap this up into a big timestep, say 5 seconds or more? That'd be real-time, not game-time, as timewarp would lag horribly otherwise.

I actually wanted to develop something similar. In the game floating point errors accumulate quickly and can change orbits considerably over time. My idea was just to consider this unavoidable shifting around as orbital decay and give the players tools to manage it. I wanted a module that I could dock to my station, which would then be entered with a target orbit through a menu. It would then automatically (or give data so you could do it manually, not decided yet) correct the orbit using the appropriate amount of propellant available. The problem is that orbits do not decay/change in KSP when you're not within 2.5 km of the craft. This is the nature of the on-rails simulation that is pretty necessary: you'd suffer horrible lag without it. Plus it means orbits are easily predictable for rendezvous and stuff. Your idea would not work unless you were focusing the craft 100% of the time (I believe, correct me if there's a work around somebody), which would be pretty boring. You'd only suffer atmospheric drag while controlling that specific craft. Anyways, I'm not a modder, but I can do basic programming and I've been browsing the tutorials to figure out how to make such a mod myself. This was inspired when I tried to do something that KSP just couldn't do, as documented in my old "How To" thread. I'm mostly posting to say that I'd be extremely interested in any mod that incorporates orbital decay. I have some ideas how to get around the on-rails limitations, though it wouldn't be 100% accurate.

Looks like you removed a lot of struts from that design since I've last checked your thread, Whackjob. Good work on optimizing it. I swear you must really hate your CPU the way you play KSP, it's hilarious.

The best way to learn how to dock is to buckle down and build a space station. Make a concept in the VAB, look up the numerous docking guides, then practice docking from assembling the first piece onwards. By construction's end you'll have nearly mastered it. Now your only problem will be finding a parking space. I swear I cover my stations in docking ports and they always end up like this:

Yeah, anybody here would appreciate it if the trailer approached it that way, but few people outside of this community would. If more people see an accurate and unsensationalized movie about space (assuming what the OP says about it is correct) because of an action-packed trailer, then that's a good thing I think. Although most would probably leave thinking they were mislead and not appreciate it. That's basically what happened to the movie "Moon." (Which is amazing, I may add).

No heat yet, but keep in mind there still is atmospheric drag acting on each part. If you have any weak connections they could pop off. And do remember to pull in your solar panels before entering the atmosphere if you have extendable ones. They simply shatter once you pass a specific mach number. Not sure what value but it's quite low, 8 m/s or so on the surface of Kerbin for example. I've had a probe land successfully but then lose battery power and die because the solar panels popped off.

Thank you so much! This is so much easier than the method I posted.

Any ASAS aboard? This is one of the few instances where it can actually help you. Lock it straight up (important it's vertical) then get a stable hover, then "fight" the ASAS to give yourself a slight amount of horizontal velocity or kill it when you get to your landing target. It's tricky but definitely doable. And it feels awesome to do this hover taxi maneuver for the first time, let me tell you.