Pecan

NICE idea! :-) Are we allowed, or even meant, to peek at the challenges now or do we have to wait for each specific day?

KOS (scriptable autopilot) is the usual way to control things when you're using RT. I have to say though I think you're making the 'background' KSP much more difficult than it has to be. Good luck, in any case.

Yes, there is no problem with launching payloads with empty tanks. All you have to do is right-click the tanks and adjust the amount of fuel in the VAB/SPH.

LV-N or 48-7S for the transfer, 48-7S or LV-1/LV-1R for the lander, LV-1/LV-1R for the probe, if you take it. Spaceplanes are very inefficient (except for Kerbin and Laythe landings) and rovers almost completely useless so leave them off.

Using the NavballDockingAlignmentIndicator be aware that although it accounts for off-axis placement of the target port it does not account for the position of the controlled one. In the OP images it therefore wouldn't help very much. Although it's based on NavyFish's he has updated that since and this may be corrected in the full version.

Almost the only mod that provides servos, hinges and other moving parts is Infernal Robotics

Solar System: Mods provide other systems but not stock. "Self-sufficient" is dead easy because no supplies are required, unless you add life-support mods or similar. Facing: There's no problem with setting a station or whatever orbiting the sun perpendicular to the planetary plane (although some planets are in inclined orbits anyway), except that you have to make sure it isn't at a planetary-orbit altitude or it might 'accidentally' encounter it, 'with hilarious results'. KSP does not model multi-body physics (again, unless you install an appropriate mod) so once in orbit around the sun something will stay there unless it enters the Sphere of Influence (SoI) of one of the planets by approach too closely. You won't be able to keep the windows facing the sun though as a vessel's rotation is not tracked unless you're actually controlling it. When you switch back to the space centre or another ship your station will just keep facing the same way so, half an orbit later, will be staring away from the sun instead of towards it. Maths: there are two equations that are really important to rocket design. Thrust to Weight Ratio (TWR): dead easy, it's the total maximum thrust of your active engines divided by the mass of your ship. The higher the number the faster you can accelerate (change velocity). Most importantly, if it's below 1 you won't be able to lift-off from the launchpad. Ideal launch TWR is generally considered to be 1.2 - 2, lower means you spend more energy fighting gravity (getting up), higher means you spend more fighting atmospheric drag (getting fast). Increase TWR by using more, or more powerful, engines or by reducing the mass of your ship. deltaV (dV): bit harder, it's the amount by which your engines can change your velocity vector - the speed and direction in which you're travelling. With 1,000m/s dV from rest you can accelerate to 1,000m/s in any direction (assuming there isn't anything in the way!) or accelerate to 500m/s, flip the ship around and 'accelerate' in the opposite direction back to 0m/s, for instance. Your deltaV depends on the fuel-efficiency of your engine(s), the amount of fuel available and the mass of your ship. You need about 4,500m/s deltaV to launch into orbit from Kerbin. Increase deltaV by using more efficient engines, adding fuel or reducing the mass of your ship. deltaV is calculated using the rocket equation, dV = (Isp * G) * LN(wet_mass / dry_mass) (wet_mass being the total mass of the whole ship including fuel and dry_mass being after all the fuel is burnt). Breaking it down: (wet_mass / dry_mass): means the greater proportion of the rocket which is available fuel the better LN(wet_mass / dry_mass): LN() is the natural logarithm function meaning there are diminishing returns to just adding fuel to improve the figure in 1. because it takes fuel to lift fuel (Isp * G): G is gravity and either 9.81 or 9.82 in KSP, I can never remember (see below). Isp is engine efficiency 3. times 4.: more efficient engines with more fuel available (up to a limit) go further Soooo - there are a few numbers you need to know before you can work out TWR and dV. Engine Isp and thrust can be seen in the part descriptions in the VAB/SPH. Each part's mass is also given there but to get the total you'll either have to add them all up or 'launch' to go to flight mode, press 'm' for the map view and click the 'i'nformation button on the right of the screen - that's the only place KSP shows ship mass. To get the figure without fuel (so you can work out dV) you'll need to subtract the mass of the fuel within the tanks, but not the mass of the empty tank itself, or launch with empty tanks and check 'i'nformation again. Every time you add or remove a part you'll have to re-calculate mass, TWR and deltaV. It's a right pain, in other words. Do yourself a favour and install either the Kerbal Engineer Redux (KER) or MechJeb (MJ) mod. These will both show you everything you need to know in the VAB/SPH as you build. First simple facts and figures to remember - you want a launch TWR of 1.5 and 4,500m/s deltaV. It's a lot easier with mods, Squad think we should have to work hard/crash a lot before getting into space. ...units of fuel...: You'll realise from the above that that doesn't tell you anything about TWR and deltaV (the important performance figures) unless you also know its mass. Shooting it into space won't be an option once all the fuel has run out because ... you won't have any fuel! Sandbox: The tutorial in my signature is all about sandbox mission and vehicle design ;-)

