If You Ran KSP's Development...

[swjr-swis]

[quote name='GregroxMun']Engineer Kerbals can overthrust an engine by increasing power output up to 130%, however it will come at the cost of much much higher heat production so can only be used for a short time.[/QUOTE]

"I dannae if she can take any more, Capt'n!"

[eddiew]

1.1 - Unity 5, 64 bit, bugfixes
1.2 - antennae updates, heating review
1.3 - new stuff that was dreamed up during previous release
1.4 - see 1.3

Stability before features :)

[More Boosters]

KR-1 "Boar" Liquid Fuel Engine

Mass : 4 t
Thrust : 1000kN
Gimbal: 8 degrees

Isp: 280-300

Radially attached.

[Red Iron Crown]

[quote name='Spacetraindriver']9th More engines (ESPICIALY a decent Single engine like the Mammoth)[/QUOTE]

[quote name='More Boosters']KR-1 "Boar" Liquid Fuel Engine

Mass : 4 t
Thrust : 1000kN
Gimbal: 8 degrees

Isp: 280-300

Radially attached.[/QUOTE]
Y'all have tried the new Vector rocket engine, haven't you? It fits these bills really well.

[More Boosters]

[quote name='Red Iron Crown']Y'all have tried the new Vector rocket engine, haven't you? It fits these bills really well.[/QUOTE]

Apples and oranges. Radially attached with less Isp is the idea here.

[Red Iron Crown]

Just use a nose cone for radial attachment. :)

[TheTom]

Ok, so let me get into the what I would do game too.

1.1: Unity 5. That is a big thing due to a whole graphics update - and the UI is all graphics and pretty hodge podge in earlier versions by admission. Fix resource loading.
2.0: Quality Update.I name this 2.0 because it would be a really breaking change for mods - but one needed. Redo the whole backup to be parallel. Phyics: 1 thread per ship if possible by PhysX. Otherwise separate PhysX, Aerodynamics, Heat and Resources into separate threads (one per resource using a task mechanism and a thread pool). Redo the API to handle multiple passes (Reqest, Get calls for a ressouce) and introduce small delays - a multi pass Resource system could handle this a LOT more efficient than the current "every request loops all objects" approach. The idea: get THREADS used and decouple subsystems, allowing a craft to efficiently use 6-8 cores. This would break extensibility, but I think it would be worth it.
2.1: Integration. Start looking for standard mods that make sense. mechJep may be too much, but waht about little things like the automatic wakeup when approaching an interesting event (Kerbal Alarm Clock)? Minimum standard life support that does not kill people (USI life support). The mods are out there. STATION parts. Scaleable parts and replaceable textures - which can really cut down the number of parts and make them more manageable for a user.
2.2: Multi Screen & Complex Craft Support. Integrate a network interface for craft inforamtion and commands and separate programs to show a nice UI for those. Which would mean a second window (as separate program) showing me how my active craft works (fuel, heat) and having buttons. This nicely bypasses the "one window per Unity program" limitation. Work on a much better rocket management model - allowing a tree of stages (which means landers can "branch off" and be deactivated) and the definition of craft boundaries and payload (as in: Everything above this is a separate craft, inactive, do not use batteries etc. and activate when decouples). The current approach gets REALLY complicated when you have multiple landers etc. all folded into one staging sequence. The separate UI would also alloe me to have visual configurable buttons for things like lights, engines etc.
2.2: Graphics and Gameplay. Make nicer GFX - not talking about parts, I mean sky etc., and gameplay meaning a better run over the planets. More variety, Biomes etc. Some of this can come earlier, but here we talk about things like adding more moons etc. Colonization? Not sure.

Then take it from there.