Jump to content


  • Posts

  • Joined

  • Last visited


999 Excellent


Recent Profile Visitors

5,379 profile views
  1. I believe that that will only work when the game considers it a single vessel, though, so you're not going to get away from needing to dock, in which case @NewtSoup has the general idea. Ground docking is usually a pain, because even if you took two identical copies of the same rover with docking ports on their noses, for example, putting them together on anything but perfectly flat terrain can cause issues because the docking ports may not be angled to meet correctly. There are some pre-robotics, stock solutions to the ground docking problem, up to and including making the refinery a landing pad and dropping the tanker onto it, but these tend to be cumbersome at best. That being said, you should be aware that quite a few people have reported problems with combining docking ports and robotic parts, so be wary. Anyway, there are some general tutorials out there for robotics parts, but I'm not entirely certain of how useful you will find them for your application. Regardless, here are a couple of them: Good luck!
  2. Certainly. The general calculations, or at least an example of them, can be found here. A more practically useful step-by-step demonstration for Duna, which you can (and should!) use to evaluate your Duna trip so you can get a feel for how it works, is here. Also note that the second link is a part of a series of KSP Let's Do The Math videos, and the next planet in that series is Moho, so you may find it especially useful. The equations used in the video all follow from the vis-viva equation, which is as follows: v2 = μ[(2 / r) - (1 / a)] Where: v = instantaneous velocity at that point of the orbit, μ = standard gravitational parameter for the primary body (it is Kerbin for the escape, the Sun for the transfer, and Duna for the capture), r = orbital radius at the point of the burn, and a = the semi-major axis of the orbit. Calculating these for your parking orbit and your transfer orbit, then subtracting to get the difference, will yield the burn delta-V. You'll need to do it multiple times, considering each leg of the trip, but that's all fairly straightforward--especially if you have a good grasp of algebra. The nuance is in selecting where and when to burn. I understand that to be part of the challenge, so I won't deprive you of a chance to figure it out for yourself.
  3. The Oberth effect is probably the easiest to calculate. You'll need the vis-viva equation and a decent working knowledge of algebra, but it obviously can be done: the ship flies, after all. Longitude of Ascending Node (which I assume is what you meant; how large the ascending node is is simply your inclination angle, but where it is is the longitude) is much more difficult to do. The problem is that in reality, LAN is defined based on a 'fixed' (that's only relatively, locally, and temporarily true, but it works for navigation for now because of the scales involved) point in space, and the only 'fixed' points in space are the stars. KSP, on the other hand, doesn't have stars. It has a pretty skybox, of course, but that skybox is essentially painted on the face of the universe for aesthetics and without any consideration for navigation. In other words, it has no fixed orientation, which means that you cannot take repeatable, reliable bearings from stars. That said, there may still be ways to help you: I find it difficult to believe that there would be an impossible challenge on the Discord without someone else figuring that out and announcing it. What is the challenge?
  4. @Just Jim: My apologies for arriving so late to the article, but I wanted to express my appreciation: you've largely become the epitome of 'local boy makes good' for the forum, and to see how much you've been able to chase the dream is very gratifying for someone who's been a fan since Chapter 1 of Emiko Station (considering that it's been nearly seven years, now,--wow!). I have two thoughts: first, considering how unique KSP is, I'll say that if, after you've finished, KSP is only half as unique, then you've done the best job possible. It looks like that's what you're trying to do, and it also looks like you're succeeding. Not to diminish the contributions of your teammates (far from it--they sound like great colleagues), but I know that there has been concern in the past about whether KSP2 was going to be a, for lack of a better term, 'spiritual successor' to KSP instead of merely a sequential one. It is beyond satisfying to see someone whom we already know 'gets' KSP doing so much to curate the tone of the sequel. Second, are you certain that you want to go with Advanced Photonic Generation System? Electromagnetic Radiation Generator System abbreviates to a much better pun. On a side note (and much more seriously), I hope you've managed to dodge the storms without too much trouble. Stay safe, good luck, and thank you.
  5. That's because orbital period defines the resonance implicitly. Resonance occurs when the two orbital periods are in a ratio that can be reduced to low integer terms, such as 1/2, 2/3, 5/4, and so on. For satellite networks, you generally want 1/1 because that keeps the spacing, and manoeuvres for that are more a matter of relative positioning rather than resonance. The reason that specific values for the apsides don't matter is because orbital period, in turn, is dependent on the semi-major axis, and only on the semi-major axis. The eccentricity doesn't matter; only the semi-major axis does. That said, for a comm system, having the satellites in high-eccentricity orbits will change their relative positioning on a cycle even though the average is constant. This can be a feature rather than a bug: satellites in Molniya orbits exploit this in combination with inclination to spend a long time above the northern hemisphere in resonance with the Earth's rotation, thus repeatably giving better satellite coverage to certain longitudes in the northern hemisphere. There are other important features of Molniya orbits, as well, but the point is that the resonance works because of the semi-major axis and its relationship to orbital period, not because of any other factor, which means that there's a lot of room to modify those other factors and thus many potential applications for different types of resonant orbit.
  6. 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.
  7. 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.
  8. @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.
  9. 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.
  10. 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.
  11. 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.
  12. @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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...