J.Random

Tsiolkovski's equation. To get the same dV for larger final mass, your initial mass should rise exponentially. Two 10-ton launches will use less fuel than one 20-ton launch. Also, they will need less powerful engines and probably even lesser amount of parts and assemblies, which means fewer points of failure. On the Square-Cube law, vessel's mass and volume will rise as ^3, but connections between stages and space to mount engines will increase as ^2. At some point rocket will either crush under its own weight or you won't be able to mount enough engines to lift it even with side-mounted boosters.

Landed this baby on Moho with 1.4 units of fuel (or some 30m/s dV) to spare.

I'm pretty sure that original ECLSS tanks are 2.5m wide, and it's the rebalance mod which changes their scale into 1.25. Look into modulemanager config file for NH, you should see @rescaleFactor and @mass there.

Yeah, only when Eyjafjallajokull was active, noone risked to send an airplane at that route. Because that's what happens when these turbines get into volcanic ash cloud: And there should be all kind of crap flying in Venus atmosphere because of 300km/h strong winds, which is stronger than most of Earth tornadoes.

After trying to drive rover using only navcam in Take On Mars, with its camera at one side and science equipment at the other, I believe it's unintentional. It was always like that: come close enough to the rock, rotate so you can see it through the navcam, drive closer, rotate 180 so that you see your own tracks right in front of you, drive backwards to get into equipment range.

Don't listen to them, it's totally OK to put hot electronic equipment into freezer. Also, you should try this:

If this thing works, if it works fast enough, and/or if you manage to spread the processing load on multicore systems, I will want to pay for such mod. Because that's going to be an incredible, astonishing improvement for KSP, and it deserves the support.

On landing: I didn't even try to land something on bodies without atmosphere. When RT2 becomes more polished, I'll try to. It will either imply doing some math beforehand, or waiting for kOS integration. m/s work. Only I don't recommend using large values there, especially for non-prograde or retrograde maneuvers. If you try to change inclination with some huge burn, you may get into situation where it not only overshoots but starts to circle around at one spot infinitely.

I don't get the logic of this suggestion. The game loads too slow, so let's add some stupid minigame to waste resources and make the game load even slower?

1) instead of using dishes for close range communication, you 'd better lower your orbit or use 4+ satellites to get them in 5Mm omni range from each other. If you're going to build remote-controlled spaceplanes, you should have even more satellites in low orbit (300km or so), because you can't use anything but dipole (500km range) in the atmosphere. 1a) Use Active Vessel ONLY on the last mile. If you're planning to leave the relay sat with powerful dish on orbit and get down some automated lander with omni antenna, then it won't work after you switch to lander if your Kerbin satellites are pointing at Active Vessel. 2) Sats from Kerbin network should each have smallest dish pointed at Mun, relay sat (or lander itself if you're planning to land on Mun side visible from Kerbin) should have a smallest dish pointed at Kerbin.

Maybe I'm bad at this, but I've actually looked for it the very first time I've heard about these supposedly Unity problems. Nope, couldn't find any. I've seen some 64-bit editor-related reports, and some for redistributable MS libraries (for which there was workaround, iirc), but nothing about engine itself.

We all decide it for ourselves. You probably should do the same. Or ask your viewers, if your purpose is to entertain them regardless of your own predisposition. Both options are better than starting another meaningless "mods-no-mods" argument here (or trying to promote your channel in this subforum).

Not exactly. There's GroundStations{} in RemoteTech_Settings.cfg where you may define your own control centers. If it makes you feel good, you may land some structure there, but it's not required.

Why would I treat it as easy mode? Targeting planets with dishes was always in the mod. Dish cones are an improvement of existing feature: now you can't simply target sun to get everything in the interplanetary space connected. Building compact (yet able to maintain several connections) satellites is a design challenge. You don't want it? I admit that sat lists may be a solution. Another solution, which I like more, is NathanKell's additive range calculation and extended list of deployable dishes (there were some of them in RT and RT2 predecessor, RTE, and I still hope for their return). Sat groups aren't really realistic as announced: there wasn't even "primary-standby" logic, this mode will effectively turn dish into omni antenna, always connecting to every sat in the group at the same time. So, yeah, don't look into the can.

There's always-on 500km dipole. Every launch vehicle of yours should have one of those.

You're targeting a planet, cone goes straight down, ksc isn't in the cone. Try the same on orbit.

Because it doesn't know what to target, even if deployed, and 3km core internal antenna isn't researched yet? Try adding the smallest omni antenna to your launch vehicle.

You can target a PLANET with a dish. That's what dish cones are for. Next example, please.

YES! All this "active vessel" targeting, sat groups and (proposed) autoredundancy shouldn't be there. Those who don't want to design their relay networks may simply cheat/edit some HUGE radius omni antenna for themselves and use it for everything. I just hope that fixing bugs and reintroducing previous features (FC, rover autopilot, target tracking dishes, remote control for sats in physical range) will be a priority when you return to RT development.

Not necessarily. Public services - yes, but I've also mentioned nVidia Shield (which I don't really approve because latest nVidia drivers include some dirty, bordering on malware, OS hacks to make it work, even if you don't have and don't plan to have Shield), which streams from your own PC, not from the public cloud.

Oh, let's not transform this topic into another "shuttle-good, shuttle-bad" argument. It's stupid. On topic: however harsh or rude it may sound, in the end, Challenger's accident was beneficial for the shuttle program. As I recall, in some 20 flights before Challenger there were only three without problems with o-rings. And of those which had problems, 2/3 had hot gas getting through cracks. ANY of them could become Challenger. It became a problem which is considered "normal". Like, "yeah, there's a leak, but there's always a leak, that's OK, probably". The closest analogy I can make is having to reboot a production server with memory-leaky app every day and not attempting to fix the root cause. Only the tragedy made americans reconsider their approach and finally reinforce boosters, fixing the problem. So yeah, it was a loss, it was a tragedy, but in no way it was a setback.

Depends on MTBC (Mean Time Before Crash) / MTBK (... Kraken) values.

Another possible solution is remote gaming. Like nVidia Shield, for example, or that weird public service (don't remember the name OnLive) where you could rent game time on server farm. Basically, it's video stream from PC to tablet and control stream from tablet to PC. Not exactly "running" it on tablet, but that's the best you can get today, I guess.

I don't know about math, but afaik metric ton is normal ton (you know, 10^3 kg, that one).

Sooooo... they should buy Portugal.