AlexinTokyo

When you get near (within physics range, about 2.5 km) you can use '[' or ']' (default bindings) to switch control to the stranded Kerbal. He will then respond to EVA controls. Note that, as you have seen, you can not switch using the tracking station or map mode. Once you control the Kerbal, have him enter a spare pod, deorbit and land.

Hi, You can download the update either from Steam (if you have KSP on Steam), or the KSP website. I use Steam, so I'm not sure exactly how the KSP website option works. After the update, you will be able to load your old game, and KSP will update it to 0.24. As you're playing in career mode, the game will load it in the new career mode, including funds and reputation. If you would prefer to continue without funds and rep, just with science as in your current save, you can follow the steps here to convert the save into a ScienceTM mode save instead. Although the update won't affect your save files, if you want to back them up anyway (which isn't a bad idea), you need to copy the files and folders from C:\{Your KSP Folder}\saves\{Your save}\ to a safe location. That folder contains the persistent.sfs file (the most current state of your game world), and any quicksave files (also *.sfs) that you may have created. It also has two subfolders, Ships and Subassemblies, which hold your saved ships and subassemblies (fairly self-explanatory). Hope this helps.

Yes there is. Please look here.

Welcome to the forums The 'Entry Cost' is supposed to be the cost to unlock the part having unlocked the node with science. (Caveat: this is a widely held view in the community, but I've never seen anything from the devs to confirm that.) Currently, this cost isn't used, and the numbers are just placeholders, which may or may not be changed if unlock costs are ever implemented. It is unrelated to the actual purchase prices of the parts in the VAB. You can think of it as a 'prototyping cost' if you like.

You can fix this by going to the RnD Center and re-unlocking the individual parts. You have to click on the node (it will have a little green circle with the number of unlocked parts), and then click on the individual part. It will then ask you to confirm; click Yes and the the part is unlocked again. This is caused because the parts were moved into a different node from 0.23.5. Yes it is. Please see my tutorial on the subject here.

That's certainly how I did it. I will add how to do it if you loaded it first, but I needed something to eat before writing it. OP updated to include how to port a 0.24 Career save into a Science Mode save. Again, please let me know if this isn't 100% effective.

It can be a bit disconcerting to have Funds and Reputation suddenly imported into a 'Classic Science Mode' save. And it seems that the contracts may be set way above the ability of the available starting funds to complete. So here's how to import your 0.23.5 save into 0.24 in the new ScienceTM mode: If you haven't ever loaded the save in 0.24: Make a backup of the persistent.sfs file in the save folder (that has the same name as your save). Open the original persistent.sfs file. This is a text file, and can be opened in your text editor of choice. In Windows, Notepad is fine. The beginning of the file will look something like: GAME { version = 0.23.5 Title = YourSave (CAREER) Description = No description available. linkURL = linkCaption = Mode = 1 Status = 1 scene = 5 flag = Squad/Flags/YourFlag Change this to: GAME { version = 0.23.5 Title = YourSave (SCIENCE_SANDBOX) Description = No description available. linkURL = linkCaption = Mode = SCIENCE_SANDBOX Status = 1 scene = 5 flag = Squad/Flags/YourFlag Start KSP and load the save - it should appear as a science mode save (a beaker in a sandbox) rather than a career save (the familiar line graph) Go to the RnD center and check that all parts are unlocked in all nodes. If an unlocked node has locked parts, click on them to unlock them. This costs nothing. This should allow you to play on as normal. If you have loaded the save in 0.24 Make a backup of the persistent.sfs file in the save folder (that has the same name as your save). Open the original persistent.sfs file. This is a text file, and can be opened in your text editor of choice. In Windows, Notepad is fine. The beginning of the file will look something like: GAME { version = 0.24.0 Title = YourSave (CAREER) Description = No description available. linkURL = linkCaption = Mode = CAREER Status = 1 scene = 5 flag = Squad/Flags/YourFlag launchID = 1 Change this to: GAME { version = 0.24.0 Title = YourSave (SCIENCE_SANDBOX) Description = No description available. linkURL = linkCaption = Mode = SCIENCE_SANDBOX Status = 1 scene = 5 flag = Squad/Flags/YourFlag launchID = 1 Find the section of the file that starts: SCENARIO { name = ContractSystem scene = 7, 8, 5, 6, 9 Delete this section down to the final closing brace (}) before the next SCENARIO Find the section of the file that reads: SCENARIO { name = Funding scene = 7, 8, 5, 6, 9 funds = 10000 } Delete this section down to the final closing brace (}) before the next SCENARIO Find the section of the file that reads: SCENARIO { name = Reputation scene = 7, 8, 5, 6, 9 rep = 0 } Delete this section down to the final closing brace (}) before the next SCENARIO Start KSP and load the save - it should appear as a science mode save (a beaker in a sandbox) rather than a career save (the familiar line graph) Go to the RnD center and check that all parts are unlocked in all nodes. If an unlocked node has locked parts, click on them to unlock them. This costs nothing. This should allow you to play on as normal. I will update this if I discover any other tricks needed. Please feel free to ask for assistance if this doesn't work 100%.

Confirmed.

Awesome, that answers that. I was afraid it might be Kraken bait.

I found the video from the KSP Facebook page. I was watching it and thinking, "Huh, pretty cool," right up until the lander appeared in front of the house. Then I almost fell over laughing Great stuff, well done.

I will start a new Career save for 0.24, but my current 0.23.5 save will live on in ScienceTM mode.

I was wondering what would happen if I took a craft file from one save, and copied it to a different save where some of the parts used were not yet unlocked? Do I need to make sure I have all the needed parts unlocked before copying the file over? Will it crash the game if I attempt to load it? Or will it just fail to load but cause no big problems? The reason I ask is that I'm planning to start a new save in 0.24, but I'd like to keep the craft designs (or some of them, anyway) from my current career. The reason I ask here instead of trying it out myself is that I'm bored at work and can't play KSP on my work machine.

I was going to nuke my 0.23.5 career save and start over, but since ScienceTM mode is a thing I'm now going to port it over to that and play it when the fancy strikes.

I already design for no to minimal debris. Boost stages are and will be dropped and forgotten during the ascent. Upper stages are either decoupled prior to circularising and forgotten or, more often, equipped with probe cores and deorbited after. Currently I just crash these stages into the ground, but will probably put chutes on and recover in the future. Caveat - it's entirely possible that the cost of the chutes (after recovery) will exceed the recovery value of the spent stage, as most of the stage's initial value is in fuel, which will have been burned off. The biggest change for me will probably be my clean up missions, which rid LKO of debris left over from failed launches, where the above strategy didn't work. Currently these missions are grab, deorbit, destroy, but I will switch to grab, deorbit, recover by adding chutes to the clean up grabber ship. Edit to add: the other change is that I'll probably try to deorbit spent upper stages to land near KSC and maximise recovery potential, whereas now they get deorbited wherever they happen to be.

Does exiting the game completely (to desktop) and restarting help? I haven't experienced exactly the symptoms you describe, but I've had similar bugs (0.0 m/s orbital velocity / spinning altimeter) which do go away after a full restart. Also, are you using any mods at all?

A polar bear walks into a bar and says, "Barman, I'd like a ... ... beer." The barman says, "OK, but why the big pause?" A new prisoner is assigned to cell block six. After dinner that evening, the dozen or so prisoners from the block are sitting around chatting before lights out. Suddenly one of the prisoners calls out, "27," and they all (except the new guy) fall about laughing. One of the others responds, "31," and the laughter redoubles. The new guy, totally confused by this, turns to his neighbour and asks, "What's going on?" "Well, we're all lifers here, and we've all been inside for a long time already." "OK" "Everyone knows all the jokes, you see, so we just gave them numbers." "You mean, I can just call out a number, and everyone will laugh at the joke I made?" "Sure. Just give it a try." So the new guy clears his throat and calls out, "15!" Nothing happens; total silence. So he tries again; "24!" Again, no one laughs. So he turns back to his neighbour and asks, "Are those ones just not funny?" His neighbour looks at him and replies, "Nah, they're good ones, you just can't tell 'em right." There once was a Kerbal named Skite, Who would travel faster than light, He left home one day, In a relative way, And returned on the previous night.

Best thing about KSP? There is no wrong way

Well, having run some simple tests I can say that this definitely gives accurate times. Moreover, from the few simple tests I ran it looks like the navball's Estimated Burn indicator might use the simple F = ma derived estimation given by cantab above. More exhaustive testing may be needed, but for now this is answered.

Thanks for doing this. Very useful. If I me be so bold as to suggest an addition, a column for the synchronous orbits of each body (where they're valid) would be cool.

My guesstimates just consistently suck Specifically, I almost always underestimate how long it will take, leaving me with not enough time to burn 50% before the actual node. I didn't think of going back to Newton to get an estimate, to be honest, I just dived in with the rocket equation. Looking at the difference in the results, it's about 0.6% for a 100 m/s ÃŽâ€v, 6.5% for 1,000 m/s, and 9.9% for 1,500 m/s. So, at the very least, it's a great sanity check for my numbers. The difference also becomes more apparent with lower Isp engines (the above are for 800 s, they drop to 1.3%, 13.6%, and 20.9% for an Isp of 390 s). Ninja1: I have KER, which I will use to get the inputs for this. Ninja2: Yeah, I will test for accuracy when I get home this evening (unfortunately, I can't play KSP on my office PC )

I'm making a tool to calculate the estimated burn time for a maneuver, because I'm sick of KSP not telling me when I set up a maneuver node. I jump around between ships a lot, and also deorbit boost stages, so I often can't get a reasonable estimate from the maneuver planner. I'd just like to have someone check my understanding and my maths: Inputs will be the current mass (m0), the current stage Isp, the current stage thrust, and the required ÃŽâ€v of the maneuver. Start with the rocket equation: ÃŽâ€v = g0.Isp.ln(m0/m1) Rearrange to solve for m1: m1 = m0/e^(ÃŽâ€v/g0.Isp) Find the difference in mass: ÃŽâ€m = m0 - m1 The rate of consumption of reaction mass can be found by rearranging the formula for Isp: Ft = g0.Isp.mbar (Ft being thrust an mbar being the flow rate in kg/s) mbar = Ft/(g0.Isp) Finally, dividing the mass difference by the flow rate gives the time to consume that mass: t = ÃŽâ€m/mbar If my understanding is correct, that should give a reasonably accurate estimate of the burn time required. Any thoughts would be appreciated.

You always have to transfer experimental data manually, regardless of type, so it doesn't matter how (or even whether) your science lab is connected. You'll still need to EVA a Kerbal over to transfer and store the data. The good news is that the lab can hold more than one copy of a given experiment, unlike a command pod or lander can. So you can do a seismic scan (for example), take the data and store it in your lander can, then do another scan and leave the data in the scanner, and when you get back up to the orbital lab you can store both and return them, or process and transmit one and return the other. To clean goo canisters and material bays in order to reuse them, you will have to dock the lander to the lab, but, as mentioned above they don't need to be directly connected.

Try F4 to toggle labels, I think.

I think one of the best explanations/demonstrations I've seen for the Oberth effect involved fixed ÃŽâ€v burns at different altitude periapsides above an object on a hyperbolic orbit. I can't remember where I saw it, though (it may not even have been KSP related. I think it could be duplicated by setting the periapsis to differing heights on SOI entry around a body (Tylo might be a good choice in KSP), and then showing the differing results of burning for 500 m/s (or whatever) at those different altitudes/velocities. It becomes clear very soon that it costs much less ÃŽâ€v to capture/circularise at a lower periapsis (i.e. greater velocity) than at a higher one.

I like Minmus; it's so forgiving. Seriously, with a half-decent ship you can screw up your insertion, deorbit, landing approach and landing, and still get away with it. Mun, on the other hand, is a lumpy, evil b@$tard that eats landers.