maltesh

Huh. Forgot about the 'No Mod Parts' bonus. I hit the kraken and stopped being able to reliably point the ship at about 76,000 km above Kerbin, and that\'s where I got the submitted top speed. I tumbled across the SOI boundary something like fifteen minutes later. Since I still had about 50L of fuel, I probably could have used time accelleration to try to stabilize the ship again, but I\'d never flown to the edge of the SOI in real time before, so I figured, 'what the heck' and let it coast.

I used the ISA-RAM mapper data to find the general location of what\'s most likely the high point, and flew in a rover to check it out. Highest I was able to locate was 5724m. However, that\'s deep in the high-latitude South. I\'ve pulled off near-equatorial orbits at 5.3 km periapsis altitude, which got within 700m of the surface at times, according to MechJeb.

Was burning the entire time up until max velocity was reached, and never once passed an apoapsis. With a pitch angle that was always above the horizontal, gravity was opposing the spacecraft\'s thrust and velocity, and thus the spacecraft was climbing. I probably could have produced a higher speed by scraping the insde of the SOI and diving back towards Kerbin while burning, though likely not high enough to offset the loss of the climbing bonus. (And, of course, the spacecraft clearly pulled off enough delta-V to do a Hohmann Sundive, which would have lost the climbing bonus, but easily hit velocities in excess of 100 km/s) I have no objections to disqualification on the grounds of shameless fuel efficiency bug abuse.

Should probably make a rule about gratuitously exploiting the 0.16 fuel efficiency bug, or else you\'ll wind up with three-part spacecraft doing sundives. (Yes, this spacecraft launched with exactly the number of parts it\'s shown having. I\'n guessing I could probably eke another 10km/s out of it on the fuel alone before leaving Kerbin\'s SOI.) edit^2: Got it up to 21.3 km/s before uncontrollable Krakening made it impossible to burn harder. Exited the Kerbin SOI in under two hours from launch. I expected to get the extra 9 km/s for leaving Kerbin\'s SOI in the prograde direction for a final velocity of roughly 30 km/s, but that didn\'t happen for some reason. Anyway... Score: 21,397 / 4 parts = 5347.75 + 1000 ascent bonus = 6347.75 .

All elliptical orbits with the same semi-major axis around a body have the same orbital period, regardless of eccentricity, and the travel time from periapsis to apoapsis (or vice versa) is always half that orbital period. ] In the image, both of the orbits have semimajor axis = 1 unit, and the elliptical orbit has eccentricity 0.8. Travel time for objects in both orbits from the green point to the red point is the same. As long as the body both are orbiting is smaller than the radius of the circular orbit , there\'s always some eccentricity you can pick that will maintain a constant line-of-sight between the two objects, as long as they have the exact same semimajor axis. And that\'s just if we restrict them to the same plane. If you don\'t care at all how far apart the objects wind up being, , you have options like throwing the second object on a hyperbolic orbit that takes it far above or below the first object\'s orbital plane, quickly enough so that the first object doesn\'t have time to slip around behind the planet before occlusion becomes impossible.

Agreed. Don\'t worry about how long it takes to swing your spacecraft around to get it pointed in the right direction. Unless your ship is a /ridiculously/ unweildy monster, you\'ll have time. The Mun is close, and its Sphere of Influnece is nearly 5000 km across. You\'ll have time. If you\'re in the Demo version, and don\'t have the patched conic view on the map screen, don\'t worry if it looks like you\'re going to get to the Mun\'s orbit long before the Mun gets there. The Mun is close, its SOI is huge, it\'s moving faster than you are at that point, and Kepler\'s Second Law means that you\'ll be hanging out near apoapsis for a long time. There\'s no need to circularize; it just wastes fuel and prolongs the trip. Be patient, and wait for it to sweep you into its SOI. THis is generally the most fuel-efficient way to get to the Mun, and a fairly quick, which is why it\'s generally so popular. Been doing it since there was a Mun to go to, and have missed the Munar SOI only once with this method, due to my own carelessness. (It\'s also the method that Harvester mentioned in one of the the first poss he made talking about the upcoming Mun)

