AHHans

Well, yes. If that isn't already general knowledge, then it is also visible at 3:05 in the video that @Serenity linked yesterday: you can see two SSME light in the upper right corner of the film well before the SRBs light. [...] And now that I re-watched that: in the next clip - where the SSME are in the upper left corner - you can see that the SSMEs start to push the orbiter up before the SRBs light. I couldn't find anything I'd consider a reliable source, but this and this internet "discussions" both came to the same conclusion that it was more feasible to engineer the SRBs so that they don't fail to ignite rather than figuring out how to stop or hold down one of them.

In addition to what @jimmymcgoochie said: IIRC picking up a deployed experiment transfers the collected by not yet transmitted data to the Kerbal. So if the experiment shut down after generating all science but didn't manage to transmit all (e.g. because of missing comnet connectivity), then I think you can collect the data that way.

Yes. If the size of the moon is so large that it extends to the L1 point then it will shed material to the parent body. That's something that actually happens in binary stars that get close enough to merge eventually (Roche lobe overflow). Under the "right" circumstances this can cause a Type Ia supernova. The other questions were already answered by @DDE

Damn! I love the Space Shuttle! It is a horrible design in way too many ways, but it just looks cool!

And if you are the Space Shuttle then the SRBs have enough thrust to rip apart some (or all?) of the bolts if they are too slow to let go. (And AFAIK the mass of the whole shuttle was essentially supported by the SRBs already on the ground.) But I'm sure there are also lots of other mechanical contraptions that release once the force goes from "umbilical supporting the rocket" to "rocket pulling up on umbilical". I don't know if Scott Manley ever made a video especially about this, but that would be the place where I would start looking.

@Streetwind already said most of it, but some additional remarks from me: - You will probably have to manually switch off the engines on your lander ship. You really don't want to have one set of engines pushing in one direction and another set of engines pushing in the opposite direction. Feel free to re-arrange the staging order in orbit, but don't trust it too much, instead make sure that exactly the engines that you want to use are active before hitting the throttle. - If you want to make it (IMHO) more elegant then you can also use the the transfer stage to only push you into a highly eccentric orbit around Kerbin, and then use your main lander ship for the rest. That way you can either land and re-use the transfer stage or safely dispose of it in Kerbins atmosphere. This means you can only gain about 900 m/s from the transfer stage, but it may be fun nevertheless. - I'm not sure if you are aware that long burns actually waste dV. If you have a high dV burn (e.g. the 1600 m/s) at low TWR, that will take so long that it extends over a significant (angular) fraction of the current orbit, then you'll need quite a bit more dV than the nominal amount. In this case you can save dV by splitting up the burn over two or more orbits (as long as you stay within the SOI of the orbited body).

First a very warm welcome to the Forums, @MaxKot Well, you might be surprised by what the people here are willing to do. That was my problem. When I have the time I'm perfectly willing to download a craft file and have a look at it. (And improving it... ) But I'm not installing any mods to do that. But @Streetwind is right, that more often than not the problem can already be diagnosed from images alone. In your case I would say that in addition to meaningful images of the craft itself an image with the staging setup that shows the dV, TWR and Isp of the first few stages is useful. (I.e. don't remove the GUI from the images. And don't crop images when asking for help!)

Another general tip is to build your rocket radially-symmetric and not point too far away from prograde (). If the rocket is symmetric and pointing straight into the wind (which in KSP is prograde in surface mode) then the torque from the aerodynamic forces cancel, so you need only little torque to keep the rocket on course. The trick here is to learn how to launch by only tipping over a bit shortly after launch and then only hold prograde until you are out of the atmosphere. (E.g. 10 deg once the rocket reaches 100 m/s, but that depends very much on the rocket in question.)

Well, if the root part of the cannot attach to anything, then it isn't a valid subassembly. But in that case you get a tiny error message when dragging it into the drop zone, it won't do anything if you click there and you don't get to type in a name for it.

What do you plan to learn from your KSP "simulation"? As already mentioned by @FleshJeb the aerodynamics simulation of KSP is rather basic. It is good for teaching general concepts of aerodynamic stability but don't expect it to faithfully represent the behavior of a real rocket. So if you want to get an idea of the difference in the flight profile of a rotating vs. a non-rotating rocket, then you can use KSP for that. You can also have a look at the differences between having angled fins vs. angled exhaust. But any details like the amount of rotation to aim for or a good angle for the fins or rocket motors are not well represented by KSP. And that ignores other practical considerations: e.g. you'll never get the ropes of a parachute tangled in KSP, because that just isn't simulated. In order to "learn KSP" I'd suggest to just forget about the model rockets for a while and just play the game. I'd suggest to start career mode because the contracts give you some guidance on what you may want to try next, but career mode can be grindy if that is an issue then try science mode.

P.S. I just gave it a try and I couldn't reproduce any problem. So my guess from earlier today may be wrong...

