Plusck

Yeah as Snark has pointed out I was being somewhat stupid earlier, confusing issues with science reports and bays... To get science out of the materials bay, right-click on it when your kerbal is close. If close enough you'll get a "take data" button. Unfortunately it has to be pretty close for the materials bay. Since your kerbal is not a scientist, you'll get a warning that it will be unusable after that. Then when you get back in the pod it'll be added automatically (saying "deleted" from the Kerbal and "added" to the pod). You can also click on the pod from EVA and there will be "store experiments" button which does the same thing. You should do this often on EVAs to get multiple temperature and pressure reports (once unlocked) from different biomes.

[quote name='Snark']I disagree with this-- I'd advise the OP to circularize (very low, like 12 km). The dV difference between "circularize at 12 km, then another burn to go home" versus "do a direct burn from the surface" will be negligible-- Minmus gravity is pretty darn low. Whereas if the OP circularizes first, it's much easier to take time to carefully set up just the right maneuver node, as opposed to trying to do it all in a hurry during a burn. My guess is that taking the time to get the maneuver node just right will more than make up for whatever small difference in dV it makes over a direct burn.[/QUOTE] Hmm. I'll accept the principle but at the stage the OP is at, will ultra-fine-tuned nodes be doable? [quote name='Snark']From the screenshot, it looks like he's got a heatshield directly under his command pod, with a decoupler below that. So he ought to be fine. Return from Minmus is no problem if you have a heat shield.[/QUOTE] True, but I'm supposing that the materials science suite thingy is meant to be going back too. So it comes down to a choice between a 30-32km quick return and loss of science points, or a higher science return and a number of grindy non-warpable passes through the upper atmosphere.

Agreed with everything said here except two things: Forget about circularising your orbit - you'll simply waste a few precious delta-V and if you are that tight it could make all the difference. And periapsis at 30km with that setup might be unmanageable. No circularising: You want to burn prograde at more-or-less exactly the point shown on Reactordrone's pics. If you are somewhere on the surface just west of there, simply prod the craft skywards then burn due east and level at max throttle until you have a very low suborbital arc that gives you time to plot your exit at Ap. Any distance you put between yourself and Minmus before burning back into Kerbin's SOI is a waste. You're already at over 5000m so most of the moon is lower than you anyway. Periapsis at 30km: The main problem that I see is your chutes. Heading back for a touchdown on the first pass back from Minmus is hot. I've tried but have always given up trying to get back with anything still attached under my pod (I'm sure I managed a materials suite thingy once or twice, but not an empty fuel tank). So quicksave before you lower your periapsis below about 40km, because you might find that you need to do several high passes to bleed off speed before you can survive reentry. It's a grind, I know.

The ISS has an orbital speed of just over 7600 m/s and an orbital period of just under 93 minutes, meaning that its orbital path is almost exactly 42,600 km long. Fire your arrow at exactly 90° to prograde, and it'll whizz back past you every 41,5 minutes in the opposite direction. Any other angle and it will do the same - but coming in above and below you and/or side to side in front or behind you - at a slightly slower frequency depending on how close to pro/retrograde you shoot. With a perfect normal or anti-normal shot, this means that the speed of the arrow relative to the ISS will start at 100m/s (say) and drop to 0m/s after 21.25 minutes, a quarter of the way around the orbit. I'm not sure of my maths here but I think that suggests the maximum distance from the ISS it can reach is 79.2 km. A perfect radial / anti-radial shot will end up being below and ahead, or above and behind, after a quarter orbit, but again a maximum distance of 79.2 km. Which suggests that you'd need to get your arrow firing at around 1000m/s to have a hope of getting it below LEO. Also, an exact prograde or retrograde shot will be 1/76th slower or faster than you, so that suggests you'll have to wait 76 orbits for it to be back on a collision course - by which time it'll have travelled over 30 million km...

I think it's perfectly realistic that large stacks of short flat parts start to wobble as soon as you start changing direction, since the rocket gimbal at one end and the reaction wheels on the other each have lots of joints to get passed through before they can affect the momentum of the parts in the middle. Fixing this with a mod is kinda an easy way out. Also, drag can have a massive influence on wobbliness. The general consensus is that drag needs to be sorted, but again it's possible to design away most problems or work around them. [quote name='A_name']ITT: A bunch of people saying OP is designing and/or flying his rocket wrong, but not bothering to explain WHY or what would be the "CORRECT" way to do it. Just install KJR.[/QUOTE] And OP hasn't posted a pic of the rocket in question, so it's hard to be more specific than all the answers already given, which are: 1. Lower gimbal 2. Use longer single parts 3. Move the "control from here" part you are using down the stack if possible 4. Use smaller reaction wheels, perhaps radially attached 5. Use struts. What else? 6. Check connections if using a tricoupler - parts can appear to be connected together but in fact not be. 7. SWITCH SAS OFF before making any movements. Move gently. Wait for stability. Switch on again. 8. Similar (or in conjunction with) the previous point, use custom action groups to toggle engine gimbal. Since your reaction wheels are generally close to your pod, SAS will think you have changed direction before the rest of the craft has straightened, but this will just cause a mangeable bend as long as the engine is not inducing a bend in the opposite direction at the same time. 9. Slow down below 15-18,000m. Drag effects will only exacerbate wobbliness. Try sticking to 140m/s under 8-10,000m and 180m/s under 13-15,000m. Yes it is inefficient but if your payload is the main reason you have so many stacked parts, that's just part of the cost of that payload.

