UberFuber

There's a lot of potentially good tweaks suggested. How about this one? Since the original "abuse" comes from the fact that you can keep cancelling contracts to get the one you want... How about have cancelling a contract takes a certain amount of reputation (perhaps 10% to 25% of the contract's own reputation penalty)? The idea is that your agency loses reputation if you keep telling someone outright that "no, you're not doing this".

I like NEAR. FAR may be a bit too realistic for new comer who may have trouble figuring out stuff like mach effects and such.

I think you mis-understood the meaning of trim. "Trim" doesn't mean you telling the pilot holding a stick at a fixed location. Trim, in real-life aircraft, is a setting that a pilot can set that sets a collection of control surface at a fixed offset. http://en.wikipedia.org/wiki/Aircraft_flight_control_system#Secondary_controls

I always like the suggestion that "massless parts" don't contain the mass themselves, but contribute them to the parent body they attach to. So if you have a 1 ton fuel-tank and adds an 1 kg "physic-less" battery to it, the fuel tank now weighs 1.001 ton (still retain the same center of gravity). The retaining same center of gravity can be explained away as the main body tank having its content adjusted to balance out the attached mass.

You are partially correct. http://www.braeunig.us/apollo/hybrid-profile.htm Apollo mission after 11 uses a "hybrid" trajectory. The initial trajectory did put the ship in a free return trajectory. After completing various system check, an additional burn is made to get the space ship out of free-return and "optimize" it for a lunar orbit capture (basically, they "slow down" a little bit early on so they save some delta-V when putting themselves into a lunar orbit). http://en.wikipedia.org/wiki/Apollo_13#Mission_highlights Apollo 13 needs to correct their course after the explosion because the explosion happen after the additional burn that took them out of free return. In short, the sequence went like this. 1. Apollo 13 on free return trajectory. 2. Apollo 13 perform burn to optimize for lunar orbit insertion. 3. O2 tank exploded. 4. Apollo 13 has to perform a burn to put them back on a free return trajectory.

I've one that's of the "forgot to check my staging" type, except so ridiculous that I facedesked a few times. Noob: Forgot to check my staging and accidentally decoupled my payload at the same time my lifter engine + SRBs are staged at full throttle. Extra Noob: Spent ten minutes trying to figure out WHY I don't have control of my winglets (payload somehow managed to stay on top of the lifter engine without falling off). Ultra Noob: Spent ten minutes going between VAB and Launch, trying to add enough struts to prevent my payload from "unintentionally decouple" from my lifters.

With that, we also need better filtering in the parts window. Especially with the possibility that we're getting more distinct "wing" parts. The current parts windows will just explode.

There are... a lot of possibilities here. First, as suggested by many, is a simple Right Click menu similar to fuel transfer. Second, also suggested by many here, is IVA. Third possibility is to make its control a bit similar to RTS. You click on a Kerbal to select it, and right click (or Alt Click, or some other key+click combination) on a part to "order" them to move there.

I think the suggestion adds complexity without adding much to the gameplay. Multiple issues with reusability can be resolved by tweaking the cap on recoverable amount. Yes, that will widen the gap between "recoverable craft" and "fully-reusable craft". However, if you're skilled enough to design and land a fully-reusable craft (and have the ability to consistently reuse it), I say you deserve that boost in fund.

I would argue that instead of placing a generic placeholder, just disconnect the section.

Depending on your angle of entry, that may not be a glitch but an expected behaviors. In fact... http://en.wikipedia.org/wiki/Skip_reentry In short, when you're entering the atmosphere fast enough, you can actually "bounce" back out the atmosphere completely without any additional external thrust.

I would argue to just go with ElectricCharge (e) as the unit of storage. The unit of charge/discharge should just be what the game is using right now (charge/second). First, you do have to distinguish between liquid and solid rockets. Liquid you can throttle and control, solid you cannot (you can only limit it in VAB). They're not minor but fairly major differences. Also, regarding "capacitor" type and "chemical" battery, as the way you suggested you do need to differentiate them, if not by player than by the game. Take for example, two hypothetical battery. Battery A has a capacity of 1200 e and discharge rate of 20 e/s Battery B has a capacity of 1200 e and a discharge rate of 10 e/s Let's say you have something that needs 12 e/s to operate. If you discharge all of it from battery A, you get only 100 seconds of operating time (once A deplete, you can no longer draw from B since it can only supply up to 10 e/s). Now, an obvious solution in this case it to draw from B first than (discharge rule, draw from low discharge rate battery first). However, if you have some odd combination is where you get into trouble. Let's say for a different battery combination. A: 1200 e cap and 20 e/s rate B: 100 e cap and 10 e/s rate Let's say you need to draw 25 e/s to operate (neither battery can fully support the electric cost). In this case, doing the reverse would make sense (20 e/s from A and 5 e/s from B, netting a max operating time of 20 seconds). However, if you discharge from the as in the previous scenario (low discharge first), then you only get 10 seconds of operating time). One possible solution is to order the batteries by the amount of "discharge time" they've left (charges stored divide by discharge per second, giving you number of seconds the battery can discharge at full discharge rate). At each ticks, the battery compute their "discharge time". Then, for each source requesting power, they "draw" from the battery that has the highest "discharge time" first. The same idea could be apply in reverse, for charging. Instead of "discharge time" you have "charge time" (charge capacity remaining divide charge per second), and each electric source charges battery that has the highest charge time first. Of course, all this added complexities means that there may be edge cases where some of this doesn't work.

