arq

Really you just need to match your orbital period to follow Kerbin. You'd need to use RCS (or better yet an ion engine) to tune it, but it can be done. Probably to within minutes per orbit, if not better.

If you want to get a good idea of 'efficient' launch profiles, try this challenge from awhile back http://forum.kerbalspaceprogram.com/showthread.php/39196-Launch-Efficiency-Exercise-Updated-for-0-21-1 If you can get it to orbit, you're using an efficient profile that is within maybe 3% of optimal. I tried ten or twenty different profiles (manually, so a bit of personal error there) and found that even seemingly different profiles ultimately perform almost the same. If you start making a turn at 10km and don't turn too slow or too fast (and that's a surprisingly large swath), the profiles differed by less than 100dV from each other (usually even less). The burn->coast to apo->burn cost virtually the same as trying to just burn all the way to apo. Also, following the prograde marker really isn't as important as you'd expect. That will probably matter more when there is a proper drag model.

My 560GT runs KSP on max just fine. You'll get better results with that computer, but any computer will chug with enough parts.

Yup, that's exactly the joystick I've used for almost 10 years now.

The reason that aircraft in KSP become wide, fat, and ugly is because of the aerodynamic model. Real-world planes can do a much better job of distributing fuel near the CoM (usually in the wings). The problem with long planes in KSP (and especially SSTOs with all those heavy rockets and rocket fuel) is that the CoM moves so dramatically in long craft that stabilizing them on re-entry is very difficult. Also, the only parts in KSP that have any semblance of directional drag are wings. If you dropped a giant rod from space, it sure as heck wouldn't come down sideways. In KSP this translates into requiring special attention to your CoD, as others have mentioned. In real life, aircraft do a much better job of pointing prograde. This is especially true in pitch, because of the wings and horiz stabilizer, though yaw is less so (hence the IRL tendency of a large vert stabilizer with a strong rudder - take a look at a B-17 sometime). In KSP, planes (especially heavy ones) can be turned retrograde just by pitching too fast. They are much less responsive to changes in attitude. In my brief foray into FAR, that was the part I enjoyed the most - rockets and planes flying in-line with the oncoming air (which makes planes much more responsive and maneuverable).

A few thoughts: Does KSP use floats instead of doubles? Really? Or was that just your simulation. Floats are almost never used because computationally they are almost equivalent to doubles (general-purpose computers are built to work in doubles) so the only thing they save you is 50% memory, which is only a problem if you're tracking millions of numbers (in for KSP orbits it's hundreds or maybe thousands). Many beginning programmers haven't even heard of floats, only doubles. Orbital physics are handled separately from part physics. The orbital physics just use the motion of the CoM (which is why orbits get jumpy when transferring to the outer planets, the CoM jiggles a little when normal physics are running). This would have very little impact on parts physics. What the OP is proposing is not n-body physics. Really it's just 1 body moving through a complex environment (it does not affect the environment). However, since even the heaviest 5000 part ship is still a dot next to Gilly, these 1-body physics are an approximation that would take contrived scenarios to even observe a difference. All of this said, I believe it would be possible to use these 'almost-Newtonian' orbits instead of patched conics. However, I am still not convinced that this would contribute meaningfully to the game. The only big plus would be Lagrange points (though I'm not convinced that would be more than a brief novelty). Then there would be the obnoxious bits like Mun pulling down your LKO ships.

No, the volume math was correct. He used 1/2 the diameter, you're just misremembering the equation. Not that it matters because at the end they're all just numbers, but my preference would be that a 'unit' of fuel be adjusted to correspond to one or ten liters. That would involve just changing the actual capacity numbers in all the tanks, and possibly the mass of the fuel. I would just like to be able to talk about fuel in 'liters,' rather than 'units'. It just doesn't sound as awkward.

Do want! Maybe bring dress up the magic boulder and bring it back?

An asparagus lifter typically has a payload fraction of 13-16%. This means that for every 1t of payload, you need an additional 5-7t of launcher. My record lift was 409t during 0.20. It was 21 x32 tanks plus a bunch of RCS and some LV-N's to make adjustments (actually it had over 12km/s delta-v because of all that fuel, but with a TWR around 0.1 I wasn't going anywhere fast). On the pad it weighed close to 3000t. You want around 4600dv to get up with some margin, and try to keep your TWR in the 1.5-2.5 range. I usually try to have the first 2000m/s of delta-v have stages with TWRs that begin around 1.7, 1.9 for the next 1500-2000dv, and for the last it doesn't matter much, usually I end up in the 0.8-1.5 range. For large constructions, Kerbal Engineer Redux (or Mechjeb) is indispensable for calculating TWR and delta-v through your many launch stages.

