maltesh

It's not in orbit around Duna. It's in orbit around Ike, and Ike's radius is 130 km. 629 km semimajor axis on a nearly-circular orbit over Ike is a distance-averaged 499 km altitude. For the approximately 15 km orbital altitude displayed in the video, the semimajor axis should be about 145 km.

These numbers don't jive with the data in your video; Most notably, the semimajor axis and eccentricity bespeak an orbit above Ike of about 500 km altitude.

Kerbal Alarm Clock has two options to predict the date of the next transfer window. There's the Formula Option. This is the one selected by default when Kerbal Alarm Clock is installed. In the Formula option, Kerbal Alarm clock assumes that all the planets are in equatorial, circular orbits, and moving at constant speeds along them. It works out the rate of change of that angle based on the synodic period between the periods of the two worlds in question, and then uses the aforementioned assumptions to generate a transfer window time. And then, since the worlds are /not/ in Equatorial, Circular Orbits, it constantly readjusts the alarm it set as the time of the window gets closer and closer, and the error on the Equatorial/Circular assumption gets smaller. However, you probably won't notice that Kerbal Alarm Clock does this unless you have other, fixed-time alarms to compare the transfer window alarm against. Kerbal Alarm Clock's Mode Option uses a list of transfer windows someone generated years ago by computer modeling the first 100 earth years of a new save game, and noting whenever the worlds were in the tranfer position. In that case, Kerbal Alarm Clock looks up the universal time of the calculated model window, and generates an alarm based on that.

Ambient Light Adjustment adds a slider that lets you decide how much ambient light the game gives you at any time.

It so happens that, about a year or two ago, I wound up being interested in surface distance as a function of angle and velocity on the Mun, and wound up putting together a Desmos Graph to work that out. Vertical axis is distance traveled, measured along the spherical surface of the Mun, in kilometers. Horizontal axis is the launch pitch angle, measured in degrees above the horizontal. The furthest surface distance for a launch velocity of 500 m/s on the Mun turns out to be at an angle of about 25.72°, for an along-the-surface distance of about 269.3 km.The higher the launch velocity, the lower the launch pitch angle for maximum distance becomes, up until you reach orbital velocity, at which point a 0° launch will take you /effectively/ around the planet, and when you hit escape velocity, of course, you're not coming back down. The actual graph is here, and allows the changing of the radius of the world being launched on (kilometers), the Standard Gravitational Parameter (in m^3/s^2), and launch velocity (in m/s) https://www.desmos.com/calculator/eqvmftnmcg

It was announced that it would be coming to the Desktop on the Google Blog back in May. Most of the tech blogs picked it up back then. Not to mention, it's a return of a feature they had years ago, but the reason it went away is not because Google didn't want it, but because Twitter didn't, and withdrew Google's access to the fire hose.

Ah. My mistake. I assumed the slash was showing the pending level, because all the Kerbals had enough experience to reach level 2 the first time I looked at them after the mod updated. It would be nice to have that information somewhere, so that the player could know "This Kerbal would go up a level (or levels) if you brought him home now." Possibly by putting dots in the stars where the levels are pending?

I think the addition's a little off for the experience levels. I sent six Kerbals on the standard minimal-delta-V-to-level-3 training cruise; Orbit Kerbin (2) Flagplant Minus (6.25), Orbit Sun (6), Flyby Mun (2) for a total of 16.25 XP, which is enough for Level 3 (16). Upon landing the Kerbals on Kerbin, the Experience: Field still listed Experience: 0/2. Upon recovering the craft, all Kerbals on board were promoted to level 3, as expected. I assume it should have shown Experience: 0/3 as soon as the spacecraft entered the Munar SOI (as the Mun Flyby was the last thing done before returning to Kerbin)? A second spacecraft that's currently orbiting the Mun with Kerbals that have gone through the same ordeal also is showing 0/2, and they each have 17.25 pending XP, by my calculations.

There's one definite obvious problem: You mistook Parking orbit altitude for parking orbit radius. If you're orbiting Kerbin at an altitude of 150km, the radius of your orbit is 750 km. I don't currently have the time to thoroughly check your math but the other potential problem is that you must use compatible units. Assuming Kerbin again, it /looks/ like you're using Standard Gravitational Parameter in m3/s2 and velocity in m/s, in which case, for the calcualtion to work as written, both parking orbit radius and sphere of influence radius must be in meters, not kilometers.

