THX1138

I have a contract to measure temperature at various places on or above Gilly. Contract says above 5800 m. I'm at 6630 m and it says the temperature scan can't be done right now. Is this a bug or am I doing it wrong? "Above 5800 m" isn't very helpful; 2E99 m is above 5800 m.

+1. I need to conserve my monopropellant for translation so need to limit SAS system to reaction wheels only. It's troublesome to have to keep switching RCS and SAS on and off to stop the SAS system dipping into my precious monopropellant. [Making a new thread is not appropriate because that would make the suggestion seem like it has less support than it does.]

Notice that this thruster appears to be below the surface of this fuel tank. For this reason I avoided the issue by placing thrusters at 45 degrees but this seems to make them less efficient. Is this problem only aesthetic or does it affect the function of the thruster?

I'm trying to dock a second vessel to an asteroid. [irrelevant detail: the first ship has a lot of fuel and was designed to push the asteroid. The second ship has little fuel and arrived later to pull following instability encountered in the first attempt]. I start translation and to avoid waiting 20 minutes I increase the time speed. When I exit the time warp, the ship which is already docked to the asteroid slams into it and is either detached from its klaw or detonates and sends the asteroid hurtling into the second ship. Is there no way of doing time warp without screwing up things like this?

I have a limited amount of monopropellant which I want to reserve for translation. I want the attitude to be controlled using reaction wheels since the electrical supply is renewable. I want SAS to control the attitude while I translate using my limited monopropellant supply. I don't want SAS dipping into my monopropellant supply when the electrically powered reaction wheels should be adequate. Am I alone in this? Currently I have to switch off SAS, switch on RCS, do some quick bursts, switch off RCS, switch on SAS; repeat x 50. Is there some way to cut off SAS' access to the RCS system?

Not sure there's much point in keeping a science spreadsheet. I've done only a fraction and I've already opened the entire tech tree.

Is there any possibility of using an smartphone or tablet as a sort of custom control peripheral?

That exploit is finnicky. Sometimes coming out of time warm imparts a seemingly random direction to my vessel which is not conducive to the precision I need for docking.

How much time do you spend alt+tabbed out-of-game, waiting for e.g. a burn or SAS-guided reorientation?

The SAS on my heavy ships overshoots its target and I have to alt+tab out of the game and leave it oscillating for 20+ minutes. It's because the SAS is stupid and doesn't start countering the movement until it's way too late. In fact, it keeps tugging and tugging until it's too late and then it starts tugging the other way. I could do a better job myself but boy is it boring. I'd rather play a truck driving simulation. It's fine if all your ship is small but mine isn't. I shouldn't have to launch unreasonable amounts of RCS propellant or reaction wheels to counter badly programmed SAS that doesn't take into account the power of available reaction wheels.

The reaction wheels use only electricity with is unlimited with solar panels. The RCS and fuel-powered engines do not have this advantage. I need bigger reaction wheels.

Apparently you can zoom into the navball in a manned craft by activating IVA. My craft is unmanned (ejection of asteroid from solar orbit) but I also need to precisely align my craft to the centre of mass of an asteroid so I need to zoom into the navball. Is that possible?

Is it a good thing or a bad thing that I can transfer fuel between tanks via an asteroid? (those are two separate vessels)

I'm not sure what the difficulty is. Could you post a screenshot of the rocket that spins around?

I would really appreciate bigger rocket boosters to spend my science points on! This would have the very welcome benefit of reducing lag due to firing 80 SRBs at the same time in the first stage of heavy launches.

When clicking and dragging staging items around in the VAB, parts of the craft being designed are also selected and dragged which is undesirable. No-one could ever find this useful. Please prevent that. Also, please eliminate the overlap of the staging options and the exit VAB button. Thanks.

Thanks, I guess this is indeed a bug. Closing KSP and loading again eliminated the bug, at least for now. What do you mean by ETA, TerminalV? I'm guessing you don't mean estimated time of arrival. I do have two claws on this craft. I'm not even sure why! :/ Could I get this thread moved to the support forum? Thanks!

