KrazyKrl

I'd suggest an extension of the action groups for throttling engines. You have 10 "Engine Groups" which you can switch between via MODKEY+(1 through 0) i.e. just like action groups. All engines default into engine group 1; but may be reassigned.

Yes we need a dV readout, this is rocket science. IMO not having a dV readout is against the spirit of KSP... as KSP is a game about rocketry and space travel. This would be amazing if your experience could be rolled into the KSPedia. "Our Kerbal engineers designed this calculator to help with vehicle design, but the computer might get confused sometimes with complex craft; here's some of their workarounds."

Here's my suggestion about adding unlock-able craft files: They should extend the contracts system. Think of it like a "quick flight" option, where you contract a planned mission to fly with a specified craft. Reimbursement for the craft would be paid (along with a bonus) at contract completion. You can, of course, edit the craft in the VAB before the mission; but reimbursement is for the base craft as-given to you. Crafts gained through the "quick flight" contract should also be saved into a subgroup of crafts to load or launch. A bonus, in my opinion; would be if this system also had a "randomizer" feature to it (at a lower fund cost or higher reward)... maybe something like a CS:GO case opening animation with rocket thumbnails. "Congratulations! You're going to X on Y!"

Probe cores are small and light on their own... even large (and heavy) wings are surface attach. I don't see any reason to limit the functionality of a part; just to add an attachment rule in the VAB when building your craft. IMO all parts should support surface attach, node attach should be the unique thing with parts.

Other than the docking port snapping on physics load portion, this would be an amazing feature. Possibly with using a strut on two parts which their colliders intersect (since struts do about the same thing anyhow.) Essentially it would surface attach them without the strut. The cool part would be that just like docking ports, if you break or decouple the other node/attachment point; the craft should reroot through this surface attach point if it hasn't already broken.

This sounds like one of those features, which are amazing, but are horribly complex to code. I'm all for a replay system in KSP, implementing it would be a huge problem though. You would need to save every physics tick to get an accurate replay of what happened, because of floating point inaccuracies in the physics engine. You would need to save these during one of the most intensive periods of a crafts flight (collisions and destruction); this is assuming saving physics ticks for replay is even possible in a Unity game. Saving rendered frames would be easier, but with massive disk space cost; and probable performance loss. Saving just graphics brings a few other problems, inability to interact with the scene for one. I guess you could annotate the saved video with event log stuff. Yes, it would be amazing; and I would love this feature. The work behind a replay though... It might be easier to use something like NVidia Shadowplay to save videos yourself as a workaround.

My 2 cents: The fuel cells should have a "local only" type of resource that is hidden from the resources panel. Name it something like "Electrolysis Byproduct". You may not transfer this resource to any other part. Each fuel cell has its own max capacity of waste. When using fuel cell waste to create LFO; small cells should be about 50% efficient, large cells should be 70% efficient. You will still lose a significant portion of the LFO you split in the first place. The power drain is double what a fuel cell can supply when reversed. You cannot reprocess the waste of the fuel cell unless that fuel cell has waste to use.

Also, Expand maneuver nodes on mouse-over to show "projected burn time" bars that are dV-centered on the maneuver node. dV remaining while-burning would be nice also (i.e. additional bar that shows fuel time remaining, iteratively colored like patched conics for each stage with fuel in it.) Another cool thing, is adding a sort of "importance level" to said pips on the bar. Say you right-click the SoI change pip mark on RandLanderMk1, you select an option to change the SoI event to "Importance: Always Shown"... now that pip should be global on the timeline; regardless of which particular craft you are flying.

Just because a part is small; does not mean the max temp should be lower. The only thing that should be lower, is the thermal mass of the object. IMO, high-heat tolerance parts are like superalloys that have specific coatings, or cooling methods (Like air ducting in turbine blades.) Heating is kinda buggy in some places still anyhow... like docking ports not transmitting heat. 1800K Docking Port Sr. not dumping heat to its mate for example.

