Jump to content


  • Posts

  • Joined

  • Last visited

Community Answers

  1. Streetwind's post in Can't repair Gigantor XL Solar Array (mission). was marked as the answer   
    Sorry for the dumb question but... is this the correct solar panel?
    You're floating in front of a fully extended panel. Perhaps the one you need to repair is not this one, but rather a different solar panel, which is not currently extended (because it is broken)? Isn't there a mount visible on the opposite side of the truss in this picture? I'm not sure if it is another panel, but it well could be.
  2. Streetwind's post in the spining rocket, how to prevent it from stopping rotating in space and the SAS to work? was marked as the answer   
    That sounds like a large build, so another guess is "not enough reaction wheel for its mass".
    But we can only guess blindly if all we have to go on is a vague text description. Maybe you could post a few screenshots, or even the craft file?
  3. Streetwind's post in Increasing Delta-V of Rocket SSTOs was marked as the answer   
    I'm going to assume that when you say "SSTO", you actually mean "spaceplane" instead. Because it's trivially easy to make a standard rocket go single stage to orbit with plenty of dV left over.
    Your plane has 4000m/s of vacuum dV, which should be plenty, given that it should only take about 3400m/s to reach low Kerbin orbit with a standard gravity turn trajectory. Hence, your choice of trajectory is to blame for losing about 600 m/s worth of dV along the way. Getting more TWR and climbing a little longer can certainly help improve this. But keep in mind that one major contributor is your launching off of the runway. That's just never going to be as fuel efficient as a start from the vertical pad.
    Also, if getting more TWR means that you lose maximum dV in return, you may find that you gain little to nothing along the way. Your maximum possible upside from trajectory optimization is less than 600 m/s; if you stick to the runway start, it's probably in the realm of 400 at most. Switching from a Dart to a Swivel will drop your dV by about 300 m/s, depending on how much the extra weight is going to impact your plane. So you might gain about 100 m/s tops when reaching orbit. Workable, but not ideal.
    (Of course, all of this is guesstimated, so your results may vary )
    Another thing you can do is take a page out of the Space Shuttle's book, and make do with flying like a brick. As in: bring less wing, or bring more tank. This makes your landing approach harder, but it'll give you more dV to work with in orbit. You're at less than a 12x multiplier of your Isp in terms of dV, so you aren't that deep in the diminishing returns of your mass fraction just yet. If you can get back to like 4000m/s while mounting a Swivel, without increasing your wing surface, that should allow for more fuel leftover in orbit.
  4. Streetwind's post in Munar Relay Network Not Connecting to KSC was marked as the answer   
    Welcome to the forums
    The issue is that your relay satellites... are not actually relay satellites.
    The DTS-M1 is a direct antenna, which cannot receive and forward other signals. The part rightclick info in the editor shows this, albeit just as a single innocuous line.
    Refer to this table for a quick overview of what antennas can relay. As a rule of thumb, relay-capable antennas are always heavier and higher-priced for the same perfomance.
  5. Streetwind's post in Does the cost of every subsequent dV exponentially increase? was marked as the answer   
    A long time ago, in a galaxy far, far away, I wrote this "little" explanation piece about the phenomenon you observed, and some of the lessons you can derive from it. I recommend giving it a read, and looking at your rocket stage design in a whole new way afterwards
  6. Streetwind's post in Cant upgrade KSP steam past 1.10.1 was marked as the answer   
    Uninstall KSP in Steam Rightclick KSP in Steam Select Properties Click the "Betas" tab Ensure that the dropdown menu is set to "none" Close the Properties window Install KSP again If this does not give you the latest version, please contact Steam support about their client not working properly.
  7. Streetwind's post in Interstage decoupling was marked as the answer   
    This is something for which there is no straightforward way to do it in the base game. As Jimmy said above, the engine plates included in the Making History DLC are specifically meant for this.
    If you don't have them, you need to use surface attachment to circumvent the lack of dedicated parts.
    Start by attaching the fuel tank of the lander to a fairing truss node, with a full size decoupler in between. No bi-couplers or anything here, don't ever use them in between stages, it never works. Just lander tank -> decoupler -> truss node.  This leaves you with a clean, full-size node stack top to bottom without any of the engines getting in the way.
    Now, rightclick the fairing and turn off the interstage truss. Not the nodes, just the truss, so that your attached lander is magically free-floating but still attached. Yes, it looks stupid, don't worry, it'll be fine later. Then, you surface-attach engines to the bottom of the lander's tank inside the hollow decoupler, in such a way that they won't catch on the decoupler ring during stage separation.
    But what if you want engines that cannot surface attach? Well, that's what the BZ-52 Radial Attachment Point is for. You surface attach a pair of those to the bottom of the tank, which gives you extra nodes outside the main node stack to attach the engines to.
    Next, switch to the Move tool, select the decoupler, and move it down towards the fairing base until the engine bells are nice and close to it. Don't clip into it, that may not end well.
    Finally, build the interstage fairing. Once it is closed, you'll no longer be looking at a magically floating lander - it is now (at least visually) supported by the interstage. Set the fairing to Not Staged, and it'll remain a fixed structure that never gets ejected until you leave it behind when the lander decouples.
  8. Streetwind's post in CommNet range question was marked as the answer   
    Vessel antenna power = strongest antenna * ( sum of antennas / strongest antenna ) ^ Combinability
    Combinability is always 0.75, except for the starter antennas.
    So: 5,000,000 * ( 10,000,000 / 5,000,000 ) ^ 0.75 = 5,000,000 * ( 2 ) ^ 0.75 = 5,000,000 * 1.6818 = 8,409,000
    Maximum Range = SQRT(Vessel_1 power * Vessel_2 power)
    When the two vessels are identical, you're just taking the square root of a square, so the result is always the vessel's own power: 8,409,000
    The Mun's orbit is perfectly circular with a semimajor axis of 12,000,000 meters. Therefore, you are correct: these satellites will not be able to establish a connection. Even three HG-5 per satellite would fall just ever so slightly short. Four would work, but with terrible signal quality.
    Honestly, Mun/Minmus exploration without a DSN connection somewhere in the mix requires jumping through hoops until you unlock the 160-point node that contains the DTS-M1 and RA-2 antennas. It might be worth to just accept that your Mun rely satellites will only link back to Kerbin while the KSC is above the horizon from their view. This should not be a great problem for the science ground station, as it is perfectly capable of waiting for a valid comms link before transmitting its latest batch of science. And you'll still have a link for an entire half of each day anyway.
    Correct, no third party ever influences the connection between any two given antennas, except perhaps for a celestial body eclipsing one of them.
  9. Streetwind's post in Hello, I'm having trouble getting to a low Kerbol orbit, can anybody help? was marked as the answer   
    It sounds like rocket construction is an area in which you can improve further. You'd be surprised just how much proper construction matters. A launch vehicle of five hundred tons in mass should get you really, really far if you built it well. I bet I could get a direct Hohmann transfer to a low solar periapsis in less mass than that, no need for a bi-elliptic one.
    If you're encountering a case where adding more fuel to your rocket is no longer improving its dV, you are most likely adding that fuel to an already overloaded stage, thereby causing other stages to get choked by the added mass. The way rockets work is that everything you add on top affects everything that exists below. This may sound daunting - that's like, an unlimited number of variables to take into account!
    Good news though - it's much easier than it sounds. Because the way the math works out, there's only one single number that matters for each individual stage, and you can in fact eyeball it most of the time and it'll be fine, so long as you avoid going really far off track. Doing the math just helps you learn how to eyeball it. I've written about it here before. Apologies, it's kind of a wall of text. I have a regrettable tendency towards those. Trust me though, it'll be worth your time
    Note that this is very inefficient, due to something called the Oberth effect. It's a particularly arcane bit of orbital mechanics, and you had no way of knowing this beyond figuring it out through trial and error, so don't be hard on yourself over it This is what the forum is for.
    The way it works, in simplified terms, is that spending fuel is more efficient the deeper down you are in a gravity well. It's not exactly that, but that's what it boils down to in practice in KSP.
    What you have been doing is spending a small amount of fuel to get out of Kerbin's gravity well, then spending a lot of fuel to aim at your actual destination while you are not anywhere near a gravity well. Thus you spent more fuel than you needed to. What you should have been doing instead is spending all your fuel deep in Kerbin's gravity well - in other words, making the full transfer burn in low Kerbin orbit. Counterintuitively, the same amount of fuel - indeed, the same amount of dV - would give you a noticeably deeper Sun periapsis then.
    Or, well, you can follow Zheetan's suggestion and do a bi-elliptic transfer. But even then, you'd ideally do the full transfer burn to your high solar apoapsis directly from low Kerbin orbit. Escaping Kerbin before even plotting your transfer is always the least efficient method.
    But how do you get from this tiny circle around Kerbin to your destination in solar orbit? Well, imagine Kerbin wasn't there. Imagine if it was just your spacecraft in a solar orbit that happens to be identical to Kerbin's solar orbit. What would you do to lower your periapsis towards the sun? Burn retrograde to your solar orbit, of course. And if you wanted to get out to Eeloo? Burn prograde, of course.
    So that's what you do, except that you must do it while circling Kerbin. You are in a low orbit around the planet, but your goal is still to make a burn in the correct direction relative to Kerbin's solar orbit. For example, if you want to go closer to the sun, you want to make a burn on Kerbin's sunlit side, so you are ejected from Kerbin's SOI "backwards". In other words, you make a prograde burn (relative to your low Kerbin orbit) that ejects you retrograde (relative to Kerbin's solar orbit). And going out to Eeloo is the same, just on Kerbin's night side. You make a prograde burn (relative to your low Kerbin orbit) that ejects you prograde (relative to Kerbin's solar orbit). In this way, the burn to escape Kerbin's sphere of influence is at the same time a burn in the right direction relative to solar orbit, so you can just keep burning in the same direction to lower your solar periapsis (or raise your solar apoapsis) despite still being just a few kilometers above Kerbin's atmosphere.
    Of course, depending on the amount of dV you must spend and the acceleration your engines provide, making a very large burn in low Kerbin orbit can be very tricky. Because the orbit is so strongly curved, and you traverse a significant portion of the circle in just a few minutes, burns you make there grow less and less efficient the longer they get. If you burn at the maneuver node, you'll burn off-prograde for most of the time, whereas if you follow the prograde marker, you'll not burn in the right direction for most of the time. Rule of the thumb is that if your burn is longer than six minutes (three before the node and three after), you're starting to get inefficient.
    You can get around this by splitting the burn. For example, make one burn that raises your Kerbin apoapsis to around where the orbit of the Mun is. (Take care not to actually encounter the Mun, you don't want that here.) Loop around once, and as you come back towards your Kerbin periapsis, make a new maneuver node there and start a new burn in the same direction as the first one - basically continuing what you started.
    Once you have an escape trajectory out of Kerbin's SOI, you can keep burning until you have achieved your desired solar orbit destination.
  10. Streetwind's post in Refueling without docking was marked as the answer   
    The Advanced Grabbing Unit (also called "the klaw") is a part that can latch onto another ship and establish a docking connection without the need for a docking port on the target ship. Though, note, I'm not sure if certain difficulty settings might not interfere with fuel transfer across the klaw. Even in that case, though, you can still use the engines on the ship with the klaw to pull your Eve return craft's orbit down to intersect with the atmosphere. After that, it's just a question of aerobraking until you reenter.
  11. Streetwind's post in fireworks and transfer apps 1.12 was marked as the answer   
    The transfer app requires building upgrades. After all, you already need to upgrade a building to even make a maneuver node by hand. It would be silly to give you a tool that would make nodes for you even before that, right?
    The fireworks launchers are parts, and like all parts in career mode, are somewhere in the tech tree.
    If they are not in the tech tree, that would be a bug.
  12. Streetwind's post in how do i repair the big solar panels in 1.11? was marked as the answer   
    A Kerbal has only two inventory slots, yes. But some parts are stackable inside the same slot. That's why repair kits have this vertical bar once they are inside an inventory. It shows how many are stacked.
    So you probably only need one of the two inventory slots the Kerbal has to transport four repair kits. I don't know the stack limit off the top of my head, but it's likely larger than 3.
  13. Streetwind's post in Can a Terrier lift a 5.25 ton craft to orbit from Duna? was marked as the answer   
    Rather than tell you the answer, I'm going to tell you how to discover it yourself without even needing to go to Duna.
    In the editor, build the craft you hope to launch from Duna, or a sufficiently similar stand-in. Now, click on the stage that has the engine in it to expand its view. You should be able to see its TWR there. Finally, go to the dV app in the toolbar on the bottom right. Make sure it is set to sea level. In the dropdown menu at the top, select Duna.
    Your stage info will now show you Duna-relative TWR at Duna's sea level. If this number is greater than 1, you can launch with your current engine. If you then set the dV app to vacuum and refer to the Community dV Map for a typical cost to launch into low Duna orbit, you can check if you have enough dV as well.
  14. Streetwind's post in Matching Inclination While in Orbit was marked as the answer   
    TL;DR: It may feel like you're winging it, but as it turns out - it's largely the way things work. If you really want to skip making mid-course corrections, you can employ an external tool to precalculate a ballistic transfer for you.
    - - - - - - - - - - - -
    Eve's orbit is inclined compared to Kerbin's orbit. Eve's orbital period is different from Kerbin's. Even the eccentricity differs, although not by much. But, to put it in highly unscientific terms, these differences are not "the same", not "in sync". As in, If you fly transfers at various recurrences of the correct phase angle, then you will not always have the same transfer with the same plane change to do. Each time the planets line up in the correct angle, the alignment of orbital planes and parameters will be different. This means there is no magical solution to the way you should do your Kerbin departure burn that works in every case. You literally have to find a new unique solution each time.
    As far as matching inclination directly through your Kerbin departure burn Kerbin goes - the general rule of the thumb is "you cannot". There are special alignments where it is possible, but outside of them, it flat-out doesn't work. If you think about it for a moment, the reason becomes clear. Where do you normally do your mid-course corrections again? The ascending/descending node, I hear you say? Yes, that is the correct spot. At these points (or rather, along the axis that goes through both of these points and the parent body), the orbital planes intersect. So you can go from one to the other. If you are not where they intersect, you cannot go from one to the other. Any attempt to do so will invariably lead you to go into a different orbital plane instead (even if only slightly different). Try and imagine it in your head - two paper discs stuck on top of each other at an angle, intersecting along a line. And you can only travel along the rim of any given disc.
    This means that, in order to match inclination with Eve's orbit directly with your Kerbin departure burn, Kerbin itself needs to be at AN or DN with respect to Eve's orbit. Then, and only then, this maneuver works. You'll simply be folding your normal AN/DN course correction into your departure burn. Of course, since the difference in orbital periods, inclinations, and eccentricities are not "in sync", Kerbin won't do you the favor of being anywhere near the AN/DN on most phase angle matches. People still use the so-called "apoapsis transfer" to go to Moho, because a Hohmann transfer to Moho is the single most dV-expensive and precision-dependant transfer you can make in stock KSP, and most people would rather have a cheaper and less finnicky option even if it takes a few years longer to arrive. For Eve though, which is already one of the cheaper transfers to other planets, this seems unpractical.
    You can, however, still typically get a direct Eve encounter from Kerbin orbit anyways. The lack of sync just means that this will be fairly easy to do for some opportunities, and fairly hard for other opportunities.
    The next thing you need to understand is that, by being in Kerbin orbit, you are also in solar orbit, because Kerbin itself is in solar orbit. KSP does a bit poorly at representing this fact, due to the way you can only be in one sphere of influence at a time. But orbital mechanics won't let you cheat either way. Try launching a spacecraft into a perfect 90° polar Kerbin orbit. Now make a retrograde escape burn like you normally would when going to an inner planet like Eve. What's your inclination around the sun going to be like? 90° too? Hah, not even close. It's likely going to be less than 9°, even. The maximum solar inclination you can achieve by leaving Kerbin is the inclination of the upper (or lower) edge of Kerbin's spherical SoI with respect to Kerbin itself. 84,159,286 meters above Kerbin's own solar orbit. You cannot go any higher without a plane change in solar orbit. And most of the time, you will be far lower than that, even when leaving Kerbin from an inclined orbit.
    This means that, in order to attain even a few degrees of solar inclination through your Kerbin departure burn, you'll need a highly inclined departure orbit. And these things are... uncomfortable. For starters, doing plane changes in low Kerbin orbit is so expensive that you'd be spending far more dV trying to enter that inclined orbit after launching into an equatorial one than you would save by not making a course correction in solar orbit. No, in order to make this worth the effort, most of the time you'd have to launch directly into the inclined orbit. This also costs more dV than an equatorial launch, because you're not getting the full eastward rotation bonus; it's difficult to fly, since you need to actively steer rather than just letting the rocket fall over towards the east; and it's even more difficult to time it right. In contrast to an equatorial orbit, which has most of its orbital parameters nulled out and irrelevant, an inclined orbit needs to be inclined correctly. Not just the correct amount, but also the correct direction: the so-called longitude of ascending node (LAN). To get this one right, you have an instantaneous launch window - you need to launch at exactly the right time of day, when the launch site is directly under where you want your inclined orbit to be. You may or may not have some practice with this kind of launch window through exploring Minmus, where you can launch directly into a 6° Kerbin orbit in the moment where the launch site passes under Minmus' AN or DN with respect to the equator, and save yourself a plane change that way. But, in contrast to Minmus, here you have Kerbin's motion around the sun to consider. That means that for any given LAN value you select, the interplanetary transfer window is strictly speaking also an instantaneous window. If you wait too long past your opportunity, your laboriously achieved inclined departure orbit will slowly drift out of alignment with Eve's orbit.
    That, anyway, is the "perfect" solution. An instantaneous launch window leading directly into an inclined departure orbit for an instantaneous transfer window that's been precalculated to represent the total trip dV minimum for this particular, unique planetary alignment. And if you're now sitting back and going "that's way too complicated", then at least 95% of the playerbase will eagerly agree with you.
    Heck, even most third-party navigation tools agree, too Even Alexmoon's mighty Transfer Window Planner, which I absolutely recommend to each and every player, makes the default assumption that your departure orbit is perfectly equatorial and perfectly circular, because deviating from that assumption makes the calculation so much more complicated and the execution ingame so much more prone to imprecision. And it can still compute you ballistic (no course correction) transfer windows to Eve for every phase angle opportunity. You may ultimately be paying a few percent of extra dV to fly these... but considering how effortless it is to go around the stock system, that's honestly negligible.
  15. Streetwind's post in How to orientate RCS in orbit? was marked as the answer   
    In such a case, I like to press V repeatedly until the camera is in "locked" mode. You can then orient your view as you like it, and the camera will keep it fixed for you, so your orientation never changes. Perfect for translation maneuvers with RCS.
    I believe that, when you use docking mode, W/S is forward/backward, A/D is left/right, and Shift/Ctrl is up/down. Same controls as for Kerbals on EVA, basically. With the locked camera mode, you'll always know which way is up, so you always know which key you must press to go where you want.
  16. Streetwind's post in Matching Velocities undocked, possible in Kerbal? was marked as the answer   
    It is physically impossible, I'm afraid - in real life and in KSP both.
    What you're experiencing is called "microgravity". When you are side by side with another spacecraft, you are still not in the exact same position - your centers of mass are a few dozen meters or so apart. And that means that these two spacecraft are effectively in different orbits. The difference is extremely small, sure - but over time, orbital mechanics will pull the two spacecraft apart, or towards each other, or the like. A perfectly nulled out velocity difference will immediately start growing, however slowly, the moment you turn off your engines.
  17. Streetwind's post in Maneuver nodes innacurate was marked as the answer   
    Posting a video is always a great way to get help
    In this particular case, you are too close to the maneuver node by the time you start to throttle up. In other words, the maneuver node is too large for you to complete it at that moment in time. In yet other words, your engine does not have enough thrust. All of these are true.
    But as CBase already pointed out, these are not the underlying cause. The actual cause is that your ascent is much too steep. You spend too much effort into going up, and not enough effort into going sideways. As a result, by the time your apoapsis reaches your desired altitude, you need to catch up to all this going sideways business. But there is so much to catch up to, you'd have to bring a really big engine and accellerate really hard to make it in time.
    If you go sideways more during ascent, then the maneuver node you have to make to insert into orbit will be smaller. Additionally, it will also take you longer to push the apoapsis up to your desired altitude, which means you spend more time going sideways more, which yet again reduces the size of the final maneuver required. With practice, you will be able to get your final insertion maneuver down to less than 100 m/s.
    So, how do you know how much sideways is enough sideways? Experience, mostly. But, here's a handy rule of the thumb: by the time your rocket has turned halfway over (45 degrees towards the horizon), you want to be somewhere between 10km and 12km in altitude. Don't sweat it if you don't hit it exactly; it is a rule of the thumb, not a law of physics. The exact "perfect" trajectory varies from rocket to rocket anyway, based on its thrust-weight ratio (TWR). The rule of the thumb assumes a launchpad TWR of roughly 1.4 to 1.5, which is considerd a good practices value for many kinds of rocket. If your launch stage has more oomph than that, turn over harder, and pass that 45 degree angle at 10km or even below; if your rocket barely manages to struggle off the ground, turn less aggressively, and go to 15 km or maybe even more for your 45 degree milestone.
  18. Streetwind's post in Best way to power a large amount of ion drives? was marked as the answer   
    Try to figure out what the longest burn you must do in one go at max throttle is.
    For example, let's say you have a TWR of 0.1, and you wish to leave Kerbin on ion power. Your acceleration is roughly 1 m/s² (one tenth of Kerbin's gravity), and you need to expend 1000 m/s in order to escape. Once you have an escape trajectory, you can keep burning as long as you want, but until you have one you're still stuck in orbit, so escape is your effective limit. At this TWR it would take you 1000 seconds, or 16 minutes and 40 seconds, in order to escape. This is clearly impractical, because any burn larger than roughly 1/6th of your orbit is going to start making problems for you with imprecision. We'll assume that you are in a 36 minute orbit of Kerbin, so 1/6th of that orbit is 6 minutes. This will clearly be a periapsis kick sequence made of three burns. The first two burns will input 720 m/s, so there's no risk to encounter the Mun as you loop around for the final burn, so this is a good setup. You can fly with your spacecraft as it is.
    Going futher with this example, now answer the question: on this mission, do you ever expect to have to make a burn that is longer than six minutes? One that asks you to expend more than, mass loss included, let's say 400 m/s worth of dV in one go? You're going to Jool, so an aerobrake-assisted capture burn is an option, which might well let you get away with this amount. After all, as long as you get any capture at all, even a super eccentric one, you've safely arrived. Afterwards, you can either lower this orbit through successive aerobraking/further burns, or tweak your orbit at apoapsis to target Laythe and aerocapture there.
    The point of this thought exercise is this: once you have figured out your maximum expected burn length, you can design your spacecraft to the most mass-efficient specifications possible to supply full engine power for just that long and no more than that.
    For example: to generate 216 Ec/s with RTGs, you need 288 of them, and that weighs 23 tons. However, if you brought only enough RTGs for 66 Ec/s, you'd only need 88, and they'd only weigh 7 tons. Then, you need to provide 6 minutes of 150 Ec/s worth of battery storage, or in other words, 54,000 Ec. Since all batteries weight the same - 1 ton for 20,000 Ec - you can calculate that that will weigh 2.7 tons. Now your final mass for your power solution is 7 + 2.7 = 9.7 tons, instead of 23 tons for straight RTGs.
  19. Streetwind's post in Persistent Yaw during launch was marked as the answer   
    Your issue is likely in the fins on the side-mounted boosters. Your craft goes in the same general direction as this one - a short-ish, draggy center core that is stabilized by fins mounted on side boosters which start flexing around the radial decoupler joint as soon as aerodynamic forces come into play. Now, you do also have fins on the center core, which certainly helps, but the fins on the SRBs may still resist active steering and begin flexing that way.
    Check out my post in the linked thread for more detail, and a bullet-point list of recommendations that might help with rocket construction. They're not the only right way to do things, but they are a right way. Hopefully you can take something useful away from them
    (By the way: confirming that the CoM is ahead of the CoL does not help on rockets. You are not concerned about the center of lift, but rather about the center of aerodynamic pressure. That is different, and unfortunately, the game does not have a means of displaying it for you. So basically, you must work with the CoM marker alone, and try to move it upward as best as you can while estimating where your rocket creates drag.)
  20. Streetwind's post in position satellite in a specific orbit of the sun was marked as the answer   
    Pre-plotted orbits for contracts can only be seen for the parent body you have currently focused. For example, if you are focused on Kerbin (the default tracking station view), you can only see pre-plotted orbits in Kerbin's SOI. If you change your focus to the Sun, you will be able to see pre-plotted solar orbits.
    (When flying a vessel and being focused on that, it shows pre-plotted orbits inside the same SOI the vessel is currently in.)
  21. Streetwind's post in Trying to salvage Duna mission/go to orbit was marked as the answer   
    If you are plotting your maneuver node with a retrograde burn at periapsis, as you describe, that is the most efficient orbit insertion possible. I'm afraid you are simply coming in with that much of a difference in velocity that you must cancel out. This typically indicates that you have not flown a Hohmann transfer, but rather something else. Either you launched well out of the transfer window, or you plotted a high energy transfer (burning really hard when leaving Kerbin to make the trip as short as possible).
    You might however be able to at least salvage your mission to the point of being able to insert into orbit and later return to Kerbin. Because luckily, Duna has an atmosphere. That means you can aerobrake.
    Make a maneuver node just a few minutes ahead of where your ship is right now, and play with the radial and normal sliders to try and move your PE closer to Duna. The atmosphere ends at 50km, so you want it to be closer than that. Of course, depending on how sturdy your ship is, and how insanely fast you come screaming past Duna, your ship may be torn apart by shock heating. So, after you have executed your maneuver to push the periapsis into the atmosphere, press F5 to quicksave. Now timewarp to your arrival and observe what happens. If you get torn apart, go a little higher next try. If you feel like you have ample breathing room, try going deeper.
    You should probably align retrograde and fire your engines even while aerobraking. If you have to bleed off two km/s just to capture, a single aerobraking pass without engine support will not do it, especially if your craft is fragile.
    Your goal should be to capture into any form of orbit. Even if it is crazy elliptic with the apoapsis way out near the edge of the SOI. Additional aerobraking passes will let you bring that down without spending any fuel.
    Note that even a slight grazing of the atmosphere at these kinds of speeds is liable to rip off any extended antennas and non-fixed solar panels. If this would result in a loss of mission... well. You're kinda screwed. Your best bet in that scenario would be to not insert into orbit, but rather to burn at periapsis so that you end up in a solar orbit from which you can later get a Kerbin encounter, so at least you can return home.
  22. Streetwind's post in How to calculate dV for other planets? was marked as the answer   
    There is a very subtle mistake in there, which is not easy to spot for someone new to the world of physics.
    The notation is not just a "g" for "gravity". It is very specifically "g0", or written out, "standard gravity". That means this is not actually a variable where you put whatever gravity is for the place you are examining. No, it is a constant. Simply a number with a fixed value. It has the same value anywhere - the average value of the force of gravity at the surface of the planet Earth.
    You see, the so-called Tsiolkovski rocket equation originally read: dV = Ve * ln(m0/m1). Where "Ve" is "effective exhaust velocity" - describing the speed at which the jet exits the engine.
    Now, enter a bunch of rocket scientists. Some live in Europe, where they work in metric units. Some live in the US, where they use imperial units. They meet and want to compare notes. And suddenly, they notice that some of them measure this exhaust velocity in feet per second, and others measure it in meters per second. Confusion ensues. If only there was some way of measuring this that works out to be the same in both of these systems!
    So they decided to split off the offending component that has the non-uniform unit into a known, well-defined constant, leaving all the variables to have units that are identical in both metric and imperial systems. By dividing a speed (something per second) by an acceleration (something per second per second), only seconds are left as a unit. This is specific impulse. It is a measurement artificially created by math in order to unify two disparate unit systems that (thankfully) could both agree on the definition of a second.
    And the acceleration they chose to divide by? Standard gravity. Both sides knew this number. It is different in each measuring system. But if you have an effective exhaust velocity in imperial units, and you divide it by standard gravity in imperial units, you get specific impulse. If you have an effective exhaust velocity in metric units, and divide it by standard gravity in metric units, you again get specific impulse. Problem solved!
    Thus, Ve * ln(m0/m1) = Isp * g0 * ln(m0/m1).
    As KSP usually works in metric units, your go-to value for g0 is 9.80665 m/s².
  23. Streetwind's post in Help me understand why my design is unstable? was marked as the answer   
    You're violating the golden rule of rocketry: "heavy stuff at the front, draggy stuff at the back".
    Specifically, you have a high amount of parts and assorted greebling sticking out your upper stage. The blunt, uncapped docking port is an absolute no-go - put a nosecone on that, you can eject it once you leave the atmosphere. Additionally, there's that gap in the rocket where the stages connect. I cannot quite understand what is going on there, but depending on how it's set up, it's a major candidate for crippling drag.
    I see you have the center of lift marker activated. Unfortunately, this marker does not actually show the center of aerodynamic pressure that is relevant for rocket stability. The game does not feature a way to display this to you. You'll have to work with educated guesses based on the CoM location, and test flights to verify your guesses. In your case, those test flights tell you "nope, you guessed wrong".
    You can use a fuel flow trick to force the CoM a little further up in flight, by configuring the fuel tanks on your first stage so that they have decreasing priority from the bottom up. That is, if your fuel tank priority is, I dunno, 30 by default, then leave the bottom-most fuel tank at 30, set the one directly above that to 29, the next one to 28, and so on. This will make the bottom-most tanks drain first, leaving the others completely full. As a result, the average Center of Mass ends up higher than if all tanks were draining equally at the same time.
    This is however only a band-aid. It can make the difference between slightly unstable and barely stable. It will not fix an unflyable rocket on its own.
  24. Streetwind's post in Dark side of the mun communication and reverse navball indication was marked as the answer   
    Yes, it works like that. You can make such satellites, and they will bounce the signal back to Kerbin for you.
    There is two reasons you're only seeing direct connections to Kerbin right now. One, Kerbin's ground based antennas (the Deep Space Network, DSN, after the real life system of the same name) are several orders of magnitude more powerful than what you can carry on your spacecraft. Antennas automatically search for the most high-quality path home they can find. Because the DSN is so powerful, this highest quality path is almost always "just talk to Kerbin directly". Two, not all antennas can bounce a signal. There are two different kinds: so-called "direct" antennas, and so-called "relay" antennas. Direct antennas weigh and cost less, but cannot route other spacecraft's signals through them. Only relay antennas can.
    The first relay antenna you get is the HG-5. It is pretty weak, though. You'll want to put two or more of them on your relay satellites, and the landed vessels on the Mun will need a dedicated antenna of their own (not just the integrated transmitter in every pod or probe core). Alternatively, you could use the RA-2, which is plenty powerful for all your Mun relaying needs. But it takes more research to unlock it.
    More information: https://wiki.kerbalspaceprogram.com/wiki/CommNet
    Also correct. The orientation of your control point matters.
    That said, you might be able to right-click the probe core and set it to reverse control in the part action window. I'm not sure if that option is always available, or only if you have Advanced Tweakables toggled on.
  25. Streetwind's post in Basic Mun Flyby rocket design? was marked as the answer   
    Hmmm. I see. Alright then, here's some very basic rocketry tips:
    1.) Train your pilots. If you are playing with the Kerbal level-up experience system enabled (meaning, Kerbals are not five-star by default), then you want to send a few pilots into Kerbin orbit and back before you head anywhere else. Orbit around Kerbin is enough to get them to level 1, at which point they learn "SAS Hold Prograde". That means you can tell your Kerbal pilot to help you fly by trying to always keep the nose pointed in the direction of travel. You will find this invaluable while launching. There are also probe cores that have this ability, but unless you are playing sandbox mode, you have to put in some research effort to unlock them.
    2.) "The golden rule of rocketry": heavy stuff at the front, draggy stuff at the back. Think of an arrow. The compact, pointy metal head is right at the tip. The light feathers that catch a lot of air are at the back. In technical terms, the center of mass is ahead of the center of pressure. This causes passive stability. A well-built, passively stable rocket can fly to orbit without turning on SAS and without touching the steering keys - only via managing the throttle. Though admittedly, in practical application not many player-built ships will be quite that stable, because payloads tend to be light and fuel tends to be heavy, which makes it hard to achieve this perfect distribution. Rather than taking this rule too far, take its opposite, and keep it in your mind as what not to do. Do not put wings or fins on the nose of your rocket, for example. And when you find yourself with a rocket that will not fly straight no matter what, then think of this rule when trying to find the reason.
    3.) Single-size designs. A major source of instability is flexing joints, and few joints flex more than stepping down to a smaller part size in the middle of a stack and then stepping up again. This also causes drag, by the way, which (as we just learned) is bad if it happens towards the front of the rocket. As you progress in the game, you will gain parts (service bays, fairings, and engine plates) that allow you to shield smaller parts in the envelope of a larger one.
    4.) Single-stack designs. Another thing that wants to flex like Dwayne Johnson hopped up on caffeine is a small radial decoupler carrying a large side booster producing massive thrust. You can use struts to try and fortify such boosters, or you can turn on advanced tweakables and simply magick away joint flexing via rigid attachment and autostrutting (if you do not feel cheaty by doing so), but you can also simply not have the problem in the first place by building your rocket without large radially attached boosters. The main limitation you have here is the thrust output of the launch stage engine. However, it is still easily possible to reach orbit on a single-stack, 1.25m size rocket. It is also possible to perform a Mun flyby and return to Kerbin on a single-stack, 1.25m rocket. Though to pull that off, you may need to get some practice in the next item on this list.
    5.) Downsizing. Contrary to what you may think, bigger isn't always better. You will learn about this as you get deeper into the game (the keyword is "Delta-V"), but for now, what you need to understand is: how far a rocket can go does not directly scale with its size. The only thing that counts is the mass of the fuel you carry compared to the mass of "not-fuel" you carry. And no matter if your rocket is 10 meters in diameter or just 1 meter - if this ratio is the same, then both rockets will fly the same distance. So the takeaway should be: you must minimize everything that is "not-fuel". Take the fewest number of parts that are not fuel tanks as is possible. And if you have multiple parts that can fulfill a certain job you need done, pick the one that weighs the least - unless this causes other problems, such as having the wrong size. Besides helping with going further, this also helps with rocket building in general - if your rocket is light enough, you do not need extra boosters to make it move! And without extra boosters, you don't get flexing decoupler joints, which means your rocket won't go out of control on ascent...
    To illustrate my point, let me show you the rocket I used for my initial Mun flyby the last time I played Career (well, Science mode, actually):
    From the top down, that is: a MK-16 parachute, a MK1 command pod, a 1.25m service bay, a TD-12 decoupler, two SC-9001 "Sciene Jr." bays, a FL-T200 tank, a FL-T400 tank, a LV-909 "Terrier" engine, another decoupler, another four FL-T400 tanks, and finally a LV-T30 "Reliant" engine. Inside the service bay, there are two mystery goo containers, two thermometers, two barometers, and two Z-100 batteries.
    Super simple. No radial boosters. No size mismatches. No struts. No advanced tweakables shenanigans. The whole thing weighs just 15.4 tons and contains just 23 parts, 8 of which are science instruments. It can be built and launched in career mode without needing any building upgrades whatsoever, and no tech tree node more expensive than 45 science. It actually has a healthy surplus of fuel for the Mun flyby mission - you could technically slim it down a little more still, but then again, you can never go wrong with some safety margin.
    It is not 100% passively stable, but perhaps 99%. Adding four basic fins to the bottom will make it perfectly passively stable - a bit too stable for my tastes even, so stable that it becomes hard to make it turn in the lower atmosphere. Which is why I prefer it without fins.
  • Create New...