Rovers are generally not very useful but if you want to drive around a bit the simplest way is to put wheels on your landers. In your picture, for instance, that thing would land on the legs. Instead of dropping/disconnecting the rover just retract the legs and it will settle onto the wheels. Now you can drive around. (That particular one would be top-heavy but then it's a very big lander. You get the idea, anyway).

The advantages of Career/science modes are i) that they initially only provide a very few parts, so there isn't any confusion about which engine, etc. to use, ii) you have to get science points to unlock new parts and, in career mode, fulfill contracts for money to pay for everything. This makes it easier for new players to choose how to construct ships and gives anyone a reason to progress. The disadvantages of Career/science modes are i) starting with manned flights, ii) having to care about science points and, in career mode, money. This makes it harder for anyone who just wants to do space-missions in a logical order. For the tutorial in my signature I use sandbox mode to create a logical mission sequence starting with unmanned orbital satellites - but then that's aimed at demonstrating vehicle and mission designs. not at "winning" KSP. Ultimately it has to depend on what your preferred gameplay style is and what you find rewarding.

You will need the Module Manager (MM) mod, which is used by a lot of other mods and changes 'things' at load time. It's a good one to have around anyway. Save the text below as a text file in KSP\GameData with the extension .cfg. MM will read this file and add MJ functionality to all command pods and probe cores. @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore } MODULE } You can then simply delete the 'parts' folder from within KSP\GameData\MechJeb2

That's pretty definitive, I would think. A plane uses wings for lift whereas a VTVL/JATO rocket may use winglets, but almost purely for guidance.

It can't gimbal but is cheaper and higher-thrust than the T45. Pod SAS is easily sufficient for making the gravity turn. Once in orbit the 909 takes over so no worries.

Drag is not necessary to fly, although it's rather helpful when you want to slow down. In the SPH the Centre of Lift (CoL) should be just behind the Centre of Mass (CoM) for balance and controlability and the Centre of Thrust (CoT), actually axis of thrust should be in-line with the CoM, otherwise the engines will always tend to rotate the whole ship. What is not shown is the Centre of Drag, which will dictate the orientation the plane naturally wants to adopt. Air intakes create a lot of drag and yours are all right at the front of the plane, meaning it will want to fly 'backwards' all the time (which won't work, needless to say). You need to make sure those drag-inducing parts are behind the CoM so the plane wants to point in the right direction.

