KrazyKrl

The barn was obviously unfinished, and should not have been RC. But as a game-play standpoint, the barn would have easily worked into a tutorial/starter area. With Jeb/Bob/Bill at the helm, under the tutelage of Werner Von Kerman on speed dial. Something like make it halfway around Kerbin and above 70km, and you get government approval for a space center. Of course science would need to tie into this, maybe mandatory, contracted, launch testing for the most basic SRBs/T30s, 100/200 fuel tanks, Stayputnick.

I would increase the granularity of the damage. i.e... High Threshold for Destruction Destructing parts keep their mounting location if the parent part still exists. (Shipping replacements!) Can only replace Destructed parts when parent part is 100% functional. Very low threshold for impact damage, and a decent level for G-Loading damage(G loads inherited from parent.) (Something like fragile solar panels touching ANYTHING and they damage) Depending on how damaged a part is, the higher level of Engineer you need. The base required level of Engineer for repairs could be tied to the Science Level of the item, or its complexity.

Since everything is named Kerman anyhow... Why not just name "funds" "Kermans" And decimal Kermans could be like Kermcents. (Kercents sounds too much like Kerbal Percentages)

Random failures are a terrible mechanic for this game, and will never be implemented. Now, "banking" science points on a station would be amazing. And using a module to create bonus science points would be neat. Of course, the lab would require ABSURD power to do so. i.e. You get munrocks, transfer them to a .625m/1.25m/2.5m science capsule. It takes so many electric charge to give you some points of bonus points to the object itself. So, you can get to the mun, land, eject to Kerbin, rendezvous with your space station, do some zero-g experiments for some bonus points, then use a deorbit capsule to return the data and/or rocks to Kerbin. You can even extend this idea to other planets, once you are high enough in the tech tree, you unlock interplanetary science laboratory modules. Testing Munrocks on Eeloo? Yep! Taking Tylo rocks to Moho for analysis? Sure! Of course, you can use some type of bonus according to the delta-v you need between planetary bodies to calculate the bonus science you generate per item.

Even without docking ports on my crafts. KER doesn't seem to want to calculate delta-v. And the same data is stuck in the window regardless of what vehicle I load into the VAB/SPH. And it persists through relaunching the game. I think removing the plugindata resets the plugin, but it gets stuck on the first craft I load again. It could be related to the runonce plugin bug. Because I am using Node Select, Kerbal Alarm Clock, Editor Extensions, TAC Fuel Balancer, KSPX, Docking Port Alignment, KW Rocketry, and ScaledSpaceDumper. There is bound to be something conflicting in there. I just hope cybutek does at the very least, a bugfix update after .22 is released. I know he has other obligations, but it would be nice of him. I haven't played much KSP since KER broke on me, I love it to death; if there was one mod that I would keep, it would be KER.

