tavert

You start having to worry about TWR at some point, but even with the lower-TWR T45 I'm not at all surprised. Especially since the 14 number was conservative, using atmospheric Isp. Agreed.

Plenty accurate if the atmosphere is isothermal. Considering atmospheric pressure in KSP (which there is a separate sensor for, and shows up elsewhere like in engine Isp) follows a simple exponential curve vs altitude, that's consistent with an isothermal atmosphere. If you want to include a temperature lapse rate vs altitude, then you need a slightly more complicated barometric formula. Accounting for species concentrations and solar effects needs something even more complicated like NRLMSISE.

Right, any temperature readings from thermometers are totally decoupled from stock aerodynamics. Kerbal atmospheres behave as if they are isothermal. For the lack of any better solution, area proportional to mass was certainly easy to implement as a placeholder. But this is a game about rockets, where mass constantly changes. Cross-sectional area should change maybe at staging events, but not by burning fuel... There's FAR if you really want physical accuracy, but it's tough to recreate its cross-sectional area and drag coefficient calculations offline without digging into the source code.

http://wolfr.am/1eyJPzo

Sure it is, if you assume rho = 1.223*p, Cd = d, and A = 0.008*m. Since there's nowhere else in the game physics that any of those quantities show up, that's a perfectly consistent interpretation of the stock drag law. Scaling cross-sectional area as directly proportional to mass is a little strange and non-physical, but that's the stock drag law for you...

It's not just the GUI stuff, it's also optimization toolbox, global opt toolbox, several others. You're also screwed if you ever use classdef-style object oriented programming, which has been in Matlab since 2008 or so but still isn't released in Octave (I think someone might be working on it in a dev branch somewhere?). Don't think KSP-TOT needs this, but the toolboxes and GUI are a pain. For a more actively-developed open-source alternative to Matlab (not source-compatible, but with maybe a little more similarity than Python) you can look at Julia. It's much newer than Python or Octave, has a smaller community (so fewer packages available) than Python but bigger than Octave, and does a lot of fancy stuff with just-in-time compilation so Julia code runs much faster than Python (even PyPy in most cases).

Yes, Octave is designed to be mostly compatible with Matlab. But it's lacking all of the specialized toolboxes, GUI programming, and many other features that essentially any nontrivial Matlab program (such as KSP-TOT) relies on. I suspect KSP-TOT would be easier to port to Python than to Octave, since you can find open-source functional replacements for most of the proprietary Mathworks toolboxes more easily in Python than in Octave. Not to mention performance, size of user-base, online resources, etc... generally you only use Octave if you're already very attached to Matlab.

Just re-watched Primer for the umpteenth time a few days ago. Love that movie. Anyone who hasn't seen it and thinks time travel is interesting should go watch it now. It's free on Hulu, at least in the US. http://www.hulu.com/watch/442155 Or don't take my word for it, take Randall Munroe's: http://xkcd.com/657/ (the movie takes... at least a few times of watching to really figure out what's going on)

That's special relativity. General rel is gravity curving spacetime.