There are two ways to 'cluster' engines. The 'official' way is to use a multi-coupler; bi-coupler, tri-coupler, quad-coupler which convert a single stack into 2, 3 or 4 respectively. The other way, which is used for all sorts of things, is using Cubic Octagonal Struts. They'll attach to just about anything, just about anywhere and create a new node to which you can attach just about anything extra. The struts themselves are massless so apart from extra part-count there is no drawback to having them. If you want 7 engines under a tank, for instance: place the one in the middle as normal. Now grab a Cubic Octagonal Strut and put it towards the edge of the bottom of the tank and put an engine on the new node that provides. Change to symmetry-6, click the strut you just placed and adjust its position so that the (symmetrical) set of struts+engines fit around the central one. The editor allows some 'clipping' (overlapping) of parts, which can make things look better but people regard as various degrees of 'cheating' (it's a single-player game, have fun the way you want to). With a bit more work you can use WASD to turn the struts inside the tank before you attach the engines, which makes them fit flush against it but then it's harder to adjust their position later.

To expand: you are required to DO xxx under certain conditions. You met the conditions but failed to DO xxx = you failed to fulfill the contract. Nearly all parts tests either require you to "test part" (right-click the part and select the "run test" option) or "activate by staging" (press spacebar to activate the part's stage) while the all the conditions are met. READ the contracts to find out what you have to DO, not just what conditions you have to meet. DOING it is a whole other game, of course. ("run test" is pretty easy, there are all sorts of tricks to "staging" and many threads about them).

There are several questions behind what you're asking. I am lucky enough to have been taught how to make presentations, lectures, professionally; something most people are just dumped into. Walter Cronkite is a fairly famous presenter and (I can't find any references so it may be apocryphal) was said to have been interviewed himself, to wit: Q: If you have to give a 5-minute presentation how long does it take you to prepare? A: For a 5-minute presentation I'd probably take two or three weeks. Q: Two or three weeks, that seems like a very long time! What if it was for 10 minutes? A: A 10-minute presentation would take around four or five hours. Q: Less time for a longer presentation? What if it was an hour? A: I'm ready. The point being that the shorter your presentation the more sure you must be of exactly what point(s) you want to make and how you will make them, everything else must be cut. If you have a long time - waffle! As a very loose rule-of-thumb expect to only make one point per 5 minutes. So what is your most important point? ?? A communications-satellite is usually placed in a planet-stationary orbit so that it can always send and receive signals with the same patch of ground ?? - sub-point: A 'stationary' orbit means it orbits (orbital period) in the same period as the planet turns. - sub-point: 'orbit' means going sideways so fast you keep missing the ground as you 'free fall' towards it. - sub-point: The lower you are the less time you have before you hit the ground - so the faster sideways (around) you have to go. - sub-point: Which means the higher you are the slower you go (orbital velocity) - sub-point: So there is an 'ideal' altitude where the orbital velocity => orbital period = planetary rotation The LAST thing I'd recommend is that you go bigger, unless you have a lot of time. To be honest I don't know what "look more like a real launch" would mean - but then neither does your audience so don't worry about it (/handwavium <-ignore this if you don't already know it). What a 'real' launch looks like (from Kerbin? Earth gravity but much smaller? Have they seen (not just watched on TV) a 'real' launch?) isn't your point - the maths and physics of it is. Just because Kerbin isn't Earth doesn't change the problem - find an orbital altitude where the orbital period matches the planetary rotation. Focus on that and only that. (Unless you have a lot of time - in which case I might start charging ^^). Edit: Oh - the MJ recommendation is because getting an autopilot to do it is more 'real' AND it means the thing is live, but you are free to talk while it happens. This isn't just a case of "watch this recording ..." (yawn), it's "here is this thing launching ..." (now). You won't be able to predict just how circular the final orbit will be, how flat the inclination, etc. YOU will have to set-up the necessary corrections in steps 4/5 of my original outline. {ETA Again: The ideal presentation is 10 minutes, following the "I tell 'em what I'm going to tell 'em, I tell 'em, then I tell 'em what I told 'em" structure: 3 minutes: why the point is important to them 3 minutes: the point 3 minutes: how much better things are if they get the point 1 minute: questions, thank you ... oops (leave them wanting more)} In brief: Introduction, subject, summary.

