ElWanderer

The BBC are reporting that the parachute jettisoned earlier than expected (hinted at in the ESA page linked to above), as well as the thrusters firing for less time than intended. http://www.bbc.co.uk/news/science-environment-37715202 PS. Mark Watney says "thanks for the new barbeque. Mmmmm, hot potatoes".

Fingers crossed. I've got to feel for the guy whose wind sensor on-board Schiaparelli is a re-run of one he had on-board Beagle 2 (as mentioned part way down http://www.bbc.co.uk/news/science-environment-37700042) To lose one sensor is unfortunate. Losing two...

Using circular 100km parking orbits at Kerbin and Duna, I get a total delta-v of 1690m/s to transfer if arriving at Duna periapsis, and 1620m/s if arriving at Duna apoapsis. That doesn't take into account any plane changes or corrections burns. I wonder if it's always going to be cheaper to transfer to an outer planet when you arrive at apoapsis. The ejection burn is larger, but in the case of Duna the insertion burn is much smaller. It may not always be the case, though. I've had to fiddle a lot with my spreadsheet to calculate these numbers, so errors may have crept in.

Can you show your working. I'm typing this on a phone, so this'll be a bit brief (no formulae, sorry), but here's my calculation of Kerbin-Duna. Hopefully any differences will jump out. 1. An eccentric orbit around Kerbol (GM = 1.7233*10^18) with a periapsis (altitude) of 1.3338*10^10m and an apoapsis (altitude) of 2.0726*10^10m (Duna's semimajoraxis, less the radius of Kerbol) has a velocity at periapsis of 10228m/s. 2. A circular orbit around Kerbol (GM = 1.7233*10^18) with a constant radius of 1.36*10^10m has a velocity of 9285m/s. The difference between the two velocities is 943m/s. 3. Now switch to caring about Kerbin (GM = 3.5316*10^12). To be going 943m/s at the edge of Kerbin's sphere of influence (84159286m from centre of planet) gives a hyperbolic excess velocity of 897m/s. 4. To get a hyperbolic excess velocity of 897m/s, at an altitude of 100km (radius 700000m) you must be going about 3300m/s 5. A circular orbit of Kerbin with an altitude of 100km has a velocity of 2246m/s. Therefore the ejection burn would be about 1050m/s. That's a middle of the road figure - you can get a lower value if you aim for Duna's periapsis. From memory, delta-v maps suggest 1030m/s to get to Duna. Note - I've used the old values from a spreadsheet I set up a while ago. I'm aware that the masses and orbital velocities have changed slightly in v1.2 to accommodate the more precise values for G and g0.

OhioBob's website is pretty handy: http://www.braeunig.us/space/orbmech.htm Try calculating a Kerbin-Duna transfer. 1. Start by assuming Kerbin isn't there. What velocity do you need to be going at Kerbin's orbit, to reach Duna's orbit (pick Duna's periapsis, apoapsis or something in between, it shouldn't make much difference)? 2. You can calculate the difference between this velocity and Kerbin's orbital velocity (which is about 9.3km/s). That gives you the velocity you need to be going, relative to Kerbin, at the edge of Kerbin's sphere of influence. 3. Based on this velocity and the size of Kerbin's sphere of influence, you can calculate the hyperbolic excess velocity. This may be in the link I gave. If not, try Wikipedia. I got it from one of the two! 4. Then, by reversing the calculation, based on the hyperbolic excess velocity from 3, you can determine the velocity at, say, a periapsis of 100km above Kerbin. 5. Finally, find the difference between the velocity calculated in step 4 and the velocity you need to be going at in your circular 100km orbit of Kerbin. That gives you the magnitude of your ejection burn. You can perform a similar set of calculations at Duna's sphere of influence to find out how fast you would be going at periapsis, and thus how much delta-v you would need to go from a fly-by into orbit. The answers should be pretty close to those given by delta-v maps. It's the same steps for other bodies, but as eccentricities and inclinations get further from 0, you may not be able to assume ideal orbits. Then again, it's in those conditions that delta-v maps get further from reality, as anyone who has naïvely tried to get to Moho discovers.

You can change both the load and unpack distances, though it's something to do carefully after reading all the instructions: http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html

I don't know if this is one of KSP's many active-vessel-only values, but assuming it isn't: is the target within the physics bubble of the craft where the program is running i.e. is it LOADED and UNPACKED?

Well, I was assuming you'd set up a perfectly non-eccentric orbit with Hyperedit or the new debug menu in v1.2 rather than fiddling with tiny thrusters!

