KrazyKrl

Kerbin cup was never made stock, and I don't think Asteroid Day should either. Barring any limitations on the DLC system with steam and the like; I don't see why the "Official" Mods shouldn't be free DLC, at least in view of the distribution platforms used.

Now just add on right-click to that Alt key; to select the node you wish (Node selected should turn yellow or something, and be cleared when alt is released.) And there ya go.

I'd say make it an even 39.3395 m/sec. Because anything above that is kind of absurd for a ground vehicle on another planet. If you want to do short hops quickly, go suborbital in my opinion.

Another workaround is to EVA a Kerbal; then re-enter the ship.

Val, easily. Been launching Jeb into space long enough; I have his grin burned permanently into my mind. I'm still waiting for a Billena and a Shaquabobaniqua (Shaq-whaa-bob-a-niq-wa) to fill out an all female crew though.

An easy rule of thumb for cooling down your steep-decent craft; is to attempt to "aerodynamically stall" it. Aim at least 10 degrees above prograde, to turn some of your velocity into lift. You'll make your decent path shallower to compensate. Sacrificing airspeed for altitude is a win-win for reentries.

I think chutes should have 2 sliders instead of the speed/altitude sliders they have currently. IMO, the chutes speed indicator is kinda pointless; because you might open them high while moving slowly. I'd recommend instead a "Min Radar Altitude" activation setting. And a "kPa per sq. cm" setting. This would cause the chutes to properly open only after you fall below the stress threshold of the parachute. Because a speed limit means nothing, when you're in the high atmo; and pressure is almost nil.

I approve. The resource bar should be lockable, when locked; the resource bar should be overlayed with a different color, and draggable to a set amount (default is 100% locked, but draggable to less.) This would also be a quick at-a-glance bar-color feature for when you click something in the resource panel in the toolbar (i.e. showing all LF tanks; and some resource bars are shown as yellow or something, for being locked.)

Click on your orbit like you're placing a maneuver node. It should tell you the time to the place you clicked. Click on either side of your location, taaa da.

I'm imagining some UI feature that is toggle-able from the options (hopefully with U5, UI work will become much easier.) What enabling this feature should do; is overlay a small window with the most pertinent information on it only. This window should be translucent until mouseover/clicked in. This window should be anchored just below the maneuver node in the map view. It should be designed as such: %DD:HH:MM:SS to Node% %Node Orbit Number Delta% (Reflects the wait an orbit indicator. i.e. +0 for "this orbit" +1 for "next orbit" etc.) (These fields auto-modify each other.) %Node Angle to Prograde% (Positioning of the node, same as Ejection angle) %Node Prograde dV% %Node Radial dV% %Node Normal dV% All fields should be editable in my opinion. This would easily solve the "when, where, and why" that's missing from the current UI. I.e. in W days on orbit X, at location Y degrees; burn Z delta V.

Yes, terrain scatters need collision meshes. Hopefully some time after the U5 update comes out, terrain scatters will get their comeuppance. I've said it before, and I'll say it again: Surface sample collection should be in a different pool, depending on the type of terrain scatter, and its biome. I.e. a rock in a crater is not a rock in the flats, and the rock is not part of the crater science pool either.

Yes, I would love this. Adding at least some of the launch sites from KerbinSide would be amazing. Imagine having upgradable launch facilities around Kerbin. Nothing complex, most of the functional buildings stay at KSC; but at each secondary launch site... you could get an upgradable launch pad, and an upgradeable runway. There could also be a "tracking station" type building; but it could functionally be a way to upgrade the "telepresence" of the launch site. I.e. upgrading the "uplink facility" would let this particular launch site, get a lower launch cost penalty, and recovery cost penalty; because these sites are so far from KSC (and shipping rockets is expensive.) Another boon to this, would be even if you don't upgrade the launchpads or runways; you could upgrade the "uplink facility" at each secondary launch site. So you could gain more resources(not just funds) from recovering crafts in the area. It would be neat to see people start, say, a north-pole KSC career; the "Penguin Space Center"; and document their adventures with a polar launch site for career.

1.0.3 was said for a long time, to be more of a balance fix update; with some bug fixes thrown in. KSP needed a balance pass anyhow, it was only a matter of time. Citation Needed. Squad has said that post-1.0, KSP should not break save compatibility through versions anymore; but you should always back up your important saves before you update anyhow. If you have something important enough to lose, it's important enough to back up.

That's exactly what I meant. PN has too many niche controls for most people (myself included). The only time I use PN, is to use the editfields to perfectly tweak my nodes anyhow. We need something small, like an editfield window like PN has; for the nodes themselves, literally 3 text boxes that you can edit normal/radial/prograde with. As for the placement of nodes; I would like to see an expansion of the "rightclick" feature that lets you "wait an orbit". The node in this mode should have an additional prograde and retrograde control to it; which when pulled, would move the node in the direction specified (this should also be editable as per my previous suggestion.) Above the node indicator should be a text overlay of the angle to prograde of the maneuver node itself. This way, the node system has an "edit node" mode, and an "edit node placement" mode.

