Pand5461

I'd say, it must be a fair bit, probably a few hundreds m/s. Communication satellites: more dV = more lifetime, about 15 m/s per year is needed to maintain position at GEO. With modern satellites being active for 10 years and more, that gives at least 150 m/s. Orbital probes at other planets: all the same. Manned spacecraft: Soyuz has about 350 m/s after separation from the launcher. Space Shuttles had about the same, IIRC. Apollo could be fueled to 2 km/s but LEO was not the orbit that ship was designed for. Buran could have about 1500 m/s if the program was not cancelled.

Pretty much anything done with kOS. Watching a rocket lift off, go into inclined orbit and finally get a satellite into a perfect orbit for a contract - and the satisfaction because you told it to do so, not a MechJeb developer... This is better than magic, it's rocket science!

Right, ε is the only term that can change the sign. But the specific energy is not supposed to do that near circularization. @Rareden are you sure you use ε= v2/2 - μ/r in your calculations?

That's strange. You cannot ever get a negative under the root with physically correct values. I agree with @YNM, you need to stick to the OP formula and use the magnitude of that vector as scalar eccentricity (and direction if you need to find the SMA orientation). See this stackexchange post to see how to get a full set of orbital elements from the cartesian representation.

Ещё может двигатель быть ещё тёплый после работы и нагрева при входе в атмосферу, а в океане водичка, да ещё и солёная... Ну и становится такой "возвращённый" двигатель настолько же пригодным для повторного полёта, как и просто шмякнувшийся без парашюта.

Именно так. Поэтому их нужно не то чтобы переводить, а пытаться угадать поисковый запрос, по которому игрок хотел бы эту деталь увидеть.

@mrvice, @DAL59 you basically want CommNet play with pre-CommNet mission planning. In than case, why bother? Just switch off "probes need signal for control" switch and enjoy no loss of connection and whatnot. The whole purpose of CommNet is to include signal occlusion, so some of the previous techniques either become impossible or require more care.

@cratercracker ротор и дивергенция будут?

@ItsSeanBroleson I think it is intentional to make "natural" craft orientation in airstream at angle to retrograde. That way, capsule bottom serves as a lifting surface and allows maneuverability in air by rotating around the axis of symmetry. In real mission, this is used to reduce g-loads on reentry and for precise landing targeting since Gemini. If you want the stock behavior, find the file GameData/VenStockRevamp/Squad/Parts/Command.cfg and comment out all the lines that change CoMOffset.

LOCK STEERING TO VXCL(UP:VECTOR, -VELOCITY:SURFACE).

@Grand Ship Builder I've been trying for the last 6 hours to reproduce that chart and fail constantly. Can you please explain how to properly make it?

Check out Kerbal Construction Time mod. It makes ship building long, so "I can be doing something else" won't be a thing anymore.

Note to self: not believe schematics from Wikipedia. I tried to draw a mental picture, and seems like speed increases after night-side flyby if it's the ascending branch of trajectory, and after day-side flyby if it's on the descending branch (ascending is Pe to Ap, descending Ap to Pe). To the point, however, gravity assists should work roughly in the same way in full n-body physics and in patched conics. @Nittany Tiger Velocity vector indeed just turns in the flyby body-centered frame. But that can be interpreted as spacecraft getting some velocity vector. If that vector is directed same as planet prograde, the spacecraft transfers to a higher orbit, if the vector change is pointed to planet retrograde, to lower orbit. The vector change in velocity is pointed towards the planet center. So, to get the most boost to the prograde velocity, the flyby periapsis must be close to terminator (i.e. not right opposite to the Sun but rather at the "retrograde" side of the planet).

Does not look wrong to me. Look at the Cassini mission plan: both Venus flybys are on the dark side. EDIT: It's unclear about the first one, the second one is clearly on the dark side.

Alright, done the Mun flyby. Cost 9,090 funds, can be counted twice because I needed some... erm... simulations... to get the correct timing. Full album here: https://imgur.com/a/a6wGx

@Nittany Tiger DOACTION is a suffix of PartModule, not Part. So, you need to find the module that has Decouple action and call LES:GETMODULE("SomeModule"):DOACTION("Decouple", True). And please, try to make a minimal script that show the problem and paste this, instead of a large chunk of code mostly unrelated to the question.

@MajorMushroom after you're at 1 km separation, you just need to keep relative velocity marker on top of the target marker . As a rule of thumb, speed = (distance to target)/(20 seconds) is a reasonable value. You may zero the relative velocity at a few dozen meters from target, I usually do that at 20-30 m. Exact matching of orbits is not really necessary, in fact, you need a slightly different orbit to complete the rendezvous. So, there's nothing wrong if, say, periapses differ by 100-200 m and a bit shifted relative to each other. To keep velocity and target marker aligned, you may use RCS. The rule is, J and L keys move velocity marker left and right, respectively, and I and K down and up. H and N accelerate or decelerate the ship in the current facing direction.

@sevenperforce, you are right, OMS circularization started about 30 minutes after MECO (according to Wikipedia). This basically means that MECO was almost at the perigee of a suborbital trajectory at around 120 km altitude. There's a thread discussing the Shuttle guidance algorithm. I looked at the equations - the guidance does not intrinsically rely on the coast between MECO and circularization. But a coast phase was explicitly specified, so that was what guidance algorithm should adapt the ascent trajectory to. I'm not sure what could happen if the algorithm was told to insert the whole thing into 200 km circular orbit. I think it could find a suitable pitch program, question is how much more fuel such trajectory would require (given the increased gravity losses because Shuttle would need to climb at a steeper angle to get to 200 km in basically the same time it climbed to 120 km in the real flights).

