Pecan

And just for some annoying trivia because I'm a yachtsman: Early boats were controlled using a 'steer board' before rudders were invented. Because most sailors were/are right-handed this was usually fixed to the right of the ship; hence that side became known as 'starboard' as the pronunciation became corrupted. Docking and loading, lading was done on the left because the steer-board was in the way on the right and, by similar corruption, that became 'larboard'. The two words 'starboard' and 'larboard' being too similar the latter was supplanted by docking to 'port'.

You can't host most things on the forum - only link to them elsewhere or post short-ish text. I don't know about reddit but the options should therefore be curse, dropbox, etc.

Either side of the top ;-) Port and Starboard would be the directions that the ship turns in when you press the yaw left and right keys (A/D). It is neither a meaningless nor unhelpful concept, even in space. aviation lights

There are several things that affect the amount of RAM used but one of the major ones is the number of parts which are loaded when the game starts. With B9 and KW particularly there are a lot of extra parts - I don't know about Interstellar - so a lot of additional RAM required. More than just the (picture) textures used to draw these it is the (polygon) 3d-model that the computer understands that takes the memory so ATM and similar can't help much. Beyond the number of parts the biggest contributor to RAM usage will be the number of flights in progress - always - and, most obviously - the number of craft/parts within render-distance while in flight.

Maybe trying to get a Kerbin-stationary orbit? If you are trying to get a synchronous orbit, so that your ship/probe stays over the same point on the surface you need to take into account that the world is turning (every 6 hours) and, therefore, you need to orbit at sufficient altitude (2 868.75 km) and speed to go 'around' in the same time.

In KSP as well more stages = more parts = more likely to fall apart on the pad or in flight (= moar struts!). Nice summary Streetwind.

Didn't: Type-up the last chapter of my tutorial Get on with Kerbal Text Program IF I'm writing Receive clue 7 for the Kerbal Amazing Race challenge Grit my teeth and sit through the 20-odd minute burn for my Moho tanker (Did procrastinate by redesigning my standard spacestation for Connected Living Spaces)

1. There would be a huge amount of advertising hype with the release-date set for September. 2. During the interval the dev team would be doubled, and productivity quartered, to add various 'game' features and make sure it wasn't what anyone wanted. 3. At the set time KSP v1.0 would be launched with even more hype and the dev team re-assigned. 4. Around January v1.1 would be released with prettier pictures, easier gameplay, a couple of bugs fixed and many more introduced. 5. There no number 5 because KSP would be too hard to appeal to casual gamers and too nerfed to appeal to KSP veterans. 6. In 2017 EA would release 'never mind the quality, look at the pictures' KSP2 with a blaze of publicity. It would be panned for its simplistic, buggy gameplay and sink without trace.

How to decide when to stage: 1. Use the most efficient engine(s) for the flight-stage = ASL or Vac ISP. 2. Give it/them as much fuel as they can push with an 'acceptable' TWR = wherever you're launching from or how long you can cope with in-space burn times. 3. If deltaV is sufficient, stop. Otherwise, stage.

Leave the science stuff at home, design and build small and have fun practicing; or go the whole hog and just practice in sandbox. With smaller and simpler vehicles your missions should be easier, you'll boost your confidence along with your experience by gaining successes, even if they are lesser ones. THEN start to build-up - landing separate modules, assembling in space/on the ground, etc. In any case the whole career mode is getting such a big redesign in 0.24 it's not worth putting much effort into mastering it in its current form.

I have used and written several AI/A-Life systems over the past few decades. They're interesting but the trouble with a chemical-scale one such as you describe is that the computer has to simulate so many billions of reactions for anything even as big as a virus - plus all its environment - that you need a supercomputer or three for any non-trivial. No-one had managed to get from chemical-stage to convincing bacteria last time I looked - but you might like to check the literature. A good place to start is http://www.alife.org/