The new SAS works wonders against wobble. However, I find that thrust vectoring is more than sufficient, even for 3000t+ rockets with 40+ mainsails, for controlling rockets. The only time where it may *need* aerodynamic surfaces is when using gimbal-less engines like the T30. Though disabling gimbals can help, on large launchers it's usually too much of a pain for me to mess with, and i really don't seem to suffer too much for it. A few (by which I do mean just a few) struts is really all it takes to keep most of my rockets stable. The only thing that I find aerodynamic surfaces helpful for on rockets is making launch turns faster, since they can then use lift forces to keep you prograde. Also, if your rocket is (for some reason) significantly drag-heavy on the top, lift surfaces will pull that back to keep the rocket from tumbling. Also, if overcontrol is an issue, you can activate gradual control mode with CAPSLOCK and repeatedly tap the controls to turn yourself very gently.

I think your best bet might actually be to drop from Minmus orbit to Kerbin Peri <100km and then boost from there out to wherever you want. The drop costs less than 200m/s from Minmus orbit and then you will have a low Kerbin orbit that is 100m/s from escape. So you should be able to escape Kerbin for <300m/s from Minmus with full benefit of the Oberth effect. It's possible Mun may shave a little bit off of that figure, but for the added complexity of lining up that maneuver with a transfer window is a lot for very little gain.

For lights, there is already a 'lights' action group by default that is bound to 'U' or the lights button at the top of the UI.

Unfortunately, Moore won't be much help to KSP. Moore's Law suggests than we could double the number of transistors on a chip every 18ish months. Clock speeds haven't increased significantly in almost a decade. There have been architectural improvements that let the processor do more with each clock, but improvements there are *much* slower than Moore's law and generally limited to specific scenarios. Processors aren't getting faster nowadays (except for breaking some aforementioned bottlenecks - mostly memory-related), they're using less power (which can allow them to be marginally faster) and we're getting more of them. But for single-threaded programs like the physics in KSP, the improvements will come at a crawl.

The main advantage of high thrust-to weight rockets on ascent stages is that it means you have less deadweight to haul through your transfers, which increases delta-v. The LV-T30 not only has more thrust than the aerospike, meaning you need fewer to get to orbit (or at least the orbital ascent can be faster, which reduces drag losses), but it weighs less which will help you get extra mileage out of an LV-N transfer stage.

