Wemb

So, I've got a science station in orbit round the Mun, and a little probe-based lander going down and collecting Science. Rather than sending a capsule based lander up, If I get an engineer to attach a ladder using KAS, can I ride Bob down to the surface as a passenger to do a soil sample and leave a flag behind? Thanks

The answer is not much , but it's probably more than you think - the reason being that while the mun has no atmosphere a very slow ascent with a TWR of near to one will not necessarily be less efficient than using a higher power engine since because there is no atmosphere, you don't need to do it quickly - BUT landing definitely is time bound - you need enough time to reduce horizontal speed and reduce vertical speed at the same time (in most scenarios), and you also need to time to spare and time to recover from unexpected mountains. For all I know (not much) this could be one of the reasons why it was beneficial for the real Lunar Module to use a separate lander and ascent stages (though there were plenty of other reasons, mostly weight and reliability issues, I bet, that were probably more important) Wemb

Today I learned that with RemoteTech installed, a Solar eclipse just before you start re-entry is a very scary thing indeed. Wemb

The straight up and turn left approach isn't a good idea, hardly ever - and while trying to do a perfect gravity turn is an 'advanced' technique, you should be able to manage a fair approximation. Instead of sticking to the prograde dead one when you get to ~45 deg at ~15km, I'd hold at a bit above your prograde on the rest of the journey. Keep an eye on the map view and cut your engines when your Ap gets out of the atmosphere (70km) and then coast with the engines off till you get to the Ap before lighting them up again to circularise. Hopefully this way you'll come up with a good compromise between a very flat trajectory at the apex of your flight, and a straight-up trajectory. You might find it helpful to put on KER or MJ so you can see your Ap and time to Ap during the flight. If you do this, after you get to ~45 deg at ~15km, try and aim to keep your ToA at about 45-sec to 1min, too much higher than that you may reach the Ap before your leave the atmosphere, too low and too low and you'll reach your Ap before you get a change to gain enough horizontal velocity. That should get you into orbit fairly smoothly. Wemb

One thing which might help illuminate why logarithms are a thing at all is that as well as being incredibly fundamental in calculations involving rates of change growth - they are also tremendously useful in simplifying manual arithmetic - and this was why they were first developed and investigated. Imagine you want to multiple two large numbers togther - 4324924823 x 6575676575 - this is a farily horrible and time consuming job if you don't have a calculator or computer (or, if you existed before they were invented). However, one of the rules that govern how logarithms work is that log (x) + log(y) = log (xy) So that if you had a compiled table of logs and their inverses, you could easily perform otherwise very long-winded mulitplications by simply looking up a couple of numbers from a table, adding them together and looking up the result in a second table. And, if you're using logs to the base 10, rather than the natural log, you don't have to worry about the decimal places till to the end, and that's also a trivial exercise in adding. Slide rules allow you do to the simialr, but in a somewhat more flexible way. This facility is why the exams I did in the late1980s and early 1990's still had printed log tables in the back of the formula book for those without calculators, or where calculators were not allowed. Wemb.

This is what I love about this game and this community - you just don't get lessons on arithmetic like this on Call of Duty forums. Wemb

Sure - and it's about the simplest thing you can design, since it'll never go near an atmosphere so you don't need to worry about aerodynamics and the TWR is vastly less of a consideration. Just pop a probe core with a docking port, a solar panel (probably), and some RCS - probably a lot if it's a fuel tanker - on the tank of your choice and you're done. Main consideration will be what engine you choose - obviously, a high vacuum ISP engine is best, but don't worry about the TWR too much - as long as it can accelerate/decelerate quickly enough to do the necessary rendezvous and docking manoeuvres you'll be okay. If you want a truly massive tanker with the highest possible fraction of fuel capacity to weight, you could, in theory, have a very low TWR and use tugs based at the station to do the capture and docking, though this may be more trouble than it's worth. Getting it into space, is an exercise for the OP - but note you can empty a fuel tank in the VAB if you don't need to carry it to space loaded. Wemb

I'm struggling in my head to decide if the rotation of Kerbin needs to be taken into account with regard to what the navball is 'pointing at'. You'd see different results if it's orbit vs. surface mode, no? Wemb

This - there's nothing stopping you flying two missions - one to stop him crashing and the other to bring him home. Wemb