Gah! Nearly forgot - I was posting a reply several hours ago when I was invited to the pub and ... you lost ^^. In the post to which you link the names of the rockets (eg; V2) are links to mediafire, a file repository. Click on that link and you'll be offered the option to download the *.craft file concerned. It should be saved with the same, ".craft" extension, if not it's just your computer being too helpful to be helpful (I hate modern OSs). Everything except the executable (*.exe and *.dll) files in KSP are designed to be text-files As Well, so we poor humans can read them if we need to. A *.craft file can therefore be read in a text editor/viewer but it still describes a ship. Having downloaded it just move it into your KSP\<save game name>\Ships\VAB (or \SPH if it's a spaceplane) folder and make sure it's got a .craft extension, eg; V2.craft. Next time you go into the VAB/SPH, as appropriate, the ship will appear in the 'load' list. Getting to Duna: (isn't much harder than Mun) Have a look at the tutorial in my signature for ships/landers if you need to. Work out when the planets are aligned to give you a "transfer window" using http://alexmoon.github.io/ksp/ or something similar. That'll tell you when to go, which way to go and how fast to go - simple (if you can understand it). If you can't understand that tool then practice going between Mun and Minmus - it's much the same as going from Kerbin to one of the moons but when going directly from one to the other you have to consider whereabouts in their orbits (around Kerbin) they are as well. As with the moons around Kerbin, so with the planets around the sun - if they aren't in the right relative positions it is better to wait until they are. [PS: Since you're still typing in English perhaps you aren't in New Caledonia, where the hell is "N.C"?]

Only if you feed it after midnight. (There is a part that includes this in its description, but I can't find it at the moment)

(and others) - Good point, the problem I'm getting is as Wanderfound suggests; after switching scenes/ships a few times I'll just get an 'oops' and have to re-start. That's always happened to an extent, of course, but with 0.25 and those mods it's down to around 7 changes and exit gracefully while I have the chance. As said, my system spec doesn't meet the requirements, but neither is this machine a complete write-off yet: AMD Athlon 64x2, 4GB RAM, Win 7 x86, nVidia GT 610 (1GB) KSP is at quarter-res (yes, it looks awful) and ATM aggressive beating-up everything. MJ is partless, added to all pods/cores by MM (I forgot to mention MM!). OpenGL doesn't work well for me and DirectX is at version 11. Last time I checked KSP sits at around 2.7GB and the whole system only reporting ~70% memory usage but I've recently done some PC spring-cleaning to see whether that made much difference (it didn't, obviously) so I'll check again once I've finished with the internet for a while. Gah! Those figures were with the mods I used to have - KSP about 1.5GB, 55% of CPU, memory used (total) 59%. I haven't converted textures to another format - good suggestion John FX. In general, I'm an ex-PC software developer and quite happy to get my hands dirty with this stuff so all is possible. Looks like more trolling through task manager followed by a conversion to DDS (I see my favourite file-utility supports it and .MBM so shouldn't be too awful a job). Thanks all

:-) Kerbal LolKats, what's not to love? Welcome to the forums

Woo, New Caledonia, nice to see people from all around the world :-) How are you trying to download stuff from the forum? There usually isn't anything here that you can download, just links to picture galleries, file depositories, etc. [Coutesy of Google Translate, if it helps; Woo, Nouvelle-Calédonie, agréable de voir des gens de partout dans le monde:-) Comment essayez-vous de télécharger des trucs du forum? Il est généralement pas quelque chose ici que vous pouvez télécharger, juste des liens àl'image des galeries, des dépositaires de fichiers, etc.]