Perilune and periselene are also used for the Moon, yeah. I've heard perijove (Jupiter) quite a few times recently. Guess the rarer ones only get brought out whenever there is a probe arriving at a body! Wikipedia has a list, though it doesn't have any for moons of bodies other than Earth.

I think the convention is to set the argument of periapsis to 0, so that the periapsis is at the ascending node. If the inclination is 0 too, then I think you set the longitude of the ascending node to 0 as well, so the periapsis is aligned with the universe reference direction (in real life, the First Point of Aries). The apoapsis is always opposite the periapsis, 180° round the orbit.

Ah, excellent. I didn't know that was possible, and it would be very handy to have.

I used to use WARPTO to a time three minutes before the predicted SoI change, then run WARP 3 until the BODY changed. This worked fine as long as the predicted transition was accurate... but I found it was often out of whack, either due to the intersect prediction finding a later intercept (should be better in KSP 1.2) or because the orbit calculations changed between real-time and rails. Quite a few Minmus transfers went wrong because it'd shoot through the transition. WARPTO can only be cancelled by a key press, so the script couldn't break out early on detecting a transition. I've since written my own warp function that will set the desired WARP based on how far away the target time is (took a bit of tuning to stop it overshooting) and an optional function delegate parameter that can be used to end the warp early e.g. on SoI transition. If we get an unexpected transition, it still takes a while to slow down warp, so we tend to overshoot and potentially end up in a different orbit to what we wanted. This is better, but not great. One solution is to warp to a time much earlier than the predicted transition and then do a series of short hops. This takes longer, but ensures you're going slower near transition.

I'm not that steely-eyed, I'm afraid! If physics warp is making a difference, is your impact velocity different or is it that the game is calculating a harder impact due to being in warp? Heck, it could be a bit of both.

I thought this was something they changed back in v1.0.x. The mk16 took longer to open than it used to and needed more than 500m of altitude to do so - hence the default got changed to 1km (I set it to 800m to save a bit of waiting). There were a spate of crashes/hard landings of vessels built in previous versions due to this.

The wiki is maintained by the community, not Squad staff. That bit you've quoted was probably based on something one of the devs said in passing four years ago. I wouldn't read anything into it. That said, at some point new sales will drop off to the point where the only options are to start charging for new content or wind down official development.

Quoth the devnotes: "It’s far from finished". What's apparently finished is the package they'll release to modders.

Oooh, I like those tanks. Or is that what they want me to think? #conspiracy

PMA could mean pretty much anything.

This has been requested, it's worth reading this: https://github.com/KSP-KOS/KOS/issues/1056 If you have a Github account, you could add a comment to that page.

Turns out calculating (all the) intercepts consistently is hard. The last couple of devnotes have had quite a bit of detail about this. It should be better in 1.2.

If this is a boot script, then my advice would be to create a boot directory within your Ships/Scripts directory and put the file there. Then you should be able to select it as a boot file while editing a craft, so it'll be copied across on putting the craft on the launchpad/runway, and run automatically every time the craft loads. Having files in the boot directory (and they no longer have to have "boot" in the name) is the new way of locating boot scripts, as of v1 kOS. If you don't want it to be an actual boot file, then yes, I'd rename it and COPYPATH("0:/newname.ks","1:/newname.ks"). then RUNPATH("1:/newname.ks"), where newname is whatever you want to call it. If you're not booting it, there's no need to put it in the boot directory on the craft.

How about an FTL-800 and a Terrier? Roughly 3500m/s at a TWR of 1 (assuming a mk1 pod plus bits and pieces). That might slow you down enough that a heat shield has a chance to work. As I understand it, too high a velocity at too low an altitude = a different kind of heat modelling, that is much more like running into a brick wall I.e. everything explodes almost instantly due to a catastrophic heat spike.

Is your file called boot and what path are you trying to run? Because it is the name of the directory where kOS looks for boot files, I'd treat "boot" as a reserved name and avoid using it. Usually I'd expect the copypath command with those parameters to copy the contents of the boot directory on the archive to the boot directory on the craft. Edit: Or maybe it'd copy the archive's boot directory into the craft's boot directory (so you'd end up with "1:/boot/boot/”) And if in doubt, run "LIST." (and possibly "CD(boot). LIST.") on the craft to see what's there.

Yes, TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT. At least, I think that's the right way around. It gives you the vector you need to burn to match velocity with the target.

They are functions that return the vector dot product and the angle (respectively) between two vectors. Both can be used to check how aligned two vectors are. VDOT is used further on in the example burn script. VANG is a bit more understandable if you're not comfortable with vector mathematics. http://ksp-kos.github.io/KOS_DOC/math/vector.html