Lexif

Erm, if your aim is to crash into Gilly at twice its orbital speed (or fly by at that relative speed), what Nimelrian says will work. If you want to land, you will have to cancel out about that much speed, there's no way around this, I think. I have not tried it, but if you have the delta-v, I would try to raise your AP to Gilly's orbit, with the ascending/descending node at the apoapsis. There, your horizontal velocity will be small and you will pretty much only have to add Gilly's orbital speed by burning retrograde. (And cancel out the normal/antinormal speed component for the 9,5° tilt.) I hope I got that right, it's late here.

This great web app will calculate everything you need for you -- if you are transfering between two bodies with the same parent. (Mun-Minmus works, Mun-Duna doesn't.) http://alexmoon.github.io/ksp/ This page is much the same, but doesn't regard the orbital inclinations and excentric orbits of the planets. That's only needed for Minmus, Moho and Eeloo, though. But it explains all the parameters very well. http://ksp.olex.biz/ If you just want to get a quick idea of the minimum delta-v requirements, try this "subway map". That's a type of chart were you add up the delta-v listed for each step to get from one place to another. Again, excentric and inclined orbits are not accounted for.

It would be cool if there could be just a bright pixel, with brightness based on shadow/daylight sate and maybe partcount or size.

I thought the ATV was very well visible, but not as eyecatching as the ISS. Here are two shots from Thursday for comparison. http://imgur.com/a/aqLcZ You can see two bright stars above the trees in the lower left corner, the left one ist actually Saturn. The ATV looks a bit darker than reality in the comparison, as it's faster moving because of the lower orbit. So it spends less time on a pixel than the ISS. Both shots are 30 s exposures at 13 mm focal length (APS-C, like 21 mm on 35 mm film). A tip: If it doesn't blink, it's propably not a plane but a sat. In the summer (with the sun low below the horizon) and under a dark sky, you can see many very faint ones every few minutes, but they are easy to miss. It's like thinking: "Hey, did that faint star suddenly move?"

Ah, that's interesting. Thanks.

Haha, yes, I forgot a at the end. Anyway, we are really well off with our launch site in KSP. I hope you all enjoy viewing all those great spacecraft fly over.

Well, Kennedy Space Center is at 28.6°N, so it's closer in latitude to Baikonour than to Kourou -- or more or less in between if you're not nitpicking.

Baikonour is in Asia, not in Europe. But yeah, Baikonour is at 45.6°N. The ISS has an orbit inclination of 51.4°, which should provide some padding for launches. ATV gets launched from Kourou at 5.2°N. But I guess that earth observation also was considered when choosing the orbit for the ISS. Most important population centers should be visible from that orbit. Edit: got ninja'd by your edit, Tommygun.

I just saw it zip over Germany about an hour ago, it's well visible. I also took some pics yesterday. Currently, it's 15 minutes after the ISS. The docking will be in the afternoon here, but it should be visible the night before together with the ISS. Fingers crossed for good weather!

Thanks for the heads up, I just saw it flying by here in Germany, but still quite low above the horizon. Past midnight, there will be a series of better passes. The ISS will also be visible here the night before it docks, so I hope to see them both at the same time on the 14th/15th if the weather complies. I still remember seeing Mir, a Progress and the Shuttle fly over in the nineties, that was awesome!

Have you tried scanning from higher orbits? I made a great map from a 427 km Orbit (at 10x timewarp) and recorded some 700 MB of CSV data in the process. This took just one night. I think in the old version, the map would have been still quite patchy at this altitude, and certainly not usable for the higher default resolution in the new version. This was with a scan resolution of 250. Also, the 500 km limit apparently doesn't exist anymore, so you can try even higher orbits. I was actually thinking I should complain that the new scanning technology made it to easy to scan a planet. Edit, to clarify: With the new version, scanning the whole planet took about 15 hours mission time, while you'd need plan with about 39 hours and an ~82 km orbit in the old version to fill a 2048 x 1024 map.

That paper is a very nice find, thanks. I might try that challenge if I find the time. This constellation could replace my non-expandable sats when I need more dishes soon. My current network has three sats spaced evenly in geosync orbit, plus two in highly elliptical orbits with a period of 6 hours. The polar sats have proven very usefull because they can reach vessels on the far side of Mün an Minmus, helping with injection burns.

Ah, so someone else has the same problem as I have, I guess? http://forum.kerbalspaceprogram.com/showthread.php/9396-0-20-ISA-MapSat-4-0-Dev-Build?p=394307&viewfull=1#post394307 I only saw this when mapping Moho, it didn't do that on Kerbin and Eve. Also, I don't know why so many here have trouble with crashes and RAM usage. That's no problem on my old laptop.

I'm always delighted when Gusdrin comes flies my ship.

I have tried this without FAR (14500 x 0 km) and got to about 1000° on the shield. (I don't have my notes here, so maybe not exactly.) My reentry speed was also lower. But it pulled about 8 g, right at the edge for a human crew or beyond allready, I guess. An the pod behind got quite hot, too, some 600 degrees. If you go in at about 20 km PE from the moon, you will pull about 4 g, but the pod will get hotter. So if you care for the g-loading, there's a window you have to respect.

So, some results on RC3, using KSC 0.20.0. I had some ships with the old heat shields and Mk1-2 Capsules in Orbit, so those were used. Temps are on the heat shield which was facing retrograde. - Orbit 150 x 0 km: velocities: ~2300 m/s @ 70 km, ~2350 m/s @ 30 km max temp: 780° @ ~28 km max g: 3,0 On the first test, altitude and velocity display froze at 22317 m height, though Kerbal Engineer could still display them. I could not reproduce this after reloading. Mods installed: Mechjeb, Kerbal Engineer, Kerbal Alarm Clock, CrewManifest, ISA Mapsat Dev Release. Mechjeb and ISA parts were not on the active ship. - Orbit 150 x -31 km velocities: 2285 m/s @ 70 km, 2150 m/s @ 35 km max temp: 880° @ 21 km max g: 3,5 - Orbit 150 x +30 km velocities: 2335 @ 70 km, 1900 @ 30 km max temp: 670° max g: 2,6 It seems a bit strange to me that the 30 km PE had the lowest maximum temperature on the shield, though I didn't monitor the temp on the capsule. I noted that on the 0 km PE try, it showed about 220° degrees at one point.

Is it just me or is the download down?

How long did you wait? I deleted my map of Moho and enabled the "looking for new planets" menu item, and the next time I loaded, it locked up for a few minutes with 100% CPU load...after that it was fine every time. Edit: I waited for a few minutes and it came back after some time -- I didn't close the program.

I don't use Steam.

For reference, it works for me with this directory structure in Win7: Thought about case sensitive operating systems like OSX and Linux, but I think I saw someone with Win7 report the problem as well?

Hi Innsewerants, forgot to thank you for this great addon! Here is a crop from a Moho polar map showing the problem. I started at the bottom left without timewarp and got only single lines each time the map updated. North of that at 5x timewarp everything was fine. Switched timewarp off again (gap), the cycled to a timewarp too high up to the northpole, leading to expected scanline gaps. Above the pole, there's a (blue/green) section without timewarp again, with a strip in the middle where I engaged timewarp again for two map updates. Edit/PS: Here's a full ISA map of this. http://i.imgur.com/IOainR5.png In think the map was updated in the display at the same interval, timewarp or not. But without timewarp only one line appeared, with higher timewarp the full distance since the last update was filled. I also sent up a fresh Kerbin probe and the problem didn't appear. More than one pixel-line was filled each update without timewarp, so the problem would have been visible, but didn't appear. I also have visual problems with the dish in .20, every other polygon seems to be differently shaded, but that might be because I have the textures set at half the resolution. Here's a screenshot:

I think I might have found a bug. I imported my old save from 0.19 to 0.20 and tried an old mapping probe I had orbitting Moho. (Which was launched with the old version of the addon.) It's in a circular orbit at 65 km. Every map update interval, it only draws one single scanline to the map, no matter what resolution I set it to. But if I accelerate time, I get full, filled in stretches of terrain drawn. If I increase time acceleration more an more, scanlines start to show up again, as expected. I tried my old Eve orbiter, too, and it shows no such problem. My laptop is really slow and old, but still, that behaviour seems unexpected, right? I don't have hyperedit installed, and don't really feel like launching another probe to Moho right now, so I'm sorry to say I can't really test it as cleanly as I should. Mods installed: RemoteTech, Kerbal Alarm Clock, Deadly Reentry, Kerbal Engineer, Mechjeb2, Subassembly Loader.

I was toying around while waiting for the mods to update today and came up with these designs. The blues stand for the delicate atmosphere and the ocean, the green is for the continents on Kerbin and of course because they are green critters, and the green star symbolizes how Kerbals conquer space. These two are more flag-like: And these are more like mission patches (inspired by the Ares mission patch): I guess I'll go with the left "mission patch", it propably stands out better against the darkness of space. The "rocket star" also brings in the inevitable aspect of kerbal life of having stuff from space rain down on them.

I had the same problem. In the persistent.sfs, search for their names to find their crew entries. For me, it showed state=1 and idx=-1. I believe the negative idx kept them form respawning. I think I reset the state to zero, and the idx too and had them back. Make a backup before trying, though.

Maybe? But it would be longwinded. If you are in a slightly elliptical orbit, when you adjust the relative velocity to zero at one point in time, it might still drift off over time. You would have to correct and keep it that way for at least (propably much more) than one full orbit, which sounds annoying. After that, you would propably end up in a geostationary orbit after some time, yes. (Btw, you might not need a time keeper probe if you leave launch clamp debris behind at every launch, so you could target them...there's always some launch clamp debris at my pad until the next launch.) I just use mechjeb (now I would use Kerbal Engineer as I have not much use for the autopilot features) to display my orbital period and just make this close to 6 hours with a tolerance of 0.1 s for my RemoteTech comsats. The point is that if the orbital period is right, drift over time is minimised. Being really exacly over KSC (geostationary) is not as important to me as that the sats don't drift relative to each other for a long time (geosynchronous). Anyway, why don't you try your method and tell us how it works? I've never seen that idea, so why not use a probe to test it?