Vanamonde must be in modest mode - his How To Reach Orbit, And A Rocket That Can Do It is possibly the best place to start. "Landing on planets..." is just a tad tougher; take it step by step (with luck my tutorial will help there). Important things to note about interplanetary - after you've been to the moons a few times, if you aren't too impatient - i) DO NOT land on Eve if you intend to come back, ii) Duna is about the easiest to get to and return, iii) planetary-alignment is important, relatively-efficient/easy missions are only possible during a "transfer window", iv) Kerbin->Mun or Kerbin->Minmus are similar to Sun->Any planet, v) Mun<->Minmus is similar to A Planet<->Another Planet but a lot easier to practice. Read lots, watch videos where the text isn't clear. It does all make sense after a while. Rocket science isn't that hard after all!

My old machine never met KSP requirements but has always behaved well until 0.25. Whether it's the extra Mk2 parts or what I don't know, but something seems to have pushed it over the edge. I either have a bad install (unlikely, as there are three of them behaving similarly) or I just don't have the 32-bit memory I used to. Either way, I have to reduce my mod-list and I need you to help with the decision as I've already pared it down to those I consider 'essential'. There are three I'm not deleting: ATM - It's SAVING memory! Deleting it would make things worse. KAC - Prise it from my cold, dead, hands. MJ - If not this I'd want KER/VOID and still be bored during transfer burns, so no gain in removing it. Which leaves ten (conveniently for the poll): Chatterer - Totally useless, but KSP wouldn't be totally fun without it. NavballDockingAlignmentIndicator - Smaller than NavyFish's but I could live without it. NavUtilities - I like instruments! (And landing in one piece). NRAP - Saves a lot of testing time, but ... ProbeControlRoom - IVA for unmanned ships, what's not to love (unless RPM goes ...). ProceduralFairings - Just aesthetics, since I'm using stock aerodynamics. RPM - The reason to use IVA. SCANSat - Maps are cool, visiting anomalies is cooler. But do I need to do it again? Toolbar - Required for ProbeControlRoom and SCANSat (unless they go ...). VesselViewer - Nice in RPM, but ... Don't be nasty about any mods or modders. Just tell me which one you think needs to go first.

These are things I've never seen. MJ sometimes engine-brakes so much the chutes get cut, then it runs out of fuel and crashes (doh!)* but I've never had it fail to deploy the chutes at all. Although, rarely, I have seen MJ keep 'hunting' for a correction heading aborting and re-issuing the "land at target" solves it. Unless there's next to no SAS/control authority of course and it can't turn. The biggest problem I have with MJ's landing at the moment is that it over-does its deorbit burn (at Kerbin) by 20-200km short of the target and then wastes time and fuel turning prograde to correct it (abort and re-issue fixes that too). [*actually, this happens so much that once the ship's nearing full-deployment altitude (ie; 500m for normal chutes) I "abort auto-land" then tell MJ to "land somewhere" once they are safely open]

Kerbin-stationary is a high orbit to launch into. It is normal to launch into a low orbit and then boost to the higher one, either still using the last launch-vehicle stage or the satellite itself (which might make a better presentation). I'd recommend that you 'script' exactly what your mission will be (here, if you want us to critique it). Might I also suggest that you look at Chapter 3 of the tutorial in my signature, which deals with Kerbin orbital satellites (albeit they are polar-orbit mapping satellites instead of synchronous CommSats). It might give you some ideas anyway. As you say you want it to be a background rather than a gameplay consider install MechJeb (MJ), which has autopilot capabilities. Presentation outline might then go as: Introduction/objectives Launch with MJ. Takes about 5 minutes to Low Kerbin Orbit (LKO), during which explain the launch vehicle (staging or whatever you are interested in), ascent burn, gravity turn - orbit is more about going sideways fast, not going up - and circularisation (orbit injection) burn. Jettison launch-vehicle. Set MJ to increase satellite apoapsis (Ap) at next periapsis (Pe), then circularise at new apoapsis. Time this first but it'll take a few minutes, even with auto-warp. Use the time for an explanation of Ap, Pe, prograde, retrograde, etc. Similarly bring inclination to zero-degrees. While MJ finishes that off explain normal/anti-normal burns. Whatever you like ... questions ...