The article ties the terms of service to Windows 10, but the actual terms of service linked in the article aren't for Windows 10, they're for having a Microsoft Account. The list of services covered by the terms of Service are these: http://www.microsoft.com/en-us/servicesagreement/?s=ecym#serviceslist Windows 10 is not on that list. You do need to go a little out of out of your way to use Windows 10 without a Microsoft Account, and not as far out of your way as you needed to go in 8.1, but it's certainly doable.

There are, actually. The game's included the Fuel Cell and the Fuel Cell Array since 1.0.

Where are these control locks that you mention here? I've been having some load/save issues myself for some time, where my main save loads like this with none of the stock UI selectable except the "Back" button. The view cannot be rotated, and buildings cannot be selected. THe time acceleration arrows at the bottom are clickable, but time does not appear to move forward. Sometimes loading a different save and going back to the main save will fix it. Sometimes I have to quit the game and reload it. About half the time, I can fix it either by deleting an old Kerbal Alarm Clock alarm from the panel, or by creating a new alarm and deleting that, which is why I'm using the old button instead of the stock toolbar button, as none of the stock toolbar buttons can be accessed when this happens. I'm wondering if turning off the aforementioned locks might help.

From what I understand, there's also the radiothermal heating of the Earth's core, which produces convection currents in the mantle, which can bring up heavy elements that are soluble in molten rock to the underside of the crust, where tectonic and vocanic action can move them out onto the surface. As far as gases in magma goes, some gases are /also/ soluble in magma, and can get pulled into the mantle at subduction zones. Their solubility is dependent on temperature and pressure. When the pressure drops closer to the surface, the gases get less soluble, and start coming out. https://en.wikipedia.org/wiki/Volcanic_gas

The instructions in the original post /only/ work if your destination is a stationary Kerbin orbit. Given that the destination orbit is intended to have an orbital period equivalent to that of Kerbin's sidereal rotation period, the rotation of Kerbin effectively cancels out when going to circular orbit of altitude 2868 km. They won't work for a 600 km altitude orbit.

Kerbin never had a 24-hour day. When Kerbin began rotating in 0.12, it had a 6-hour sidereal day, and it's year was about 106 Earth days, as it is now. The MET Clock and other game times did initially count in 24-hour days and 365-day years, however.

Yep, when the orbit is in the reference plane, the convention is to use the reference direction as the location of the ascending node, which would be a Longitude of the Ascending Node of 0°. The game does this as well when storing and restoring orbits in the persistence file. For whatever reason, it's the contract display code that's decided that's an Undefined LAN.

Use the Rotate Gizmo. Press 'F' to switch on absolute rotation (instead of the default relative rotation) Click on the angle snap. Allows for adjusting to produce straight and true landing gear, regardless of the slope of the parent fuselage.

He's Superman. He's not Astro City's Samaritan. Superman gets time off.

