DStaal

It wouldn't need it everywhere. Put the solar systems in a 64-bit universe, and make each of them be a separate 32-bit space, and then you have the 32-bit local environment. The only place you'd really notice is when trying to dock ships in interstellar space. But I think we're getting off-topic here... I wouldn't mind a warp-drive or jump-gate as part of a themed DLC. I also wouldn't mind if it was left for modders entirely.

I mostly play in science mode. I enjoy the progression of unlocking parts and having doing science mean something - but I'm not interested in the contracts or tracking every last funds. I'll set my own goals, thanks. (I do use Kerbal Environmental Institute to avoid the early-game grind of going around the KSC sampling science. With the number of mods I run (some of which have their own experiments), that typically gets me about halfway through the CTT before I build a single rocket.)

DLC are mods, but mods are not necessarily DLC - at least by the common use of the terms.

I think it depends on what assumptions you make for both types of drives. Regardless, Metallic Hydrogen would be safer to handle and operate, as there's no pesky radiation to deal with. (Admittedly only 'safer' in that nitroglycerin is safer than a nuclear bomb: Both will explode and kill you if make a wrong move, but the bomb will also kill you if you hang around to long. And even that comparison is bad, since the nuclear bomb has the bigger explosion...) Ah, but for metallic hydrogen we at least know it *can* exist (whether or not it's metastable is up for debate, with it leaning towards 'not'), and what it would take to manufacture it - even if we don't have a way to do so at commercial volumes, it's barely possible within a dedicated lab. Exotic matter we're not even really sure exists - the only real evidence we have for it is that the numbers add up correctly in the theories. Which could be just because math allows you to put in nonsense numbers and get a result, and that our theories are only descriptive of the real world. So, likely neither one really works - but even if metallic hydrogen *isn't* metastable you could make a metallic hydrogen drive. The mass of the fuel tanks would make it a stupid idea as all your dV would be spent moving the pressure vessels, but it could be done. Warp drive... We've no evidence that it exists outside of numbers on paper.

What you want for that is the 'snap' and 'Angle'. Then it will 'snap' to the 'angle' you set. (But note the setting has to match on both docking ports.) In general, I'd want most of the settings to match between both ports, except for maybe the force and torque settings which I might set higher on one.

You can have both in one screenshot - you just need to click the 'pin' in the top-right corner of the pop-up, then that PAW will stay. I generally wouldn't play with that setting, personally. The 'port range' on the top screenshot was probably a large part of the problem: You have to get that dock within 0.5m of the other dock before the docking will kick in. (And then it has to stay there while everything else gets aligned...)

Can you show us the PAW for *both* docks? (The right-click window.)

The main problem with the ports on the containers and MechJeb I've seen is that MechJeb assumes there's only one docking port on a part. Which means for the orbital docking containers it's going to have to pick one - and it tends to pick the node you have for 'moving the container around the station' rather than the node for 'attaching to the station' - which typically in my experience is the wrong one, so it's trying to dock 'backwards'. I tend to solve it by using the docking node on top as an attach node and putting a regular docking node there, which then has to be disposed of when the build is done...

Best to ask this in the KAS thread as there would be the best answers, however: There's no direct replacement. The functionality is however replaced by having a socket on one part, and a fixed telescopic joint on the other. Attach the telescopic joint and to the socket, and you have a de-facto strut.

And note that 'playable' is often subjective: The game will slow down under load, but typically doesn't lock up. If playing at half speed is fine for you - then it's still playable.

Depends on the feature and how much it affects balance, as well as how it's programmed. I don't actually think *disabling* life support is likely to be hard if they programmed it with that in mind. Changing the detail level of it on the other hand requires balancing *each level of detail,* and possibly having extra parts for some of them, etc. That's the part that would have more work.

I'm still not entirely convinced that there will be actual life support in the game - they could just have been talking a colony support mechanic that's life-support like. I'm a little ambivalent about whether they should have a life support system - both in that it's unlikely they'll get a detail level that everyone thinks is correct, and even more that the open sandbox without to much overhead is a good part of the draw of KSP. The latter could be dealt with using difficulty levels, of course. (As could the former - at the cost of a lot more work for the developers.) On the other hand, having a good system well integrated into the game would be better than trying to integrate one of a half-dozen systems into whatever set of mods you want to use.

