Delay

@ManeTI This just happened: Edit: False alarm. Everything's normal.

"1.6" still works in 1.5.1, right? I'm mostly waiting for Principia to update to 1.6. Oh, and I just want to note that the Falcon 9 legs that come with VSR are blatantly overkill in impact tolerance, not even water manages to get rid of them.

Just a Falcon 2 (because it's a 2.5m rocket, but it also fits the actual Falcon's naming convention) landed in the middle of an EVE city. Absolutely nothing to worry about. And while I'm on the topic of SpaceX, here are some Stage 2-esque shots from LKO:

Huh. This looks... interesting.

Not the Skipper's fairing. Granted, that one was also somewhat off in combination with a size 1 part, but I mean a custom fairing (hence I used payload fairing) and that actually looks very nice. The size 1 decoupler is the problem: It's too far inside the engine, so that attempts to select it always select the engine.

@Kerbas_ad_astra Skipper and size 1 decoupler are not a nice combination as of now. First off: The decoupler fits exactly into the Skipper (which has its node slightly higher), therefore I think this is done on purpose. Moreover, adding a payload fairing looks like the Skipper itself is held. However, this makes the decoupler virtually unselectable. You have to remove and replace the Skipper if you want to remove the decoupler.

Wait, what happens when you put Duna into Kerbin's SOI, but close enough to its end that Duna's SOI goes beyond Kerbin's? Essentially a Venn diagram of SOIs. Turn on the fuel lines. Maybe it's not considering a tank? Also; not surprised that something as complex as the Space Shuttle's fuel system would confuse a tool like this.

I helped my mother make lasagna. But while trying to put it into the oven I hit the top (which was quite hot) and instinctively pulled my hand away. I think you can imagine the rest. Damn it.

Launched a satellite. The contracted orbit was close to the Mun and rather inclined, so I thought "Why not use the Mun as a means to save dV? It can take care of raising my orbit and incline it too!" Why not? This is why not: It took hours to fine tune this trajectory! And all of this for this tiny satellite! On the other hand, the maneuvers combined took less than 1600m/s of dV, but I don't know if that's a good result or not. I reckon it is - raising apoapsis, raising periapsis and then doing a plane change surely takes more than 1600m/s, right? You need over 800 for just the apoapsis.

I tried out some things and answered some (two) of my own questions: 1. Is the Twin-Boar or a Mainsail better? (The first one is better as it has a higher thrust, which means more fuel and an extended burn time) 2. Is it better to perform a boostback than to simply keep burning until your trajectory hits land again? Depends, I'd say yes. Mostly because it takes less time to do and it's directly at the KSC, so ~100% refund in career mode.

@eggrobin Out of curiosity: I would like to know how high you guess the chance that Principia will do Trajectories-esque atmospheric predictions in the future, taking drag and lift etc. into consideration in atmospheres and allowing for (e.g.) aerobraking maneuvers? I reckon that Trajectories itself only works with the standard KSP model, incorporating similar predictions into Principia would be a powerful feature and a good feature to spend time on in my opinion.

That's not funny. That's concerning. We've reached the point at which a machine can drive better than some people. "Worrying" is euphemistic.

What I meant by that is "if it is present, it is a negligibly tiny error in most situations", with going to L4 not being included in "most situations". I'll try to recreate it in a copy that only contains Principia. Right now I have Scatterer, VSR, DistandObjectEnhancement, MM and EVE as well.

Interesting. Substituting i in my original equation for the spherical "extension", I got this huge thing, which I have made in GIMP for better readability: vO is still the orbital velocity, i is the inclination, L is latitude and vR is the rotation of the body. My equation is based on a right triangle, with its vertical component at the top and the horizontal one at the bottom.

