Stoney3K

Unless there are some turbopumps in the SABRE as well, an alternator would only work in subsonic airbreathing mode, since an alternator needs something that turns to work and ramjets/rockets don't generally have turny bits that can spin an alternator. Only turbojets or turbofans do. "Rocket alternators" are powered by the turbopumps spinning, which would only be a viable scenario if the engine in question has turbopumps to begin with.

You really don't need the retractable solar panels, just use the unshielded ones. Saves on cost and not hauling unnecessary weight. The way you attached the lander cans right now is not really going to work, docking ports need a port at both ends to be useful. Attach the cans directly to the station and have the docking ports face outward. Just a single docking port inline with a stack is (in most cases) fairly useless.

This could very well be the case. The ModuleAlternator depends on the amount of engine thrust related to its maximum thrust to determine output, but the RAPIER has two modes and therefore it does not have a "predefined" maximum output. It could be a related issue to when you build a craft with only RAPIERs and try to look up its stats in KER, it will only show zero Delta-V. So there may be an issue with detemining max. thrust there.

I have never been a fan of procedural wings. I kind of like the Lego-style wings, it's just a shame that we've only got tiny wing parts which are suitable for Mk2, but not for Mk3 aircraft.

Just this very thing, nuff said. When flying skywards with an SSTO which only has RAPIERs as main engines, you will run out of EC quick with no capability to recharge, leaving your ship completely steerless in the upper atmosphere. That's kind of silly, because every turbine engine in existence comes with an alternator for auxilliary power. If you build an SSTO with Whiplashes and a Terrier you have unlimited ElectricCharge on the way up. Was there an intended game decision not to have an alternator on the RAPIER engine, or was it just an oversight?

How is such a thing an "exploit" in a single player game? The fact that it may offset career balance in favor of someone grinding rescue or tourist missions does not change the balance against your playing style. There are a lot of parts that I consider to be useless while other people consider them to be really useful or even exploitable. In my playing style, I would not pair a probe core with a 1-Kerbal crew pod to do rescue missions or run tourists, because I find those missions to be boring very fast and sending an unmanned taxi somewhere is not realistic. But that is my playing style, and I am not going to claim that some parts are out of balance because they don't suit my style of gameplay. Also, there is no difference between such a part and the Mk1 Lander Can that serves the same function in the game right now. Just strip the reaction wheels, Monoprop storage and batteries off the lander can, and adjust its weight accordingly, and we would at least have a part that fits in the visual style of all other 1,25m / Mk1 circular parts. For example, if we make this part the same weight as the Mk1 crew cabin but have only a capacity of 1 Kerbal, it would not become worsely balanced than it is now. For the record: The Mk1 Crew Cabin *does* have hatches, in fact, it has one at each bulkhead end (at the attachment node). So if you want a super light exploit, slap a probe core on the side of the Mk1 crew cabin using cube struts or radial fuel tanks, leaving one end free after decoupling, and you can do exactly the same as the proposed part.

Well, there is an easy way out: If we have a model of an airlock/hatch, we can just make it a 1-Kerbal crew cabin with a hatch much like the Mk1 lander can but flatter. We'd need no additional code changes to make that work, you can just transfer the Kerbal you want into the airlock and EVA, since you can transfer crew to and from anywhere. Having a 1-Kerbal capacity on such an airlock is valid enough: The little green guy (or girl) needs a place to suit up and decompress for EVA, right? It's not like they're floating around a science lab wearing their space suit and helmet. The part does not have to be physically large enough to fit a Kerbal, but at least have the proper MODULE {} directives in the part file to seat at least one, and have a hatch collider. Look at the Mk1 lander can or Mk2 crew cabin for examples.

I suspect the mechanism could be very simple: * Kerbal XYZ wants to get on EVA, is seated in an MK1 Crew Cabin. Currently, this would just render a "Hatch obstructed, can't exit" error message. * Search through the part tree if the part nearby (up or down the stack) has an unobstructed hatch. * If not, repeat with one part down the tree (imagine Kerbal XYZ just climbing through the corridors of a station.) * Is the part tree exhausted without finding an unobstructed hatch? Display "Hatch obstructed, can't exit." * Is there an unobstructed hatch in our search? EVA said Kerbal through that hatch, invisibly transferring him to that part first and subsequently doing an EVA. For a Kerbal wanting to enter through a random door in a module that is completely occupied, use the same algorithm to find an available seat. The whole idea could be augmented through mods like Connected Living Space which limit the parts through which a Kerbal can transfer.

This, or add a dynamic that Kerbals can exit through the nearest neighbouring door, and board into the nearest available seat which may not be on the part they boarded. That would also make it viable to add a dedicated door, air stair or airlock part and strip the Hitchhiker and science lab of its doors.

It would be more realistic to have the landing gear apply massive amounts of drag once they're touched down on grass and have the plane burrow its nose in the ground, snapping off the front gear. Less weight on the wheels means less drag on rough terrain so if you want to land on the rough, add plenty of wheels, think Antonov 225.

If you mean license concerns: If a mod gets purchased by SQUAD the license bets are off. Previous versions of the mod may still be licensed under the original mod license (or fork into a "community" mod with said license) but the purchased code can be under proprietary license, since the original modder, and consequently SQUAD, retain the rights to modify the license of that mod at any time. A copyleft license on a mod does not mean that any possible future versions of that mod are locked into that license, neither does it enforce that license on SQUAD if they decide to purchase code from a mod. They would become the rights owners, and hence, have the rights to relicense the mod under any terms they see fit. Were SQUAD to incorporate code of said mod into KSP without any further negotiation with the rights owner (the modder) it would be a different matter since SQUAD would be bound by the license terms like any other derivative mod. "Purchasing" a mod and incorporating it into stock KSP is perfectly possible, if the mod does not depend on any other mod(s) with licenses that disallow it and the mod owner agrees with it.

