Zhetaan

Members
  • Content count

    369
  • Joined

  • Last visited

Community Reputation

396 Excellent

About Zhetaan

  • Rank
    Curious George

Recent Profile Visitors

2563 profile views
  1. @KSK, thanks for the idea. And remember, kids: Before they send us To a grave, Evil Kerbs use Kerba Shave.
  2. Occam's razor says that the simplest explanation is probably the best (though it does not point out that by that logic, Occam's razor is probably a razor used by someone named Occam), and combined with Chekov's gun, it says that Val or Dilsby have an honourable duel up one of their sleeves. As for how to get out of that, I am waiting with bated breath. Maybe razor can beat gun in a duel?
  3. help with setting up relay orbits

    I usually go for an equatorial (and equilateral) triangle of satellites set at 777 km altitude, but that's because I use RemoteTech and that altitude gives separation at a good middle of the range for two satellites using Communotron-16s. I don't bother with a set that gives polar coverage because a) I'm not that OCD of a completionist, and b) I also use SCANSat and that guarantees at least three polar-orbiting, relay-capable satellites anyway. If I have a probe that needs to do something over the north pole and there's no coverage, then by the next orbit, there will be. If I go high enough, I get coverage anyway because there's an altitude above which the equatorial satellites are visible from the poles. I don't know what the range limits are for CommNet in stock KSP, so you'll have to figure it out. Remember that for a constellation, there is both a maximum limit set by the antenna range (the sats in the constellation need to be able to talk to one another) and there is a minimum limit set by the planet (three sats at 70 km will not be able to see one another; the planet is in the way). You may wish to avail yourself of the Visual RemoteTech Planner to find the best altitudes (it lets you add custom antenna configurations), but if you want to do it the long way: Remember, that is all preliminary and meant to get the right altitude at which to place your constellation. Once you have that altitude, it is actually sufficient to get only approximately close--the trick to orbital synchronicity is not orbital altitude, but orbital period. So long as the orbital periods are identical, the satellites won't drift. The problem is that KSP uses floating-point maths, and that leads it to make rounding errors that build up over time to alter the orbital period and thus the spacing. My solution is to get the satellites to agree on an orbital period, hopefully within a tenth of a second (this requires Kerbal Engineer Redux or equivalent, thrust limiters, and tiny engines), switch views to something else, set the correct values in the persistence, and then never focus on the satellites again so as to keep them on-rails and immune to orbital recalculation. However, for an evenly-spaced constellation, you'll need to do a couple of additional things: You've picked a good test of both piloting and navigational skill, but make no mistake: KSP has some very specific limitations to what it can do because of the nature of the simulation and the amount of computing power it has available. The best overall solution is to get your constellation in the sky so you don't have to worry about controlling probes, and once you have a constellation that will stay reasonably functional for a year or so, simply make certain that you put a relay on everything else that you put in the sky. Eventually, you'll have enough of them that it won't matter what the spacing is.
  4. It is true for some stock bodies and not others. The Minmus flats biomes are all the lowest point of Minmus's surface and all set at datum. The Mun's lowest point is about 250 m below datum. Moho's lowest point is--or was at one point--30 m above datum, and I don't know why. I do know that all stock bodies with oceans have the datum set to the ocean surface, and the ocean is present everywhere that the terrain dips below datum, but that only accounts for three bodies.
  5. RemoteTech + Root Mode

    @DrPastah: No, there's no preference for which side of the link gets the stronger dish: the range in root mode depends only on the antenna combination, not the order. However, the solution is easy: add stronger dishes at Kerbin. You won't even need to re-do your current satellite constellation: just have one new satellite in a large-radius polar orbit (this reduces the chance of occultation) that has a dish powerful enough for Duna and enough antennas to connect to your existing constellation. As to the reason why you cannot connect, the range is not the average or arithmetic mean of the component antennas' ranges; it's the geometric mean. The formula for it is √(r1r2), where the r values are the antenna ranges involved. 90 Mm x 90 Gm gives 8.1 x 1018, and the square root of that is 2.846 Gm. There is also something called a clamping value, which says that an antenna is limited to a hard increase of 100x its base range for omnis and 1000x its base range for dishes, but we're not running up against that. The idea there is that it keeps you from using a DP-10 to communicate from Eeloo just by linking it to a stupidly-overpowered dish at Kerbin. This also means that you will never be able to connect a KR-7 (which, if I have it right, is what you're using at Kerbin) to anything more than 90 Gm away, because 90 Gm is 1000x the KR-7's range. When linked to a sufficiently-powerful dish, they can reach Duna, but the dish you chose to use at Duna is not powerful enough. You'd need something rated to 4.5 Tm or better to connect when Duna is 20 Gm away. The issue is essentially that while Duna has powerful dishes orbiting it, the ones at Kerbin are so weak that they can't transmit a usable signal with enough strength for the Duna dishes to sort from the background noise. In reality, more powerful antennas are perfectly capable of picking out the signal from weaker antennas. For example, sensitive antenna technology is what allows us to continue communicating with the Voyager probes (at least, I'm fairly sure that no one's upgraded Voyagers' radios), but the simplified model used in RemoteTech does not allow for that because it doesn't simulate noise at all. They're working on it for RemoteTech 2.0, but there's nothing like a release date on that yet.
  6. @OhioBob is one of our resident experts on this one (just look at his signature), so treasure that link. You want the vis-viva equation, which is as follows: v2 = μ ( (2/r) - (1/a) ) where: v = orbital velocity μ = the standard gravitational parameter of the primary (that's the mass times the universal gravitational constant, which for Kerbin is 3.5315984×1012 m3/s2) r = the distance between the orbiting object and the primary's centre of mass (in KSP, current altitude plus primary radius, whick for Kerbin is 600 km) a = the semimajor axis of the orbit (in KSP, this is equal to the periapsis plus the apoapsis plus the planetary diameter (for Kerbin, 1200 km) all divided by 2) If you want a circular orbit, then the orbital radius is both r and a, so the equation becomes v2 = μ / r Inclination doesn't matter; the equation relates the gravity and any lateral velocity (I would say horizontal velocity, but the value of horizontal keeps changing when you're in orbit) independently from a 3-d reference frame, which means that the solution can be fully represented in 2-dimensional space. In real life, inclination can matter quite a lot because planets don't distribute the mass evenly and that causes perturbations (see Molniya orbits for an explanation and solution to part of that problem). Keep in mind that the orbital velocity at a given altitude for a circular orbit is going to be different from the orbital velocity for an elliptical or hyperbolic orbit; while the altitude of the craft at that point is the same, the orbital energy is different, and that is reflected in the interplay between potential and kinetic energy that occurs as the object moves between apoapsis and periapsis. Specifying that the velocity is for a circular orbit at that altitude makes computation easier but it doesn't really help when you want to know about the elliptical and hyperbolic orbits that get you there in the first place.
  7. Gravity Assist

    I found two Dres-Jool transfers, but they're terrible; they require 5.5 km/s of dV, take about ten years to complete, and require flyby altitudes of three and four metres in order to get enough of an assist to make it happen. It's possible that better ones exist, but I don't see the point in looking; the problem is that Dres is, as others have said, too small. If Dres only has a few m/s to give to you, then you have to arrive at Dres with the rest, but when you add the timing and conjunction to the problem, the end result is that you spend years on an orbit that reaches out to almost Jool while waiting for an absolutely perfect encounter with Dres. Contrariwise, if you start at Dres, there are a couple of good assists via Jool that get you home. Somewhere in this forum is a post from a person who ended up at Dres with a fuel miscalculation; while the Rocket couldn't get to Kerbin, it could get to Jool, and that was enough. Jool gravity and Kerbin atmosphere took care of the rest.
  8. Three days is an insanely fast transfer. I'm a little curious to know how you're getting such a trajectory if you're burning only 930 m/s in low Kerbin orbit; such a burn should keep you within Kerbin's sphere of influence, if only just. Since it does not, there is something else at work, even if it is only that you are burning far more than 930 m/s without realising it. When you set the node for the Minmus transfer burn, do you do so using only the green prograde/retrograde adjustments, or do you use the magenta normal/antinormal toggles to change your inclination in the same burn? If so, then that could explain why your capture burn is an extra 400 m/s--it can take about that much to change inclination in low Kerbin orbit. You are far better off correcting your inclination in a separate burn, either in low Kerbin orbit or as a mid-course burn where it isn't quite so expensive. Better yet, you can try launching directly into an inclined orbit, but you have to do it at the right time of day.
  9. Ha! I did. I have to say that the coincidence is almost too good to pass up, but pass it up I will.
  10. Yes, well, given that we have a nuclear reactor on board, I would rather not see this end the same way as On the Beach. There is still time, brother.
  11. @Booots is right. You'll find it in GameData/Dangit/Textures as appBtn.png. I can't tell you what the multiplier does; I'll have to go digging for that.
  12. @Fergrim: I'm inclined to go with @Spricigo's answer here. You mentioned that this is at 2.5x scale, so any issues with line-of-sight at ground level would be exacerbated. It's also possible that you didn't scale the ground station location correctly and it is now technically below ground level, which could put it out of sight of everything. Change the ground station height in RemoteTech's default settings file and see whether that helps. I believe the default for a 1x scaled Kerbin is 75, so try 187.5 (or 200 if that doesn't work) and let us know whether that fixes the problem. If that doesn't work, then try rescaling Kerbin back to 1x to see whether it really is a scaling issue. Then try turning off the connection requirement (also in the settings), and if that doesn't work, then try reinstalling the mod. @James Kerman: Only certain types of antenna can 'point', as you put it, but the funny thing about RemoteTech is that if you need to point to Mission Control and are not already pointed to Mission Control, then there is no option to reset the antenna because there's no connection to send the command. Unlike stock, loss of signal means total loss of real-time control (you can pre-program commands using the simple flight computer, but that's it with default settings). However, the dipole antenna (both of them, actually) start out activated, so that cannot be the issue. I don't know whether the challenge appeals to you, but since you haven't used RemoteTech yet, I do encourage you to try it out.
  13. It depends on the choice of Ap, but my back-of-the envelope calculation (ignore Kerbin escape and the initial Oberth effect; just assume you're starting in space at Kerbin's altitude over the sun) gives about 6260 m/s for a Hohmann transfer and about 4310 m/s for a bielliptic for this mission. The bielliptic is split between an initial burn of about 3090 m/s and a second burn of about 1220 m/s. Of course, these numbers are off by a lot because of my initial assumptions, but the relationship between the Hohmann and bielliptic transfers should be apparent.
  14. That's called a bielliptic transfer. When the higher orbit's SMA is greater than ... eleven times, I think ... that of the lower orbit, the bielliptic transfer is cheaper in delta-V than the Hohmann. It requires three burns instead of two for the full transfer (or two instead of one for this sort of fly-by) but the relatively high cost of the initial burn to reach the high Ap is negated by the much cheaper cost to lower the Pe once there. Given that Kerbin orbits at over thirteen Gm and the target Pe was half of a Gm, bielliptic was the way to go--the only real drawbacks to it are that has a minimum limit of effect and that it takes even more time than the Hohmann. @Bill2462: Nice mission! What did you use for a core on the return probe? I take it that you clipped it into the adapter?
  15. When you find yourself putting Kerbals beneath Mk. I Illuminators for dialogue and introducing Jeb's fifth long-lost twin, then you'll know it's gone too tacky and that it's time to wrap up the story. Otherwise, run it until the bolts fall out.