I tested the equation yesterday. I placed myself at 46.5° N and launched into a 70° orbit. Unfortunately I have neither an RSS save nor Making History, so I don't have any inclined launch sites I can actually launch from. So I built my rocket, turned on infinite fuel, flew there, landed, turned infinite fuel off and then launched as normal. The orbit seems to line up really well. I only had a few meters per second, 100m/s at worst, of deviation. I don't see a difference between launching in the northern hemisphere relative to the ascending node and launching in the southern hemisphere relative to the descending node. Launching south from the northern hemisphere / north from the southern hemisphere also shouldn't be a problem - the orbit instersects all latitudes twice (aside from lat = inclination). You're just moving your own position from "local ascending node" (if I can call it that) to "local descending node", the angles should remain intact.

Are you sure? Keep in mind that y is inside the sin(), but not inside sin-1().

@YNM Is it possible to simplify sin(sin-1(x)-y) and cos(sin-1(x)-y)?

I should still be able to use that part of the original equation. I only needed a term to correct the inclination for launching at a non-zero latitude. What my original equation does is basically vector addition - but instead of adding vector "a" to vector "b" to get vector "c", I have "b" and "c" given and solve for "a". Or more specifically: The angle of "a". "b" represents the rotational speed of Kerbin (~175m/s). It's angle doesn't matter, since it's always parallel to the equator. The magnitude of "c" represents orbital velocity (~2270m/s) and the direction represents the inclination. My reasoning is that "b" only varies in magnitude as your latitude increases. It's direction is always the same. The orbital speed doesn't change and so does the inclination of the orbit, so "c" is constant. I should be able to reuse the equation entirely - only substituting "i" for this slightly more complicated correcting function.

@YNM So... sin(90 - i) / sin(90 - latitude) = sin(90 + Cross Angle)/sin(90)? Given their equality I should be able to drop one of them. The sin of 90 is 1, so it's equal to sin(90 + Cross Angle) sin(90 - x) = cos(x) cos(i) / cos(latitude) = sin(90 + Cross Angle).

That seems a little too highbrow to me. Would it be possible to provide a more in-depth explanation?

Going for the cheap joke.

Yesterday I posted an equation in the "What did you do in KSP" thread. It can be used to calculate the burn angle required to achieve a specific inclination, based on the orbital and ground velocity. Due to the planet's rotation around itself, inclination angle and burn angle won't line up exactly; you'll burn slightly more northern/southern than the inclination demands to cancel it out. And the equation works as expected! You can put in any number and it will give you the correct angle to burn at. However, it has a slight problem that makes sort of makes it unusable for most cases. On Kerbin it works perfectly fine, but it is assumed for the calculation that the starting point (i.e. the launch pad) is exactly on the equator. Now, the varying ground speeds at different latitudes are not problematic at all; it's variable, you can use any value. Want to find the angle required if Kerbin rotated 10x faster? Go ahead! The problem is that on a sphere, the angle at which the orbit intersects a line of latitude changes constantly as you move "up" and "down" (north/south) in the orbit. At its most northern/southern point it will run perfectly parallel, for instance, while at the equator it will have the highest angle before it decreasing again. The solution to the original problem is essentially two-dimensional, this one requires the third dimension to be solved. And 3D space, most of the time, is a mess. So I may need some help generalizing the equation to work in any arbitrary situation, at any latitude and with any inclination as long as it's achievable. I fear that it is a little more complicated than I think, and the third dimension is something I never really required so far, so this is entirely new to me. Essentially what I need is merely a way to figure out how to calculate the angle of intersection between orbital plane and line of latitude. This angle then becomes the inclination you're aiming for and the equation works as expected again, giving accurate results.

Due to Kerbin's rotation, launching to a specific inclination is a pain. So yesterday I derived an equation to calculate the angle at which I need to burn, rather than eyeballing it every single time. Now I finally tested it. With a 45°, 90° and 135° inclination. The 45° orbit was pretty terrible because I didn't quite hit 48° on the navball. 90° was essentially perfect. As for the last one: I'm off by 0.257°.

Well, the problem is a little confusing. Intuitively it seems as if the direction was correct and the markers are off, when in reality the opposite is the case.