Jump to content

Zhetaan

Members
  • Posts

    1,018
  • Joined

  • Last visited

Everything posted by Zhetaan

  1. The only way I know to do what you want without mods is to use what I will call the contract slot machine. Normally, there's a penalty for declining contracts, but you can turn that off in the settings (it's one reputation point per decline, so it may or may not be worth it for you). Then, start declining contracts. Mission Control will generate new ones, and you can keep declining contracts until you get one that you want. However, there are two points of caution: Some contracts are locked until you do certain things in the game, whether it be visiting a celestial body or something else. If a contract is locked behind a milestone, then no amount of random number generator abuse will get the contract that you want. There's a weighting system in place for contracts. If you decline a contract, then the system takes that as evidence that you won't want that type of contract in the future. If it's a contract type that you don't ever want to do, then that's fine, but if it's a contract that you'd like, but not right now, then it may be a problem for you to decline contracts of that type too many times, because it means that you won't see that contract type when you decide that you do want it. If, however, mods are something that you might like, then I suggest that you give Contract Configurator and its associated contract packs a try. It will let you choose the contracts that you like from a list of available types. It won't necessarily have every contract possible (random numbers and player progression are still part of the game here), but it will show you contracts of the various types available as well as the requirements needed to unlock other types of contract.
  2. Docking mode does change the controls. If you're having this problem, then it is possible that you have a keybinding issue or a conflict of some sort in your settings. However, it seems more likely to me that you have a CommNet problem. Are you playing with comms, as well? You might be having a problem where your radio signal (or lack thereof, actually) is only letting you have 'limited control', in which case it's not a docking mode issue at all. Does the vessel respond to rotation input when you turn SAS off? It may help to know that in normal flight mode, WASD provides rotational control (technically, it's WASDQE, because roll is a thing in three dimensions), and IJKL provides translational control (technically again, it's IJKLHN for a similar reason). The nice thing about that is that it allows you to have simultaneous control of rotational and translational motion, and also doesn't train you to press the shift key for anything other than engine throttle.
  3. @Hamfisted: Here's the key to making it work: The Sentinel telescope works by scanning on behalf of the next planet farther out. This means that to scan for asteroids for Kerbin, it needs to be between Kerbin and Eve. If your telescope was saying that it was tracking objects near Duna, then its orbit was too high: it was between Kerbin and Duna, not Kerbin and Eve. How does it know which planet is the next farther out? There's no single orbital altitude when an orbit is eccentric (and don't forget that Eeloo is actually closer to the Sun than Jool for a portion of its orbit). However, it can compare semi-major axes. The telescope knows the semi-major axis of its own orbit, and it knows the semi-major axes of the planets' orbits, and so it tracks objects 'near' the body with the next larger semi-major axis than its own orbit. Thus, what happened with you is that when you burned to bring your telescope's orbit down, you reduced its semi-major axis to a value just below Kerbin's, and so the telescope began tracking objects for Kerbin rather than Duna. On the other hand, this: ... is not the answer. There's no list of discoverable asteroids; the game generates them at random. You cannot 'fish out' the asteroids from one orbit in the same way that the stock science sensors (thermometer etc.) can only extract a specific number of science points for a given experiment in a given biome. So long as one leaves the telescope in the right orbit and tracking objects, it should continue to do so indefinitely. Considering that it's been three and a half years, I certainly hope that that was enough time.
  4. The Oberth effect does have, well, an effect, at least in part, but the relationship is less obvious because one tends to see the result through the lens of gravitational effects without intuitively recognising the fact that the orbital speed at the periapsis of the 200 x 10,000 orbit is necessarily greater than that at the periapsis of the 200 x 300 orbit. Instead, one tends to look at it in terms of orbital energy getting closer and closer to escape, but since higher initial velocities are unavoidably part of that, and the Oberth effect is the resultant change of orbital energy that is dependent upon (and attributable to) the initial velocity, the Oberth effect is unavoidably part of that, as well. To the maths! (In the spoiler; I'm not a sadist.) I hope that helps a bit.
  5. That's because it's technically a gravity assist, as well. You're moving at high orbital speed with respect to your primary (in this case, Earth), so you get the benefit of the Oberth effect, but you're also using that effect to direct your velocity retrograde against Earth's solar orbit, which is to say, it's a deceleration with respect to the sun. Many people think of only unpowered gravity assists when confronted with the term gravity assist. Powered assists also exist. The end result is that the difference (with caveats, of course) between going to Mars and going to Venus, most everything else being equal, lies in which side of Earth you're on when you start your burn. However, that looks very similar to what I will call the second half of unpowered assists, where the difference between an acceleration or deceleration is which side of the planet's sphere of influence you exit.
  6. That's not quite it. The transfer isn't impossible; it's just extremely inefficient to use a one-burn transfer when you're on that sliver. Part of the issue is that there's no single solution to the problem of how to get from your origin to your destination. There are literally infinite paths to take. The porkchop plot exists as a tool to help you choose from a group of solutions that offer some value or benefit over other possible choices, but it's important to remember that choices in that range are all trade-offs of one another. One set of solutions covers fast transfers, which take less time in transit. Another might cover immediate transfers, which let you leave right away. Another set covers efficient transfers in terms of delta-V expended. There are valid use cases for all of these: a fast transfer may be the best option when you have a life support mod to consider. An immediate transfer may be needed for a rescue mission. An efficient transfer is good for when you have limited delta-V or want to save it for some other part of the mission. However, when setting up the plot, there are still a few assumptions that the planner has to make. One of them is whether you want a ballistic transfer (that is, one burn at the beginning that gets the encounter), but sometimes that's not the best one in terms of your delta-V budget. Sometimes, a mid-course correction is cheaper, for the same reason that sometimes, it makes more sense to raise your apoapsis before making a drastic inclination change. Let me try to illustrate the problem a little better. I don't have a good Paint drawing, so I'll just have to be descriptive. When you're transferring to another planet, you have to account for the fact that you're already in motion, co-orbiting with the planet about the star. Generally speaking, efficient transfers are those that take advantage of your existing motion, because if you can use existing motion to your advantage, then you can subtract the cost of that existing motion, since you start with it and don't need to expend propellant to get it. This the exact same idea as to why it's more efficient to launch to the east; the planet is already rotating that way, so you can use it for free delta-V. However, if you want to go to the north pole, then launching east won't help you because your destination isn't in that direction. Similarly, if your destination planet is outside of your origin's orbital plane, then transferring within the origin's plane won't get you to your destination, because your pre-existing direction of travel doesn't go there. You can choose to transfer when you're at the ascending or descending node relative to the destination, but you might wait a century for a transfer window that aligns with the node--if there ever is one. You can go at the right window while staying in your orbital plane, but when you reach the destination's orbital distance at the correct time, you'll find that the destination planet is somewhere to your celestial north or south (i.e., 'above' or 'below' you relative to your plane, for whatever value those words have in space). In order to actually intercept your destination planet in a good transfer window, you'll need to leave your orbital plane. Generally, the best place to do that is as far from the line of nodes as you can get on that leg of the orbit--i.e., the mid-course correction--but if we've already established that this is a ballistic, or single-burn transfer, then that's not an option. The only burn that you can use to make the encounter is the initial interplanetary ejection burn. In most cases, you can add a bit of inclination (and possibly a bit of radial, too) to get a satisfactory encounter, but in extreme cases, the only solution to encounter a planet that will be a few billion kilometres to your origin plane's celestial north when you get there is one that arrives from the celestial north itself. This doesn't necessarily mean a totally polar orbit, but a burn that has you ejecting at 30° inclination when you don't need to do so is going to be inefficient no matter how you arrange it. Well, you can, to begin. If you want the very best in terms of efficiency, then I'd suggest using a transfer calculator (e.g. the Alex Moon planner or the mod that incorporates it into the game) and using the information from it to set up the burn. But that's not strictly necessary; you can get very good corrections on your own. The best place for a mid-course correction is a point 90° of true anomaly away from your encounter with the destination--or, rather, I should say from the point where you would like to encounter your destination, since you won't encounter it without the correction. I should also point out that the ballistic transfer is sometimes the better choice. MechJeb's advanced transfer calculator is very good. It automatically offers the best available ballistic choice, and that is usually negligibly different from the one with a course correction. Let's not forget that that sliver of inefficiency doesn't matter much unless the transfer that you want falls on it. If--if--it does, then sometimes, you're close enough in inclination that a mid-course correction is more expensive than simply working with the inclination difference ... or, of course, picking a different transfer. The option that works best also depends a lot on your mission: even when the delta-V difference is slight, different trajectory choices will affect your orbital insertion when you arrive at your destination, and possibly cost you more in terms of local manoeuvres if you're looking for a specific inclination on arrival. An example of where this is relevant would be when you're transferring to Jool: arriving in an inclined orbit over Jool in itself doesn't mean much, but if you want to visit the moons, then you'll probably want to arrive with an inclination close to matching theirs. Of course, changing your arrival characteristics so that you get favourable encounters requires a mid-course correction anyway, so you may be stuck with that. If you want to try your hand at figuring this for yourself, then I strongly recommend perusing Rocket and Space Technology and getting a feel for some of the mathematical relationships involved here. The link will send you partway down the page; there's a subsection titled Non-coplanar Trajectories that touches on some of your questions. Also, it has diagrams! Good luck, and should you have any further questions, please don't hesitate to ask.
  7. @Lt_Duckweed has the right idea. I will offer one correction and say that the best place to make the mid-course correction is not at the node, since the node being in the wrong place is the root of the problem, but I'll get to that. If you take a look at the Alex Moon launch planner, just using the default Kerbin-Duna ballistic transfer, you'll see a sliver of inefficiency cutting across the plot. Switch the transfer type to 'Mid-Course Plane Change', and you'll see that the inefficiency goes away. When two orbits are not coplanar (which is the case for most orbits, even in KSP), then the mathematical solution for their intersection is a line, called the line of nodes, that joins the ascending and descending nodes. If you depart your origin at that node, then you can move efficiently in your original orbital plane and encounter your target, because when you reach it, the target will also be in your original orbital plane; you'll end up in an inclined orbit about the target, but you'll at least encounter it. If you depart from somewhere that isn't the node, then you need an orbital solution that will intercept the target. For intercepts that are relatively close to the nodes, you can get the encounter with only a slight amount of inclination, but anything that is more than a few degrees of true anomaly away will require a transfer that is a polar orbit of the sun--at least if you want to get the encounter with a single transfer burn. Adding a mid-course correction provides a much cheaper solution, because the midpoint of the transfer is an efficient point to change your node relative to the target. The cheapest place to change the node is as far away from the node as possible. For a (nearly) Hohmann transfer, that's at only one point (since you generally only use half of the Hohmann orbit), so the solution isn't difficult to calculate. However, some porkchop plotters don't bother with that solution because, for one thing, the solution that doesn't involve mid-course corrections is usually going to be cheaper anyway, and for another, if you're advanced enough in KSP to use a porkchop plot, then you're probably advanced enough to know about mid-course corrections, too. If you want to see more evidence of this effect, then you can play with the Alex Moon planner and try transfers between destinations with high relative inclinations, such as Kerbin-Eeloo and Kerbin-Dres (or, for an extreme and dramatic example of this, try Dres-Eeloo). Look at the ballistic (single-burn) transfer, and then re-plot using the same general settings but with a mid-course correction.
  8. I don't know about faster, but whenever I do any kind of complex orbital assembly, I use a tug, which is basically a flying RCS tank with a docking port (or two; I tend to use Sr. and standard Clamp-O-Trons and build tugs to suit) and probe core for control (and obviously all of the electrical and communication support that it would need). For your application, you might consider fine control mode for your RCS. You get that by hitting caps lock and can tell that you are in fine control mode when the pitch, yaw, and roll indicator arrows (on the lower left of the screen) turn blue instead of orange. Fine control is slower, but it has the advantage of using compensated thrust, which is to say that it will adjust each attitude jet for you to try to push the thrust vector through the centre of mass.
  9. It can grip it by the husk! Anyway, I'm glad that worked out for you. The orientation of the Sr. docking port (and correcting it if it's put on backwards) has been a point of contention since ... it was introduced, actually. For all I know, it's one of the reasons KAS was developed. It's nice to see that stock in-flight assembly has offered a way to deal with that.
  10. You should probably look into those gravity assists. Without seeing more of your mission profile, I can't say anything definite, but my main suggestions are to check to see whether your encounter inclination at Moho is too high, and to see where you're meeting Moho on its orbit. The best way to Moho after a gravity assist is to try for one that encounters it at its periapsis, not apoapsis. Encountering it at the periapsis makes your orbital ellipse more similar to Moho's, which cuts the cost for capture.
  11. If I understand your question properly, then no: you need to store it, dock, and transfer it directly. Science transmissions in KSP only go to Kerbin for processing. Data processing in a science lab entails taking the experiment data (not necessarily the experiment part) to the lab; once the lab is finished with it, then you can transmit it--again, only to Kerbin.
  12. No go. Return to orbit, do whatever you need to return to Kerbin, and come back to the Mun with a better-equipped vessel with a design informed by the lessons learned from this attempt. I've never tried not returning a tourist, so I can't say for certain that the game requires it, but you shouldn't risk it anyway. Tourists cannot EVA, so any rescue mission needs to involve docking, whether be it for propellant or passenger transfer. That's much easier to do in orbit. Or, I suppose, you could make a vessel with a big cup on the nose and use that to return your Mun non-lander to Kerbin. Good luck flying that, though.
  13. I tend to go in the other direction and make it harder. The finance system and the science system don't really interact in the stock game, and while reputation does influence both, I have never felt the need to pay special attention to it. Of course, that's just a way of restating your point--if the science and finance systems were interdependent, then you wouldn't be able to cheat one out of existence and still have a meaningfully playable game. My general goal is to try to force the science and finance systems to interact more, mainly by making science points tremendously more expensive so that I have to spend more money to acquire them (and even more to use them--I have the game set to require Funds to unlock the tech in the various nodes). I mod a few things, such as the big ISRU converter, to work less efficiently (no self-powered LFO plants for me), or to die off, such as the RTGs which I mod to decay. I use an extended tech tree that costs more to unlock, and also spreads out the technology so that each node unlocks less. I also turn down the science rewards to the point that there isn't enough science in the solar system for me to unlock the entire tree without labs, asteroids, and contracts that award science outside of the fixed-value experiments on and around celestial bodies. I make labs a good deal less efficient, but I also massively increase their data storage because the alternative is needing to revisit them every five minutes to top them off--I prefer to macromanage those sorts of things, not micromanage. This approach generally forces a careful build-out, but it puts me in a position where I need to pick and choose what I am going to develop for missions farther afield. The contract system, then, helps to guide and direct those missions--whether I go towards Moho or Eeloo is often determined by the contracts generator--rather than serve as a way to make some quick money to use in the thing that I really wanted to do all along. The research choices are then informed by the contract destinations: I can invest in power technology so that I can charge a battery out near Eeloo, but at the cost of being able to invest in more powerful engines, for example. Or I can go the other way and use the basic solar panels at Moho, but not unless I have good enough engines and propellant tanks that I can actually stop there after I arrive. I do make a couple of things 'easier': I set the temperature and pressure sensors (and any other sensor that only generates a number without handling a material) to fully return transmitted science, because why would it somehow be better to recover the sensor that reads '173K' rather than just transmit the value? However, to balance this, I also generally make it so that it takes multiple experiments to fully extract the available science points. In other words, I'm not going to land in the Badlands, take out a thermometer, and assume that that is the Universal Badlands Temperature. I'm going to take several measurements, which means either staying a while or making multiple trips. There are exceptions: I don't need to take multiple pressure measurements in high orbit, for example. The overall idea is to make the science, research, and development sides have a little more to do with one another, and thus make the game a little more realistic without needing to go to the same extent as Realism Overhaul. Then I can return the science that I gather and maybe unlock something that will ease the second trip. If this all seems very tedious to you, well, that's probably because it is. But it works for me. I will say that I try to balance it so that I unlock everything before I've gone everywhere (that's where contracts and labs come into play) because it doesn't make sense to unlock that big, fancy engine only after you've proven that you don't need it and can do just as well with something inferior. But I've never liked the idea of being able to unlock the whole tech tree before getting beyond Minmus, either.
  14. You can boost, though, right? If that's the case then it's a matter of one of two most likely causes: pilot error and rocket design. Pilot error is the easiest thing to correct, but it assumes that you are completely new to KSP and need help learning to fly. That's not a bad thing (we were all new at this once), but if you can get a rocket into orbit and fly to the Mun, then it suggests that rocket design is the most likely issue. Just the same, if you are completely new and need help learning to fly, then some basic instructions are in the spoiler. On the other hand, let me ask: are you simulating an Apollo-style mission? Do you have a separable lander of any configuration? Your problem may be that, assuming that they are docked nose-to-nose, your upside-down vessel is the control point for the whole assembly, and every time you orient retrograde to burn for capture, you're actually burning prograde to escape. If that's the case, then right-click on the pod correctly oriented, select 'Control from Here', and try again. Don't forget to tell us whether that worked (and if not, then please provide a screenshot of your rocket, preferably in flight, so we can try to diagnose the problem). Good luck!
  15. I see a whole-vessel delta-V of nearly 7,000 m/s and a thrust-to-weight ratio of 2.3. You're fine. Actually, at this point, I'll caution you that that is a very energetic lifter and you may find that, after launch, you have a hard time turning it in atmosphere without ripping pieces off if you're too aggressive with your pitch control. If that happens, then the solution is to use the thrust limiters on the SRBs. You should be able to turn down the thrust to, oh, 67% or so. That will drop your launchpad thrust-to-weight to a respectable 1.5-ish which will keep your rocket flying upward but with less unplanned disassembly. The other issue that might become a problem is staging away the SRBs when they burn out. They can have a tendency to strike your core after you detach them. I usually prefer pairs over quads for this reason, but don't be afraid to use Sepratrons if you need them.
  16. In Kerbin orbit? That will take you to Minmus and back several times. On the launchpad? Add a launch booster to get it into orbit.
  17. It's also possible to get back to Kerbin for under 1,000 m/s, provided that you go from Dres to Jool. There are flyby trajectories that have you using Jool for a braking gravity assist to drop you into the inner system for a Kerbin encounter; the best flybys that I've found so far can do it for between 950 and 980 m/s. These are obviously very time-dependent (transfers that coordinate three moving bodies--not including your vessel--are an order of magnitude more complex to plan than two-body transfers) but the window does reopen every few thousand days.
  18. Technically, that would be an asymptotic function, not an exponential. Anyway, according to this post, it's probably an algorithm, which is to say that the results change based on arbitrary rules that don't necessarily relate well to a mathematically-precise continuous function. I'm interested in finding out a bit more about it myself, so I think that I'll look into it a bit more deeply. I won't have much time to do so until the weekend, though, so don't expect an answer from me for at least two days.
  19. 200.25, in point of fact. @Nicias: Since you are a dedicated mathochist, at the least you'll need to get to eccentric anomaly so that you can figure your time-of-flight and ensure that you'll intersect Vall's orbit at a time that Vall is actually there. Which means that you'll need true anomaly, and well, it becomes an avalanche at that point. Do you use Kerbal Engineer? You'll need a way to get the true anomaly, which you cannot do with celestial observation in KSP (the skybox is just painted on; there's no First Point of Aries, and if there were, it wouldn't stay in the same place). Alternatively, if you're feeling extra insane, you can simply define a coordinate system and solve for it there. So long as you have the relative positions of your vessel, Vall, and their orbits correct, then you can solve for the burn in any convenient system without needing to use mod tools.
  20. I'll second @Streetwind's post, at least for planes. However, nothing in your post says specifically that you're flying a plane; just that you're flying in an atmosphere. Nevertheless, the logic holds. The only really good reason to take a tank full of LFO is if you intend to use it, and if you're using closed-cycle Rapiers when you have Nervs available ... well, why would you do that? Pushing through the upper atmosphere might be a good reason, but you don't need a big rocket tank of LFO for that. Depending on how much oxidiser you need, you may be best-positioned to use a Mark 3 liquid fuel fuselage with a Mk3 to 2.5m Adapter. It still has a lot of LFO--likely more than you'll want--but you'd need the adapter anyway for the cleaner look. Of course, you can always try a mod; there are plenty of rocket-profile LF tanks out there, since people correctly saw that it made no sense for the Nerv to be a fantastically-efficient LF-only space engine and not have any good rocket-profile LF-only tanks to go with it. Some of these are just fuel-switching mods that will make a stock LFO tank into an LF-only tank without the need to add extra parts. It's worth a look: without mod tanks, the result is often that you either get a Mark 3 fuselage assembly that adapts down to 1.25m for the Nervs (and the adapters almost all have LFO, so watch out), or else you get clusters of Mark 1 fuselages because they have the same 1.25m profile as the mid-diameter rocket parts (small in KSP would be the .625m parts, like the Oscar-B). In fairness to the developers, the Nerv originally was an LFO engine like the other rocket engines (it wasn't realistic in its function; it just had great efficiency), so when it was introduced, there was no need for new tanks. They corrected that later, but never added new tanks to go with it.
  21. Hmm. Well, it doesn't seem right that it would reference field work (as opposed to contracts) and then not convert field work. Perhaps 'field work' refers to things such as part tests and experimental surveys--these are things that generate science because of the contract, but are not counted as part of the science reward for completing the contract. To put it another way, if you have, for example, a contract to test some part on the pad, then the test itself will often generate science over and above the listed contract reward. I must offer my apologies because I did not test this myself. I'll take a closer look later today and report on what I find; I have a test install of KSP that I can use for this. In your mission summaries (these would be both the report after you recover a vessel, and the contract completion report that you access from the toolbar) does it show a number in parentheses next to the science total? That would document the effect of your strategy. I ask because it may be that the devs decided to leave actual experiments available as a source of science points if you needed them (this would be from before they made the changes to the mobile lab, mind), though it boggles the mind that they would not have been thinking of these experiments as field work. I'll look at the cfg files as well when I run the test rig. There are couple of other possibilities to consider, as well. How high is your reputation? One important difference between science and rep is that science is a running total that cannot go below zero, whereas reputation asymptotically approaches the endpoints on its -1000 to 1000 scale. If your reputation is sufficiently high, then you cannot gain more. (The same is true in the other direction: the general public becomes inured to your indiscriminate and reckless disregard for property and the lives of your Kerbals, and your reputation cannot go below -1000, either.) In other words, the more reputation you have, the harder it is to get even more. I think that the game would take the many disparate sources of science, add them up, and only then convert the total into reputation points, but if it does each conversion individually, you might be gaining thousandths of a point and thus seeing no practical change. What this means for your strategy is that if you already have a high reputation, converting science points into more rep may just be a way to get rid of excess science points. and nothing else. Another alternative is to ask whether you committed 100% to the strategy? You mentioned unlocking the entire tech tree, so I assumed that you also had a level 3 Administration Building, which you need for 100% commitment. I'll have an answer within twelve hours, I hope. Edit: Did it in eight! Anyway, the strategy configuration file is very clear: 'field work' consists of ScienceTransmission, VesselRecovery, and Progression. ScienceTransmission is straightforward. VesselRecovery covers, I think, both experiments recovered with the vessel and the vessel itself (for those times that you bring back the first vessel to fly by, orbit, or land on a body). Progression is the internal name for World's Firsts rewards. I also ran a short career save with the strategy turned up to 100% and with a number of experiments in different situations. The vessel recovery window showed the science value of each experiment, but the bottom of the window showed zero science gain. The notification window (the one with the green checkmarks for completed contracts and blue globes for World's Firsts--it's the first button on the toolbar) showed the correct subtractions of science and additions of reputation as I expected, and my actual science total did not change after the mission. Perhaps that was the problem?
  22. It just means science points from doing actual experiments, as opposed to the science points that you may receive from completing contracts.
  23. In that case, this is pretty much the definitive post on the subject. It's also the case that you'll be looking for something more nuanced than just passing in front of or behind celestial bodies, because the main trick to those multiple-assist trajectories is getting the timing right for the intermediate legs. For example, there's a multiple assist to get to Moho by way of Eve: you can get to Moho by way of Eve but the problem is that Eve cannot, on its own, slow you down enough on an infalling trajectory from Kerbin to both get you to Moho in one pass and save enough propellant to be more worthwhile than just flying there directly. So the way to do it is a K-E-E-M assist. For that middle leg from Eve to Eve again, the exact flyby orientation is less important than the timing of the interval, which needs to be exactly 65.5 days (one Eve year) or else you'll miss the Moho encounter (or make it very expensive, at least). But that means that you need to take the assist that will give you that interval, not the one that reduces your solar speed the most. It's not so bad as it sounds, because the assist that gives you the right interval will put you in the right place for the next assist, which is the point. But it means that you're not looking for the maximum possible effect on the flyby, either. That's okay, since multiple assists are really just chained transfer windows, and transfer windows are mainly about timing. Your mission may be about propellant efficiency and delta-V budgets, but the windows don't care one bit about that because the planets move and align regardless. Unlike, for example, a Tylo gravity brake to get into Jool orbit, where it's ideal to approach Tylo from directly behind (if possible), swing round at nearly ground level (if possible), and exit exactly in Tylo's retrograde (more or less required), you may find yourself exiting (or approaching) the intermediate celestial bodies at a weird angle, because that's the angle that gives you the right timing for the next encounter. Do not neglect your course correction budget, and remember that when you correct for an upcoming encounter, you should really be looking at the encounter after that. Well, maybe glance back to ensure that you're not getting that 'encounter' via a collision course with Kerbin or something. Otherwise, this encounter should be all about setting up the next encounter. Do that and you'll be fine.
  24. If you mean passing in front and passing behind, then ... roughly, yes. It would be more accurate to say that your exit speed relates to how close your exit direction is to the celestial body's prograde direction. If they are roughly parallel, then you speed up in the primary sphere of influence. If they are anti-parallel (meaning that you're aligned with the body's retrograde), then you slow down. B and D show the craft leaving the body in something like the body's own prograde direction (it isn't exactly parallel, but it's obviously more prograde than retrograde), so the craft speeds up. A and C show the craft leaving roughly retrograde, so it slows down. There's a whole list of caveats and addenda to that, mostly relating to your speed, angle of approach, and periapsis (and a lot of it deals with the fact that, being in three-dimensional space, you can do other things like change inclination with a gravity assist).
  25. Apsis is borrowed from ancient Greek. 'Apses' is an attempt to use a Latin pluralisation on a Greek root, which is not correct. The correct plural is apsides. Wall of explanatory text in the spoiler: In the end, though, languages--even dead ones--change over time, so eventually, apses is probably going to be accepted as a legitimate plural of apsis. However, if you do decide to use the correct Greek form, then please be aware that the pronunciation is ap-si-DEES, not ap-SIDES. It rhymes with keys or freeze, not rides or hides. In theory, they can be anywhere. Of course, an escaping comet or asteroid has no apoapsis because it is not on an elliptical orbit, but escape is not a function of position; it's a function of speed. There is no magic line where an object on one side is captured and an object on the other side is escaping. You see this on any interplanetary launch from low Kerbin orbit: with enough speed, you escape Kerbin from a, for example, 100 km orbit and go to Duna. Burn in the retrograde direction and your orbital speed drops to zero and you land (or 'land', in the sense that the char and ash will eventually hit the ground). Do nothing and you orbit until the hard drive fries. It has nothing to do with being in low Kerbin orbit: all three scenarios are possible. Another way to look at it is in terms of eccentricity. An elliptical orbit has an eccentricity strictly less than 1, but the problem is that the formula for eccentricity is this: e = √(1 - [b2 / a2]) Where e is the eccentricity, a is the semi-major axis, and b is the semi-minor axis. The problem with this is that eccentricities less than one are achievable for arbitrary values of a and b, because a can tend to infinity and b can tend to zero while keeping the b2 / a2 term nonzero. A parabola, which has an eccentricity of exactly one, can be seen as an orbit where a is exactly infinite. A radial orbit, which while not a parabola also has an eccentricity of one, is the case where b is exactly zero. Practically, comets are going to have some nonzero speed which will constrain the possibilities for apoapsis if they have an elliptical orbit, but I don't know the range of those possibilities.
×
×
  • Create New...