BenCushwa

I will try to reuse general designs within a single career mode game in order to keep refining them. When I start a new game, I'll take what I consider to be the most useful/successful aspects of my favorite past designs and incorporate them into the new game, while still trying to do new things. It's neat to see how my designs have evolved over time.

Since Asteroids don't have their own Sphere of Influence (SOI), they won't provide any "in space" results from experiments. As Streetwind mentioned, a Kerbal can collect a surface sample from one. I've never tried it, but I wonder if a ship that uses a grappling arm to physically attach to an asteroid can get any "landed" science results? Anyone know?

You can set your Avatar, Profile Picture (different things), and Signature in the "Settings" tab at the top right of the menu. Avatar is what displays on posts, Profile Picture is what displays when someone looks at your profile. The green bar is reputation, and it's only earned when people share it with you. You share reputation with others by clicking on the black star-shaped button in the lower left of each post. Hope this helps.

[quote name='Jouni']Remember that the joints between large parts are already rigid enough. The joints between small parts are the real problem....[/QUOTE] This is why I'm more prone to use struts on Mk1-based vessels than I am on pretty much anything else: Mk1 joints are kind of flimsy

[quote name='Jovus']Since, as we know, orbit is halfway to anywhere, first you have to send it to orbit. Then, you have a choice. Since you're in orbit, you're halfway to anywhere. There are oceans on Kerbin and on Laythe. Sure, you could reenter on Kerbin right away, but doesn't that strike you as a little silly? So you send up and dock an interplanetary tug. Finally, after the transit, you do an aerocapture and then a hydrocapture at Laythe. Voila! You're on the ocean![/QUOTE] This post made my morning. B^)

[quote name='EdFred'][URL]http://forum.kerbalspaceprogram.com/threads/139219-Fairing-CoL-Offset-%28also-staged%29[/URL] I experience the same issue: [spoiler="whaat?"] See where that center of lift is. Makes it impossible to launch. Even if you go ridiculously slow. I went back to 1.0.4 because of it. [URL]http://webpages.charter.net/edfred/kerbal/2015-11-12_00015.jpg[/URL] [/spoiler][/QUOTE] Needs more struts. ;^) I know that this is often a silly response to any kind of issue, but in this case I think it's true. You have a large, relatively high-drag payload on top of a 1.25m rocket. Once that joint starts flexing the heading of your engines relative to your pod will get you stuck in an SAS feedback loop and rip you to shreds. The only way I could see posibly getting that rocket into orbit as-is would be to launch it straight up to keep thrust and drag forces in-line until after you pass 30k (i.e. the bulk of the atmosphere) then start circularizing from there, but that's really inefficient. Another alternative would be to replace your 1.25m core with a 2.5m core, but that would be a more extensive, and expensive, redesign than simply adding struts.

[quote name='H2O.']Love the way you clear the door :)[/QUOTE] Thanks. I spent a whole lot of time looking for a "fixed" solution (i.e. not detaching anything), but ensuring that you have enough room for a Kerbal to access the hatch while still providing sufficient aerodynamic protection (both launch and re-entry) made the final orbital stage too long or involved excessive amounts of clipping for my tastes. My other primary candidate design was one that had the two crew cabins perpendicular to the cockpit such that the hatches faced out the side; it worked well, weighed less, and had fewer parts/stages but I didn't like the way it looked.

[quote name='Threadsinger']Wow, I never considered that myself. Thanks for the imparted wisdom - so many launch troubles now make way more sense.[/QUOTE] Yup, any amount of bend in a joint between your active pod and a gimbaling engine translates to your SAS commands being off. This can set up some nasty resonating states that will tear an otherwise reasonably stable rocket completely apart. This is one more strike against really tall rockets: they're much harder to keep perfectly straight. On a few occasions, I've manually limited the gimbal range of my lowest stages and this also helped.