In my tutorial I include lists for both orbiting and landing, including plane-change but ignoring aerobraking so the figures are high-ish: "How hard is it to transfer to and orbit (from Kerbin, m/s)?" table Mun 1,170 Minmus 1,430 Ike 1,550 Duna 1,700 Eve 2,880 Gilly 2,950 Dres 3,860 Tylo 3,860 Vall 3,890 Pol 4,040 Laythe 4,360 Eeloo 4,790 Jool 5,170 Bop 5,920 Moho 6,640 Kerbol 33,680 "How hard is it to transfer to, orbit then land (from Kerbin, m/s)?" table Minmus 1,610 Mun 1,750 Ike 1,940 Gilly 2,980 Duna 3,000 Pol 4,170 Dres 4,290 Vall 4,750 Eeloo 5,410 Tylo 6,130 Bop 6,140 Moho 7,510 Laythe 7,560 Eve 14,880 (Jool & Kerbol N/A)

That would be indefinitely, but it's 45/min not sec. The description says 'decades' but I don't think anyone has reported one ever decaying.

We're at risk of hijacking the thread - If you'd like to PM me a list of the science/comms equipment you are including on your lander I'll attempt to design a ship for you that is less incredibly massive than those. Ascent path is about the gravity turn, staying at/near terminal velocity, etc. This should actually be easier with FAR (apparently) because the deltaV requirement is lower. Going straight up will require a huge amount more fuel and, therefore, a heavier launch vehicle. Much better to build small and learn how to fly it properly - not a dig, by the way, because I've never managed to get to orbit with FAR (having only tried twice). Transfer strategy is about how you get from LKO to synchronous or Mun orbit, or wherever; Hohmann or bi-elliptic transfer or direct-burn, for instance. Again, the right manoeuvres are 'right' because they save a lot of deltaV, which means you need much less fuel, which means you need fewer/lighter/more efficient engines to lift it, which makes the whole thing much smaller.

There has been an awful lot of discussion on spaceplanes because they are so hard to get used to. You have summarised it all very well I think, the critical thing being to build horizontal, not vertical speed. The one thing you didn't mention though is that you can keep the jets thrusting - and the plane accelerating - when they would otherwise flameout by reducing throttle, and therefore their air requirement. That was the one thing that made spaceplanes work for me - until I nicked Claw's intake-stack clipping technique.

And have you tried adjusting trim yet, instead of using SAS?

Here's a few: Atwood's law: Any vehicle that can be powered by ion engines will eventually be powered by ion engines Parkinson's law: Payloads expand to fill the launch vehicles available Pecan's rule: Use of the term 'SSTO'is inversely proportional to the meaning of 'SSTO' Peter principle: Transfer vehicles vehicles are stretched to their level of incapability

378 tonnes is a big ship (378 kilotonnes is reserved for Whackjob ^^) and almost certainly over-large for a satellite - unless the satellite itself is massive, of course. Chapter 4 of the tutorial linked in my signature deals with manned orbital flights (<18t) and lunar and easier interplanetary satellites (~41t). Apart from the satellite and launch/transfer vehicle designs themselves, have you considered your ascent-path, gravity turn and transfer strategies?

You might like to look at the tutorial linked in my signature - chapter 5 deals with manned lunar landings and interplanetary satellites, although you may find some of the stuff in the earlier chapters helpful too. Chapter 6 has a 'Kerpollo' vehicle capable of Minmus, Mun, Ike, Gilly, Duna or Pol landing, while chapter 7 has a low-part 40t launch vehicle based on it.

As I mentioned, I have fuel lines running from the core to the outriggers (under the I-beams). That means central tanks can feed all engines in that way; the 2-in, 2-out arrangement was just an alternative for consideration. Much of the economics depends on the relative cost of fuel vs tanks themselves. We will find out in due time ...

A nice idea and, yes, co-operation appeals to me. Having some sort of space-war definitely doesn't, so co-operation would be the point of a multiplayer game for me. On the other hand, multiplayer is promised in stock at some point, if I remember correctly, so I'm happy to wait for that.