I have no real idea how your physics system works, so I have no idea how possible this would be. However one area of minor frustration with the game is that there is no way to save hugely expensive bits of rocket that we jettison on the way up. Attaching parachutes fails because when too far away from the main rocket they are simply treated as "burning up in atmosphere". So would it possible to make an exception, to make recovery of our most expensive kit possible? I'm sure coding the system to retain "real" physics for objects out of range would be impractical. But might it be relatively simple to have an exception to the "burning up in atmosphere" treatment, e.g. by testing for deployed parachutes + current airspeed, checking whether this allows for a touchdown / splashdown, then applying a % recovery value to the object (even if this means cheating and placing it immediately on the surface as far as the tracking station is concerned)? My apologies if this has been suggested before...

Yes, that worked! Sorry, I could have sworn I'd downloaded the most recent 1.0.5 version.

If there is any kind of galactic civilisation out there, I'm pretty sure they'd consider the launch of a Von Neumann probe to be a heinous crime. One of the worst kinds of deliberate pollution of the interstellar environment and utterly immoral by what has to be the single truly cross-civilisational ethical standard: don't do to others what you don't want done to yourself (or even the amoral watered-down version of the principle: don't do to others what you couldn't deal with if they tried it on you).

I'm having exactly the same problem on 1.0.5. - I built a new lab, parked it in 110km orbit and it never ticked off the "near Kerbin" condition of the contract. I then decided to put the same lab down on the Mun for a second contract, and it doesn't recognise being "near the Mun" This is a quicksave from that time (mac os, build 01024): quicksave about to give up on the lab

1.0.4 - Build id 00861 / OSX 10.6.8 / direct download install, unmodded Two connected bugs on my system. 1) Clicking on the crew hatch does nothing - no option to transfer or EVA crew. All right clicks and alt-right clicks work fine. 2) Clicking on one of the buttons of a science / crew / EVA report will click through to the crew hatch viewed behind. 2b) Mouse hover will always show "crew hatch", no matter what is blocking the view. Screenshots: The in-game screenshot doesn't show everything that is actually visible with mouse hover, oddly ("keep data" is visible, but not "crew hatch"): A Finder screenshot, however, does (even though KSP does not have focus). If I click the button, the "Transfer / EVA" window will pop up. So far this is the ONLY way I can get the window to pop up. So bug No. 2 is absolutely essential as a workaround to bug No.1. Finally, I know this is an old version of OSX and I should update etc. Trouble is it's the last OS to include PPC software support and the transition to all-intel software will be painful, so I'm sure I'm not the only one who 'needs' to keep 10.6.8. Am I the only one to suffer this problem? Is there any kind of possible OS-level fix?

Yeah, it was stupid to restart before finding the logs. Is a quicksave good enough? This was what I went back to after posting the thread: trying to recover a mucked-up Mun outpost contract with more fuel. After completing that contract, I accepted an easy 10-person Minmus orbit contract (no lab or fuel or anything required) and unlocked a bunch of Mk2 fuselage bits for it. It was while on the outward leg to Minmus that I switched to another ship from the map screen. Going back to the Mk2 ship/plane, I noticed that my credits weren't visible. This actually happens quite a lot - I have the impression it happens if you switch out to another vehicle while still able to revert the flight - so I didn't realise there was a problem until the contract completion message failed to appear.

Oh sorry - I forgot to give the details: Build id 00861 / OSX 10.6.8 / First install, no mods (but I previously tried the old demo in 2013 and the newest demo last month) / player log here but I relaunched the game after losing the contracts.

Hi, this is getting to be a game-breaker. After trying something new, all active contracts simply disappear. This means I keep the advances from the previous 10 accepted active contracts, but I had a few I was working hard on and it kinda ruins the fun :/ This is the third time it happened, just now. I quit immediately and I've tried looking for the "logs" since I saw a request for something like that in another thread, but can't see where they might be. My speculation: it is the fact of entering into a new area of game-play that triggers the generation of a new type of contract. For example, first time contracts disappeared: I had been to Minmus a couple of times, then decided to send a probe out towards Duna. So for the first time I was actually controlling a spacecraft outside Kerbins SOI. As soon as I went back to the space centre, all active contracts had disappeared, but now I got contracts about exploring other planets (rather than the stock "fly by Duna" which came up very early on with no expiry date). Second time: I had just acquired drilling tech and sent a drill ship up to Minmus. Back at the space centre all contracts had disappeared, but now I had new ones offered such as hauling ore from the Mun. This last time: I tried out Mk2 fuselages for the first time - sent to Minmus to complete an easy contract. Lack of a "mission accomplished" message implied all was not well. However, although all active contracts have disappeared I don't see any significant change in the offered contracts.