IVA already has most of this data, Radar Altimeter being one of them. Vertical velocity indicator is in both screens. (It's the gauge thing to the right of your altitude, 9 o'clock is 0 vertical speed, logarithmic scale.) Horizontal velocity is easily extrapolated on the navball, and is also a function of your vertical speed. More prograde deviation from heading == more horizontal speed compared to your vertical speed. Kerbal Engineer is what I have used to calculate most of the info I need for normal operations. (Too bad it's currently broken(as of Oct,2013).) I agree with IVAs needing a bit of love after the maneuver nodes were added. But, in my opinion, are a low priority compared to the rest of the features that need to be added to KSP (SCIENCE! being the next one.) You can check out SteamGauges(I think) if you want a nice looking set of HUD Gauges.

I would be all for some type of reinforcement tweakable when tweakables are added. Something like "tweakable submenu" -> "Reinforce connection to part X" (Adds Y mass to craft, makes connection very rigid.) Adding mass for making connections more rigid is a completely realistic, and I don't see why it couldn't be used; at least for small items that are, say, less than 2 tons. As for the multinode connection system, since crafts are bound by the tree layout for parts; One parent to many children must be maintained. Therefor, in a later update, I see no reason why multi-node connections between a parent to child interface wouldn't be added. Squad could use something like Interferometry with multiple interfaces.

Would make sense for ejection seats when tweakables are added. Tweak each seat to RCSPack or Ejectionseat. Where Ejectionseat replaces RCSPack with a small solid rocket (for zero-zero ejects, with thrust vectoring), and a Kerbal Parachute. Now that I think about it, the Kerbals could ALWAYS be in ejection seats in-atmosphere. And the EVA could always wear the RCSPack. Ejection seats are a one-way abort anyhow.

Very nice, but I can't see the cowboy hats If the background flag was removed and replaced with something less busy, and the top hats were sitting on top of, instead of nested around the hats, it would be a winner.

Viewing all the flags made by all yous people, makes me kinda jealous. Fantastic work. I'm looking for a flag for myself though... - Commander Fishstick shall be in the center of the flag. Backround removed, of course. Only Hat, Head, Body, Arms, and Flippers. - Trivette and Walker (Left two characters, respectively.) Heads and hats only. - Trivette and Walker are on either side of the commander, left tipped to ~11 o'clock, right tipped to ~1 o'clock. i.e. T-Cmdr-W or W-Cmdr-T (whichever looks the best) - All must be wearing monocles - All must be wearing top hats in addition to their normal hats. (i.e. top hat on top of their hat.) I'd prefer to do it myself, but I'm no designer. And the work done in this thread is AMAZING. Source Images: Commander Fishstick: Walker: Texas Ranger

I'd much rather see the actual tech tree become breakthrough-centric. Having custom parts from breakthroughs only ends up obsoleting other parts. Every piece needs to be useful in some place or another, and limiting them seems poor design. Now, if the game was split up into breakthroughs; you could still iterate through the next available tier of upgrades. But to progress any further, you need to apply what you've unlocked towards the next breakthrough in technology. I.e. Tier 0 is starting, you unlock several basic parts. Plus several others via SCIENCE! points. Tier 0 culminates in the ultimate upgrade for its tier, decouplers. You use this new knowledge of multi-stage rocketry to attain the next tier. Tier 1 requires you to reach a minimum orbit of 80kmx80km of Kerbin, this breakpoint enables some more stuff also. Tier 2 could be a flyby or landing on another body. Tier 3 could be Interplanetary flyby. Tier 4 could be Interplanetary landings. Tier 5 could be fully interplanetary space travel. I'd MUCH rather see a system of large achievements to enhance your space program. The point being, you can have tiny goals for, say, getting that landing gear unlock. Or you can spend your science points in the prerequisites for the next tier of space travel. And make that next big breakthrough in technology level.

More keyboard shortcuts would be amazing. The problem isn't adding the hotkeys, it's making them easily apparent. Say... {cFFFFFFFF:<colored text>} Where the brackets and "c" is literal and FF,FF,FF,FF is Alpha/Red/Green/Blue, the only problem is escaping the closing bracket... Of course, this would be saved as a string internally, and parsed on load.

I can see many parts being condensed when tweakables are introduced. The models could stay the same, just the artwork wrapping the parts would change. Say, you took a rockomax 2.5m decoupler, and tweaked it to become a separator, it could use the blue artwork, instead of the yellow. Same with the radial decouplers. You could also extend that to fuel tanks for oxidizer/liquidfuel/monoprop/xenon.

Types of science would, of course, be a requirement. And as for recovering science, I believe you should have the availability to move ScienceResources between vehicles nearby. Until something like KAS is implemented in unmodded KSP, you may need to take a manned mission to your rover, and recover science with a Kerbal.

Naa, it would be easy to limit the procedural tanks to set limits depending on your tech level. And, of course, the rigid tanks would be cheaper to use, but contain a set amount of resources. Having procedural tanks and other devices is pretty much a requirement, the part count is already near the point of absurdity for large crafts.

I posted this in another thread, I think it works in this one too.

I'd prefer procedural parts to fill the gaps. There is a reason NASA stuff tends to be hand made. Procedural: Fuel Tanks Girders Structural Elements Wings Fairings Parachutes Landing Legs Wheels Ladders Docking Ports Bi-Tri-Quad Adapters Batteries All would be AMAZING to get JUST that part you need.

Well, since physics are disabled on crafts, and they are on rails, and they are static in their reference frame until within 2.5km. I don't see why each craft couldn't have a simplified 1:6000 render for overlay into the map view that would be saved the last time it exited 2.5km. And it would only be added to the scene as a render if the distance makes the object more than 1 pixel in size, else it could just be an anomalous white dot in space. Seeing your other crafts as moving "stars" would actually be quite amazing. But is only really eye-candy, unless you're doing a rendezvous.

I would suggest something like a part that has like 16 Kerbits of data (magnetic coil memory?). And can only talk to the part it is connected to, and any parts connected to the parent. So, you could, say, give an order to the decoupler on your fuel tank to fire after the fuel is out, and to automatically fire drogue/main chute at the altitude you want (would need tweaking of persistence of game debris outside of the physics area). The size limit on the code it's carrying could increase over upgrades you research. And the language used could be the same C code used everywhere. There is no reason to make up some obscure programming code for it. The main problem with adding something like this; is limiting it early game, so you don't end up with fully automated everything.

"When in doubt, give the ability or decision to the users." I'd recommend the addition of a drop-down where you can select user-named classes. i.e. [checkmark/nockeckmark]Unnamed Group (0 Ships) final line would always be "add new group". Later, they could improve the interface a bit more. A simple, extra, dropdown would be useful for the short term, and pretty simple to implement.

Something like that could be added to a tutorial to KSP. And would be nifty for starting players. But this is all something for a later version of KSP. And having more in-depth tutorials would be AMAZING. The game is very much in active development, and all the features aren't even in the game, let alone a guide to using them. Tutorials are more for the "polish" and "near release candidate" dev steps. If persistencefile <> exists then msgbox("It looks like you have not played KSP before, Play tutorial first?" Y/N)

Now, compressing all the textures into the standard directx or similar format for decompression on your videocard itself would go a LOOONG way towards performance. As it stands now, it uses raw images that it loads into RAM.

With the SAS tweaked, it should be default enabled on all launches. Before, SAS would return you to the held trajectory when you release a key to change your direction. Now SAS will update its direction to wherever you intended to aim. SAS is now, properly, a resistance to unintended trajectory changes. And as such, would be helpful to have default enabled. Further fixes for SAS would be useful, like making it more aggressive the farther it is off of your intended vector, but still having "Gaussian blah blah" to stop the yo-yo effect. A simple message on-screen for when you enable/disable SAS/RCS would be helpful. Somewhere near the time warp text. All it says is "SAS Trajectory Assist Enabled. Press "T" to Disable." and "Reaction Control System(RCS) Activated. Press "R" to Disable."

Having locked assemblies would be neat. You could recover an assembly from somewhere, and use it as an entire assembly. They could automagically appear in the sub-assembly library. And have something like "Total cost (SalvagedQuantity)" i.e. "DockyII" [Cost: K$3,000] [1 Salvageable(K$1,750)] And, of course, using salvaged assemblies would have an additional bonus savings. There would need to be some type of cost-bonus applied to each part interface. So if you salvage a BACC booster with nosecone, chute, and blown decoupler manifold; it would be a bit cheaper then salvaging each part individually. Salvaged assembly as-a-whole cost mechanics is an inevitable addition that adding reusable parts would need to have added to the game.

I wouldn't suggest a binary fail/nofail from radiation. I'd suggest a metric that decreases the effectiveness of some devices, and with poor radiation shielding/radiation hardening; they would be less and less effective over time. They would never fail completely, but they would become less effective over time for each unit of radiation. Think of it like the overheating system for engines, just that instead of exploding when they overheat; they become minimally effective. Say, 25% of what the part is rated for. Of course, you could research improved radiation shielding, and later, the lighter radiation hardening.