Here's an abuse of KSP physics, with only 180 fuel, flag planted at 3:07:30. Fuel margins are nonexistent so I doubt this can be flown on the same flight plan without MechJeb (a slower more efficient trajectory to the Mun could probably work with manual flying though), and some substantial lithobraking was performed on both the Mun landing and the Kerbin return landing. Only part that broke was an octo-strut that was only needed to cheat physics. Good thing the aircraft landing gear are massless and have a very high landing speed tolerance. This time is definitely beatable - I could've cut off 15 or 20 minutes if I had launched at the right time, whoops - but not by much without using more fuel as far as I can see (or with jets, which aren't allowed here). Counting the ways this exploits odd glitches in KSP physics: 1. The Kerbal rides on a perpendicular ladder, so has no inertia and gets brought along on the ride for free. The Kerbal mass costs no extra delta-V or fuel beyond bringing just the probe with this design. It does limit time warp to physical warp, or require you to let go of the ladder and drift around while warping. 2. As previously mentioned, the aircraft landing gear are massless and can stand very rough landings without exploding. 3. Placing an octo-strut below the last-stage engine means its thrust is not counted as obstructed, so I can freely asparagus one tank at a time, in a single stack below that engine while firing it from the start. There's just one more 48-7S on the first drop tank, helping to stay at terminal velocity for the first ~25 seconds. Did I miss anything else that seems strange?

Yeah, do as many optimization iterations as your computational power and sensor sampling time allows. It becomes considerably more difficult to get provable guarantees of feasibility and strict descent for a single iteration when your control inputs and/or states need to satisfy hard constraints. The constrained optimization algorithms that converge most reliably and in the fewest number of iterations are unfortunately the ones where intermediate iterates are infeasible. Most people do an unconstrained optimization and just saturate the results, but you're very lucky if your problem is simple enough for that to actually be the right thing to do in the presence of constraints. Simple problems are so much less interesting...

Once you've hit escape speed, it doesn't really matter what direction you're going. The path dependence only influences the portion of the trajectory when you're burning at finite thrust. For very high TWR this portion is vanishingly small and you can approximate maneuvers as impulsive. Also worth noting that since KSP SoI's are finite (except the sun), technically the lowest-energy orbit that will escape a planet or moon is the one that goes straight up with an apoapsis just barely outside the SoI (but still an elliptical orbit) and a periapsis near the center of the body. However since most escape burns want to get all the way into a hyperbolic orbit, the orbital energy you need to reach is pretty much the same whether your periapsis is at the center of the body or just above its surface.

So you're saying you're trying to track a moving target in an optimal way? Sounds like you want to write an estimator (some form of Kalman filter) using as many past and current measurements of the target as you can get, along with a best-approximation model of the target's dynamics, and a best-guess prediction of its future acceleration (which might just be zero, if you don't have any better idea). Then you want to solve a constrained finite-horizon optimization problem to reach the target in a way that minimizes a weighted combination of time to intercept and fuel use, subject to a model of your dynamics, sensor measurements, and estimation/prediction of the target's dynamics. Assuming you have enough computational power to solve this optimization problem in real time, you repeat this process every time you obtain new sensor measurements of the target, updating your predictions accordingly. This is known as receding horizon or model predictive control.

This was from .21, so you can get away with less fuel now that the 48-7S has 50% more thrust: 855 fuel, about 7h 21min (pictures are a few months old, so no flag + mission timer shot, sorry) Using a seat should cut down on the fuel usage by quite a bit. You should also probably ban infinigliders, unless you want to see someone do that...

Glad I didn't see the first version then? Anyway... Can you be more specific, explain exactly what you mean by "changes that occur during flight," "operational envelope," and "some of the things the game [takes into account]"? As you burn fuel, your mass decreases so your TWR increases. But this happens faster with lower Isp, so if two craft with the same initial TWR execute the same maneuver, the lower-Isp craft will end the maneuver with a higher TWR (and in less time) than the higher-Isp craft. My charts are combining the rocket equation with the stats of the stock engines and fuel tanks, despite the visual complexity of the results there's not much more to them than that. You should be able to verify the results in-game with KER or MechJeb readouts of TWR and Delta-V. Maybe "small SSTO" is too generic. We can work with some concrete numbers if you propose an example craft. Edit 1: or here, I put together a simplified comparison with Desmos: https://www.desmos.com/calculator/o1too2zrat This compares the vacuum delta-V (y axis) vs total craft mass (x axis) for 1x LV-N (purple) vs 2x 48-7S (green) vs 1x LV-909 (blue). The LV-909 gives a little less thrust than the other two options (50 kN vs 60 kN), but still it's a worse choice for all but a tiny range of masses/delta-V's. Play with the slider for p to modify Payload mass, which is everything on the craft except the bipropellant tanks, fuel, and engines. This includes any disabled jets, your cockpit, wings, RCS, leftover jet fuel and tanks, etc. Aircraft landing gear are massless in flight so they don't add anything here. For small masses/delta-V's, a pair of 48-7S engines is the better choice. You can get better dV in exchange for lower TWR by using only one 48-7S instead of two, but I didn't plot that option here. I'm also assuming you're only using FL-T100 or larger fuel tanks in this simplified plot, the more detailed original set of charts considers combinations using the smaller tanks as well. Edit 2: and here's the solution for the intersection point between 1x LV-N and 2x 48-7S: http://wolfr.am/1dsHaIL Solution plotted with payload on y-axis, dV on x-axis: http://wolfr.am/1cqzen0 Below the line a pair of 48-7S is better, above the line an LV-N is better.

Did you read the chart(s) I linked to? There's a region in TWR-dV-payload space where the 48-7S gives better performance (lower total craft mass), and a region where the LV-N gives better performance. Despite the lower specific impulse of the 48-7S, for small craft the extra 2 tons of fuel mass often gets you more delta-V from the same total craft mass. For orbital insertion on spaceplanes, you don't need high TWR or thousands of m/s dV. And as far as the LV-909 goes, it is very very rarely the best choice. Its optimal region is a very narrow band between the 48-7S and the LV-N, at low TWR.