So, here I am, posting my very first ship to the Spacecraft Exchange. One of the new parts I was really excited about in 1.0.5 was the Mk1 Crew Cabin. I saw a lot of potential there for lightweight and/or early Career Mode shuttles to get Kerbals experience and rescue stranded Kerbals from LKO. Unfortunately, this lovely part has one serious drawback: both of the crew hatches are underneath the connection nodes, which means that you can't EVA a Kerbal in or out of the cabin if connected to something on both ends. Needless to say, this complicates the design process. Not one to let simple issues like this stand in my way, I pressed on. My early attempts involved excess amounts of crew shuffling and then excess amounts of clipping. I went through several different configurations before settling on the Tristar configuration that met what I consider to be my design ideals: functional, easy on the eye, and clipping only in seemingly realistic ways. After a few minor revisions, I felt satisfied with the results. NOTE: Even though it's listed under Mod Craft, this craft is entirely stock except for the presence of one KER part to provide the KER readouts. So, without further ado, I present the TriStar 1b. [spoiler="Pictures"] [IMG]http://i.imgur.com/xiFI3sZ.png[/IMG] [IMG]http://i.imgur.com/uWOK7GC.png[/IMG] [IMG]http://i.imgur.com/q6FY4YT.jpg[/IMG] [/spoiler] [spoiler="Quick video of orbital mission"] [video=youtube;gwkqcSJn3kI]https://www.youtube.com/watch?v=gwkqcSJn3kI[/video] [/spoiler] [URL="http://kerbalx.com/BenCushwa/TriStar-Ib"]Link[/URL] to craft file on KerbalX. Ascent is simple and stable: stage to launch, pitch the nose down to ~80 elevation and the ship should maintain that heading on it's own. Drop the SRBs and the drop tanks as soon as they empty. After dropping the tanks, you should be near 30km in altitude, which is about when you should start pitching the nose down to continue raising your apoapsis and circularizing. Drop your main engines (and blow the forward hatch covers) when they run our of fuel (you'll still be sub-orbital, so no long-term debris to worry about) and continue your orbital insertion with the final orbital vehicle. You should end up with roughly 1000 deltaV left in the tanks for rendezvous maneuvering in a circular LKO of 80-90km, be it to transfer crew or rescue stranded Kerbals. Re-entry is likewise simple. Perform your re-entry burn, separate your engines, and hold retrograde through re-entry. It will handle negative periapsis re-entries from LKO (as seen in the video) as well as shallower angle 30km periapsis re-entries. It should be able to handle re-entry from anywhere in the Kerbin SOI with careful flight planning, but I have not tested this. Stashed away inside the hollow Structural Fuselage is a battery and an additional reaction wheel to ensure sufficient control authority. The TWR is relatively balanced throughout ascent so you don't have to worry about throttling down to reduce drag. My plan moving forward (once I've gotten this particular career mode game far enough along) is to add RCS capability and a docking port to the design to turn it into an effective LKO station transfer shuttle. Enjoy. UPDATE: I just confirmed that the TriStar 1b can fly from LKO from a free-return-to-reentry flyby of the Mun and can survive a reentry from the Mun's SOI if you set Kerbin periapsis at ~30km[I].[/I] I was reasonably certain it could make it to the Mun and back (flyby only) based on how much deltaV it had on LKO, but I was less certain about the landing because I cut the heat shields back to the bare minimum. She had just enough.