I think I had a similar issue ages ago, but I don't recall exactly what it was or how I solved it. It is possible that this has to do with the name of the subassembly and the way KSP replaces "special" characters in the name and the filename. So maybe try only letters and numbers in the name of the subassembly and see if that works (no spaces, dots, slashes, or other fancy stuff).

What's so scary about this?

A lot! Your plane wants to flip if the center of mass (CoM) is behind the center of pressure (CoP) - the point where the aerodynamic forces (in game: lift and drag) apply. If a plane that is stable in normal flight wants to flip during reentry then this can be due to two causes: the CoM moving backwards and the CoP moving forwards. The CoM moving backwards can happen if you have most of your fuel in front of the fully fueled CoM, i.e. the empty CoM is behind the fully fueled CoM. This is fairly easy to see - and then correct for - in the editor. The CoP moving forwards can happen because at low speeds (e.g. subsonic speeds) the lift is the dominant aerodynamic force and at hypersonic speeds the drag is the dominant force. In spaceplanes that have the (heavy) engines at the back and the comparatively light crew cabins etc. at the front, you tend to put the wings (and thus lift) fairly far back to have it fly well at low speeds. But this often leads to having a good portion of the drag in front of the CoM and thus make it flip happy at hypersonic speeds.

I'm not sure if I would use such strong language, especially with only six docking ports. But there definitely is an effect.

Another solution is to launch the arms as they are in a way that you can decouple them in orbit - where they would just drift uncontrollably without any external help. And then have a small tug that can dock to the shielded docking port and maneuver each arm to their destination.

Because the engineer on the station that is managing the ISRU is rigging a fuel line from the converter to the fuel tank(s) with the highest priority. That's my explanation and I stick with it! On a more serious note: it is a well known (at lest to some) feature that freshly created fuel from an ISRU will ignore the crossfeed rules and just show up in the (non-full) tank with the highest fuel priority (i.e. the tank that would be drained first all tanks were available). I regularly use that to refill craft on the other side of a non-crossfeed part - e.g. the Klaw.

Probably not. (But I'm not 100% sure.) I play KSP on a Linux machine with also 16GB RAM. And my impression was that KSP likes to allocate lots of RAM(*), but doesn't really use much of it at any time. I.e. even with a large craft in the physics bubble the machine isn't swapping, but it is the CPU that is the bottleneck. My guess is that your "CPU" isn't at 100% because KSP uses only about 1.5(**) cores of your CPU and the other cores are idle. P.S. (*) It may be that this isn't really allocated RAM that is actually swapped out, but memory mapped files. (**) My guess is that only one core is used for the physics simulation, i.e. the big CPU hog of KSP, and tasks around updating the display etc. can happen in another thread (=core).

You are right, I just couldn't help myself. (And my first test rig yesterday had only two FCAs...)

I don't know if there is a best(TM) place for a refueling station in the Joolian system. I guess it depends on what you want to do. I placed my big station in an orbit around Jool between Laythe and Vall, so that I can easily refuel from Vall and don't have it far to Laythe. But I also have a Laythe ground station on the way that will supply the air-breathing operations on Laythe, once they arrive.

Well, you do need enough electricity generation capability to run all required modules. (SCNR! ) But that math isn't too hard, for a simple setup three Fuel Cell Arrays are enough.

The fast but cheaty way is to switch the drill off to charge the batteries, then switch everything on, confirm that it works and generates fuel, and jump to another vessel outside the physics bubble (or the KSC). Any vessel that is not in the physics bubble doesn't consume ECs, but when you jump back to it then will have produced fuel as if it was running all the time. The no so cheaty way would be to ensure enough EC generation that is solar independent. You can either have enough RTGs or fuel cells to power everything. (Yes, even with only fuel cells, when powering a large Convert-O-Tron you get a net fuel gain.)

I also usually go the "put a relay dish on them and have them pay for my relay network" route. I also designate satellites for finished contracts as "relay" and remove the relay category from the display in the map screen to reduce the clutter. (Which implies that I designate satellites that are still on their way as "probe" so that they are displayed in the map.) P.S. Another use for the satellites is as an impactor for the seismic surface science experiment.

I guess you have set the action group to "Play Sequence" of the KAL. Most people set their KAL play forward and the play position to the start of the sequence in the VAB (or SPH). So when the group is triggered the first time then the KAL play the sequence as expected. But then the play position is at the end of the sequence, and when the group is triggered again there is nothing to do because the KAL is already at the end of the sequence (and it is still set to play forward). Long story short: add "Set Play Position to Start" to the action group(s), I guess that will solve your issue. (I would also add "Set Play Direction to Forward", but that's just me.)

Exactly. In the end it may be that our idea that electromagnetic radiation consists of "photons" is deeply flawed. But for the time being it lets us predict how it behaves with remarkable precision. And that latter is the essential test for a good theory.