:-) I saw you were active in the thread and might comment. Did you ever get to the bottom of that problem? I didn't see anything in the thread on it. To be honest the ship started as an exercise in modularity and flexibility (last part of my l-o-n-g tutorial, which I really must finish this week). In practice every component is reusable except the fuel-module launch-vehicles (because I haven't been able to make a reusable LV for a 40t payload that I'm happy with yet). That means my empty tanks fly home too, or are at least de-orbited by another tractor and then parachute down. The engine modules are not meant to return but, yes, to park in orbit until needed again. I don't use a station for this for clutter/stress reasons such as Claw mentioned; instead I just stick them in their own high-ish parking orbit. They have some fuel - not usually as much as in that second picture - and RCS to rendezvous and dock with the tractor, rather than the other way around, because the tractor is pretty impossible to control when it is part-loaded and therefore unbalanced, as you can imagine. Putting RCS fuel and thrusters on them helps the 'core' tractor and again lets me adjust the amount of RCS according to which group of engines I'm using. The twin-nukes just have those little roundified RCS tanks for instance, while quad-nukes might have cylindrical. Again, in practice, I hardly ever need that much RCS fuel though. The modules have cores in the first place simply so I can enable SAS on them to hold them steady while docking. Since they have cores they need a solar panel (which also assists the tractor) and since they're going to dock or be docked to they obviously need a docking port. Yes, that could be saved by not using the modular engine design but then I forfeit the ability to adjust the number of engines attached. Whether that ability is worth it is a moot point and I haven't really made up my mind either. A second, lighter and non-modular, tractor can be used to dock fuel/engine modules to the larger one as an alternative but then those modules need two ports or the light tractor has to use a claw. PS: Your mothership looks like it could be the mother of my tractor :-) Same plan writ large. @ Commander Zoom - I launch the same way, for the same reason but also haven't tried it with FAR. @ Aethon - that's a nice smaller version of the same thing too. Good one - that small tank is probably a very good size for local independent operation of the nukes.

Shakes are usually a sign that SAS is fighting very hard so I suspect the drag/balance of your plane is shifting as it is dependent on speed. The best cure is to turn SAS off and adjust the trim of the plane so that it flies more-or-less stably without that or constant control-input. Hold the 'mod' key (alt on Windows) and the WASD keys to adjust trim, alt-X to reset it. I find that a lot of planes work best with positive (up, alt-S) pitch trim of 1 - 2 notches on the control-indicators at the bottom-left of the screen. The thing is to just check what your plane does without SAS and use trim to counter it - so if it goes into a dive on its own use pitch-up, if it does a back-flip use pitch-down, etc. You might have to re-adjust trim every now and again as your speed/AoA or fuel (if applicable) changes. Note that a tendency to back-flip often indicates that there is too much drag ahead of the CoM. That's often because of air-intakes but I take it that isn't the case here.

Welcome to the club :-) I will be back in action tomorrow, then need to finish my tutorial and I can really get stuck in. ETA: OKAY! 2.30am, work in 5 hours but I couldn't sleep without doing 6. Things worked well in the end where I expected to need a rescue mission, which is why I thought I'd finished it yesterday. First attempt at the other part - which should have been easy but I was pushing too hard - totally failed, which is why I had to redo today. Ended up with a fuel-tank left in orbit this time. Wonder if I'll need it for something later. Too tired to actually post the screenshots and timed now, I'll do that tomorrow.

Oh yes - someone even gave me an array of 7 LV-Ns in a large adapter ^^. Don't forget you can attach engines on the core as well, behind the payload - so every number of engines, from 1 to 35 (5x7) is possible without clipping (needs the arms a bit longer than pocket I-beams). KAS/IR are handy with designs like this too, by the way. Mine has fuel-lines from the 'core' to the out-riggers but that makes it tricky to use with drop-tanks. You can put as many as you like in the centre, of course, but that makes for some very long payloads. Using 2-riggers with lines IN to the core and the other 2 OUT to the riggers means you can have 2 engine stacks and 2 fuel stacks, without disturbing the payload. IR is great for unfolding things from inside fairings, of course. ETA: My fuel and engine modules tend to be 'smart' too - here is the last of a set of twin-nukes docking with the tractor pictured above: