Vector

This is a fun challenge. I just did a mission using starting parts, high and low flyby of all Jool's moons except Bop, and got a bonus high-altitude Eve flyby on the way home. Didn't bring a transmitter for crew reports tho. I had plenty of fuel left over, so I'll have to give it another go (with a transmitter) and see what all I can get.

In real life engines are expensive. In KSP everything is free, so who cares if you throw away extra engines. Liquid engines can be treated like SRBs.

This sounds fun, I'll definitely be trying my hand at this one with some gravity assists.

Orange tank (36t) Two cockpits 1t x 2 Skipper engine 4t Jet engines 1.2t x 7 Landing gear 0.5t x 3 Intakes 0.011t x 64 Delta wings 0.07t x 12 ... and I stopped counting Total is at least 36 + 2 + 4 + 8.4 + 1.5 + 0.7 + 0.84 = 53.44 tons Also I could have gotten "hard mode" by circumnavigating at least once, but I wasn't paying attention and ejected before the first full orbit.

While you're at it, see if you can figure out the physics explanation for why in the game of Tetris, blocks fall with constant speed instead of accelerating like they would on Earth.

Very nice. Would also help if the navball and altitude indicator were not right in the center.

Primary objective: 100 points No winglets: 25 points Orange flavored: 50 points Nightmare Mode (Beyond Minmus): 1000 points Manly Mode (Flyby of Duna): 5000 No mods, exactly 8 engines. Total: 6,175 Craft file is here. I attempted a crash-landing on Duna, unfortunately none survived (and I hadn't saved). Space-plane of death indeed. I had enough TWR, in retrospect I should have gone for a rocket-style landing, as I was able to lose almost all the velocity in the atmosphere.

Never: Reduce time-warp one step at a time. Invariably and infuriatingly overshoots due to "smooth" time-warp transition. Always: Reduce two, increase one. Watch the day count down, then "left, left, right". Watch hours count down, then "left, left, right". Watch tens of minutes count down, "left, left, right". etc.

I was thinking about trying to generalize and automate the procedure I use manually. First get an intercept, any intercept. Then you have a very narrow range of intercept angles and velocities, but by changing the displacement (using a small adjustment far in advance) you end up with a wide variety (two degrees of freedom) of possible output angles and velocities. Some of these lead to subsequent intercepts, some do not. Right now I search for these by trial and error by tugging on the maneuver nodes for a while, but it would be possible to find all reachable intercepts within a given time horizon. Each of these subsequent intercepts will have an associated intercept angle and velocity and again displacement would be adjustable with small corrections (adjusting even before the first intercept if precision is high enough). This would ultimately produce a tree of potential intercepts that are reachable with only tiny course corrections, exploiting the chaotic nature of orbits. If your initial intercept has enough velocity, and the body has enough mass, the choices multiply to the point you can get pretty much anywhere for free. What's missing is the program to compute the transport network, but it definitely has me interested.

Well done. I landed on Tylo for the first time yesterday as well. I had brought 2 Kerbals which are now stranded -- I had hoped to get them back to Tylo orbit, but it wasn't meant to be. At least they survived. I used a horizontal landing patterned after Kosmo-not's landing discussed here.

One of the things that makes asparagus work well is that it drops engines in addition to tanks. If you drop only the empty tanks, then your TWR increases over time, and high TWR usually means you're hauling more engine than necessary.

Counterintuitive, but with all the other errors I've seen, not surprising. If you fly the albatross stock airplane at more than 1x, the wings deflect a lot more. This is not a matter of accuracy, this is a bug in the physics model. Something is not correctly accounting for time step.

Fair point, updating scores list. Also, some great information (and part of the inspiration for me to investigate chains of gravity assists) can be found here.

Enjoy slingshot maneuvers? Try this one. You must start from LKO (meaning apoapsis below 100km) with a craft having not more than 1862 m/s delta-v, and crash into the Sun. If you are running without mods that measure delta-V, either construct or download this craft: You must post a screenshot of your LKO starting configuration, and at least two images showing intercepts, and an image of your final approach into Kerbol. These images must show the resource panel or delta-v stats. MechJeb is permitted, and generally any mods that do not alter the deep-space physics. If you use non-standard parts, you must demonstrate that the LKO starting delta-v is not more than 1862. You may use any means to get the 1862 m/s craft to LKO, and a sample craft is provided that can easily meet this need. I performed this challenge with a craft having more (but using less) delta-V, then decided to lower the limit so a direct shot to Jool is unreachable and at least two intercepts are (I believe) required. Results will be scored by delta-v used, and by mission time: Least delta-v used (vanilla): 1. 2. 3. 4. 5. Shortest mission time (vanilla): 1. 2. 3. 4. 5. Least delta-v used (with MechJeb): 1. Vector (1666 m/s) 2. 3. 4. 5. Shortest mission time (with MechJeb): 1. Vector (7589 days) 2. 3. 4. 5. I know you guys can do better...

I agree, except that it's not the center of mass that's moving, it's the fact that the center of control is extrapolated to compute the orbit, not the center of mass. This is one of the things I think is wrong about the model. If I put an Okto-2 on a long arm, rotating (using reaction wheels only) perturbs the orbit much more than when the control is near the center of mass, and in a predictable fashion. This tells me that it is not rounding error, it's the center of control vs. center of mass. There may be rounding error in addition. I agree that RCS can create unwanted but real translation forces, and that these should be allowed to modify the orbit. I am suggesting rails only for rotation from reaction wheels.

I don't see this as covering up a problem, I see this as a more accurate model. If I have a linear function y = mx + b, and I increment each delta-x step using y = y + m * dx, then it's mathematically equivalent to the function but numerically the result is different. The errors accumulate when using a large number of small steps. In contrast, evaluating the function at different x accurately follows the function and roundoff does not accumulate. This is the difference between mathematics and numerical analysis. I can't say for sure but it really feels like this is what is happening, where physics mode is introducing a large number of small errors. This is inherently less accurate than a closed-form solution for the trajectory of the center of mass. When accelerating due to thrust or atmosphere, then sure, use incremental delta-v and compute each delta-position since you have to calculate each step anyway. But when your orbit is supposed to be a patched-conic, use the closed-form patched conic.

Suggestion: when outside the atmosphere and all thrusters are off, put the center of mass on rails even at 1x time warp and even when rotating via reaction wheels Observations: 1. Orbits at 1x time-warp "vibrate" even when the ship is completely passive. 2. Orbits appear to be extrapolated from instantaneous control module velocity instead of center of mass. Rotating a ship introduces errors in the extrapolated orbit. 3. Orbits change when changing time-warp between 1x and higher time-warp.

From his persistence file, first try using Kosmo-not's method: http://i.imgur.com/cR8iAAs.png For some reason MechJeb didn't load, but I had 32.13 liquid fuel remaining at touchdown. I made an extra trip around the Mun because I hate landing in the dark. Also pitched up for a bit to coast past an inconveniently located crater, probably didn't cost much fuel. Final low-speed low-altitude descent was essentially retrograde burn for a very small minority of the descent. Definitely not suicide burn because for me those frequently end up suicidal. Normally when I land on the Mun I have high TWR so I don't need the constant-altitude approach, but I definitely like it. It's also much easier and less stressful than my typical landing. Nice to know that it's also efficient.

You didn't say horizontal takeoff and you didn't say no airhogging, so I'm not sure if these are constraints for you. A week or so back I built a vertical-launch SSTO (lands using parachutes) that can deliver an orange tank to LKO. 68.88 tons in VAB and not difficult to get to orbit. You can add extra bipropellant and still get to orbit no problem, if you find yourself running out of fuel while trying to rendezvous. This version cut down the bipropellant to try to maximize the payload fraction, but it's got capacity to spare so it works fine with a bit of extra weight. Just for you, I ripped off MechJeb and uploaded here: https://www.dropbox.com/s/u0cckrmmi50sczg/SSTO%20Whole%20Can%20Fueler%203_2.craft

Whackjob I have to hand it to you, I have tried to make large rockets and it always ends with magnificent explosions, half the time before leaving the pad. I can see a certain pattern to your designs, with struts attached to girder segments instead of to the tanks directly. It also appears all the tanks stack in tall columns with nothing but struts between them, with no radial connections at all. Can you describe the experiences that led you to these designs and why they work well?

If they are symmetrical about CoM then for translation it doesn't matter how far from CoM they are. For rotation, farther is better, and rotation will be used to counteract any accidental spin you may get from translation.

I agree that procedural would help a lot, but there need to be limits on the parts and ranges that it's applied to. For example, part of the challenge with LV-N is that they don't come in all sizes, which means engineering trade-offs have to be made. If there is a single best solution that applies to almost all problems, then it takes away from the challenge and fun of the game. But that said, there is still a ton of room for procedural parts to simplify designs that are already possible but annoying to construct.

Place them symmetrically in sets of 2 or more, so they are symmetrical about the center of mass. Also remember that as fuel is burned, the center of mass moves, so you want to predict where it will be at the time you will be using RCS. If they are near the center of mass then they can't apply much rotation due to short moment arm. Place them farther from CoM (but symmetrical about CoM) and they will stabilize their own torque.

Not really "weird," and something people probably already know, is what I call a "split Hohmann transfer". Instead of spending a half-orbit in the transfer orbit, I'll use a longer one-and-a-half transfer orbit. And then, rather than burning all the delta-V at once, it's split so some of it is burned initially and the rest is burned at the second pass through periapsis. By varying the fraction burned on the first and second passes, the timing of the intercept can be varied widely and accurately, and it doesn't cost any more fuel than a regular Hohmann transfer. The downside (and it's a big one) is for interplanetary transfers you lose the Oberth benefit for the second portion of the burn.

For those who say it can't be done without Infernal Robotics, yes it can: Technically this does not obey all the rules because it starts from the VAB and not SPH/runway, but apart from that, it qualifies. The rocket engines are sequenced with action groups.