Zhetaan

Members
  • Content Count

    786
  • Joined

  • Last visited

Community Reputation

764 Excellent

2 Followers

About Zhetaan

  • Rank
    Rocket Scientist

Recent Profile Visitors

3,878 profile views
  1. Welcome to the game, @wobartoz! I can certainly help you with reproducing the calculations, so that is what I will do. This is the original post: Let's take this in steps. Also note that I will use American notation conventions (commas for thousands separators and periods for decimals). First, we have a lander in a 40 km circular orbit of the Mun and another vessel ahead of it in the same orbit, with a separation angle of 77°. 1. Calculate the orbital period. The equation for this is T = 2π √(a3 / μ), where: T = orbital period, a = the semi-major axis of the orbit, and μ = the gravitational parameter of the body that you are orbiting KSP displays your orbital altitude as an altitude above datum, which is the zero point or 'sea level' of surface elevation. The problem is that semi-major axis for an orbit is calculated with respect to the centre of mass, not the surface. You need to add the radius of the Mun, which is 200,000 metres. You can find that in the wiki, but it is also displayed in the information pane for the Mun that you can find in the Tracking Station. The formula for semi-major axis in KSP is (Apoapsis + Periapsis + celestial body diameter) / 2, so for a 40 km circular orbit of the Mun, that is (40,000 + 40,000 + 400,000) / 2 = 480,000 / 2 = 240,000 metres. The gravitational parameter is also unique to a given celestial body, and is equivalent to the universal gravitational constant times the mass of the celestial body. This is also something that you can find either in the wiki or in the Tracking Station, and for the Mun is 6.5138398×1010 m3 / s2. Putting that together: T = 2π √(a3 / μ) T = 2π √([240,000]3 / [6.5138398×1010]) T = 2π √([1.3824×1016] / [6.5138398×1010]) T = 2π √(212,225.05) T = 2π * 460.6789 T = 2,894.5 seconds 2. Calculate the separation in terms of the orbital period. Since we're working in degrees, I will continue to do so, but know that many orbital calculations require radians. 2,894.5 seconds per 360° orbit gives 8.04 seconds per degree--we can round this down to 8 seconds exactly for our purposes. 77° at 8 seconds per degree means that, assuming that you are ahead in the orbit, you are 616 seconds ahead of the target in your orbit. To allow your target to catch up to you in minimum time, you will want to increase your orbital period by that much. Then, when you return to the same point, the target will have advanced by that exact amount and you will complete the rendezvous by matching velocities (which is the same thing as returning to your previous circular orbit). However, it is not necessary to do it that way. You can choose, for example, to increase your orbital period by 308 seconds and allow the target to catch up over two orbits. That will save fuel, but at the cost of time. Sometimes, it may be necessary to do it that way, such as when your phasing orbit will cause you to strike a celestial body, eject you from the sphere of influence, cost too much of a limited fuel budget, or otherwise cause issues. Anyway, in this case, since we want to slow down and allow the trailing object to catch up, we need to increase the orbital period by 616 seconds. This is as simple as 2,894.5 + 616 = 3,510.5 seconds. 3. Calculate an orbit that has the required orbital period. In this case, we want to use the same equation for orbital period, but we need to work through it the other way: we have the period and we want the semi-major axis. With algebra, we can derive a new equation to be: a = 3√(μT2 / 4π2) The variables are all the same as before, but please note that the outermost operation is cube root, not square root. a = 3√([6.5138398×1010] * [3,510.5]2 / 4π2) a = 3√([6.5138398×1010] * [12,323,610.25] / [39.4784176]) a = 3√([8.02740229×1017] / [39.4784176]) a = 3√([2.03336476×1016]) a = 272,942.9 metres Remember that semi-major axis is equivalent to (Apoapsis + Periapsis + celestial body diameter) / 2. In this case, we want to keep the periapsis for ease of rendezvous later, and we are naturally going to remain in orbit of the Mun, so the only variable to change is the apoapsis. This problem simplifies to (2 * a) - Periapsis - celestial body diameter = Apoapsis, or (2 * 272942.9) - 40,000 - 400,000 = 545885.8 - 40,000 - 400,000 = 105,885.8 metres (or 105.8858 km) for your new apoapsis altitude. 4 - 8. Complete these steps as given in the quoted post. One item of extreme interest here is that, although the calculation is valid, it depends on foreknowledge of the phase angle or angle of separation between your vessel and its rendezvous target. In the example, this was given as 77°, but KSP does not give you this information. You will need to either install a mod that will give the information (Kerbal Engineer will do this), estimate it by eye, or else use a protractor on the computer screen. You can calculate it based on the separation changes resulting from tiny orbital manoeuvres, as well, but that is often more trouble than it is worth. The typical approach for this is instead to raise your apoapsis by some arbitrary amount, wait for enough orbits to get a 'close' encounter, lower the apoapsis to get a near-perfect encounter according to the close approach markers in the map view, and rendezvous. The idea is that you get some fuel savings by choosing a lower phasing orbit to offset the cost of the minor adjustments. The net effect is equivalent to estimating the required phasing orbit and then refining that estimate by iteration until you get a rendezvous.
  2. It doesn't, as you discovered. I believe that the reason for it has to do with the on-rails versus off-rails way that KSP calculates orbital information. When the craft is active, the orbital parameters are dynamic, but once you switch focus to something else, those parameters are treated as constant initial values in the orbital equation. Knowing that the craft's mean anomaly was a given value at the specific time you last controlled it is exactly as useful for calculation purposes as knowing what the mean anomaly was at some arbitrary zero time. That being said, I don't know that for certain, so I may be far and away off the mark. It doesn't tell any more about what OBT is, either.
  3. Six parameters define the orbit in three-dimensional space. You need a seventh to define which celestial object you're orbiting, but that's handled here, obviously. Technically, you need an eighth to define the time element: mean anomaly defines one's place on the orbit as a radial angle from the periapsis, and mean anomaly from epoch (also sometimes called time of periapsis passage) defines position with respect to some time, but without a reference time to respect, it doesn't mean much. That time parameter is usually called epoch; I have no idea what 'OBT' describes. Granted, these extra two are not, strictly speaking, orbital parameters. They are properly considered part of the reference frame; an orbit can be just as well defined without knowing what you're orbiting or when (incidentally, orbits don't care about the surface elevation of the primary, either), but the practical value of knowing these things should, I hope, be readily apparent.
  4. Welcome to the forum! It's nice to see new people here. You're not doing anything wrong, though I will say that you misread HvP's post. Note that @HvP did not say that there could be too many control surfaces. HvP said that there could be too many control inputs. That is not the same thing. Too many control surfaces is something that can happen, but it usually results in an unstable plane with too much control authority--in other words, tapping the ailerons to level the plane instead results in flying upside down, and trying to go back the other way results in flying sideways, because you have so much control that you cannot make fine adjustments. Too many control inputs means that each control surface tries to operate in all three axes--pitch, yaw, and roll. Normally, planes devote a control surface to controlling one axis at a time: elevators control pitch, rudders control yaw, and ailerons control roll. Occasionally, one surface will be used to manage two axes as in the case of elevons that manage pitch and roll (in fairness, though, I've never seen elevudders or rudderons). KSP doesn't know that a given control surface is supposed to be an elevator and another is supposed to be a rudder--even though some parts are called elevons in the VAB, nothing prevents you from using them as rudders (or as landing legs, if they've the crash tolerance for it). The game provides a way for you to instruct the parts to operate only for pitch control, but you need to select it when you place the part. If, for example, you leave your rudder set to roll rather than allow it only to control yaw, then an attempt to roll will also turn the rudder, even though its total contribution to roll is, at best, two or three percent of its contribution to yaw. The result is that the plane rolls (provided that you have ailerons as well), but rather than rolling while maintaining forward motion, it also yaws and invariably pitches down. With a full complement of control surfaces, they all end up fighting one another. The other part of that problem is what @AHHans mentioned. When your wings are too close to the centre of mass, the control surfaces on the wings are also too close to the centre of mass. This creates two problems. One is that the surfaces lose control: if you imagine that the control surfaces apply a force like a wrench turning the plane about its centre, then having the control surfaces father from that centre provides a longer wrench, more leverage, and thus more control. Having the surfaces too close to the centre shortens the wrench to the point that it has no control. Worse, if the centre of mass moves about because of a shifting fuel load, then the control surfaces that were slightly to the rear of the plane may find themselves slightly to the front once the centre of mass moves past them. Since KSP moves those surfaces according to their relationship to and direction from the centre of mass, it means that elevators that work correctly on the runway may suddenly switch and work backwards at some point in flight. I'd also like to see a picture of the plane in question. It doesn't make sense for time warp to change control surface function, but I've seen stranger things.
  5. That is an excellent point. To the bug tracker, then. Edited to add: Issue 24504
  6. Given that use of the cheats menu is now a standard part of the advice toolkit, is it perhaps to the point that we need to revisit the requirement that a satellite be new in the first place? I know that contextual contracts give contracts to move already-launched satellites, but those contracts are for specific already-launched satellites: the contracts pick a satellite and say, 'move this one'. The fact that they invariably pick satellites that I've placed with tender care into their orbits and have no intent to move for any price is merely twisting the blade for me--but that's a separate issue. Instead, what I mean is to ask whether it is possible to have a contract that will accept any satellite that meets the other requirements, regardless of its launch time. In other words, let's say that a contract requires that a satellite with an antenna and 600 units of monopropellant be placed in X orbit, and I happen to have one from an earlier contract that required 1,000 units, so it qualifies. One Hohmann transfer later, I've completed the contract. Does anyone know whether such a thing is possible without overhauling the game? @bewing, perhaps? If it is, then I'll write it up as a feature request for the bug tracker. If not, then I think I'll do that anyway.
  7. In this situation, is it appropriate to train a telescope on the station? It's not like that other time--I'm only looking at the sky. No, officer, I really am an astronomer! My name isn't Tom! Anyway, seriously, @GungaDin, there are mods that will spawn new Kerbals for you if you leave male and female crew on vessels and stations that have the right amount of space and other amenities, but not in the stock game.
  8. When you're getting different results for your burn time, that's just KSP. When you're getting different results for your delta-V, something's wrong with your tank and fuel flow arrangement--or it's the case that MechJeb or KSP is seeing a connection that doesn't exist. Check your tankage and the way your feed is set up. Try detaching and reattaching the stage in the VAB. If nothing else works, then you're going to need to rebuild the rocket and see whether you can duplicate this.
  9. You definitely should try Docking Port Alignment Indicator, then. The navball indicator is strictly visual and doesn't give the numeric information that you want. Keep in mind that a new KSP version was released recently, so it may not be updated yet. Also, even DPAI doesn't give you everything numerically; it'll give closing distance, which is the z-axis separation you asked for. It gives roll angle numerically, as well. X-Y alignment is still visual.
  10. The first part is: After that, when you select 'Control From Here' on the docking port you want to use, you may find some assistance when you make certain that you also click 'Aim Camera' (it may be an advanced tweakable; you can activate advanced tweakables in the settings) so that the locked camera that @5thHorseman mentioned centres on the docking port instead of the centre of mass of the vessel. Also, large vessels that take several seconds to rotate have more angular momentum; they also take several seconds to stop rotating. Consider using fine control (toggled with the caps lock key; when active, the pointers for roll, pitch, and yaw in the lower left corner turn blue rather than orange) for small adjustments and better balance when you align with RCS.
  11. Others have answered these two well enough; I have nothing to add. They come from the military tradition; modern rocketry has its origins in weapons development. The military, in turn, gets these words from its centuries-old tradition that the nobility and aristocracy would constitute the officer corps, which lent its vocabulary to the planning process. The vocabulary, but not the nobility, were retained by the American military when they won independence from the British. You may be inclined to think that the British would rather prefer English words, but no. Because of the Norman conquest, French was the language of the upper class (even though the British were often at war with the French), which of course included officers in the military, and in fact, the concept of 'the King's English' was a complete paradox for more than three hundred years, the amount of time after the conquest that it took for a king who spoke English as a first language to accede to the throne. Even after this, the social elite continued to use French as a second language, alongside the merchants, educators, lawyers, and others who may not have been noble but nevertheless came into contact with French-speaking officials and thus needed to know the language. The lingering effects of French on official titles and the like are seen in a few other places, such as the inversion of noun-adjective order in high offices like attorney general and tribunals such as court martial. The lingering effects on the rest of the vocabulary are seen in words that relate (or once related) to high-class activities. For example, many words naming livestock, such as cow and sheep, are English (technically Germanic) in origin, but the words for the meats prepared from these animals, beef and mutton, are French-derived, because raising these animals on a farm was a peasant activity, but having them prepared by a chef (that's a French word) who was trained in cuisine (also a French word) was a higher-class indulgence. (Incidentally, the other lingering effect of French on English is to provide a ready source of euphemisms. To return again to the barnyard example, the only functional difference between using the words dung and manure is how polite the speaker wishes to sound. There is a similar euphemistic shield between the word derriere and butt.) In similar fashion, manoeuvre (to move--though it comes from a word meaning manual labour) and rendezvous (to meet) are not, in themselves, high-class activities, but as military activities, they were planned by high-class officers who originally predominantly spoke French. Many other military terms, such as the words ordnance, bombard, sergeant, enfilade, captain, fort, and munition, are similarly derived.
  12. I cannot speak to it having been tried before, but you should be able to get a corrected velocity by use of the solar day rather than the sidereal day. The sidereal day is 21549.425 seconds; the solar day is 21600.000 seconds (exactly six hours). If we assume a constant ten-km altitude, then we're travelling a circle with a radius of 610000 metres; the correct velocity is then 177.44 m/s.
  13. Hello! Welcome to the happy little group. 1.9 km isn't the absolute best closest approach for the final rendezvous. This all depends on context, too; rendezvous with a vessel in orbit about another planet requires you to take the intercept you can get with the intent of fine-tuning it later. For orbit of the Mun, it's possible to do much better. If your vessel has RCS, then you can use that to fine-tune your approach. If not, then you can work with it; just know that it leaves you a bit far away from your target when you do reach rendezvous. I typically try for less than a kilometre--hopefully about 500 metres--for my rendezvous close encounters. That would be the essence of your problem. Everything prior to this is correct--though I would say that 10 m/s is a little slow for covering 1900 metres. It's your three minutes, though, so if that's what's comfortable, then do it. I suggest that it would be better to begin your approach, turn your vessel retrograde, and then simply wait until you are within thirty to fifty metres of the target. Bring your velocity to zero relative again using the navball's target mode and then you don't have to worry about how close it's going to be. Once you've matched orbits, your relative positions will change extremely slowly. At thirty to fifty metres away, you won't need to look for the rescue vessel, either. You may wish to include lights in case of night rendezvous, though. The rescue ship flies away because you left it with 10 m/s of relative velocity and couldn't get to it with your jetpack Kerbal in time. Remember to bring your rescue ship to zero relative; otherwise, that will happen every time. As for the rest of how to control the jetpack, @VoidSquid has the right of it. For your information, though, when you send a Kerbal on EVA, that Kerbal begins with the same orbit and motion as the vessel he or she just exited. The trick to rescue rendezvous (and crew transfer) is to ensure that the rescue vessel is moving at that same velocity, too. Then it's rather straightforward to fly over. Good luck, and do please let us know whether you need any additional help.
  14. Batteries can be attached anywhere. Some are radially-attached and can go anywhere, and there are two sized at 1.25m and 2.50m for in-line placement. The radial ones are best placed inside a service bay, fairing, or cargo bay until you get out of the atmosphere, because they cause drag otherwise and are not very heat-resistant. Also, there are more generators than just solar panels. Many of the engines, for example, have 'alternators' (a real device but not used on real rockets) to generate power during launch when the solar panels are stowed or hidden behind fairings. If you haven't noticed a loss of power during ascent, then it's likely that your engine has been keeping your power levels full during launch without you noticing. If you're not planning on using the vessel again, then you don't need solar panels; you can send enough batteries to complete the mission and then abandon the vessel to space. If you do plan to use the vessel again, then you only need enough batteries to send your most demanding (in terms of electric charge) report, and only enough solar panel to cover your average consumption plus a bit for recharging. If you're less patient and want to send more reports, then add more batteries. If you're even less patient than that and want to recharge quickly, send more solar panels. Just remember that each battery and panel you add beyond what you need adds parasitic mass, which requires larger and larger rockets to lift. As a secondary recommendation, note that batteries all have the same charge-mass ratio, meaning that no battery is more mass-efficient than any other for the amount of charge that it contains. Solar panels are another matter; the OX-4L and OX-4W are the best, and the Gigantor is next.
  15. You found a helpful glitch. They're rare but they do occur. The rule is that cargo bays do not normally work that way, though I concede that your mod may have played a role. Cargo bays are useful to shield parts from aerodynamic forces and reentry heat. Tie-down straps for the actual cargo are not normally included; you normally need either the claw or docking ports on both parts to recover something in a cargo bay. If you do not time warp, then the bay should contain the part. However, the part and the bay are then both subject to collision forces, and that may cause one or both to explode should you jostle the vessel too much (when you open parachutes or land, for example). I also do not know how the game treats detached parts in bays for purposes of shielding from reentry heat; it may not understand that the part is inside a bay at all, which will make things interesting. In almost all cases, parts in a cargo bay are meant to be attached to that bay. The exceptions are for when you're in the process of launching or recovering something (such as releasing a fuel tank from it or driving a rover into it), and even then, the intent is that there be some means of attachment (or detachment) involved.