For 1.7.x, try the 1.6 version. Most 1.6 mods also work with 1.7. (And don't work with 1.8.)

Why has no one else thought of this idea?

In theory that's probably fine. In practice, what happens is people come and complain on the forum that the calculation is wrong.

There is an exploit you can take advantage of for EC storage: EC is only consumed when the ship is in the current physics bubble. If your station is not in the physics bubble at night (not in focus), it won't run out of EC, as long as next time it is in the physics bubble is during the day. So, if you never visit your station at night, it only needs solar generation to match what it currently needs.

You've just made a couple of invalid assumptions about how KSP works: First off, you assumed that the night passing would affect EC usage and generation. It doesn't *unless you're currently watching the ship.* If you go away before it's night, and come back during the day, the game will implicitly assume all the intervening time was daylight. Secondly, you assumed that you can extrapolate the current conversion rates on it's own. Again, not quite correct: They will depend on radiator efficiency, and storage of any intermediate resources. A miner converting to say MaterialKits may run out of RareMetals before it runs out of anything else, and that will shut down production entirely. Or it may run out of Machinery and degrade over time. Or it may overheat and slow down. (Or it may reach optimal heat and speed up...) Thirdly, you've assumed that looking at the ship/base in normal view will extrapolate directly to how that same base produces in time warp. It may not - Again using the same base, the player may think to plan for a 15-hour Mun night, but only have small 'transitional' storage for some of the intermediate products in the production chain. If you switch away and come back after the night, you'll find that the base was mostly shut down - as production occurred in 'batches' over 6-hour periods, and if they didn't have enough intermediate storage the entire production shut down. These are all common conceptual issues on how KSP works in the background - and typically it doesn't matter. However once you start predicting what resources you'll have in the future, you start running into these all the time. (This is a common discussion point for players new to USI-LS, for instance.)

Sure - I mean, I play KSP. I've put rockets into space without putting them into orbit. However, an elevator helps with the 'fast' as well - as it drops you in geostationary, at speed. (And if you want to transfer to someplace else, you can now use a high-ISP vacuum engine...) And while it does take the same amount of energy as an ideal lifter, it would allow you to choose from a much wider range of possible engines, and you wouldn't have to lift any fuel as well. (It could be lifted otherwise, or you could send power through the elevator.) It's also right on the boundary of science fiction - we think we can make materials strong enough, but not in the lengths required. For that matter, an elevator on the Moon or Mars would be much easier (within current materials), and have many of the same benefits. All of which is really irrelevant to this discussion - Unless there's a more-major-than-we-expect overhaul to the KSP engine, KSP2 isn't likely to be able to support a space elevator any more than KSP1 can.

I would expect so, if it's a pure-parts mod. However, it's not one I use myself, so I'm not sure.

Part mods are almost universally forward compatible. There have been a couple of breaking changes to parts in KSP's history, but only a couple, and only to certain types of parts. Code-based mods (mods with .dlls) are *usually* compatible as long as the underlying version of Unity doesn't change - but may have other issues on a mod-specific basis. Expect them to nearly always work within a release series (1.7.0, 1.7.1, 1.7.2, etc), and likely to work if the version of Unity didn't change between release series, and to require at least a recompile (usually - not always) if Unity did change. The Unity version changed from 1.7.x to 1.8.x. Specific mods will likely have something in their threads on their own take on the issue, and part mods that depend on a .dll mod may work with newer versions of the .dll or not.

Do you mean while building it? No mod needed: Pick up the part of the vessel you want mirrored (from the root of the subassembly), turn on mirroring, then re-attach.

Actually, that station doesn't look to bad for that. Put an engine after the greenhouses, disable/remove any other engines, undock any docked ships, transfer fuel to the orange tank to balance the solar wing, and you should be able to push directly through the CoM, so just take it nice and slow.

For all the Apple hate: A comparatively-speced and performing Windows laptop will be priced similar, from what I've seen. And while it's annoying that Apple has dropped the ability to upgrade their laptops, the actual hardware is quite good usually, and if you think and plan what you want/need you'll get a good machine that will last and hold it's value. I run KSP just fine on my Macbook Pro. (But I bought my laptop knowing it was going to be my main computer, and that I wanted to both work on it full-time and play games like KSP or XCom2 on it, so it's speced to match.)

He said he's on a MacBook Air - Apple's least-upgradable, least-powerful, machine they make. IIRC, it's glued shut.

I've played KSP with some very slow machines - much slower than your new Air. Your problem is likely RAM - if you got the base Air, you had 8GB of RAM, and the OS needs at least 4. So even at best you'll be in swap. Unfortunately, the Air can't be upgraded with more RAM. I'd nearly recommend a cheap Linux laptop just to run KSP.