Jump to content

Snark

Lead Moderator
  • Posts

    9,989
  • Joined

Everything posted by Snark

  1. The other thing to be careful about is the structural integrity of the ship itself. With really big ships touching down on Eve, often the problem is not the landing gear failing, but rather the ship comes apart like a pile of jackstraws (radially attached tanks come loose from the center, engines sliding off their tanks, etc.) Whether any given ship would do this or not, the key is testing, testing, testing. Girders as landing gear can take the impact, but transmit a lot of shock to the ship. The "Mammoth" engine has an unusually high impact tolerance (20 m/s), as well as having (relatively) good Isp in atmosphere; it's possible to land directly on the engine (using it as landing gear, in effect), but this can be risky if the ground's not very level-- you can get the mass of the ship sliding sideways off the engine and snap it off its fuel tank.
  2. Handy answer to that problem: airbrakes. They're incredibly effective (overpowered, IMHO). My experience has been that it's practically impossible to have reentry problems if there are deployed airbrakes on the ship.
  3. Explanation is below, but the TL;DR is: You don't need to worry about this, go ahead and take them out of the science lab, it won't hurt anything. Reason: There's the science data, and then there's the science. The science is the thing you pull out of an instrument and store it wherever (could be in a command pod, could be in a science lab, wherever). This is the thing that gives you science points when you retrieve it on Kerbin, and which is consumed in the process. The science data is what goes into the science lab when you click the yellow "analyze" button on the science report. This is the thing that the lab can only hold 500 of. This is the thing that the lab uses when it runs continuously to generate science points over time. The important thing to understand is that these are completely separate things. The science lab only cares about science data. It doesn't care about actual science at all. It happens to be the case that you can store the science in the lab if you want to (just as you can store it in a command pod, if you want to)... but the science lab neither needs nor uses it in any way. So here's how your science-gathering operation should look like: 1. Acquire science (via instrument, crew report, EVA, or surface sample). 2. Put that science somewhere that is physically connected to a science lab. Doesn't have to be in the lab. It could be stored in a command pod of a vessel that's docked to the vessel that has the science lab, for example. 3. Review the science data. If it hasn't been analyzed yet by that particular science lab, then the "review science" UI will have a yellow "analyze" button. Click that. This uploads the data for that science result into the lab. 4. Repeat #3 for all of your science results. 5. At this point, the science lab has received all of the science data and no longer cares about any of the actual science results. 6. Return your science results to Kerbin and retrieve them to get points you can now spend on the tech tree.
  4. Airbrakes = easy mode. They weigh almost nothing, attach radially so you can slap 'em on anywhere, and are astonishingly effective. They slow you down gently as a feather, way up in the upper atmosphere, often without so much as a single visible reentry effect.
  5. You're thinking of RemoteTech: http://forum.kerbalspaceprogram.com/threads/83305
  6. Taking a step back: Are you in career "hard" mode? My experience has been that contracts are (mostly) financially worth it, and generally don't require recovering debris for cash. I never bother with trying to recover debris, and do financially OK. Of course, it's caveat emptor with the contracts-- some of them are sucker deals, keep an eye on what they pay and don't accept if they're asking for something really hard and don't pay much. So the solution here may not be a matter of "how to recover debris," but rather being more choosy about which contracts to take, and being careful about ship design to keep costs down. For example, use SRBs as much as possible-- they're dirt cheap, it doesn't matter much if you don't recover them. One thing that took me a while to catch on to: You know how the contract advertises an "advance" and a "completion" amount for funds? When I first started playing career, I just assumed that the advance was taken out of the total reward (i.e. if a contract has a $20K advance and a $100K reward, I just assumed that I'd get $20K up front and then $80K when I finish.) It turns out that my assumption was wrong: they add together. You get the advance right up front, free and clear, and then the reward when the contract completes. I find that the advance is nearly always enough to cover the cost of the ship I need to do the contract, with funds to spare. Maybe I'm the only person to make that dumb mistake , just mentioning it in case anyone else has been similarly confused.
  7. +1 to doing Kerbal rescue contracts, for several reasons: - They require minimal investment. You can build a very cheap craft that will get to LKO to pick up a kerbal. - They're excellent practice. They require you to develop skillz for performing a rendezvous in orbit, which is something you'll need throughout your KSP career. - They give you additional Kerbal staff (which you'll want later on when you start sending multiple missions all over the system) without having to pay a bunch of money at the astronaut complex to hire them, with the added bonus that they're already level-1 for free (since they've been in orbit). - And you get some cash along the way. :-) Other than that, +1 to Grumman's suggestion of doing Minmus before the Mun. It's easier in every way: less dV needed (so easier to build the rocket), and the surface gravity is much lower, so it's much easier to control your lander during the last bit before touchdown. Also, Minmus has lots of perfectly flat, level ground to land on-- that can be a big plus in your early career, when you have limited part selection and your landers tend to be tall and top-heavy. The flat ground makes it easier to land without tipping over.
  8. You definitely want to launch when you're directly under the ascending/descending node. If visually identifying that point is tricky, here's a handy technique: 1. Before launch, switch to map view. 2. By default, it's centered on your ship. Double-click on the planet, this will switch to be centered on Kerbin itself. 3. If you pull back on the camera a bit, the map view will draw a little gray dot right in the center of Kerbin. 4. Rotate the camera view so that you're looking perfectly edge-on to the desired orbit (i.e. so that the orbit looks like a straight line passing through the center of Kerbin, rather than an ellipse). 5. Now timewarp until your ship moves to be right there on that spot (i.e. your ship shows as being directly under the orbit line, directly on top of the dot at Kerbin's center. 6. Launch. Immediately upon launch, use Q/E to roll your ship so that the desired orbital direction is directly down (or up) from the center of your nav-ball (this makes the next step easier, since you can adjust your gravity turn just by pitching up/down). 7. Start your gravity turn, climb to orbit 8. Profit!
  9. +1 for the rescue, simply because it's more fun. But you don't actually have to rescue him, if you don't want to: 1. Kerbals can survive reentry on EVA just fine. No heating at all, you don't even get graphic effects. 2. A kerbal on EVA can fall out of the sky and land without a problem. IMHO, both of those facts are way overpowered and ought to be nerfed (after all, the name of the game is "Kerbal Space Program", not "Kerbal Xtreme Skydiving")... but until/unless they change it, it's no problem to bring the little green guys without a ship.
  10. Pretty close, but actually, the optimal point will be somewhere between these two, depending on how much burn you're doing. The ideal case (in terms of minimal dV expenditure) is for you to be traveling perfectly Kerbin-retrograde (relative to the Mun) at the point where you exit the Mun's SoI. Alshain's recommendation will start you heading in the right direction, but since the Mun's gravity will bend your trajectory a bit, you actually want to start your burn a few degrees earlier than that. (90 degrees is way too far-- Alshain's recommendation is closer than Sigma88's.)
  11. If you're on an orbit that's already captured to Earth (or Kerbin, or anywhere)-- i.e. you're not on an escape trajectory to start with-- then it's physically impossible to aerobrake into an escape path. Conservation of energy requires this. If you're in a captured orbit, it means you do not have enough energy (kinetic + potential) to escape. Period, full stop. The only way to escape would be to add energy; contact with atmosphere reduces your energy. So you can't aerobrake your way to escape. Q.E.D. I could certainly see that being a concern. Doesn't explain the "lost in space forever" comment, though. And in real life. Conservation of energy says that you can't raise apoapsis to escape; conservation of angular momentum says that you can't raise your periapsis out of the atmosphere. Cannot be done. This is physically impossible. If you're orbiting a planet, the only kind of "gravity assist" you can get from the planet itself is if you fire your engines at periapsis to take advantage of Oberth effect. You can't bounce your way to escape, any more than you can drop a rubber ball and have it bounce higher than you dropped it. ...Of course, none of this explains the "lost in space forever" concern that DarkGravity raised initially. That piqued my curiosity, so I rummaged around on the web a little. Most of what I could find (Wikipedia, NASA) is maddeningly coy about return-trip details (e.g. exact time of trans-earth burn, exact time of reentry), but I finally tracked down this: http://history.nasa.gov/ap11fj/index.htm Rummaging through this account, I find the following timestamps (these are hours/minutes/seconds of mission time from launch): To the Moon: - Translunar injection: 002:44:18 - Lunar orbit insertion: 075:49:51 Back to Earth: - Trans-Earth injection: 135:23:44 - Reentry: 195:03:06 approx ...if I'm doing the math right, I make that a bit over 73 hours for the outbound journey, but a bit under 60 hours for the homeward leg. On the other hand, if I just plug in the numbers for how long a minimum-DV burn would take (i.e. half of an elliptical orbit, with periapsis at LEO and apoapsis at the Moon's orbit), I come up with 126 hours. So it sounds as though they were making the transfers between Earth and Moon a lot faster than optimum dV conservation would suggest (perhaps to save consumables?). If that's the case, it may be that they were actually on an escape trajectory when they were coming home, which totally explains the "lost forever" comment: if you don't aerobrake enough, you don't kill enough velocity to capture, and you end up flying off into the solar system.
  12. From the standpoint of physics, you're entirely correct... but I think the real issue here is more one of gameplay. After all, we already know that the Kerbal universe has properties very different from our own; there's no realistic way for a planet 600km in radius to have Earth's gravity. It's a toy solar system, and they made the right decision in doing so. KSP aims at giving us the experience of "what's it like to fly rockets," making it real enough to be challenging and to give an appreciation of what's hard, while simplifying enough to make it fun to play without requiring an advanced degree in aeronautical engineering. It's a tricky balancing act, and for the most part, Squad has done a brilliant job with this. And part of flying rockets is that reentry is supposed to be hard. This is a game, so it's fine if it's not as hard as real life, but it should at least be hard enough that you have to care, and your ship design should have to make at least a reasonable nod in that direction. So if we can accept planets that are 10x denser than reality, I think it's fine if we also postulate reentry heating above normal, for the sake of fun.
  13. Yeah, those ones are rigid. I don't use them all that often, but when I do, I usually add some hefty reaction wheels to the vehicle so that when I'm turning, I can add SAS torque to the (tank-style) wheel steering to help with the turn.
  14. Yes, re-entry heat is definitely easy-mode. I love that they added heat shields, I love that orientation matters, that the heat shields are ablative, all of that stuff... except that it's possible to re-enter without a heat shield without experiencing any ill effects, as long as you're careful about it. In particular: airbrakes are way overpowered. Put some airbrakes on a ship and you can slam into atmosphere at several kilometers/second and it decelerates you as gently as a feather way up high in the atmosphere with no problems-- indeed, without even any graphic effects at all. Don't get me wrong, I love that they added airbrakes, and I love the way they look, and the fact that they're tied to the brakes hotkey... it's just that they're massively overpowered, they shouldn't be a free ticket to atmospheric reentry. Also, a kerbal in EVA can reenter with no overheating problems at all. That's just wrong. Myself, I like to play by just imagining that reentry heat is deadly, and putting heat shields on things even when I don't really need them. But I wish the game made it more of an actual challenge rather than an imagined one.
  15. Also, it's worth calling out explicitly (Murph alluded to this), just in case you're not aware: MPL processing is on a per-lab basis. You can only process a given science result (instrument + celestial boy + situation) once for any given lab, but if you have another lab, you can run it through that one. It's unfortunate that the lab doesn't have any sort of UI display to let you know what it has already seen, but you can always start afresh with another lab and know that it can process everything. (Also, if you're really determined, I imagine that the save file must have a list of processed experiments for each lab, though I haven't bothered to go and look). Seems like a good place for a mod... hopefully someone will create such, if it's not there already.
  16. Not sure whether it's "supposed" to happen, but yeah, it's pretty common. Been doing that since forever. It seems to be mainly just cosmetic, at least in my experience; I've never had a problem with any physical consequences such as a craft tipping or whatever.
  17. Agreed that the satellite-encounter problem makes the contract harder than you'd think when accepting the contract. I actually kinda like a challenge like this... but it ought to happen deliberately (with appropriate design), not by accident. That is, I wish they'd do something like this: 1. When the game is generating a rescue contract, and rolling the dice, it should decide "should this be a hard-rescue-with-encounters or not?" 2, If it decides "no, this is a normal rescue" (which should be the majority case), then the orbital parameters should be set up safely, to guarantee no encounters with the Mun or whatever. 3. If it decides "yes, this is a hard one", then the contract text should clearly include something like "NOTE: This orbit is subject to Mun encounters and is extra-hard" or whatever... and the contract reward should be made higher, to reflect the added difficulty. Anyway, regarding the current problem, ...That's a brilliant suggestion, excellent idea! It actually wouldn't even be all that hard in terms of dV. Send your rescue craft into a Mun orbit, target the rescuee. Even before the rescuee enters the Mun's SOI, you can see what its trajectory will be as it transits the SOI, so you just set up an intercept to that (it's pretty much the same problem as setting up a rendezvous to capture a passing asteroid). So it's a bit more dV, but not all that much (basically, the only extra dV you pay is to get captured by the Mun, and then to leave again; just a few hundred m/s). Totally doable.
  18. Are you a KAS user? Maybe you could tow the asteroid with a long winch cable, would allow your engines not to have to point sideways so much, fewer cosine losses.
  19. Interesting... are you running any mods? The only time I've run into this was when I had a mod installed with a custom engine, and the engine was what was touching the ground-- my guess is that it was some sort of problem with the engine's collision mesh, or something. Have never seen this bug in stock, though. One question: Does it just say you're in-flight when you're focused on the spacecraft, or does it apply to your kerbal when he/she is out walking around? e.g. could you complete the contract by taking the kerbal out, and then retrieving just the kerbal? (leaving the craft)
  20. I feel your pain... the claw is such kraken-bait, and has been for a really long time. I'm sorry I don't have more concrete advice for you-- my own solution is "don't use the claw, ever, and just ignore asteroids completely." Which I realize doesn't help you. My experience is that "more claws" doesn't mean "less kraken," but quite the reverse. Aside from kraken problems, though, one thing that can help with the "wobbling back and forth" problem is to keep your torque and your thrust entirely separate. For example: 1. Your main ship has engine thrust and a single claw on the front. 2. Put docking ports on the sides and give it a couple (or 3, or 4) little robot "daughter ships" that are just a claw, command probe, some monopropellant & RCS thrusters, and big heavy reaction wheels. 3. When you dock your main ship to the asteroid, detach the daughter ships and have them move to a different part of the asteroid and latch on. 4. Then you go and carefully disable ALL sources of torque on the mother ship: turn off all reaction wheels, disable any torque on the command pod, make sure that its engine is gimbal-locked. 5. Now you're good to go: your main thrust won't waggle (since it has no torque authority), and your little daughter ships can handle torquing the 'roid to the orientation you want (since they're not thrusting, it doesn't matter if they waggle). Another approach I've done is to pull the asteroid instead of pushing: the claw is on the back of the craft, and it has engines that stick way out to the sides on booms so that their exhaust goes past the asteroid. This works like a charm... except it's limited to smaller asteroids (wouldn't want to try anything bigger than a C), and I haven't tried launching such a contraption in 1.0+, I imagine it would be an aerodynamic nightmare.
  21. Answering a few different questions from different posts: Depends a lot on your specific trajectory, and also what your desired end state is. For example, is your only goal "be in orbit and I don't care what it looks like"? Or is it "be in a circular orbit at a particular radius"? Assuming that all you care about is "lift my periapsis above a certain minimum height" (e.g. "out of the atmosphere"), then the most efficient way to adjust periapsis is to thrust prograde (if you're raising) or retrograde (if you're lowering) when at apoapsis. However, if (for example) you've already raised apoapsis of 200km, want to be at a circular orbit of 100km, and are currently rising past 80km, it may be a different story (e.g. may be worth burning a bit radially inward from prograde). Working out exact numbers would require orbital parameters, though. Absolutely correct about the "doesn't matter" part, the numbers are tiny... just want to note that Minmus isn't actually tidally locked; it rotates fairly rapidly. However, that's irrelevant to the current discussion-- you're right that it doesn't matter, since you can practically sneeze your way off Minmus. What I mean is "the angular momentum of the object as it orbits around the parent body." Sorry, I guess I should be more careful with my terminology. I mean this: http://en.wikipedia.org/wiki/Specific_relative_angular_momentum This is the vector cross product of its momentum with the radius vector from the primary to the orbiting object. Easiest way to think of it in KSP terms is the product of orbital radius times the "sideways component" of your velocity. It's conserved, meaning that unless you apply thrust, it stays constant. That's what Kepler's 2nd law is about: http://en.wikipedia.org/wiki/Kepler%27s_laws_of_planetary_motion If you're in an orbit with an apoapsis of 1000km and periapsis at 500km, you'll be moving twice as fast at periapsis as apoapsis. Note that for purposes of doing this math, I refer to periapsis/apoapsis as measured from the center of the primary (which is what physics cares about), not from its surface (which is what KSP reports to you). Conservation of angular momentum is really important in calculating orbital mechanics. Pretty much every math problem (e.g. "I'm currently at this location moving at this speed in this direction, what will my periapsis and apoapsis be" or "how much of a burn will I need to make my orbit like thus-and-so") involves writing down the equations for energy (call it E) and angular momentum (call it L), and then solving for the case where E1=E2 and L1=L2.
  22. If you're using a warpdrive, I think you're basically out of luck-- the game's not designed for that, the UI doesn't really offer any help. Seems like something to suggest to the warpdrive mod author that they add. If you were flying there conventionally, then the reason you'd care about your relative velocity would be "how big a burn will I need to capture when I get there," and that would be easy to answer: just click on the planet, set your focus there (which will show your trajectory sweeping past it), and drop a maneuver node to see how big it needs to be to get the orbit you want.
  23. A few thoughts: First, make your front end more aerodynamic. You have a lot of exposed parts, especially those radial bulgy tanks on the adapter-- that drag is gonna get you. Move all that paraphernalia into a 1.25m service bay (it only masses 0.1t), with an appropriate nosecone in front of it. That makes your ship a nice smooth cylinder. Secondly, you have the "Thumper" SRB driving the thing-- that's way overpowered (by default) for that tiny middle/upper stage, as stibbons has suggested. At the very least, make sure you've put a thrust limiter on that SRB so that it doesn't slam you past Mach1 right away. If you're trying to pick a number, I find a TWR of about 1.5 works pretty well. Look at the craft's total mass on the engineer's report, multiply by 1.5, multiply by 9.8, then divide by 275 (the thrust of a BACC), that'll tell you what to set it at. I'd also suggest that your mass ratio between that huge BACC booster and your tiny 1-ton 2nd stage is a pretty big gap. Maybe consider downgrading the SRB from a Thumper to a Hammer, and then upping your 2nd stage from 1 ton of LFO to 2 tons. (And of course make sure to re-do the math to figure out how to set the thrust limiter on the SRB.)
  24. By the way, I play RemoteTech and am in the regular habit of setting comm satellites to "debris", never had a problem with it (they still communicate, never had a problem with them despawning). Of course, I don't have a very high-debris play style, so I don't think I ever approached the default 250 limit. In any case, if you're ever worried that it could be an issue, just give your satellites distinctive names before making them debris, and then every once in a while go to the tracking station and manually clean out a bunch of non-useful debris, to make sure you don't get close to the limit.
  25. http://wiki.kerbalspaceprogram.com/wiki/Tutorials#Real_life_missions http://wiki.kerbalspaceprogram.com/wiki/Tutorial:_Apollo_11 And no, you can't use funds to train kerbals-- the only way to train them is to go out and do things (e.g. get to Kerbin orbit, land on various celestial bodies), then come back to Kerbin for experience points.
×
×
  • Create New...