LV-N and "small" do not belong together in the same sentence. Unless you need thousands of m/s of delta-V or are pushing 10+ tons of payload, the LV-N is too heavy and you'd be better off using a smaller engine (most often the 48-7S). See http://forum.kerbalspaceprogram.com/threads/45155-Mass-optimal-engine-type-vs-delta-V-payload-and-min-TWR

The horizontal launch trajectory you'd need to make it work with TWR < 1 would increase the dV cost quite a bit. I've only ever seen one successful stock spaceplane launch from Eve, and it took even more asparagus stages (dropping both engines and fuel tanks) than a vertical launch. I'm all for giving it a try even if not for this challenge, it would be interesting to see the result if you do succeed. You could maybe use Hyperedit to make Kerbin's atmosphere and gravity resembly Eve's, but at that point you may as well just Hyperedit yourself (or edit your orbit in the save file, change REF to 5) to the real thing.

Hm, alright. I never use the large decouplers since they're too heavy. Small decouplers and/or small docking ports is pretty much all I use, and my designs are lighter because of it. I think my lander should have enough fuel margin that I can afford to add a small docking port on the last stage. You do know you can use the stock docking ports as decouplers, right? You can right-click on a docking port and decouple whatever part was attached to it, whether or not that other part is also a docking port. Seems like the only thing you get out of making a custom part for it is having the decoupler in the staging list.

More intakes mean better fuel efficiency, so go nuts until you think it looks ugly. Instead of switching to the rockets when your jet first flames out, instead you should nurse the throttle to keep using the air-breathing engine for as long as you can. Hit x immediately to get the engine back on, and throttle back up to just below wherever you previously had the throttle when you just flamed out. Keep this up and you should get more speed and higher altitude out of the jet. Don't fly an SSTO like a rocket. Instead you want to level off your flight path at the highest altitude you can sustain enough throttle to keep accelerating - drag drops off pretty noticeably above 30 km, and it takes very little throttle to counteract it and continue building speed at high altitudes. The more intakes you have the higher this will be. When you're happy with the speed you've gotten off the jets, then switch to the rockets and pitch up to climb the rest of the way out of the atmosphere.

Try saving the rover as a subassembly, under the last tab of parts. Then load your rocket and you can add the rover subassembly to it. Or you can save the rocket as a subassembly and add it below the rover.

You're not going to get enough dV with just one engine, even if it's all drop tanks and max amount of fuel to get to TWR=1 in Eve's gravity. At least not launching from the ground with stock parts. Depending how heavy the balloons from the airship mod are, you could probably even manage a 1-engine SSTO, pick between T30, Skipper, or Mainsail depending on how big the craft is. Is docking strictly required? With a Kerbal in a seat or on a ladder, Eve designs can be pretty small even with only 2 engines. It does the job of getting a Kerbal back to orbit, then he can switch to a return vehicle via EVA.

Interesting challenge. I have a design that should be able to do the launch from high altitude with one aerospike and one 48-7S, and shouldn't need any engines for the landing. What about deorbiting, does that count as use of an engine?

This may fall under the category of concepts that are hurt by the cancellation of the ASRG, as that would've only been 20 kg as opposed to the 45 kg of the Curiosity-type MMRTG.

Thanks for posting your source. Linus' law, given enough eyeballs all bugs are shallow. Looks like you're getting closer to something usable and useful here. Just needs some setup guidance for anyone other than you or alterbaron to get PSOPT working from a clean slate. Have you ever used Travis CI? Could be worth setting up here, gives you free testing and helps you establish a blueprint for how to set up the dependencies in a controlled environment. It's a pretty minor difference, but I recommend using the gravitational parameter (aka mu or G*M) instead of G and M individually, since I believe planet mass is a derived quantity in the game. The product is the value that really matters. Makes no difference for Kerbin, but the wiki's a bit confusing on atmosphere height - you should use the version that does not depend on sea-level pressure. The second equation on the wiki that depends on sea-level pressure gives the wrong values. On Eve for example, the atmosphere ends just under 97 km, or ln(10^6) = 13.8 times the scale height. For handling the atmosphere cutoff you could either try a sigmoidal function (arctan, or tanh, or erf, or a logistic function - watch out for overflow though) to smooth out the small discontinuity in pressure, or make 2 assumptions: that the last staging event happens before the craft leaves the atmosphere, and the craft only leaves the atmosphere once (doesn't reach apoapsis then start falling back into the atmosphere before it gets into orbit, might happen for low TWR). With those assumptions, you could add another problem phase for the final portion of the trajectory that happens in vacuum. It's started to pitch over by that point so the story's a little more complicated than that I suspect.