This is a great idea.

Have you try Mechjeb? http://forum.kerbalspaceprogram.com/threads/12384-PART-0-24-2-Anatid-Robotics-MuMech-MechJeb-Autopilot-v2-3-1 It has something called Ascent guidance. If you've a fairly stable rocket, you can set it up to target a specific orbit. There's even a Rendezvous module that will get your two ships together once they're in orbit.

2001: A Space Odyssey? A planet seem a bit big and too obvious to be an "Easter Egg". Easter Egg should be something that's fairly small and hidden. One random generated name, a bizarre object somewhere, but not an entire planet. Perhaps as one of the randomly generated asteroid designation? So you can potentially get something like ORK-####

Option 3) would be for more advanced rocket builder. For most others, one can go with default value. I wonder if it's possible to have a button in tweakable that sets some sort of default setting. For example: 1. Heading Lock - Primarily a PI controller with D for damping. 2. Kill Rotation - Primary a D controller (to zero out rotation) and nothing in PI. 3. Custom - Allow player to set individual PID values within reason.

Current "On the rail" system means that unless the object is loaded (I think it's 2~3 km), it'll orbit indefinitely, even if the periapsis is within the atmosphere. So as long as you don't get within 2~3 km of it, it will never experience aerobraking.

Considering that there's no orbit decay, perhaps a difference phrasing? "Scientist working on Skylab is getting a bit bored of the scenery." Mission: Adjust Skylab orbit to 150,000m ~ 200,000m.

Probably can be added as a mod. The behavior would be somewhat similar to the Firespitter propeller (except much bulkier, heavier, low thrust at low velocity, and consume no resources). In fact, the Firesplitter propeller mod could probably be adapted to implement the nuke jet engine.

The "minimum speed" could be implemented as the nuclear engine having horrific thrust at low velocity that only ramps up to some reasonable thrust level at high enough speed. I think you can implement this by using the velocityCurve property. Note, I'm taking the Turbo Jet number and tweaking it. velocityCurve { key = 0 0.01 0 0 key = 200 0.1 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2400 0 0 0 } Note, I don't know whether the engine can handle a thrust ratio of <0.1. In the above, the nuke engine will have the following thrust profile. From standing still, the engine only generates 1% of its maximum thrust (if you want to be a bit sadistic, you can put that at 0). At 200 m/s, the engine will generate 10% of its max thrust. At 1000 m/s the engine will generate 100% of its max thrust. Beyond that, the engine once against start to lose thrust until 2400 m/s (0% thrust). Also in theory, nuclear engine don't need "intake air", since it doesn't need to combust anything to generate thrust (it just heats up a working fluid/gas). Therefore it doesn't need a minimum "Intake Air" amount to operate. So that may require a new module written for it, since current setting for atmosphereCurve deals with Isp, not thrust. Nuke engine, it could, in theory, consume very tiny amount of Intake such that a single Intake can supply all its need until it reach vacuum. The thrust curve can be adjusted against the atmosphere, with 0 thrust in vacuum.

In this case, won't it be a bit OP given the current design for nuclear engine (aka, infinite nuclear fuel)? For an air-breathing engine, that means 0 need for any fuel (just fly into atmosphere, boom, free thrust).

I think one possible way is to use science to unlock "modifications" to it, instead of letting you tweak specific parameters any number of ways. Take for example, the current LV-T30 Liquid Fuel Engine and LV-T45 Liquid Fuel Engine. They're very similar. So instead of having two engines, we can have just one engine and can "unlock" various mods for it. So for example, we unlock LV-T30 Liquid Fuel Engine. And from that engine, we can unlock "mods" such as. "Atmospheric Nozzle": Increase atm Isp at the cost of vaccum Isp "Thrust Vectoring": Add thrust vectoring capability, increase cost and slight reduction in thrust. "Embiggen Alternator": Increase electricity production at the cost of Isp. "Strip Alternator": Remove electricity production for slight increase in Isp. "Nu Metal Construction": Reduce engine mass, but increase cost and overheats easier. Each mod can have a unique component that appears on the engine when active.

Could be the issue of digitization. The thermometer may have a physical drum that records more precise temperature reading (and pressure readings). Kerbal's Analog-to-Digital conversion electronics may have fairly low precision (can only distinguish between 10 degree C difference, while the drum reading can achieve 1 degree C difference).

I envision a mission like the following. 1. A Monolith spawns near at the distance of Eeloo orbit, with extreme inclination (something like 70~80 degree inclinations). Said Monolith would have a very unusually high mass(12,245,589 kg?) 2. The mission is to "grab" said Monolith and bring it back to Kerbin surface. 3. Monolith have a fairly high impact resistance (something like 200 m/s). If destroyed, a new Monolith will respawn. 4. Mission is completed successfully once Monolith is recovered. The Monolith will be displayed like a statue at the space center, like a visible achievement of sort.

I agree, the current distance between waypoints can be ridiculous for rovers. Perhaps something like < 3000 meters for the entire trip (5 minutes of travel using the top speed of the slowest rover wheel). Btw, is it possible for science contract be generated referencing existing "rovers"? Considering that real-life rover operation is more like "Land here, look around, find something interesting, drive there, study it, look around, repeat". Can a Contract be created as followed: 1. Pick an existing rover landed on a planet. 2. Plot new sets of way-point from said rover. Perhaps even include the rover name in the Contract.