I'll just leave this here:

Nice job with the free-return trajectory. 6 m/sec dV is cutting it sorta close. That is well within the boundaries of trying to get a more efficient orbital insertion. Nice job nonetheless. That's a LOT of monoprop. You could dock probably 20 times with that much. Dumping all that monoprop would probably give you 500 dV or more.

PreciseNode should be stock in some form, in my opinion. Patching conics modes, and such, might not be needed for stock (I've never really needed to use them.) A "circularize orbit" plotter for the maneuver node system seems like a needless feature. A more beneficial feature would be a 0x time warp "pause". Because sometimes, you just gotta get that extra time to plan something. And you don't get a lot of time to plan your orbital burn when your apoapsis is literally 10 seconds ahead of you.

This would be amazing after they unify the UI with the Unity 5 update. Right now it seems like there is, and rightfully should be; a feature freeze on UI improvements. Why spend dev time on something that is a very minor issue; when the entire subsystem for said issue is currently being rewritten.

I always took stuff like crew transfers, and fuel transfers (and now heat transfers); as "this action implies an EVA, this function implies internal/external ullage, piping, and pumps." Some abstraction is needed for very low level stuff; needing to manually pipe your fuel tanks by affixing fuel lines around every I-Beam just doesn't add anything to the game.

Configurable letter decals on any part? Yes please. It would just be a simple tweakable to add (barring actually implementing the overlay texture on the part itself.) Just needs a single new option "Set Decal Text", empty string should totally disable the decal.

Simpler solution: In each situation, a drill has a max ore per tick it can produce and transfer. If freespace of all ore storage < 2 to 10 ticks of ore production, disable drill with reason "Ore Full".

Assuming the Nerv is 1.25m in diameter; and has an overall length of 3.136m. The Nerv weighs 3 metric tons. For a density of 780 kg per cubic meter overall. To get a, say, 300 kN Nerva; we would need to preserve that approximate engine density (or mess with ISP, but i'm ignoring that.) Which would need to be a cylinder massing 15,000kg. Assuming a 2.5m diameter form factor. A 19.23 Cubic Meter engine would need to be 3.9m in height. This form factor, and mass; is met by a Rockomax X200-32 fuel tank; with 270LF/330Ox removed from it. That's sort of insane for a 300 kN thrust engine. You're pretty much flying an 81% full Rockomax X200-32 as deadweight.

Decouplers need to use the new fairing system. The decouplers should autofairing to the part the engine is connected to, and to adjust their taper accordingly. I.e. in those screenshots; it would create a cylinder fairing. Example: If you had a 3m decoupler attached to a NERVA, which was connected to a 2.5m fuel tank; the decoupler should taper, and interstage, to the 2.5m fuel tank. Example: If you have a 2.5m decoupler attached to a NERVA, which is on an octag truss; the decoupler should taper an autofairing to the node-end of the NERVA. The fairing should be editable, the decoupler should act as a fairing base. The fairing should get jettisoned one physics tick before the decoupler activates in the staging sequence. (Or the fairing could be set up to be "Simultaneous or delayed" via a tweakable. i.e. the fairing does not auto jettison on stage activation. This feature would require the part to have two staging icons, or one staging icon with two staging events. (One to jettison, one to decouple.)) Decoupling needs to trigger a fairing jettison; but you may jettison the fairing first, through right-click (or action groups.) The fairing should be limited in height to the part it is decouping to. (i.e. you can only make it as tall as an engine or fuel tank.) (For dedicated fairings, you should use fairing bases imo.) And also, the fairing interstage needs to act like a strut via the fairing.

Check out some DasValdez or Scott Manley videos. You pretty much want the least number of engines possible for your purpose. Which means as low a TWR as possible, but still able to meet the mission requirements. TWR is dependant on if you're landing, or in atmosphere. In vacuum, most of the time TWR doesn't matter. Unless you're trying to accelerate quickly (i.e. direct launching to a station.) High TWR crafts are less of a draggy mess in atmosphere now. Just keep the mach effects (white vapor) away until you're at least at 15,000m or higher. You need to check out a few videos by someone like DasValdez; and use a mod called "Transfer Window Planner". This way you get efficient transfers, and it gives you all the information you need for the transfer burn; including how much prograde and normal/antinormal you need. Please please please don't use mechjeb, making mistakes is part of KSP. It's more fun to figure out stuff yourself anyhow . Use the afformentioned Transfer Window Planner for interplanetary transfers. Use Kerbal Alarm Clock to set alarms that automatically alert you to a specific item that needs your attention (the warp-to function has some bugs, and sometimes warps too far.) Precise Node is great to get your burns just right. And, of course, Kerbal Engineer; for all of your informational needs.

I agree that we need a decent early rover wheel. Possibly the smallest one as early as the tiny landing legs. This way, we have tiny parts to make tiny rovers. With a small fuel cell powering them, they could have very good range; even without solar energy from a tiny solar panel. And since the rovers will be so tiny, they can't carry large science experiments like the materials bay.