[quote name='Streetwind']Not sure the example is a good one, since burning more than 90 degrees from the node is counterproductive in every case and heading... though maybe the 90 degree variant might be a good extreme-case test scenario, I suppose. And about change in direction versus fixed direction, hmm. I'm not sure. You're twisting your orbit about a whole lot with that radial component, which should shift the apoapsis around... maybe it's a result of radial burns being so inefficient when deep in a gravity well, that the deviation is less than what you get from shifting your ap around with fully prograde burns? I can only speculate...[/QUOTE] It was intended as an extreme example to show that for burn long enough you cannot simply burn to the maneuver node and expect to land up in the target orbit. And I totally agree re: radial component and shifting apoapsis; this is why I included provisions for a correction burn in the "burn straight prograde" scenario. [quote name='OhioBob'][FONT=Calibri][SIZE=3][COLOR=#000000] [TABLE="width: 575"] [TR] [TD="width: 147, bgcolor: transparent"][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]Scenario #1 aligned to Prograde [/FONT][/COLOR] [/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]Scenario #2 aligned to Maneuver Node[/FONT][/COLOR] [/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]Theoretical Ideal Orbit[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"][COLOR=black][FONT=Calibri]Semi-major axis, km[/FONT][/COLOR][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]-450472[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]-450473[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]-450459[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"][COLOR=black][FONT=Calibri]Eccentricity[/FONT][/COLOR][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]2.58596[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]2.51543[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]2.50957[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"][COLOR=black][FONT=Calibri]Periapsis altitude, km[/FONT][/COLOR][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]114430[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]82660[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]80000[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"][COLOR=black][FONT=Calibri]Longitude of periapsis, deg.[/FONT][/COLOR][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]-7.506[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]-2.466[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]0.000[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"][COLOR=black][FONT=Calibri]Longitude at infinity, deg.[/FONT][/COLOR][/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]105.24[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]110.96[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [TD="width: 77, bgcolor: transparent"][CENTER][CENTER][COLOR=black][FONT=Calibri]113.48[/FONT][/COLOR][/CENTER] [/CENTER] [/TD] [/TR] [TR] [TD="width: 147, bgcolor: transparent"]Δv, m/s[/TD] [TD="width: 77, bgcolor: transparent, align: center"]2054.4[/TD] [TD="width: 77, bgcolor: transparent, align: center"]2067.4[/TD] [TD="width: 77, bgcolor: transparent, align: center"]1990.4[/TD] [/TR] [/TABLE] [/COLOR][/SIZE][/FONT][/QUOTE] Excellent work. It seems I was reasonably correct: burning to a maneuver node will cost you more deltaV and be closer to your desired orbit, whereas burning prograde will save you some deltaV but require correction. In your case, I'd wager that the 13 deltaV saved won't be enough for a correction burn, so burning to the maneuver node is likely the better option. Cheers!