If the two objects have exactly the same period, you can often avoid the obscuring situation by proper placement. Consider the situation where object A is in an equatorial circular orbit around Kerbin, and Object B is in a polar circular orbit around Kerbin, with the same radius (and thus, same semimajor axis, and consequently same period). Furthermore define the positions of object A and B such that both are together whenever the two orbits cross one another. If A and B are at orbits of sufficient altitude, the line of sight between them will never pass through Kerbin, as long as they have the same period. Similarly, consider the situation where B is in an elliptical orbit around Kerbin, but again, with the same semimajor axis. define their positions so that when B is at periapsis, A is directly above it, and when B is at apoapsis, A is directly below it. You can find an elliptical orbit that matches these criteria such that the line of sight never passes through Kerbin, if the orbit of A is high enough. And in this situation, there\'s no danger of A and B colliding, as they never reach the intersection points at the same time. Though if the player ever causes either craft to leave the rail, the two craft won\'t have the same period any more, and an occlusion will eventually occur.

Most inclined orbits will work. In KSP, the important thing is that A) you orbit the planet in the same period as the other satellite, and position yourself so that the line of sight never passes through the planet you\'re both orbiting. As a result, there\'s a large range of eccentricities, inclinations, ascending node longitudes, and perigee arguments where you can pull this off, as long as you have the same semimajor axis as the other satellite.