Spending +30% OMS fuel for orbital insertion would've left the Shuttle without fuel to deorbit. However, the ET could probably hold enough hydrogen and oxygen to get it into orbit. The main reason not to do it was to avoid leaving a huge uncontrollable piece of debris that could later fall anywhere and cause damage.

Lightworks (as in free beer), Cinelerra (as in free speech, Linux-only).

And you did not mention Soviet designs. But concerning the actual advice, it rather supports it than disproves. No need to worry or throttle down if starting TWR is higher than 1.3 or something. More TWR = less gravity losses. I watched the numbers carefully, you went full thrust up to 3.1 SLTWR. It's just you have to have a really unorthodox design to make throttling down before TWR = 3 put you into a better trajectory. Ah, by low-thrust burn I meant "not at max throttle". That's a consequence of control theory. The full sentence should be "for a fuel-optimal trajectory, engine must always be either at max throttle or min throttle". In KSP, that means either go full throttle or coast. In RL, rockets usually don't coast and don't throttle engines, so rule is satisfied. Also, RL rockets typically go without coasting to much lower (compared to planet radius) orbits than KSP ones do. 75 km Kerbin orbit transforms into roughly 800 km Earth orbit, and spacecrafts do coast to reach that orbits. Finally, the control theory does not say exactly how many coast periods is optimal, so more than one might in fact be needed, and it does not say if coast is a lot or just barely better.

@Landwalker glad you figured out how to fight your problem. As a side note, I would like to point at the few things you can learn from the @Streetwind's video. 1) The ideal on-the-pad TWR is usually about 1.5-1.7. Real-life designs usually have it closer to 1.2-1.3 but that's because mass difference between fully fueled rocket and rocket at lower stage burnout IRL is much greater than in KSP, so that pad TWR of 1.5 would result in unacceptable g-loads midflight. 2) Start turning as soon as you reach TWR > 1.2, meaning you can start pitching right off the pad with 1.5. 3) Aero effect animations are misleading. You may have pretty impressive plasma effects while having in fact very little drag, so don't be afraid to go red. The overheat gauges is when you need to start worrying. 4) You absolutely don't need to throttle down before reaching TWR of 3 (and maybe even more if you're pretty high in atmosphere at that point). Trying to keep constant TWR is just going to increase gravity losses. If you're worried about high vertical speed, pitch down more aggressively. You don't need to throttle down at all while at vacuum (other than for the sake of precision). 5) Cutting off engine, coasting to apoapsis and circularizing at full thrust is more efficient than a long low-thrust burn. And a couple more things regarding multistage rockets. 6) CoM shifts up as you burn the fuel, so first stage generally becomes more stable as time goes. When you stage, positions of CoM and CoL change very suddenly and that may cause instability. Therefore, it's better to turn surface prograde before staging, especially in low atmosphere. And try not to design things that need staging at 300 - 600 m/s (the typical maxQ region). 7) Do not jettison anything in unpowered atmospheric flight (e.g. when you coast to the apoapsis). Lower stage or a fairing don't affect the cross-section (and drag force) much but increase mass, hence with them attached you get lower acceleration (or, rather, deceleration) from drag. And a note on this thing Some may infer that this is untrue because Tylo and Eve have massively different dV to orbit while having similar size and gravity with Kerbin. But don't fall to that common misconception, drag losses on Kerbin are truly that low. The difference is mainly to the fact that you can't follow a good launch profile on atmospheric planets and have more gravity loss due to need to go upwards at launch for quite some time (and even worse, you need to do it when the engines have the worst performance).

And, by the way, what's so difficult about matching orbits with another spacecraft? Yes, it requires more-than-usual mission planning. But hey, why do you think mission planning for getting to an L-point must be simple? Another reason not to add the faux orbits is the educational mission of the game. For the educational purposes, the physics model must be scientifically sound, have the minimum of arbitrary assumptions (I will call them "magic" further on) and have good illustrative examples. The model with the least magic is of course the true n-body physics. It has L-points, it has Keplerian orbits in the 2-body case, it has naturally occurring orbital resonances and the equations are really easy to write down. The only "magic" is the inverse-square law for forces. Unfortunately, it results in barely predictable and chaotic trajectories in reality and not amateur-friendly at all. The patched conics approximation mimics the problems of spaceflight quite accurately, inherits the Keplerian orbits and makes orbital paths more regular and more predictable. The trade-off is that we need another bit of magic - sphere of influence definition. But at least there is some scientific explanation for patched conics - it's what true physics reduces to if we only count the body with the strongest gravitational pull at the point spacecraft currently is. Introducing faux L-points without true n-body physics is just adding more magic for the sake of more magic. It's not the next approximation to the true n-body gravity after the patched conics, it's cherry-picking of some effect "we want to see in the game".

@sevenperforce If you increase SOI radii for Mun and Minmus, you can get Kerbin-synchronous orbits there within the patched conics approximation. Can easily be done with Kopernicus and cfg tweaking. L3-5 are already stable and easily reachable. Gilly's orbit is probably too elliptical to have stable L-points, and Jool system is too complex to have them stable. And I disagree that adding faux L-point is not computationally complex. Given that I have a save with broken patched conics, I'm certain that adding new type of objects with weird dynamics is going to spawn countless bugs.

@wumpus managing a huge half-empty tank in microgravity is... complicated. The CoM just won't stay in place relative to the control thrusters. IIRC they even vented all remaining hydrogen before tank jettison. This, I guess, was the reason why its possible use was as structure, not as a tank.