KrazyKrl

I think this small issue shows a problem with the in-flight part selection system. There is no way to give multiple parts the same shared command concurrently. I.e. OP's problem. Or even something like setting the brake torque on landing gears. What should be available when selecting multiple parts with shift or alt (or Shift+Alt Click); is it creates a dialog on the last part clicked; that contains any option shared between all parts selected. (Or maybe an extension of the current part multiselect, that when alt is depressed with multiple part selections) Multi-edit mode should be a "collapsed tooltip with header only" tooltip on the "slave" parts; and on the last selected part, it should have a window with only the part configuration entries that are shared between at least 2 of the selected parts. This could cause weird tooltips that would never exist otherwise also. Example: You could make a selection of all gear and engines, and be able to set your brake torque and gimbal range with only a single tooltip open.

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.

In my opinion, there are a lot of things that should be improved upon with the new, unified, UI. But this isn't the time to add features... First the current features need to be redone (and refactored) in the new engine, as shown by HarvesteR's updates on the wheel subsystem. There will be plenty of time for new features after the existing features are all ported over .

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.