Generally I end up with 2-2.5 intakes/jet on my SSTO's. As for getting into orbit with only an LV-N, I have not succeeded in doing so but I haven't actually tried. Still, with 9 intakes, 4 turbojets, 2 LV-T30s, and 1 LV-N I have been to the surface of Minmus and back. The issue with rockets for SSTO ascent isn't ISP, it's thrust. Kerbin's atmosphere at 20km is less than 2% of the surface density, which means that rockets perform with nearly their vacuum ISP (the LV-N for example has 789s at 20km). The main issue is that you typically need a rocket TWR of at least 1 to get an efficient to-orbit transfer from 25km. But suppose we could do it with 0.5: that means that you would need one LV-N for every 12t of vessel (though the LV-N eats up 2.5t of that), so you will need at least to 2 for a 20t ship if those are your only engines, but I don't know if that leaves enough mass for the rest of the craft. One thing to consider is replacing your aerospikes with LV-T30s. the T30 has 5% less vacuum ISP (and we already established that sea-level ISP is irrelevant here) but 47% more TWR. Because of its low TWR, the aerospike is only really useful in thick air where it can take advantage of its very high ISP (even on Kerbin, it's only really useful for the first 10-15km, otherwise I use T-30s). If the T30 is overkill for your rocket then the mini-rockomax engines (the 24-77 or the 48-7s) are great options for boosting TWR for the early part of your rocket ascent, plus they add vectoring. You need to carry all your engines with you wherever you go. Bringing a load of aerospikes to Mun or Duna is heavy. Thus it is best to use a single LV-N and let the rest of your engines have high TWR, so that you can minimize engine mass.

The station under construction, now using standard docking ports and no cubic octagonal struts: And the finished project (took 25 dockings to assemble): It went off without a hitch or any kraken attacks. Thanks! Unfortunately, the spacing isn't quite right so the ring has small gaps. Maybe inline batteries are the right thickness to close them? That's a problem for another day...

It was back in 0.20 that I made that massive ship, but I'll try to recall it here: The ship was over 650 parts and 3000t on the pad. It had 43 mainsails on the bottom, onion staged. In orbit it had 67200 units of fuel (21 x32 tanks), plus another 2250 monopropellant. The orbital stage had 6 LV-N's, giving it an acceleration of just under 1 m/s with a full load. With all that fuel it had over 12km/s dV, though it was mostly intended for Kerbin operations (moving it to other planets was much easier if I docked a transfer stage with more thrust). If I ever get around to rebuilding it I'll see about posting a screenshot. By 'iterations' I mean that I had the core design together but had to go back to the VAB many times to add or relocate struts because of RUD events. Because of the challenge of holding it together without massive partcounts I tend to make tankers smaller now, carrying maybe 35k units of fuel. This lets me keep the partcount significantly lower and keeps the mass below 250t. Unfortunately, I like single-launch missions so I have used my tankers for refueling maybe once.

Thanks, after ditching the octagonal struts and the Jr docking ports, things are going much better. Though now the spacing is messed up. I'll need to work out a way to fix that...

One way to keep the plane stable in this configuration is to have significant wing-area in the rear, so that the plane is 'fletched' like an arrow. In fact, this is the best way to keep an aircraft stable in atmo. One nice thing about the engines in front is that they are heavy so the CoM will be more forward, which amplifies any 'fletching' you may add. I've lost many spaceplanes on re-entry because the CoM shifted too far back as fuel burned.

Some of the things you're suggesting (IE rocket deformation affecting thrust characteristics) are not deformable-body physics but rather fluid dynamics, which are gloriously hideous and would require very sophisticated (read: expensive) computations to do in a setting like KSP. Some of the other things you're mentioning, like re-entry damage, are already planned features for KSP. Though you're suggesting a very sophisticated ablation model which would ultimately be nearly indistinguishable from a simple 'hitpoint' based model. I feel that rigid-body physics offer a good tradeoff between realism, computational load (though I really hope Unity can get a GPU-accelerated physics engine), and user transparency. My biggest physics-related wish-item is the new aerodynamics model they're eventually planning to implement, as the current one is *not* a very good characterization of realistic aerodynamics. FAR is better, but is still limited by some of the core KSP mechanics and messes with the gameplay balance a bit (ie significantly reduced dV to orbit) and I'd be much more willing to use a stock model.

It looks like you're using turbojets. I'd recommend the regular jets, since they have higher thrust at low speeds and higher ISP at low altitudes, unless you're really hoping to go up closer to 15km where you can use those turbojets effectively.

I finally decided to make a more-elaborate space station. I really liked some of the toroidal designs that people had and decided to follow that. I know that multiple-port docking is possible, though it treats all but one (the 'primary') of the connections as struts. So I set out to make a station with 12 ring segments covering 30deg each. I have 3 'spokes' going to a core and so the orbital assembly step involves adding 3 segments between each pair of spokes. I successfully added a piece to each of two spokes, but when I try to 'connect' them with a third segment in the middle it gets very grumpy and starts flailing the 'secondary' connection around. Half the time the flailing subsides and half the time it rips the new part off or causes some other bug. So far I've only been able to complete 1/3 of the ring (and the connection there isn't great). So, does anyone have suggestions for or experience with docking multi-port ring segments? Getting the alignment is especially difficult, because you need to connect with two ports that are 150deg apart (even with the docking port alignment mod this is tricky) and once it gets in range of one port the segment tends to get swung around a bit while the connection completes.

I'm not certain. I rarely have more than one strut between any two parts. Maybe I'll mess around sometime to find out too. That said, there are cases where even single struts can be bad. Struts can serve to redirect forces to other parts of the vessel. Sometimes the parts can't handle these forces and this causes them to fall apart. Though I've only really experienced this with 2500t+ vessels.

I've always meant to try running the numbers through a numerical simulation to work out a dV-optimal profile and the necessary TWR through the process. Maybe I'll get around to it one day.

Maybe you could enable 'no crash damage' (or w/e it's called) in the debug menu (alt+f12)? The largest payload I've put in LKO (that I remember the tonnage of) was 409t. It was a fuel-tanker (prob 350t worth of fuel). Took prob 30 iterations to keep it together through launch (I try not to overkill with struts).