A bit more geometry. If your planned apoapsis is much higher than your periapsis, the leading angle winds up being about 63 degrees. At an altitude of about 100km over Kerbin, the angle between the visual edge of Kerbin and the center of Kerbin is about 59 degrees. As a result one of the most popular and efficient methods for timing the transfer burn is to get into a low eastward equatorial Kerbin Orbit, wait until the Mun (Or Minmus, if that\'s your target) rises over the edge of Kerbin from your spacecraft\'s viewpoint, and then burn to put your apoapsis on your target\'s orbit. Since the Mun is close, has a huge SOI, and is equatorial, an intercept is almost guaranteed. Minmus tends to require mid-course correction, as you mention above.

You also could have looked in the persistence file. And yep. You\'re close. 0.03125 mass units. Well done.

Was mucking around with part rescaling. BigTrak. Size comparison: BigTrak and GarganTrak

If you\'re running 0.16, I imagine the liquid engines ignore the Fuel Consumption statistic if a specific impulse rating is provided. Put Extremely Large Numbers in Isp = and vacIsp = , and while that won\'t result in 0 fuel consumption, it will result in ridiculously low fuel consumption, I believe.

Been there. There are weird camera issues, but no pyramid at the north pole of Kerbin.

Changing the folder names won\'t break your spacecraft Changing the title = parameter in the part.cfg file won\'t break your spacecraft; it will just alter the title in the description in the VAB/SPH. Changing the name = parameter in the part.cfg file will break existing and saved spacecraft.

Quicksave only makes one save, which is overwritten every time you quicksave again. I really don\'t know what causes the hgt = attributes to be set to -1, so I can\'t really give any information on how to prevent it. And, if I recall correctly, if you set it too high, the base will drop from that height when the active scene approaches within 200m, which will result in its own problems. IF you want to generally fix it if it\'s already happened, manually BACK UP the persistence file by copying the file to elswhere on your hard drive., find out what bases are afflicted by attempting to load them from the Flight Tracker screen, then restore from the backup and start tinkering. My general rule of thumb: All the parts that make up the vessel have a position = attribute with three numbers separated by commas, the second being the y- position. Find the Y-position of the lowest part attatched to the craft, flip the value to positive, and set the hgt = value a bit higher than that. If it explodes, restore from the backup and set it a little higher than that. If you screw it up, restore from the backup. And yeah, if you\'re going to tinker with the persistence file, back it up somewhere safe first. I know, I mentioned it before, but it bears repeating. I edit it fairly often, and every so often, I still make a make a mistake that wipes the file and requires me to restore from the back up.

I call it 'Explodey Rover Syndrome,' primarily because most of the time when it happens, I\'m usually approaching the base in a rover. What happens is that, for some unknown reason, the hgt = attribute in the persistence file on a landed craft gets incorrectly set. It\'s supposed to provide the height of the 0,0,0 point of the craft above the local terrain. When 'Explodey Rover Syndrome' occurs, it gets set to -1. This attempts to put the craft entirely underground when the active scene comes closer than ~200m, resulting in its destruction. If you\'ve got a backup or a quicksave from before the explosion occurred, you can fix it by reloading the quicksave or copying over the afflicted vessel, and, if neccessary, adjusting the value of the hgt = attribute until it\'s high enough that the base/debris/rover doesn\'t explode when you get closer than 200m.

The eccentricity of a conic section is the ratio of the distance between its foci to the length of its major axis. A circular orbit has eccentricity 0, and in-game, is only achiieved by Kerbin, Minmus, and the Mun. The best you can do with a spacecraft without persistence file editing is an extremely low-eccentricity ellipse...And yeah, I\'m fine with that definition. Though I admit, when I wrote my orbit calculator, I had it consider any orbit of a spacecraft with flight path angle of 0 degrees and velocity that matched the circular orbit velocity when both were rounded to the nearest 0.1 m/s to be circular.

Well, as of now, it\'s still 2 days, 13 hours, and about 20 minutes to the 43rd anniversary of the Apollo 11 Moonwalk.

[sarcasm detector offline. ETA on repairs, 3.2 hours] Pretty much everyone uses time-acceleration to hit the Munar SOI within minutes of play time after setting up the transfer orbit. ( Quicksave (F5) and Quickrestore(F9) are also useful to make things didn\'t happen.) I\'ve done two realtime trips to the Mun. The first was the last weekend before v.0.14 came out, and while it was serenely calming to watch the nine-hour trip running in the background, it was also kind of boring. I realtimed the stay and return out until leaving the Munar SOI, but ultimately got impatient and decided to kick back on time acceleration shortly after Munar SOI exit. It would definitely be easier in v0.15+, because of the patched conics giving you ETAs to SOI switches; I wouldn\'t have had to calculate those myself. The second realtime trip was about a month ago, when I just decided to run for the Mun using one of my high-powered stock Sunspotters, and hit the Mun in under 30 minutes from launch. Lithobraking ensued. I think I\'ll see what I can do to build one that can stick the landing.

829 MB, currently containing 1,253 screenshots in the current version. Symlinked to my Dropbox account\'s public folder. And then there\'s an estimated 20 GB of video.

While there\'s a lot of land, the circumnavigatory path is very convoluted. To get to KSC 2 the short way overland, you\'d have to take a path that goes as north as the 63rd parallel. You can cut a significant amount off that travel distance if your craft can jump or swim across a 30km strait, otherwise it\'s the long way around. To get to it by going the opposite way around the planet, you\'d only have to hit 53° North at a point during the journey, still pretty northernly.

To be honest, ten hours seems extremely long for a 300-day trip. You can do 300 days in 45 minutes at 10k time. The Bi-elliptic sundives that I bookend persistence-wiping updates with take under four hours to fly and last 1200 days of game time. I typically take the sundives out to 131Gm, more out of tradition than anything else. Anything capable of reaching about 5000 m/s in Low Kerbin Orbit can ride that velocity into a Kerbol escape if its escape trajectory is pointed near the leading pole of Kerbin\'s SOI. My longest successful return to Kerbin took 2200 days, but that was just me being bad at finding Kerbin\'s SOI and eventually giving up and riding the inside track in v 0.12.

Munar slignshot doesn\'t help for a bi-elliptic sundive. You\'re far better off taking advantage of the Oberth Effect and doing your burning for the outbound leg in low Kerbin orbit. You gain velocity on a slingshot by being bent closer to the travel direction of the body you\'re slingshotting past, and when moving at 4+km/s, even a Munscraping flyby doesn\'t bend you much.

Unfortunately, v0.16 will break both persistence file and .craft file compatibility, so you\'ll have to throw another spacecraft out there.

An ASAS module means that you don\'t have to double up on RCS to keep the thrusters from rotating your lander if you\'re using it to sand off horizontal velocity. Admittedly, the game considers RCS modules massless, so having fewer of them primarily cuts down on accidental overcorrection and RCS wastage. My stock lander uses three half-size tanks to widely space its footprint. I\'ve only had it roll over once, and that was because I was tying to land on a steep polar mountainside. For the vast majority of the Mun (which is, admittedly, much generally smoother in the paid version than in the demo), it comes down fine. As others have mentioned, 4 m/s is a lot faster than I usually wind up landing. My typical approach means that I\'m often leaving the throttle at the last near thrust=weight setting I found near the surface, and half the time, I wind up using RCS to push the spacecraft down on my descents, for touchdowns at less than 1 m/s. I\'ve never had a landing leg snap off, but I also don\'t manually land monster landers.