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.

Hey, it's an exciting idea. So exciting that a mistake in my math made me want to fly to Jool immediately and try it out. I'd name your telescope the James Kerbin space telescope, since the James Webb space telescope is essentially what you were trying to recreate whether you knew it or not. I'd give it a slightly larger solar shield to account for the fact that you'll get the full heat of the sun, and plenty solar panels on the sun side to power the cyrogenics aboard. It'd certainly still be possible to do it that way in real life if you had to, just expensive, and Kerbals don't care about money when it comes to space exploration.

Since I always believe in posting my work, I've meticulously typed out my proof twice. The forums deleted the first draft Values: M = mass of sun m = mass of planet R = semimajor axis of planet r = semimajor axis of satellite T = period of planet t = period of satellite G = gravitational constant Kepler's Third: 4 pi^2 / T^2 = G M / R^3 Finding period of planet: T^2 = 4 pi^2 R^3 / G M T = 2 pi ( R^3 / G M )^(1/2) Finding period of satelitte same way: t = 2 pi ( r^3 / G m )^(1/2) Now equating these, as that's the only way you get such an eclipsing orbit: 2 pi ( r^3 / G m )^(1/2) = 2 pi ( R^3 / G M )^(1/2) r^3 / G m = R^3 / G M r^3 / m = R^3 / M So the axis of the orbit is: r = R ( m / M )^(1/3) The definition of the sphere of influence radius, or Hill sphere: R(soi) = R ( m / M )^(2/5) We want this value bigger than r to work: R ( m / M )^(2/5) > R ( m / M )^(1/3) ( m / M )^(2/5) > ( m / M )^(1/3) ( m / M )^(6/5) > 1 ( m / M ) > 1 m > M So you see, the mass of the planet would have to be greater than the mass of the sun for this to ever work in KSP. Not likely...

Bah... I'm so silly. My equation is correct, I've just flipped an inequality when analyzing it. Turns out this can only work if the mass of your planet is bigger than the mass of the sun in KSP, which would never happen. The problem you ran into (and myself, when I followed your math) is that you used the synodic orbital period, which is not what you want. You want the period of the orbit itself, without regard to the surface rotation of the planet. I had forgotten that siderial and synodic periods take the rotation of the planet into account, so it's the completely wrong number to use. So, no. It's not possible in patched conics to achieve this orbit, and therefore impossible in KSP sadly..

This feels so wrong, but I checked the math several ways and it seems to work... Perhaps you've found an inaccuracy in patched conics that you can exploit, but I'll leave it to an expert to say for sure, I merely took a class in Astrophysics (which I enjoyed immensely). I'm going to come at it from a different direction, using the definition of the hill sphere and Kepler's third law to see if this is true in general that you can't be stable at the L2 Lagrange point in patched conics. In the meantime why don't you go ahead and launch a light-weight probe to Jool, and see if it's battery runs out due to no sunlight. I'm intrigued. So far I've gotten the nice result that such an orbit would have a radius around the planet of r = R cuberoot( m / M ) where: r = semimajor axis of satellite around planet (this is all assuming circular orbits) R = semimajor axis of planet around sun m = Mass of planet M = Mass of sun This looks nice and all, but is just wrong. Plugging in the definition of the hill sphere gives the result that this is possible for any planet which has a mass less than the sun, which is nonsense. I'm gonna take a break for now.

You seem to want to put this telescope at Kerbin's L2 Lagrange point relative to the sun. While this is possible in real life, and in fact a telescope is planned for this specific orbit, it isn't in KSP. The reason is simple: KSP doesn't model more than one gravitational body acting on you at a time. You've probably noticed this when you switch sphere of influence to another planet / body that you're acted on by that object's gravity only. It's not likely to be possible to do for a long time, either. This is due to two reasons: 1. The L2 Lagrange point is unstable, it'd have to have frequent small corrections made to its orbit to keep it there just like in real life. This would require some sort of mechanism to automatically control craft when you're elsewhere, which is troublesome due to the on-rails nature of KSPs engine. 2. The most important reason is that increasing the number of gravitational bodies acting on your spacecraft would at least double the performance requirements of the physics engine. Even more importantly, it makes it so orbits aren't exactly predictable, so the on-rails system that saves so much performance power doesn't work again. Sorry... =/ Does your telescope really have to have an eclipsing Kerbin?