Both inventor and solidworks are owned by Autodesk I believe. I would like more of the keybinds to be reflected in the GUI in some ways. Stuff like trim, the VAB camera and view tools, symmetry mode, rotation tool mode, and disable node attach. Are a few of the more esoteric VAB stuff that should be reflected in GUI elements. This would require some pretty nifty GUI element "buckets" to be designed though. But it would make the game much easier for newbies, and people with accessibility issues (bonus points for colorblind compliance.) Having Symmetry/Snapping, Placement Orientation, and Camera GUI buckets also is a very good place to put tooltips that denote the keyboard shortcuts for each function.

In my expert opinion of an expert of explosions, yes.

You have my axe. I would also like to see that idea extended. I.e. "Science Archives" Becomes "Rocketry Museum and Science Archives". The science archives as they are now stay as a subset of the Rocketry Museum. World firsts should get their own section, along with any other flight you've ever had. The world firsts section should have something special, maybe something like the VAB/SPH "craft thumbnail" image of the craft; as it was when the craft broke the record. Of course, the Rocketry Museum would also track every flight you've ever had; the worlds-first section would just be the premier section.

I'd like some type of widget you could use via a control part. This widget would let you change the reference orientation for the control part, essentially "zeroing" the navball to another orientation. Bonus points if you're able to have, say, 2 or 3 differing saved modes for orbital/surface modes. Along with the ability to swap between them via action groups. Imagine being able to make a space shuttle that can VTOL on another planet via engines that thrust out dorsally (out of the cargo bay), then being able to swap modes to your aft orbital engines... And on re-entry being able to set your probe core to 30 degrees above horizontal to keep a reasonable reentry glideslope before returning it to the natural horizon for approach and landing.

The NERV is already quite balanced. It has a high dry weight, very low TWR, weird form-factor, no gimbal, and very horrible atmospheric ISP. Making a rocket is easy, making an efficient rocket is hard. Just because the NERV has 800s ISP, doesn't mean that it's even outside of the envelope for realistically usable engines in KSP. A whole radiation shielding system for literally one part doesn't sound like a reasonable use of game developer time.

This shielding argument has been discussed ad-nauseum since the introduction of the NERVA. Adding radiation doesn't add anything to gameplay, other than ship bloat. A rep loss due to losing a used NERVA would be plenty. Anything more along the lines of a radiation-shadowing and radiation sickness life-support subsystem doesn't seem fitting in unmodded KSP. I don't see anything "fun" about needing to mess around with radiation shadow shields. What does this add to gameplay?

I'd recommend that launched satellites get handed over to the company the contract is for. Then the crafts themselves get "hidden"; they still exist in your persistence file as a flight, but the crafts themselves never get loaded or displayed. This way, the contract craft can be out of the way for performance and other stuff; but still be accessible for contracts. The game just needs to calculate the satellite's updated position when the contract for the satellite disables the "hidden" flag; when you accept a contract for that specific craft. I can accept the craft "going missing" after control is handed over; a config entry could be added to "hide/show craft not owned by player."

Yes, I was suggesting another part entirely. Launch clamps stay. I don't think hatches being attached to the launch tower are really necessary. There are plenty of features that I can accept as an abstraction, like crew transfer, or fuel-duct-less fuel crossfeed; KSP is a game first and foremost. I'd just like to see another part where you can stabilize a tall craft, just like the Saturn V or space shuttle on the launch pad. Having it procedural like this would make the launch tower be a minimum of parts. Being procedural would also mean the launch tower won't get in the way of whatever absurd boomy-thingy you design (which is the entire reason the static launch tower was removed, the launch tower sometimes got in the way because you couldn't move it.)

This is what I would want in a launch tower: Launchpad has a default "launch tower path" for the launch tower to sit on the terrain. Maybe a 50m long tarmac or something, just graphical for the tower to "sit" on. New part in VAB: Launch Tower Segment, only can be placed to-the-north of the rocket. Launch Tower Segments can be moved, but are locked on a north-south path (identical to the launch tower path on the launchpad.) The launch tower automatically telescopes an "Umbilical Clamp" that provides support and fuels to that part (obeys crossfeed.) Placing more Launch Tower Segments on the launch tower adds more "Umbilical Clamps", May be placed anywhere along Z axis. Selecting the vertical tower lets you move the tower (and subsequently all clamps) in-and out. Selecting an Umbilical Clamp lets you move the clamp up-and-down on the tower.