This shouldn't be too difficult once you know a few pointers. Right click on your target and select "set as target". You need to decide whether you're letting the target catch up with you or you're catching up with the target. Whomever has the smallest orbit will be orbiting faster and doing the catching up. By watching you craft and target orbit in time warp, you'll get an idea of when an encounter is coming up. When an encounter is about one or two orbits away, adjust your orbit so that the difference between your orbit and the target orbit is smaller. This will reduce the rate of catch up and allow you to more finely tune the encounter. When your target is less than 10 km away adjust your prograde marker so that it aligns with your target marker. Accomplish this by burning on the opposite side of the target marker (compared to your prograde marker). Click on your speed indicator to change it to target speed (the speed of you relative to your target). You need to get this to zero by the time you have completed your rendezvous. If you do this too early, you'll make the whole procedure take longer than necessary. You will shed this speed by burning retrograde. As you near your target, small deviations between your prograde and target marker will become more obvious. By the time you'll actually be more interested in your retrograde and anti-target marker. Bring your anti-target marker into alignment with your retrograde marker by burning on the opposite side of the anti-target marker (compared to the retrograde marker) - note that this is the opposite strategy to getting the prograde and target markers into alignment. Failure to get your relative speed to approx 0 m/s is why you had the target rush past you earlier. By hovering your cursor over target, you will get an indication of the separation between you and you can use this to inform an appropriate relative speed between you and the target.

I've been forced to make an odd craft to drag an asteroid out of Sol orbit. I don't expect a ship to survive a launch in time warp (although that would be nice) but it's normally okay once I'm out of the atmosphere. When I initiate time warp on this craft, the sudden freezing of its attitude (I hope I'm using terminology correctly) shakes the ship apart. The attitude is hardly even changing when I start the time warp so basically this ship is unusable. Has anyone else experienced this? It doesn't even make much sense to me that the Probodobodyne core detaches from the RCS tank. Is there some quick fix? I spent a few hours putting it together and getting it in orbit Save file is here if anyone wants to try it themselves. The save should load on the craft in question (called Class E asteroid ejection craft IV). Output log KSP 0.9, as updated by Steam. OS: Win 7 64-bit Mainboard: Gigabyte GA 790FXTA-UD5 CPU: AMD Phenom II 965 X4 RAM: OCZ Black Ed 2x2GB DDR3-1600 + Corsair 2x2GB DDR3-1600 Graphics: Sapphire HD 5770 1GB GDDR5 x2 DVDRW : LG-GSA-4167B Sys Drive: OCZ Vertex 2, 60 GB Data Drives: PSU: Thermaltake 705w / 700W +3.3V 30A = +5V 28A = 4x +12V 18A

I think I made a mistake. I think the change in orbit I was seeing was due to the oscillation of my craft attached to the asteroid. I have a strange problem. I've had a bad time trying to push a class E asteroid out of solar orbit - I was forced to leave the rocket at no more than 10% thrust (prograde) to prevent it spinning and I left it minimised like that for about eight hours. When I came back I found that the opposite side of the orbit is getting smaller not larger! Worse still, it carries on doing it after I switch off the thrust! The orbit is changing even though no forces are being applied! Save file Output log OS: Win 7 64-bit Mainboard: Gigabyte GA 790FXTA-UD5 CPU: AMD Phenom II 965 X4 RAM: OCZ Black Ed 2x2GB DDR3-1600 + Corsair 2x2GB DDR3-1600 Graphics: Sapphire HD 5770 1GB GDDR5 x2 DVDRW : LG-GSA-4167B Sys Drive: OCZ Vertex 2, 60 GB Data Drives: PSU: Thermaltake 705w / 700W +3.3V 30A = +5V 28A = 4x +12V 18A KSP 0.9, as updated by Steam

So no-one feels any obligation to the organisations who paid for the contract then?

The work around to this bug seems to beget another bug! After cutting the flow of xenon the batteries start charging which is good. What's not so good is that SAS is now broken. I can turn the SAS light on and off but the little options (regular SAS, prograde, retrograde) don't appear and SAS is completely ineffective. The reaction wheel responds to manual control. Switching to another craft and back again fixes it.

What do you with satellites etc after you've satisfied the contract? Name it and leave it there? Send it off to collect science data you need? Self-destruct?

The contract descriptions should be completely cut because they're unreadable nonsense. None-native-English-speakers may not even realise that they're nonsense and waste time struggling to comprehend them. My first language is English and I still wasted my time trying to parse a few before I realised they were meaningless. I'm not certain whether this is what the OP is talking about though.

What? Eight SRBs aren't going to lift anything I'd call heavy. I've got to move a class E asteroid out of the solar system. That's heavy (the rocket, not the asteroid although obviously the asteroid is also massive).