UmbralRaptor

Wikipedia is actually an okay place to start. If you have a bit of a Math/Physics background already, I\'m partial to Fundamentals of Astrodynamics. Basic(?) formulas that I find useful: ?V == Ve*ln(mi/mf) Circular and escape velocities: Vcirc == ?(?/r) Vesc == ?(?/r) Orbital energy: E == v²/2 - ?/r (E<0 for circular and elliptical, E=0 for parabolic, E>0 for hyperbolic) E == -?/2a (Circular and elliptical orbits only, I think) ? == m*G (Iff the object you\'re orbiting is much more massive than you are. This is always the case in KSP) ?Kerbin and ?Mün are in the KSP wiki. semi-major axis and eccentricity stuff: Pe + Ap == 2a Pe == a(1-?) ?p == a(1+?) ? == (Ap - Pe)/(Ap + Pe) Ap/Pe == (1-?)/(1+?) T² ? a³ (and in the case of the solar system, T² = a³ if T is in years and a is in AU) T = 2?/?(a³/?) (? == 0 for circular, 0 < ? < 1 for elliptical, ? == 1 for parabolic, and ? > 1 for hyperbolic orbits. Granted, Ap goes to infinity for the last 2, and T becomes somewhat undefined...)

The Excel file opens fine in LibreOffice, so it should work on most-any system. That said, the tech levels listed in it are 1 higher than in the spoiler (1-7 vs 0-6). I\'m guessing you want to change one of those? ...and so it begins. ;D

Eep. Be safe?

So the trees will be sufficient to silence them, then? Excellent...

Silbervogel: (Old HP Pavilon) Pentium 4 3.2 GHz 1 GB DDR2 Ram ATI Radeon X300 Some 250 GB HDD Windows XP MCE 2005 Keldysh: (HP x4400 -- yay for old workstations) Core2Duo E6600 2.4 GHz 4 GB DDR2 RAM (with some really weird timing) ATI FireGL V7200 2 TB WD Caviar HDD. (The newest piece of hardware in it.) Windows XP Pro (32bit) KSP runs on both of them, and quite well on Keldysh. Yes, this means that if you\'re careful, KSP will run on mid-range 2005 hardware.

Quick! Send them on a Kerbol escape trajectory before they can tell the others!

As mentioned before, the navball will tell you a *lot* about where you\'re facing and how the ship will turn. Look to it more than the spacecraft. If you\'re looking for additional maneuverability, RCS and vectored thrust engines help greatly.

More control authority (winglets, RCS, vectored thrust), maybe? Certainly, they can help stabilize otherwise problematic designs.

Welcome to the forums. It\'s annoying when that happens -- all I can suggest is starting firing the engines late in descent, especially in an atmosphere. Granted, it\'s easy to crash into terrain at hundreds of m/s that way (especially on the mun)... >_>@augerman: Please have posts that consist of more than image macros/reaction images? =/

Additionally, will some objectives be mutually exclusive? Perhaps by category? For example, a suborbital mission that achieves 80 km altitude and 1200 km ground distance cannot also take 50 km altitude and 600 km ground distance. Similarly, an orbital mission is disqualified from all suborbital range/distance objectives. That said, there could be a lot of mixing and matching of orbital objectives, as they do not overlap so thoroughly. eg: a ship might be able to easily achieve a 200 km retrograde orbit or a kerbostationary orbit, but have difficulty doing both in a single mission.As for the excel file, does this mean that we should ignore the cost of mechjeb in the VAB and always treat it as free?

Ooh, sounds like fun. Turns on consistent days of the week (eg: Mon/Wed/Fri or Tues/Thurs/Sat) might well be simpler. I suspect that we\'ll need to discuss who has what days open. Then again, one could design ships for various missions/budgets beforehand, meaning that submissions will be relatively quick/easy. I\'m partial to 2-3 turns per week. Rules questions: How will skipping ahead/going back for missions be handled? Eg: if the first person to do an orbital flight does this before anyone has achieved an ICBM, do they get credit for both? Would the 'lesser' achievement remain at full value or be diminished? If I have the budget, can I submit multiple flights (with the same, or varying craft and/or objectives)? Is every item in a level of the tech tree individually researched, or are they done as a group? How will part recovery be handled? (Do they need to survive impact, or is it enough to parachute them down? If the former, will parachutes better than the Mk 16 be available?) A balance suggestion: the tricoupler should probably be a lower level unlock (or have a substantially cheaper research cost) than the radial decoupler. Otherwise, there is sadly little reason to use it with current stock part balance.

Yay, rounding error. ;P Drop the empty mass of the half-tank to 0.15, and they\'ll offer identical performance.

Specifically, half-tanks have ~5% higher Isp, but the better mass ratio of full tanks outweighs it under most (all?) situations.

Yes, though they tend to be rare and thin.

Yeah, they look like renders. I\'m reminded of the images at space4case, actually.

We\'ll see -- gravity drag losses hurt this badly. Maybe if I have an initial Ap of more like 40 km...? edit: I think a more continuous ascent profile is in order? edit 2: I *think* reversing the tank order makes a difference here. Also, pitchover runs into some harsh issues. Too early, and aerodynamic drag kills you. Too late, and gravity drag does instead.

I managed to badly mistake the design -- I thought it had 2 full tanks. :-[ I don\'t suppose that Kosmo-not\'s approach is acceptable? Same amount as tankage as what you\'re going for, though higher overall part count.

It\'ll still have enough ?V. eg: What Foamyesque did back in February.

In principle, it has a good enough mass ratio for orbit. However, the TWR is a nightmare. It might be easier with an LV-T30 or 45. >_> edit: best I\'ve done with this is ~2100 m/s at ~55 km. Grr...

Meh, it\'s easy to get student licenses for a slew of AutoDesk products. Good for classwork, messing around, etc.

0.8.4, some time in July.

As long as you\'re careful to use 'save as' and what advanced features you use, it\'ll be fine. (advanced meaning new stuff in 2012 and/or plugins from the various vertical programs AutoDesk has)

*grumble* The difference between falling short of the Mün\'s SOI, and overshooting it is something like 36 m/s. For the amount of velocity we have to burn through to hit LKO (and TMI), this difference can easily be caused by alignment errors.

Varying drag coefficients. IIRC, something with especially draggy parts will slow down at higher altitudes, while one with especially low drag parts will need to go lower into the atmosphere to avoid multiple passes.I suspect you\'ve worked it out in more detail?

To answer what I can: It\'s because KSP only calculates gravity from one body at a time. If you\'re not within the Mün\'s Sphere of Influence, it cannot effect you. The rule of thumb is that you want the drag on your rocket to be about the same as gravity. For low TWR rockets, just leave it on full throttle. For high TWR (stock) rockets, Closette made a table: Which one is preferable depends on if the orbit has some specific property you want. A 90° orbit requires ~350 m/s less ?V than a 270° orbit. I *think* it\'s just a coincidence of geometry, but am unsure. Yep. I tend to do whatever. If you want a slow, low G reentry when coming in from the Mün, aim for a periapsis of ~30 km. (Ship dependent)