My view? Same as Chris Kraft's mostly... See this clip from 'From the Earth to the Moon' - you're yet to do docking and rendevouz, get to grips with the dV maps and build your rockets to requirements so you don't run out of fuel after landing, and keep on doing it over and over till it's easy. Then head for the planets :-) Good luck, and godspeed. https://www.youtube.com/watch?v=xZVe8N5uICI Wemb

One thing I really want to explore is some properly automated launches that don't rely on MJ. I want, at some point, to fly a missions to dock at my orbiting station and do it entirely from within the IVA view with the games main GUI turned off via the F2 key. It should be possible to do this using MJ (for it's SmartASS) coupled to the RasterPropMonitor MFD displays. The one element that's missing is a sensible way to launch this. I could wing it from the navball, but my goal will be to do the launch with kOS. kOS isn't something I've remotely looked into yet, but it sounds interesting and would add a whole new interface to the game, rather than extending the game outwards with more planets, it'd provide me with an entirely new mechanic, and set of challenges, for handing even the simple stuff. Wemb

Not in the strictest sense, no. The problem comes if you get any sort of off-axis translation when you're trying to dock - and if your vessels are moving in circles round planets, this is quite likely. Correcting for this with a reaction wheel and main engine isn't so much difficult as very time consuming and unwieldy as it requires you rotate the entire ship in the opposite direction of the drift and then burn to correct and then turn back to the target. Attempting to do this when you're 10 seconds from a docking is almost certain to be disastrous in some way. Wemb

You'll eventually hit other issues with certificates as well as games that start to use newer frameworks and runtimes - I'm afraid it really is time to consider changing to or upgrade your OS to something supported. Wemb

As the others have said - It's designed (invented) for fine control of translation and rotation that generally cannot be done, or be done easily, with the main engine. It's principal application is for assisting with docking where extremely accurate control of attitude and velocity is vital, but it can be used to help in many other areas such as landing, launch stability, or even to replace a main engine if needed. This is a brilliant video of the Soyuz TMA-19M mission to the ISS last year where the automatic docking failed and had to be done manually by the commander. you can see at ~3:50 onward the RCS thrusters on the soyuz capsule firing to help keep the capsule aligned in the right direction for docking, and at 4:35 firing to reverse the capsule and back away from the ISS. Wemb

What he said. The only way you could have something that looks like an exception would be if the planet had it's centre of gravity somewhere other than at it's geometric centre and while that happens in a tiny degree IRL, I don't believe it happens in KSP. Wemb

How you dock is dependant on how you fly your ship, of course, but as much as that is dependant on your skill, it's arguably just as dependant on your design - have a ship where the CoM doesn't lie on the CoT, and you're in trouble. Equally putting the RCS thruster blocks in poorly chosen places can also be disastrous when docking. One thing which will help you is to ensure you have 'Fine Control' (Caps Lock) turned on - this balances the thrust levels on your RCS to ensure you rotations don't turn into translations and visa-versa if your CoM isn't exactly at the center of your CoT from the RCS system. Also Docking Port Alignment Indicator mod is a must-have for me. Wemb

This is true, but I find the time taken to actuall process the data so slow, and for some reason, I object to cranking up the warp to high speed to generate science - therefore, since you can get enough science to max out the tech tree pretty easily with a few trips to Minmus, I've often not bothered. Or, if I have, I've filled up a science lab and then maxed out the tech tree before the lab has been close to finishing processing even a small portion of the on board science. Some sort of requirement to deal with the science in the lab, or even, perhaps, different flavours of science data points could be used to more strongly encourage a science infrastructure - that lab, in most cases, is largely cosmetic. Wemb

Yeah, well, it's not exactly rocket science, is it? Ah, no, wait... Wemb

Ahh, shame - last time I went through this I got a ton of sub-orbital tourist flights which were very cheap and easy to pull off - and was able to generate a ton of cash that way before going orbital.. Perhaps concentrate on satellite launches for now? Or, go to the admin building and cash-in some reputation? Wemb

