Samniss Arandeen

Recieves a fully-functioning perpetual-motion Turing machine. Inserts a Rambo action figure.

5/10 You were so afraid of a rabbit in the Ban User Above thread. That tank must suck.

Granted. Merry kishmish, @kerbiloid! I wish I were chibi.

pneumonoultramicroscopicsilicovolcanoconiosis

Banned for being so afraid of a rabbit whilst inside a tank.

The last time I tried to ask a minor something, I ended up with a 1000 foot restraining order.

Tweakable fuels. As in, if I remove oxidizer from a tank, I should be able to put more fuel in its place. If I had the option to play around with fuel stoich in this manner, resulting spaceplanes potentially would be smaller, lower part count, and less ungainly in appearance.

That does not help, as delta V also depends on vessel mass (which I don't know from just looking at the picture). Having 1160 fuel left after docking to the station means you're lugging around quite a bit of dead weight, and you can omit some of those tanks if all you want is a crew shuttle/light utility craft.

It's a unique design, but you certainly went overkill with the engines and fuel. What's the dV on it after orbital insertion?

You gotta be Kerbin me. There are people on the forums that can be Reliant on to have a KSP pun handy, but they tend to Dart around like little Terriers. The best ones are shining Jools of comedy gold to be hung on the Vall, but the worst ones will earn you a Bop on the head. Ike ant even begin to think of a Duna related pun. Did Juno the resulting mood Whiplash will Rapier mind? We should probably have a Pol to decide whose puns are best. That's your serving of puns. Here's the Bill.

As an option for adjusting the Tweakables values on certain parts, such as control surface authority, thrust limiters, fuel levels and the like, I'd like to be able to just type in my desired value. A simple text box that lets me manually enter the design amount saves me quite a bit of trouble having to faff about with the horrible, horrible sliders. For lights, why do we have to deal with RGB values in decimal? Just let us enter a value from 0-FF or 0-255 so we can get the lights in any standard hex color code. Why can't we adjust colors on lights placed with Symmetry enabled asymmetrically? Sure, it's a cosmetic item, but dammit, I want my disco pimp plane. I like how engines can have their gimbals adjusted for control authority in all three axes independently. Why can't control surfaces have the same configurability? The elevons at my wingtips have crazy roll input at full deflection that I want to scale back, but maybe I want them at full authority for pitch commands. And for that matter, why can't they be enabled/disabled via Action Group? Speaking of Action Groups, making them editable in-flight would do wonders in the quality-of-life department. There are quite a few smaller craft I've carried into orbit as payloads of a larger vessel, and those craft don't have Action Groups because giving them groups would interfere with those of the carrier craft. Same story goes for on-orbit construction projects, too.

Is this challenge even possible without the use of HyperEdit and Alt+F12?

Hinges, so I can make rovers foldable. I'd be more likely to bring one along if I could more easily pack one in the spacecraft.

Introduction Most of us are familiar with the simple "due east launch": just gravity turn 90 degrees and get into an orbit. To most of us, orbital inclination is merely a consequence of, say, a Minmus or Mun encounter, rather than anything we try to pursue actively. But what if we want to achieve a specific orbit? Plane-change dV is notoriously inefficient, and eats through a ship's fuel faster than you can say "stranded in space". Or, say you've landed and wish to take off again, or you're playing with Kerbin-Side and launching from an alternate spaceport. This will also apply to everyone who plays with RSS and has KSC set to the actual Kennedy Space Center launch site (22.5 degrees northerly latitude). For the below tutorial, you will need: -Your launch site's latitude. Positive values are northerly, negative values are southerly. Zero latitude is directly on the Equator. -Your target semi-major axis. For a circular orbit, it's the planet's radius plus whatever altitude is needed/wanted. -The planet's gravitational parameter in m^3/s^2, sidereal rotation period in seconds, and equatorial radius in meters. -The target orbit's inclination. Note that inclination can never be lower than the launch site's latitude without the help of a correction burn later on. Launch Azimuth Put simply, the Launch Azimuth (β) is the heading along which a space launch is sent. Not only does this affect the inclination of the final orbit, but it affects the amount of dV used to place the vessel into orbit. A handy formula to remember is: cos(i) = cos(φ) * sin(β), where i is the inclination, β is the launch azimuth, and φ is the launch latitude. Thank you, spherical trigonometry! Let's say we want to launch from the KSC pad (at 0 degrees, 6 minutes, 9 seconds southerly latitude), heading into a 45 degree orbit to rendezvous with our space station. We just solve our equation for β: β = arcsin(cos(i)/cos(φ)) And plug in our values: β = arcsin(cos(45)/cos(-.1025)) = arcsin(.707/.999) β = 45.000... degrees. Great, so we have our launch azimuth, and we can space now, right? Actually, no. While our equation is indispensable, it will only work in an inertial reference frame. Kerbin's surface is always rotating, and that velocity is transferred to our spacecraft. That velocity must be accounted for if we are to get a correct orbital inclination from the launch. Accounting for Rotation To transition from the rotating (initial) to the inertial (final) references, we need a way to account for the velocity already possessed by our launch vehicle prior to liftoff. But how much velocity do we already have by rotation, do you ask? It's rather simple. Kerbin has a radius of 600,000 meters. Its rotation takes exactly one day, and because we know the circumference of a circle based on its radius (it's 2*π*r) and the time taken to cover that circumference (one day), we can get rotational speed. Be careful, however. We can't use a solar day for this calculation. A solar day is calculated with respect to Kerbol; while this is fine for terrestrial timekeeπng and tracking the Sun's position, the rotation of Kerbin in a solar day is actually significantly more than one full revolution, as a solar day uses more rotation in order to keep the Sun in the same position at the same time of day. What we instead need is a measure of time called the "Sidereal Day" - the time it takes for exactly one full rotation of Kerbin without respect to Kerbol. Looking around on the KSP Wiki, we see that Kerbin Sidereal Day = 21549.425 seconds, or 5 hours, 59 minutes, 9.425 seconds if you will. We know that the circumference of Kerbin's Equator is (2*π*600000m), approx. 3769911.184 meters. And with a rotation distance and time, we can get rotation speed. 3769911.184 meters/21549.425 seconds = 174.9425 meters/second velocity on Kerbin's equator. (Note: This value is also listed on Kerbin's entry on the KSP Wiki. I just wanted to show how it's calculated.) But this value is on the equator, where the radius from the axis of rotation is equal to the radius of the planet. At increasing latitude, the radius from surface to axis progressively decreases, until finally at 90 degrees latitude, you're standing on the Pole itself and simply rotating coaxially with the planet. Luckily for us, the answer to this problem can be found by cutting Kerbin in half. That's right, by modeling our position on Kerbin as a right triangle, with the hypotaneuse represented by the radius from our launch site to Kerbin's center, we can simply take the cosine of our latitude to determine how much shorter our actual radius is - and just multiply that by our equatorial velocity. It really is that simple! VRot(φ) = ((2*π*600000m)/21549.425s)*cos(φ) VRot(-.1025) = ((2*π*600000m)/21549.425s)*cos(-.1025) VRot(-.1025) = approx. 174.9422 m/s. Not a whole lot different in our example, but consider that if you're launching from higher latitudes, it's an important consideration. Alright, enough waffling about. We want to launch into a 45 degree orbit in an inertial reference plane. Our rotating planet moves us along due east at 174.9422 meters per second relative to the inertial frame. So how do we reconcile these into a number we can use? The answer is to use vector addition. If you think about it, our launch consists of a magnitude (delta V) and a direction (our azimuth). Our rotation is a magnitude (Vrot) and a direction (due east). If we add these vectors together, what we get is the final orbit magnitude (orbital velocity) and direction (inclination). In an equation: Vlaunch + Vrot = Vdest. Since we're solving for launch azimuth: Vlaunch = Vdest - Vrot. But what is our orbital velocity? This is where we need to know exactly what orbit above Kerbin we want. This is important, as orbital velocity is affected by semi-major axis and altitude above Kerbin, and will differ depending on different orbits and mission goals. For our example, we want the 45 degree orbit to rendezvous with a space station in circular orbit 150 kilometers up. (For the purposes of this tutorial, hopefully you already know how to calculate orbital velocities given semi-major axis and radius. If not, I'm just going to skim over my example briefly) Since this is a circular orbit we're going to, we can simply take our semi-major axis of 750 kilometers and treat that as our radius to simplify things. Remember that our SMA is 750 km, not 150, as the focus of our orbit is at the center of Kerbin. The velocity of a circular orbit is Vcirc = (GM/R)^(1/2), where GM is the planet's gravitational parameter and R is our previously calculated radius. Since we know Kerbin's GM = 3.5316*10^12 m^3/s^2, and our desired R is 750,000 m, we can calculate the velocity of destination orbit Vdest: Vdest = (3.5316*10^12/750000)^(1/2) Vdest = 2169.976 m/s. A quick recap on what we know: Vrot = 174.9422 m/s @ 90 degrees. Vdest = 2169.976 m/s @ 45 degrees (our inertial launch azimuth) Vlaunch = our horizontal delta-V requirement @ our rotational (compass) launch azimuth. Vlaunch = Vdest - Vrot. Let's add these vectors, shall we? First, we split them into their X (east/west) and Y (north/south) components. Obtaining the X component of a vector is as simple as multiplying its magnitude by the sine of its direction. Therefore: Vrotx = 174.9422 m/s * sin(90) = 174.9422 m/s Vdestx = 2169.976 m/s * sin(45) = 1534.407 m/s Vlaunchx = Vdestx - Vrotx Vlaunchx = 1534.407 - 174.9422 = 1359.465 m/s And for the Y component of a vector, the magnitude by the cosine of its direction. Thus: Vroty = 174.9422 m/s * cos(90) = 0 m/s Vdesty = 2169.976 m/s * cos(45) = 1534.402 Vlaunchy = Vdesty - Vroty Vlaunchy = 1534.402 - 0 = 1534.402 m/s We finally have X and Y components of our rotational launch vector. By combining them, we can finally see how much horizontal dV we need and what way to point it! It is at this point where I finally get to call in my good friend Pythagoreas. Since our X and Y velocities are perpendicular, we can treat them as sides of a right triangle. Vlaunch = (Vlaunchx^2 + Vlaunchy^2)^(1/2) Vlaunch = 2050.009 m/s And the launch azimuth, the heading from North we need to launch? tan(β) = Vlaunchx/Vlaunchy β = arctan(Vlaunchx/Vlaunchy) β = arctan(1359.465/1534.402) β = 41.540 degrees. Mathematician's Note: What may seem like mathematical incongruities result from more than a few rounding errors. I use Excel to get my numbers, and it goes to several times more decimal places each operation than I care to write down for the purposes of this tutorial; to someone plugging my given numbers into their calculators, my truncated decimals will most certainly propagate error all the way down. Most notably, the reason sin(45) and cos(45) are unequal is due to such a truncation thanks to the -.1025 degree latitude of the launch site in the calculation. Spreadsheet: I placed a copy of the aforementioned spreadsheet in my Dropbox, downloadable HERE. The fields for gravitational and orbital parameters have been placed on their own sheet to be edited, so you can use it as a calculation aid.

"The Booster Concerto in C4"

He's trying to sing his favorite space-themed opera piece.

Remember Porco Rosso? After finding some free time today, I successfully got it on the runway at KSC. It handles reentering like a champ and can dead-stick if you get it right. I undershot and had to kick in the jet engines, then my game went slideshow mode. I broke off the lower two Whiplashes on my landing, which is pretty good considering I was getting 1 FPS. I took some screenshots of the craft and its reentry, all viewable here: http://imgur.com/a/Fp9OG This coming weekend I'm going to make various refinements to the design and see if I can fly some cargoes into orbit. Does anyone know the most mass-efficient way, barring seats, to get two more Kerbals aboard? I need six crew and an RC-L01 for an eventual planned mission.

Neither angle gives me any idea what engines your craft has, Rune. Not the most efficient design, but still a fun one nonetheless - I'd say it's the AK of SSTO designs. Those Big-S Strakes make the best tailplanes. What's your reentry profile look like? I've never had to up-armor any of my designs, just add more airbrakes to some, so you doing so is quite weird to me.

Ah, another spreadsheet guy. KSP makes me really glad I took all those Microsoft Office courses in high school; with my Excel-fu, I can calculate orbits and required dV stage-by-stage. burn-by-burn, using it to influence craft design and loading.

Not unless KSP's playerbase really, really wanted to cook scrambled eggs on their CPUs.

This anaconda don't want none unless you got buns, hon.

I'm just as curious as you are about the general safety and toughness of Porco Rosso, my current WIP. It's an SSTO that's (mostly) stock. KW Rocketry provided the battery packs and there's a MechJeb unit on it as well. https://kerbalx.com/Samniss_Arandeen/Porco-Rosso

So my work-in-progress Mk. 3 spaceplane made it into orbit when I wasn't even planning...

This is my current work-in-progress, dubbed Porco Rosso. Since you're reviewing crafts, I figured I'd request another pair of eyes giving feedback and possible improvements. Download link (KerbalX craft with full description and Action Group listing): https://kerbalx.com/Samniss_Arandeen/Porco-Rosso Here's a picture of Porco Rosso (as of current, the only one I've yet taken) as she currently flies:

Good list, but may I add more? Soften the rear suspension in a tricycle arrangement. This will help absorb the shock of a landing and prevent bouncing off the ground. It will also help with the next hint, which is... Arrange your landing gear so the nose points slightly up at rest. This will give you a slight AoA on your takeoff roll and give you an extra bit of lift as a result. In my experience, it also cuts down on tailstrike risk at takeoff. There's no easy way to check this in the editor, but shoot for 3-5 degrees pitch up when stationary on your wheels. Remember that steering is enabled by default for the gears that have it. If you're using smalls or mediums all the way around, be sure to disable steering on the rear gears. This may be counterintuitive, especially if you're into cars or motorcycles like I am, but you want a rear brake bias on the landing gear. That's where most of the weight is if you positioned your gears correctly, and less/no brakes on the front wheel reduces its likelihood of slipping when trying to yaw.