Just adding my $0.02 after some other great posts explaining things: basically, you need to make sure that you have sufficient control authority. This can either be achieved in atmosphere by controllable fins and anywhere by vectored-thrust engines or sufficient reaction wheels (although I wouldn't rely too heavily on the latter while maneuvering under power). Too-tall liquid fuel stages are also bad for stability: they drain from the top down making your rocket tail-heavy which makes it harder to control. Good luck!

[quote name='Streetwind']How can it be that one method generates less of an error than the other?[/QUOTE] Again, this is a total SWAG, but I think it has something to do with the fact that if you burn prograde, the direction of prograde changes over the duration of a long burn, whereas maintaining a maneuver assumes making a burn in a fixed direction. (This is ignoring the fact that the maneuver marker can change position over time because I have no idea how that change is calculated. I could be dead wrong here.) It's like burning normal/anti-normal to change your inclination: as your orbital inclination changes, so do your N/AN vectors, so you have to change your heading otherwise you'll start adding some prograde or retrograde. Keep in mind, the whole notion of patched conics is based on the idea of instantaneous (i.e. zero burn length) deltaV being applied at the maneuver node. Putting the maneuver node at the middle of a burn with an actual duration provides a close approximation, but the longer the burn the less accurate the approximation. EDIT: Take the notion of a long-burn maneuver node to the extreme for a moment. Assume that you have a simple prograde maneuver node that requires a burn so long that you have to start it on the direct opposite side of whatever body you're orbiting. If you burn according to the maneuver vector, you'll be burning the [I]exact wrong direction[/I] for the maneuver and you'll end up on a trajectory nothing like what you planned, and you'll likely de-orbit to boot. If you burn prograde and maintain prograde until you generate enough deltaV, you'll likely get much closer to the intended results. I <3 orbital mechanics. B^)

[quote name='Aser']I came back to KSP for the new update (haven't played since 1.0 hit), and I've noticed that the heat shields do not behave themselves any more. I first noticed it on returning from my first orbit in a new career. I always try to return pretty gently (~75k ap and ~50k per). Everything seemed pretty normal until i reached around 20k. I'm blazing towards the ground and it seems like I'm coming in way too hot. Maybe I'll start slowing down? Nope. Ended up pulling my chutes at 1000m going 350m/s. Of course they ripped off and I slammed into the ground, killing Jeb. ... Is this an intended behavior, or is this a bug?[/QUOTE] That approach is likely way too shallow now. 1.0.5 changed the properties of the atmosphere so re-entry tactics had to change too. It's not just enough to have enough of a heat shield, you now need sufficient drag to slow you down or else you'll burn up in the atmosphere or land too hard for chutes to save you. This is not a bug from what I've read.

First off, I'm assuming you're aligning your burn such that the middle of the burn coincides with the maneuver node. I highly suspect that you are too, but I just wanted to clarify. Setting SAS to point prograde and just burning prograde for the length of the maneuver should be the most fuel-efficient way to complete your maneuver, but for a burn that long your final trajectory will be different than your planned trajectory. Make sure you have enough deltaV budget for correction burns to tweak your flight path. Following the maneuver through the whole length of the burn will land you on a trajectory that's closer to your planned one, but will be less efficient. The real question is whether the correction burns from burning straight prograde make up the amount that gets wasted by following the maneuver. I suspect that they're about the same, but I have no evidence of this beyond a handful of personal experiences. Hope this helps. Note: I deliberately ignored multiple burns (aside from the correction burns) and TWR because, hey, it's your thread. ;^)

I had an issue similar to that one. I don't know exactly what resolved it, but when I saved, closed, and reloaded the issue was gone. I'm guessing that KSP does some sort of check to see if a ship has comms on it when the game loads and goes from there, but who knows. Side note: For a while I got so bad about attaching antennae to things that I made grabber-comms probes to fix my mistakes. Just launch one, ram it into the lab, and boom, instant comms. I called them OIDIA probes: Opps, I Did It Again.... B^)

This is one of those instances where a "Center of Drag" indicator would be handy. Even if your CoL, CoT, and CoM are fine, if your CoD is offset too far in one direction, it'll flip your plane over just as quickly as any of the others. Try offsetting CoM/CoL/CoT to compensate for what I'm guessing is your offset drag. EDIT: [quote name='ElMenduko']By the way, is there any way to see where the Center of Drag is?[/QUOTE] Heh. We were just thinking of a CoD indicator at the same time. Nice.

Transfer windows are nothing more than the most economical times to send a ship from the standpoint of minimizing deltaV. You certainly don't have to launch a mission within a transfer window, especially if you're doing a gravity assist to help you along, but you may end up burning ore fuel to get there.

[quote name='Venusgate']from 75x75, anything (and I mean commandpod+.625 chute) with an entry Pe below, say 15km, is going to be going too fast to deploy the chutes in time.[/QUOTE] I re-enter in 1.0.5 from 80x80 with Pe of zero or less all the time. The trick is to have a high enough drag to weight ratio and sufficient heat shielding. A simple Mk1 pod/heat shield/chute would probably crash on my descent profile because it wouldn't slow down in time, but a ship that's three Mk1's wide with three Mk1 shields and not a lot of extra weight slows down very nicely, even with only 20% max ablator to start.

I really like this. Great use of the new cargo bay and smaller mining gear!

[quote name='Meithan']Yep, as others have said, the new Δv-to-orbit values are due to the new aerodynamic model. The tl;dr version of it is that KSP now attempts to correctly estimate how streamlined a body is. You see, the aerodynamic drag force experienced by most flying objects is [URL="https://en.wikipedia.org/wiki/Drag_(physics)#Drag_at_high_velocity"]proportional to its "cross-sectional area"[/URL] (the "frontal area" it presents to the airflow). Before 1.0, this area was not properly calculated (it depends on the geometry and orientation of the craft), but simply computed directly from the [I]mass[/I] of the ship: KSP assumed that the cross-sectional area was 8 m^2 per tonne of mass, regardless of shape and orientation. I guess that the rationale behind that choice was that, very roughly, in general heavier ships are "bigger" and thus have a larger cross-sectional area. But this assumption fails to acknowledge the fact that we can build things to be streamlined: simply make rockets tall and slim and you can make them quite heavy without increasing the cross-sectional area. Before, your small 20 tonnes rocket (at launch) had an effective cross-sectional area of 160 m^2: that's as if it had a frontal diameter of 14.3 meters! Anything heavier than a few tonnes was essentially considered a pancake flying face-on for drag purposes. Hence the soup-o-sphere. Now KSP does an honest try to correctly calculate the cross-sectional area of your ship, and thus streamlined shapes (like most of our rockets) now fly with considerably less drag.[/QUOTE] The downside of this is that there is now less drag available to slow you down during e-entry and aerobreaking. Plan accordingly, and pack your heat shields.

Something I've noticed is that electric charge seems to drain (and replenish) from all available batteries at roughly the same rate, which means that small batteries (like the ones in pods) will drain first and be completely empty even if the ship as a whole has lots of charge available. Check to make sure that your lander had power because without that you won't be able to run your reaction wheels or use SAS. (Side note: I've gotten into the habit of locking the electric charge on pods and probe cores by default. This leaves them with some amount of reserve power in case I SNAFU on the dark side of a planet or something.)

[quote name='Alshain']Direct burns are not always best, New Horizons used gravity assists to get where it was going at a fraction of the cost in a fraction of the time. However, that is interplanetary travel. In the case of returning from a moon to it's parent planet, I'm not sure gravity assists are really all the useful (maybe at Jool).[/QUOTE] I think that as long as there's one body between where you are and where you want to go, you can do a useful gravity assist*. I've done gravity assists from Kerbin to Minmus (and vice versa) using the Mun, but it was mostly for fun since it didn't save me a ton of deltaV. *This is, as you indicated, just within the bounds of one planetary/lunar system. You can use a gravity assist from Jool to help get you anywhere if you have the time. ;^)

[quote name='Friend Bear'][I]Ultimately[/I], it is good practice to avoid large burn maneuvers with multiple burn stages. This applies everywhere. Say you want to go to Eve from Kerb. It is hugely inefficient to first leave Kerb and have a matched kerb orbit of kerbol then burn to hit Eve. Instead, you want to burn from inside kerb until your outside Kerb orbit is where you want it to be...meeting Eve. Similar idea here. You don't want to leave Mun then adjust. [B]Burn inside Mun so that your outside Mun orbit is where you want it[/B].[/QUOTE] (emphasis added) When I'm leaving the Mun or Minmus to return to Kerbin, I wait to depart until my ship is as close to the moon's orbital retrograde as it can be and then burn straight up. (If I'm landed at a latitude of more than +/- 10 degrees or so, I'll shift my burn towards the orbital plane.) By the time I enter Kerbin's SOI I've effectively done a retrograde burn dropping my periapsis while at the same time escaping whichever moon I was on so I'm not wasting any deltaV. If I time/position my burn correctly, I can return to Kerbin's SOI, re-enter, and land with a single burn.

Very nice. Simple, functional, clean lines.

I only registered on the forums yesterday, but I've been playing KSP and lurking the forums on and off since about 0.2something. I've always been a huge fan of your work.