jwbrase

A couple things I'd like to see are science experiments with secondary benefits and a few of the more common real life experiment types. For example, one big thing that real life probes do is imaging. So you could have camera parts, and for a given planet you'd get so much science per square kilometer imaged at a given resolution (with resolution being a function of the imaging abilities of the camera part and the distance to the imaging target). But in addition to science, youcould also get other benefits from imaging: Pretty pictures are good PR, so imaging could contribute to reputation. Also, as things currently stand, you get full-featured maps of each planet from the get-go. With imaging science the player would start out with a high detail map of Kerbin, a mid-high detail map of the near side of the Mun, a mid detail map of Minmus, and low detail maps of Duna and Eve, with everything else being completely unmapped. You would need to map a planet to locate biomes and potential landing sites, and surface contracts for a body would only be given for mapped regions.

I'd have a fair number more binary fails than either Snark or KrazyKrl mentioned: For example: as I understand it, real world engines with moving parts (jet turbines, rocket turbopumps, reciprocating pistons, etc) tend to fail when overheated in a fairly binary fashion: the engine works for a while at fairly nearly full performance, then some component suddenly catches fire (necessitating shutdown) or seizes (or even explodes). I'd tend to have control surfaces and reaction wheels jam completely as well. I'd probably do the same for solar panel rotation, though I'm not sure that solar panels wouldn't tend to fail aerodynamically before they failed thermally. For parachutes I'd have max drag until the part reaches its disintegration temperature, but I'd have the "risky" and "safe" parameters for chute deployment become more restrictive as the chute takes more thermal damage. For fuel tanks, it might be fun to have the game actually model the vapor pressure of the fuel and have tank failures be pressure driven: for slow heating, safety valves vent pressure, allowing the tank to cool evaporatively and causing fuel levels to decrease. For rapid heating, pressure builds faster than the safety valves can release it, and the tank fails explosively.

I'd actually have 3 critical temperatures for a part: 1) Functional failure: If the part does anything special, that function stops working permanently (command modules stop providing control, kerbals in command modules or other crewed components die, engines will no longer produce thrust, decouplers won't fire if this temperature is lower than the other two temperatures, propellant tanks start to overpressure and begin venting propellant through relief valves, etc). 2) Structural failure: The part detaches from all attached parts. 3) Disintegration: The part explodes. For light components that might do too much damage breaking fre, like thermometers, the disintegration temperature could be made lower than the structural failure temperature.

I think the term we're looking for here is "misfeature". My take on this is why not make most spaceplane components act as bidirectional fuel ducts and use rocket-type fuel flow dynamics for jets?

From my observations (though I haven't heard it confirmed anywhere), the contracts that have no expiration date and don't allow you to cancel don't seem to actually eat a contract slot, don't even have a decline button, and you get the rewards for fulfilling them whether you actually accept them or not (note, for example, you can fulfill multiple speed/altitude/distance record contracts in one flight session). While you've fulfilled this contract, it might be useful to know for similar contracts in the future. They seem to be complete freebies.

That still won't help if your tug is manipulating a much larger module that pulls the COM of the combined stack past the tug's forward RCS thrusters. Yes, one can put RCS on the station module, but RCS, while not exorbitantly expensive, is not completely cheap either. It would be preferable to have all the RCS on the tug.

Tugs can sometimes have trouble towing station modules around due to the center of gravity of the tug-module assembly being far from the RCS thrusters, causing all kinds of undesired coupling between rotation and translation. An interesting solution to this would be an RCS part that can be moved by Kerbals on EVA (perhaps generically, perhaps as an engineer skill). The idea would be that the player could build a tug with this part, dock the tug with a station module, then move the tug's RCS to line up with the center of mass of the tug-module assembly.

I have two interesting ISRU ideas: One for Dres and one for Eve. The Dres idea is fairly straightforward: Have a special ISRU resource that Xenon can be extracted from, available only on Dres. This would allow players to get a fairly cheap source of Xenon by mining Dres, which would encourage exploration of a planet that might otherwise be considered out of the way. The Eve idea is twofold: First, since Eve's ocean biome is called the "Explodium Sea", have liquid fuel be an ISRU resource that can be directly and quickly collected by craft splashed down on Eve without any intermediate processing. Secondly, have jet engines work on Eve, but instead of using atmospheric oxygen and onboard fuel, have them use atmospheric fuel and onboard oxidizer on Eve. Potentially one could also have a "fuel condenser" part that used copious amounts of electricity to extract liquid fuel from air gathered through intakes on Eve, to allow craft landed inland on Eve to also extract liquid fuel, although more slowly than craft landed in the ocean and with much steeper power requirements.

I've had a similar idea wherein the NERV has open-cycle and closed-cycle cooling modes. In open-cycle mode, it behaves as it does currently (your idea is nice from a realism perspective, but I'm not sure I'd want that much complexity in engine management). In closed-cycle mode, it provides no thrust, but acts as a source of copious amounts of heat and electricity (say two or three times more than the existing alternator output). If more than a certain amount of fuel is available in attached tankage, the heat is transferred to the tankage and can from there be disposed of with radiators. If insufficient fuel is available, no electricity is produced, and the heat builds up in and quickly destroys the engine. (Basically, in closed cycle mode the NERV is acting as a nuclear power plant and needs a source of coolant, which the fuel provides. The fuel is recycled in closed cycle mode, so it's not used up, but enough of it has to be present to fill the cooling loop). The idea is to make the NERV provide more than enough power to large spacecraft that are already using a NERV for propulsion, but, due to the weight of the engine and the fuel required for coolant, not have it be a great option for smaller spacecraft, especially those that can use an engine with less ISP.

IRL, the cheapest way to drop something into the Sun is to send it by Jupiter first. Not really. You want to send yourself in a direction opposite to the way Jool is orbiting. If your Apoapsis is in Jool's SOI, your Jool-relative velocity vector approaching Jool will be opposite to the way Jool is orbiting. Your Jool-relative speed leaving Jool's SOI will be the same as your speed entering Jool's SOI, only the direction will change. As a consequence, a slingshot cannot provide you with a Kerbol-relative boost in the same direction as your Jool-relative velocity entering Jool's SOI (conservation of momentum* is a royal pain in the neck ). Thus, you want to arrange your Jool encounter so that you're approaching Jool from a different direction than you want to be boosted in, and preferably for a fairly high encounter velocity. One thing that you may want to look at, time and transfer windows permitting, is one or more Eve slingshots to boost you onto an orbit that sets up your Jool encounter. Another thing to consider is that you may be able to get around the "no boost in your approach direction" bit with a sling off of one of Jool's moons. Nope. Same dV to leave Kerbin, more dV to launch into that orbit.

This doesn't relate directly to a bug in KSP, but rather to an issue I encountered while trying to report a bug on the bugtracker at http://bugs.kerbalspaceprogram.com/projects/ksp/issues , and didn't know where else to report. As stated in the thread title, I registered, but did not receive any activation e-mail. I double checked to make sure that the e-mail address the registration screen reported having sent the e-mail to was correct and checked my spam folder. I also attempted to reregister with the same credentials and a different e-mail address, but that of course errored out on account of the username being a duplicate of the one I had already submitted. When I subsequently registered for the forums, I received an activation e-mail at the same address instantly. I'm not sure this is the best place to report issues with the bugtracker, but I couldn't find any instructions on where to report such issues on the bugtracker site itself.