It just never occurred to me that the actual CSS frame wasn't transparent, since dragging the image was dragging the background-colored frame with it; making it seem like the image didn't have transparency (when the image on the page itself does). Such a silly fix, for such a small problem. .ipsUserPhoto {background-color: transparent}

Bumping this, because it only has 21 views as of right now (and it's been over a week.) No comments either way about this problem. I'd imagine this is tied to IPS trans-coding the avatars to jpg or something, so I'm not that optimistic about any available fix (since it's probably tied to the backend of IPS.)

This is a stylish userscript. It is essentially an add-on to your webbrowser that lets you change some display aspects of the webpage. This is non-invasive, and cannot (in most cases) be used for malware. The userscript itself is the "config file" to tell the Stylish addon what to do with the webpage. You need the browser addon "Stylish" for your browser. (Firefox: https://addons.mozilla.org/en-us/firefox/addon/stylish/) (Chrome: https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en )

I'm terrible at this, lol. No prior experience with CSS or userscripts, so I made this up in the last hour or so. This will hide elements under your username until you mouseover it. (Saves some page space for 1-line or so posts.) I bet there is an easier, and more efficient, way of doing it. /* Hide portions of the Author Info until mouseover. */ /* Uncomment some of the next 7 lines to hide portions of the Author's information.*/ /*.ipsComment_author .cAuthorPane_info li:nth-child(1){display:none;} /* Hides Member Title */ /*.ipsComment_author .cAuthorPane_info li:nth-child(2){display:none;} /* Hides User Reputation Pips */ /*.ipsComment_author .cAuthorPane_info li:nth-child(3){display:none;} /* Hides Avatar */ /*.ipsComment_author .cAuthorPane_info li:nth-child(4){display:none;} /* Hides Member Ranking */ /*.ipsComment_author .cAuthorPane_info li:nth-child(5){display:none;} /* Hides Total Reputation */ /*.ipsComment_author .cAuthorPane_info li:nth-child(6){display:none;} /* Hides Post Count */ /*.ipsComment_author .cAuthorPane_info li:nth-child(7){display:none;} /* Hides Location Info */ .ipsComment_author:hover .cAuthorPane_info li:nth-child(-n+7) {display:list-item;} /* Required: Reshow All Elements on mouseover. */ And I slapped this together to hide the "Multiquote" "Quote" and "Like This" bar at the bottom of every post until you mouseover a post. .cPost_contentWrap .ipsLikeRep, .ipsComment_controls {display:none;} .cPost_contentWrap:hover .ipsLikeRep, .cPost_contentWrap:hover .ipsComment_controls {display:inline;}

Yea, even with disabled signatures, the username area of the page still causes each post, even if one line, to several inches in height. And for the bright white, on bright white, color scheme; I ended up downloading a firefox addon (Color that Site) as a work around.

With the change to the new forum software, the old avatars were downscaled to atrocious quality; requiring a higher-res reupload. Since the forums only allow a square image not exceeding 0.25MB; and my avatar is a weird aspect ratio... I was forced to add padding to either side (I did not want to crop the Admiral's flippers.) This is the image I used as my avatar, I believe the forums itself transcode and save its own version of the avatar for local use on the server. And unless I am mistaken, transparency is not preserved in the conversion. And transparency would be nice to keep weird aspect ratio avatars from requiring solid color padding or cropping, especially if an image is used for the "cover photo" banner image on your profile (like mine which is part of the HubbleUDF.)

While being a decent Xp gain on its own, this is yet another feature that could benefit from contract tie ins. XP from orbits/landing/EVA/etc. could stay; but the majority of exp should come from contracts that explicitly reward experience values. Contracts should be the thread that ties the entire game together as a whole, but right now; they are more of a separate system on-the-side.