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^)