To be honest, I've never actually done it without guideposts. When I fly to place a Draim configuration, my typical tactic is to edit the persistence file to place targets at the desired points, and then I fly my spacecraft to rendezvous with them. In the Draim configuration, all four of the satellites are in orbits with inclination 33°, and eccentricity 0.28, and a semimajor axis that gives a periapse high enough for the satellite to do its part in covering its section of the planet; Draim's parameters for Earth were these: The minmum 27-hour requirement over Earth is how he specified the semimajor axis for his orbit. This works out so that, for any particular world, the minimum semimajor axis for the Draim configuration is about 7.25 times the radius of the world. As such, these were the parameters I picked for the challenge, which are a little larger than the minimal Draim configuration over Kerbin. [table=width: 800] [tr] [td][/td] [td]Sat 0[/td] [td]Sat 1[/td] [td]Sat 2[/td] [td]Sat 3[/td] [/tr] [tr] [td]Semi-Major Axis (SMA)[/td] [td]4350000 m[/td] [td]4350000 m[/td] [td]4350000 m[/td] [td]4350000 m[/td] [/tr] [tr] [td]Eccentricity (ECC)[/td] [td]0.28[/td] [td]0.28[/td] [td]0.28[/td] [td]0.28[/td] [/tr] [tr] [td]Inclination (INC)[/td] [td]33°[/td] [td]33°[/td] [td]33°[/td] [td]33°[/td] [/tr] [tr] [td]Argument of Periapsis (LPE)[/td] [td]270°[/td] [td]90°[/td] [td]270°[/td] [td]90°[/td] [/tr] [tr] [td]Longitude of the Ascending Node (LAN)[/td] [td]0°[/td] [td]90°[/td] [td]180°[/td] [td]270°[/td] [/tr] [tr] [td]Mean Anomaly at Epoch UT=0.0 (MNA)[/td] [td]0[/td] [td]-1.57078[/td] [td]3.14159[/td] [td]1.57078[/td] [/tr] [tr] [td]Epoch (EPH)[/td] [td]0.0[/td] [td]0.0[/td] [td]0.0[/td] [td]0.0[/td] [/tr] [/table] Viewed from a point perpendicular to the orbital plane, each of the orbits has this shape: And the video below has a run of the simulator that I bashed together back in march to show someone that the Draim Configuration does do full-surface coverage. The satellites were placed using the above parameters. It is probably best viewed on YouTube, in full-screen mode, where you can see the numbers in the table. In the big upper square, we assume a non-rotating Kerbin for simplicity, and using a plate-carree projection. Each of the thin horizontal and vertical lines represent 30° of longitude or latitude. The secondary vertical lines are at 90° intervals, and the big thick lines represent the equator and Prime meridian for the simulation. The numbers on the big grid represent the point directly under each of the four satellites on this non-rotating Kerbin. 0 is Cyan, 1 is Orange/Yellow, 2 is Magenta, and 3 is White. The colored contours around each satellite represent contours of how far above the horizon the satellite appears in increments of 10°. Right below the satellite is the number, the next contour has the satellite appear 80° above the horizon, then 70°, and all the way down to the thick contour, which is the limit on the surface where the satellite can be seen. Below that is a table. Latitude, longitude, and altitude are the surface coordinates of the satellites. Horizon is the radius, measured along the surface, of the region of Kerbin each satellite can see. Surface % is the fraction of Kerbin's total surface that each of the satellites can see at any one time. Sat0 Link, Sat1 Link, Sat2 Link, and Sat3 link is sort of a split table. The upper right triangle shows the length of the communications link between each pair of the satellites, with the stipulation that none of the links are allowed to pass closer than 600km from the center of Kerbin (because then Kerbin would be in the way). The Lower right triangle shows the link path. As it turns out, Kerbin never gets in the way of the link between any pair of the satellites. Finally the lower three views are animations of the satellites viewed from above the X-Z plane, the X-Y plane, and the Y-Z plane, The reason they don't look elliptical is because all the orbits are at angles relative to the planes of view.

That's really more part file modification than save file modification, which generally refers to editing the persistence.sfs or quicksave.sfs files. And typically, modifications to part files do not break with updates, unless the update changes the way the part works, or you've changed the part to implement a feature of a mod that was broken by the update. The Modulemanager mod is kind of made to allow you to make modifications to parts (and really, anything else that uses a .cfg file, such as agencies, strategies, etc.) without having to edit the original, if you are so inclined.

Actually, the Draim Tetrahedral Configuration can do it with four satellites in specific positions in inclined, elliptical orbits. All four of the satellites maintain line of sight to each of others at all times, as well as providing full surface coverage. I wound up writing up a challenge to set up a minimum-size Draim Tetrahedron over Kerbin a few years ago, and spent some time writing a computer program to simulate the surface coverage of one earlier this year. As it turns out, for the minimal Draim, you'll need communications links of about 11,000 km to maintain connections between the satellites. The navigational tools KSP provides, however, are not very good for setting up your own Draim Tetrahedron, and the three-polar, three-equatorial satellite solution is definitely a lot easier to fly in KSP.

This has not been my experience, in general. I just threw a 3-man Pod to Kerbin from the altitude of Minmus, and entered the atmosphere moving faster than 3km/s, and re-entered with an initial periapse of 25 km. Slowed to less than 250 m/s at 10 km or so, and opened the chutes without issue. No heat shield, and did get a single temperature bar onm the pod, but the chutes never got anywhere near overheating.

The stock game allows you to rename vessels from the tracking station. Select a spacecraft in the tracking station. Click on the "i" button that appears on the right of the screen. Click on the name of the vessel in the info panel that appears.

radiator-fixed-1 has the following attribute: TechRequired = highPowerElectrics While there is a node called "High-Power Electrics" in the stock tech tree, the tech-required node for it, judging by the other parts in that node, the attribute should be TechRequired = largeElectrics It appears that there is no node that responds to the "highPowerElectrics" value, as in my current Career Mode 1.0.2 game where I have cleared the stock Tech tree, soacecraft that I have saved in the VAB with that radiator on them are now reporting as having the part locked in the VAB. I'm using Heat Control 0.1.2, according to CKAN.

Kosmo-Not kind of copied a bunch of different equation images from several sources when he made the initial post. Since a lot of them were images, the reuse of different variables for the same quantity can get a little confusing. The ÃŽâ€v1 in the equation in windows_x_seven's post is the /is/ the necessary SOI exit velocity to produce the desired Hohmann transfer.