RCS balancing is a must for quick, painless docking. This thread changed docking forever for me, try it. It's the unwanted translations / rotations that make docking annoying and time consuming. And the lag just means you have too many parts (building a big space station, huh?). Either do more with less or just learn to deal with it, no way around it. Edit: Oh and align your docking ports normal + and normal - (on the navball, where the North line crosses the horizon, similarly for the South). Those are the only two points that won't move on the navball, that way you can be assured you have perfect alignment and can concentrate on translation.

So, I've found a solution / workaround that works pretty well. I've put KSS at an 85 km orbit so it'll always be at least 5 km away from DVS which orbits at 80 km (the rendering distance is 2.5 km, so a spacecraft can never render both at once and lag horribly). This means there is a transfer window every 48 hours between them. That normally would be horribly annoying, since you can't timewarp that fast in LKO, but I remembered that I had downloaded a mod and never used it. So I extracted Kerbal Alarm Clock into my KSP folder and tried it. After working with it today, I've found that I can just use mechjeb to calculate when the next window will be, then set an alarm 20 mins before it happens, then do other stuff! Or I could just follow one of my high-orbit satellites until it's time. It works extremely well, plus I'm now managing several probe missions at once now, this should definitely be in the stock game when campaign mode comes out. They're not in the same orbit, so I don't have the aesthetically pleasing situation of two stations hovering right next to each other. However, this is almost preferable: if you actually had two stations that needed transportation between them with minimal delta-v, and one was an explosion hazard, you'd arrange them just like this. They're only close once every 2 days, and the rest of the time progressively far away, so the chance of an explosion wiping out both stations is essentially nill (not considering the debris an explosion would produce, but it would be relatively low velocity), you just have to plan ahead to transfer at the right windows. So I'm in the process of building KSS among other things. It's coming along nicely. Wish I had the ability to create an SSTO to build it with like the shuttle did with the ISS but oh well... I'll consider this thread answered, even though I technically didn't achieve what I wanted. I had a question for the modders who may be lurking: would it be possible to create an active orbital correction module. The way I would do it would be to have an orbit monitoring module, which would open up a menu where you could enter the desired orbital parameters. Then at a cost of propellant and electricity it would keep it there. Obviously it'd be tricky to implement with KSP's on-rails physics, but the way I would do it would be to have it actively push the station around when out of timewarp, then if you timewarp or select something else it'd teleport it to the target orbit, calculate the theoretical amount of propellant required to do that, subtract that propellant from the reserves, then put it on rails... I don't know if you can modify the game that deeply and I'm barely competent at programming...

Those are some neat rocket designs. Had no idea you could fit that many LVs on the back of an orange. Yeah, and my insistence on playing this as a pseudo-campaign mode does take time. Really annoying when an update comes out and you have to do everything over again (I can get to the Gemini program pretty quick now). I've actually done a lot more than my medals in my sig show, I've just decided that they should only apply to my current save to help me keep track of things. I just had a save delete itself on me, but I'm almost to the point where I can start mining Kethane again. I can't wait for the real campaign mode comes out, but then I'd have to deal with money. So far I've been assuming a space program where the public is as eager about space as I am and are liberal with funding. I've been fuel-efficient, but I'm not sure if that translates to money efficiency considering the amount of infrastructure I build to do one mission...

You mean the LV-N's? I'm okay with using those, although now that I think about it they're pretty advanced being rocket engines with 800 isp. I don't think there's any rocket currently that could match that efficiency but it's at least feasible in the near future. Even with those you can burn a lot of fuel with heavy loads. Perhaps I am being a tad bit too efficiency-minded, but I had to split my station design in two due to lag and that's introduced another drain on my precious fuel (which is shipped clear from Minmus, mind you).

Believe me Veeltch I get that, I wasn't attacking you. But right now I'm more satisfied with emulating a space program as accurately as I can in KSP than I am with difficult challenges. I start with atmospheric rockets, move through the historic missions like Vostok, Mercury, Gemini, then up to Apollo and beyond. Takes a damn long time but is very satisfying seeing a whole space program grow like that under your maintenance. Sometimes KSP has trouble doing things that would be pretty trivial in real life (like having two space stations near each other) and I have no problems using mods to overcome these limitations.