Well, firstly, design your rocket so it looks like other things that fly like that - i.e. arrows and darts. You put the heavy stuff at the pointy end, and put the fins/winglets at the back. As for the rocket going 'boom' on the pad, this shouldn't ever happen unless you've done something very odd indeed with parts that aren't properly secured, or unless you're firing an engine that's somewhere in the middle of your rocket, rather than just the bottom stage - check your staging. The pitching and yawing can be caused by several things - as I said, putting fins on the top of the rocket instead of the bottom won't help. Also, flying with no fins or insufficient fins will do this. Also, flying too fast too soon can do this - don't accelerate too quickly low in the atmosphere - this will cause an instability to get worse, not better. Finally, keep your rocket pointed toward the prograde marker as much as possible when you fly through air - the more 'off-target' your point the rocket, the more likely it will be to go out of control. Try keeping, as much as possible, the rocket pointing in the same direction as it's travelling. Sure you need to steer it, but small gentle corrections, not big turns. Good luck! Wemb

Wow, okay, I think the answer to all of your points in 2 can generally be summed up with the words 'because they're curves not straight lines'. Two curves crossing each other will have two points of intersection, hence two pairs of intercept markers. They move around so much because when you burn in a straight line by a constant amount, the resulting changes in the intersection of the two curves will chang in a non-linear way. This also answers point 'c'. For 'd' - use the manoeuvre node marker when you want to execute a manoeuvre. The pink target marker is just the direction your target is in - and does not automatically have any particular relevance to whatever manoeuvre you're trying to do. In short, it's very hard to describe exactly what any particular manoeuvre will do to an intercept without a computer - your best bet, till it becomes more intuitive, is to set a manoeuvre a considerable time away to give you the space needed to fiddle and tweak the node till your resultant intercept is as close as possible. Do not expect to see a linear relationship between changes in the nodes and the effect on the intercept - you won't. Small changes and tweaks and using the Mk1 eyeball is the way to go. Eventually you'll stumble upon a nice, close intercept. Once you've got it a good intercept, just wait till your vessel gets to that point in space, then forget about manoeuvre nodes and intercepts - just get into target mode, zero your relative velocity. Then you've achieved your rendezvous and you can begin the process of a close approach for docking. Good luck, and remember, not even the crew of Gemini IV got this s*** right the first time - took Dr Buzz Aldrin to write the book (literally) on rendezvous before NASA got it done. Wemb

You know what this makes me want to try? Landing a really lightweight lander on Minmus, having some wheels on it, and getting out and pushing it to the next biome. Sure, I could use solar panels, but where's the fun in that? Wemb

I hesitate to say this, because it goes against what you're trying to do - but if it's really, really difficult to pull off due to the limited number of parts you have, you may simply need to bite the bullet and accept this is the point in the game where you should upgrade the VAB? Wemb

Yes, what Jedensusch says. It's not really helpful to describe it as a measure of speed at all. It's related of course, but that's about as far as you can say. The nearest analogue in normal experience might be the 'range' measure found on modern car computers that will recalculate how far you can go on the available amount of current fuel in the vehicle and the speed at which you're moving. The situation, in space, is of course completely different - you won't slow down due to friction and gravity may be changing depending on where you go - but because changing _any_ aspect of your trajectory requires you to change your velocity and because the amount needed to do this is not dependant on your total mass, you can describe_any_ journey of _any_ rocket as a the sum of the velocity changes needed to perform the various maneouvers needed (e..g this much velocity ot get into orbit, this much to circularise, this much to transfer to the Mun, this much to circularise around the Mun, this much to come back, etc. and use the value to plan a 'budget' for building your rocket. It also means you can use charts like this to also help plan your mission, and associated tools (mods) for KSP to tell you how much dV your rocket has. Good luck! Wemb What he said! Also: Wemb

Ah, okay, you're making up new meanings to words - that's cool, language evolves, but that probably isn't going to help anyone else understand what you're talking about. Asparagus, used elsewhere in KSP, is derived from the physical resemblance of a rocket with multiple strap-on stages to a bundle of asparagus spears (see the vegetable's wikipedia page). Using it to describe what you have is pretty obscure and will probably just confuse everyone. Anyway, I've certrainly not sat down and compared the behaviour of the 32-bit to the 64-bit version for given scenarios. Having said that, I've not seen any horrible shocks to re-entries when I switched ot the 64-bit prerelease a few weeks ago. So I'm not sure what's going on here. I would suggest backing up your current install, and re-installing KSP into an entirely clean folder (so no left-over bits of mods, etc.) and trying your experiment again - if you still see this, you should file a bug report at http://bugs.kerbalspaceprogram.com/ Good luck, Wemb