I agree. In the VAB, you have all the information you need to calculate TWR and dV, but you still need to do so on a piece of paper. The 'not wanting to run out of gas' problem is exactly what causes novice players to overbuild rockets with enormous TWR values and fuel tanks enough to circumnavigate the Kerbol system three times over, just to drop a lander on the Mün. Which in turn is a major cause of said rockets becoming uncontrollable. When building spacecraft, less is more, but to do that, you need some information on where your lower bound of that 'less' is. Making your upper stages TOO light means you're gonna run out of gas in mid-mission, wasting game time, satisfaction and resources.

I'd stretch that even more: IMO, if we want to have optimal building freedom, we would want to have ANY part surface-attachable. If you can surface-attach whatever you want using a cube strut, what's the point of having a restriction on surface attachment in the first place?

Exactly that. Right now, with the stock SAS it's all but impossible to fly "exactly 90 degrees east, 10 degrees pitch up, and wings level", you can only approximate that manually by pointing your nose in about the right direction and hope for the best. I don't really need Ascent Guidance or a Maneuver Planner (although a tool that shows me where the best Hohmann transfer window is would be great) but something that allows me to steer a craft with some degree of precision is really appreciated. A better SAS would also give you control over where your PROGRADE vector is pointing (ie. where you're actually going) and not just where your nose is pointing. If a crude autopilot can control that, it would be less tiresome to fly straight and level for 10 minutes (prograde on zero pitch would just hold altitude) or to track a nearby target in orbit (keep prograde on the target and you're going to hit it bang on).

Action groups on fuel tanks? Enable/disable and feed-in/out? Yes please!

With cheats this is super easy, just build a random pod and slam it into Eve's atmosphere straight from interplanetary space.

In a different perspective: Do you pay the EXACT same amount, dollar for dollar, for the game in the KSP store as you do from Steam? If not, then the Steam users paid extra for it to compensate for Steam's profit on the game, and this extra money gives them access to perks like the 1.1 beta. I suspect Squad could strike a deal with users from their own store to pay the difference and get a Steam key, so Steam can earn their share instead of giving away the keys for free.

I don't think I'd want MechJeb in stock, but some degree of precision in my control would be nice. Right now the only control you have over attitude with stock SAS is to use the stick and to eyeball it, where you can only see the result (not even the target attitude) on the navball. The same with maneuver nodes -- you can only do a rough approximation of the node you want but it's hard to get any precision out of that. A numerical control panel which allows the player to punch in numbers for exact attitude, and for maneuver nodes would be awesome, something similar to RemoteTech's Flight Computer gadget. It's part of even the most basic of spacecraft so IMO it should be part of the game.

Why not make some bandwidth available for the non-Steam users who really want to test 1.1? If the Squad servers can't spare the enormous bandwidth demand, people will just have to wait in line for the download, or distribute the 1.1 prerelease via peer-to-peer networks, e.g. torrents with some means of copy protection. So if people purchased the game through Squad and really want 1.1, they can just get it from the website with a big WARNING message that the download may be slow and you may need to wait for a bit until you can download. Restricting access to the prerelease to Steam users only is going to help nothing, it's only going to cause copies of 1.1 to show up on big pirate networks. Sincerely, a Steam user.

You can say the same thing about the Wheesley which is not really useful for SSTOs either. Unless there are going to be career goals that say "Land this payload or this tourist on location X", there is absolutely no use for subsonic aircraft. Which raises the question what the stock Mallard is even used for. I mean, airliner parts are cool, but I'd like to do some more things with them than just circling around the pattern at KSC runway 09/27. That gets boring pretty quick.

I don't see why existing users who purchased the game through the Squad store can't get a key to register their existing copy of the game with Steam, though. All people who already purchased KSP before it got on Steam should be entitled to a key which allows them to download the game through Steam if they want to. It's a bit ridiculous that Squad wants them to buy another copy just to have access to the game on Steam. Is that *really* a technical matter or an issue of negotiating proper distribution rights for the profit margin of Steam?

He didn't say anything about timewarp though.

The easiest starting point is to use inward feeding using fuel lines: Since tanks drain from the furthest away to the closest (seen from the engine), you can abuse that mechanism to keep your CoM higher up. Put a small fuel tank at the top of your core stage and have the side boosters feed fuel towards that using a fuel line. The core will empty that tank first, causing the fuel in the boosters to flow upwards and top up the tank, shifting the CoM upwards. Once you dump your empty boosters, you're already far enough up to have less effect from aerodynamic drag, and you've got a full core tank of fuel at your disposal.

Surface-mountable (jet or RAPIER) engines. Since we don't have pivot joints right now, if you want to build a VTOL, you're left with sticking Wheesleys on the surface of an aircraft and half of the engine (and attachment point) sticking out the other end. Junos are too underpowered to be of any use for VTOL, and the other jets are too heavy or bulky to be integrated into any aircraft. They also lack the gimbal range required for decent VTOL flight. So some engine we can surface-attach, has a massive static thrust but a rapid falloff with speed and a large gimbal range would be great. Oh, and one tiny but really useful tool: A decent part editor with documentation for all the parameters. Just sayin'.

Which leaves you with an ugly-looking decoupler/girder left over on your craft. The launch clamps are fine if the offset tool would actually work as it should on those parts and not clip the launch clamp INSIDE your craft when you try to move it. Having a part that would act as a "launch tower" which can also transfer crew or fuel would even be better. The Stability Enhancers would then serve as ground clamps.