KrazyKrl

Well, [URL="https://en.wikipedia.org/wiki/Slush_hydrogen"]Slush Hydrogen is already being proposed as rocket fuel[/URL], with density increases of up to 20%. And [URL="http://www.grc.nasa.gov/WWW/Fuels-And-Space-Propellants/GELLED.htm"]NASA has already done work on [I]Gelled[/I] hydrogen.[/URL] "The propellant density increases and their attendant Isp changes with the aluminum additives allow a payload increase of 14 to 35 percent by replacing the Space Shuttle Solid Rocket Booster with a Liquid Rocket Booster using O2 /RP-1 /Al and NTO /MMH /Al, respectively." [URL="http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19910014991.pdf"]Here's a PDF of some data.[/URL] If you [I]really[/I] wanted to get down to it. You could make [URL="https://en.wikipedia.org/wiki/Metallic_hydrogen"]Metallic Hydrogen[/URL] at 250,000 atmospheres of pressure. But good luck fueling a rocket with [URL="https://en.wikipedia.org/wiki/Degenerate_matter"]degenerate matter[/URL].

I don't think we need "Engineering Points" to replace the tech tree. (The game is already 1.0 anyhow, changing a major game system kinda seems wrong.) And it's understandable to get more parts via earned science; due to research (and testing) done in the field. I can accept the abstraction of science points being used for part research, KSP is firstly a game. [quote name='Xiion']snip[/QUOTE] TBH what's currently lacking with the science system, is [I]a tie in with contracts[/I]; and the science archives. With the Kerbal system being hand-made and not procedural; lots of work can be done designing the universe to research. Running science experiments per biome should not only reward science points, but [I]fill out the science archives with descriptions[/I], and [I]reward small "world first"-like contract completions[/I]. I know that the devs do not want an "achievement" checklist, but there is nothing I can see against the [I]Science Archives[/I] being a "completion list" of sorts. The Kerbal solar system itself is another character in this game, and needs quite a bit of fleshing out as a game entity... The game is, of course, a trifecta of characters... Kerbals, The space they inhabit, and the space program to get there.

My 2 cents: Balance fixing and part model tweaks? Needing to redo a few crafts? [B]Okay.[/B] Physically unable to load a save from post-1.0? Forcing a new Career game? [B][I]NOT OKAY.[/I][/B]

[quote name='GreeningGalaxy']Once again, I'm not asking for these mechanics to be extremely detailed, just that there be something more to nuclear stuff in KSP than "just another engine, this time with magic." People have frequently accused nuclear engines of being overpowered (at least before career made them cost money) and there's still talk of giving them absurd reputation penalties for their use to "balance them out." Instead of mucking around with all that, why not give the player some direct, tangible reasons - namely danger and complexity - why using them isn't a perfect rainbows-and-happiness solution to every delta-V problem?[/QUOTE] The NERV is already pretty balanced. The dry mass is already very high; means you're using lots more fuel, and mass, than you need to in most cases. And the engine does already create lots of heat, for the amount of thrust it provides. Just because the NERV has the highest ISP, doesn't mean it's the best in all cases. Adding an entire subsystem of radiation poisoning, to something that is already performing on-par; seems like a lot of work, for so little added gameplay. Because once you fire up that nuclear reactor, the fission products keep it radioactive for decades. Then it just becomes a matter of "don't stand there, ever."

A simple KAC in stock would be amazing. KAC is a very powerful, and complex, tool though. I'm thinking of a (mod expandable) simple alarm clock, something like: [list][*]"Stopwatch" icon in toolbar, lists all events set when clicked. [*]Maneuver nodes are automatically added to the alarms with the alarm being something like (NodeTime - 5 minutes). [*]Clicking the button also allows you to add a MET-specific alarm that you can custom name.[/list] Nothing super complex for the first iteration in stock. Having automatic alerts of Maneuver nodes would be the main feature, and being able to set custom alerts can be used for everything else (landed craft, etc.)

IMO this is out-of-scope for stock KSP, sounds like a lot of "what" and not a lot of "why" for gameplay. The NERVA is one engine out of many, and has one use. There is no really power-hungry application for a reactor in space, that can't be solved by solars/fuel cells/RTGs and battery-capacitor type setups. Also, what would this add to gameplay? Needing to ship nuclear fuel rods to a ship every 5 years of MET doesn't seem like it adds much. Same with the gradual reduction of efficiency (which takes [I]years[/I], even with the reactor running continuously.) The radiation mechanic makes no sense, you're already suggesting automatic shielding; and space suits already have quite a bit of shielding from cosmic radiation. KSP is first a game; and adding more complexity without a reason for it, sounds like a low-reward high-effort tradeoff. A 2.5m NERVA would be useful though.

[quote name='Torgo']They are brother and sister, so eww, unless you're in West Virginia, Alabama, or Newfoundland. [COLOR=#e6e6fa]Yes, I made that part up, but go with it.[/COLOR][/QUOTE] I thought Val was Krussian. Jeb is obviously from the Uknighted Steaks.

An explosive ballistic orbital mortar won't work. Due to air resistance. You also need to burn some fuel at the peak of your trajectory to circularize anyhow; or else the only thing you can manage is an escape trajectory from Kerbin. [spoiler=Shipping Cannon?]I know what (I think) you mean. But as it's an absurd request, I'm assuming a misspelling of Cannon.[/spoiler]

+1 Fuel tanks that can be set in the VAB/SPH to hold any resource would be amazing. Want a big orange tank full of Xenon? Sure! LF? Why not? (There possibly needs to be a weight and/or capacity penalty for differing fuels per-tank though. Like loading Xenon into an LFO tank reduces the Xenon capacity by 30%.)

My 2 cents: 1 Star+ Commanders: Can "Field Promote" other Kerbals within 3m(EVA), or in-craft, up to the commander's star level. I.e. subordinate Kerbals do not need to return to Kerbin to "star up", but they must still gather EXP. (Commander must obviously return to Kerbin first. Commanders may not promote other mission commanders.) 2 Star Commanders: Grants all abilities otherwise granted from building upgrades to themself and any Kerbal within 3m(EVA)/in-craft. Patched Conics, Maneuver nodes, EVA, Flags, etc. 3 Star+ Commanders: Temporary ranking of Kerbals within 3m(EVA)/in-craft. Applies (Commanderlevel - 2) abilities to all Kerbals in range. Does not increase stuff like ISRU/Lab efficency. Only adds abilities like repack chutes/repair wheels if Kerbal is not high enough. 4 Star Commanders: Equipped with short-range radio. Maybe something like 5km. Also acts as a radio relay with range of 5km for any Kerbals/devices within 3m/in-craft. 5 Star Commanders: (Ideas?) I'm at a loss to what would be a good (and not broken) reward for 5 stars. Maybe Trajectories? IMHO, piloting abilities like radial hold/prograde hold should be tied to the star of any Kerbal. Even engineers go to space. Maybe 0 star Kerbals have no "SAS", 1 stars have stab/pro/retro, 2 stars have everything.

Just off the top of my head: Something like an advanced vehicle properties window. (Parts explorer?) This window would consist of a hierarchical tree starting with the root part, and containing all sub-parts. (Maybe something like windows explorer folder GUI.) Multi-selection with shift/ctrl/checkboxes. This feature would essentially be a copy off of manually selecting parts in the flight scene. The bottom half of this window could be a grouping system where you can add parts to each "bucket". "Buckets" of parts can be renamed. You may replace/merge into a bucket with tree/bucket/flight-scene selected parts. You may "view" the bucket of parts in the main hierarchical tree (replaces any current selection.) Using some GUI button in this advanced vehicle properties window would open, essentially, a singular condensed tooltip containing all settable features for selected parts. Other than an absolute mess of parts, like a large portion of your entire craft; this would be a nifty feature. Needing to abuse camera mechanics to select parts that may be in a fairing or whatnot is a hinky workaround. The GUI needs some love, and as a bonus; you could use those part buckets to make easier use of action groups too.

Yes on the strutable fairings. But as for the size restriction, why ever use the fairing base; if the decouplers do the same thing (and can also jettison the base after the fairing is ejected.) I'm proposing the stack decouplers/seperators are replacements for interstages. If you want a larger fairing, IMO use a fairing base. This would give both parts a reason to exist.

I think quite a few of us has made the same argument for the autofairings on engines. The autofairings are a placeholder for a more permanent solution. I've posted about this before... IMO; stack seperators/decouplers should be able to create an editable fairing up to their diameter. Fairing bases should be able to make oversized fairings for their size.

Same here, limiting node attach to only same nodes seems quite limiting for a game like KSP. But as for node placement... I'd suggest another placement tool. An extension of the angle snap button, with a submenu. Maybe change the angle snap button when modkey is held to a placement node icon or something(mod-rightclick can toggle using node exclusion). This submenu would contain a checkbox listbox of all placement node sizes. This way you can enable and disable each node size as you see fit.

I'd replace a few of the suggested items with these: Structural Components (Including all other parts): Reduced temperature tolerance and reduced impact threshold. Leads to exponentially quicker destruction as the severity of the damage increases. Science Experiments: Unable to be collected via a scientist, or reset. Can still be activated. Any data read is saved until repaired by an engineer. Parachutes: Max drag until failure gets reduced until the icon turns red for complete failure. Fuel Tanks: Massively reduced fuel flow. Fuel tanks already have a flow restriction feature like this, when you use the transfer fuel feature. Command Pods: IVA gauges graphically wander. EVA navball visibly wanders, but does not affect flight directly; including utterly wrong navball orentation (things like prograde and radial are unchanged). Staging ceases to work after critical damage. Pilot/Engineer on board affects severity of command pod errors, dependent on level. Probe Cores: Navball wanders, loss of SAS, flight name slowly gets truncated; dependent on damage. Scanners: Only can return a reading up to their health. (100% health = no loss. 50% health = 50% max deposit detection. 10% health = Deposits are only 10% or lower regardless of higher quality.) As for the binary fails: Anything that opens/closes or extends/retracts will cease to function, but will still be repairable. Fuel crossfeed parts will cease to crossfeed. (This will probably get VERY absurd, due to fuel flow logic.) Docking ports will not dock/undock. Docking ports (when undocked) will randomly disable docking magnets when attempting to dock to another docking port. The claw will become possessed, and will randomly activate. Quite a few would be pretty hilarious to see. Like the random docking magnets, the possessed claw, a probe slowly forgetting its own name, or your navball wandering around.

Well, since the thermal system tracks both skin & core temps of all parts now... Skin temp over max temp: Part connections to all parts fail, and part becomes no longer attached. Core temp over max temp: part explodes. This may be a decent thing for the Unity 5 update also. (Updated physics.) You can simulate the aero for the disconnected parts via "primitives" (this part is a cylinder, cone, sphere, etc.); and since they are disconnected, you should be able to run less intensive stuff like collision detection at fewer ticks/precision.

It's overly verbose because I'm getting into specifics about the system itself. But it'll essentially be "save this craft in this orbit", and "I'll pay extra for a copy to be put in that orbit. But I'll need to prove I can do it manually first." Needing to program it via some sort of autopilot scripting language seems much more complex than extending something which contracts do anyhow (add flights to the map).

I'd say something like: Requirements Requires max level administration building, at least level 2 tracking station, probe cores unlocked, antennas unlocked, and power generation unlocked. Craft must have a root node of a probe, have an antenna, and have a method of providing power. Craft cannot contain Kerbals, any crewed craft must be flown manually. (i.e. crew-able parts must not be crewed.) Certification for KSC Subcontractors Before a craft is certified to be launched by KSC subcontractors, you must launch this craft to orbit 5 times. The craft is saved via certification, any modified craft must be re-certified with 5 launches before being automated. The craft needs a way to say "This is a certification flight" at launch; and "Save this certification flight's orbit" to denote when to save the orbital parameters of the flight. The craft's part count (and staging menu) must be identical to each previous certification launch. (Craft should be identical other than resources contained when saved.) The cert flight must not be at an altitude and inclination at which it would leave Kerbin's SoI. (i.e. Minmus'/Mun's SoI torus must not touch any portion of the final orbit.) Automatic Flight creation of a certified craft The craft's orbital parameters of the automatically launched certified craft must be approximates between the top and bottom parameters of the 5 combined certification launches. The craft's part properties (power, fuel, orientation, etc.) must be approximates between the top and bottom parameters of the 5 combined certification launches. The craft appears in orbit after a delay of the MET times of each certification flight. (Simulates launch by another party) The craft's cost should be the cost of the base craft, plus a penalty to pay for the subcontract work. The craft should always be cheaper to fly yourself. I may be leaving a few things out. But essentially, cert-ing a craft would save a cert file on the hard drive which contains the craft file, plus the min/max orbital (and part) parameters that the game can extrapolate an orbit from. Other than the backend for creating the cert system save feature, there are already "in-flight" orbital contracts that stick stuff like stranded kerbals in orbit anyhow. And requiring 5 launches of an identical craft just to automate it, should be a large enough hurdle to prevent other abuses (and have the benefit of orbit variability.)

I did some math on this(assuming just a larger form-factor NERV, keeping the same balance):

I'd say to have something simple... The non-IVA altimeter backround turns "(pro/retro)grade green" If you're in-atmo, or on a sub-orbital trajectory. This way, you have another indicator of being orbital, aside from map view. You may also click the altimeter to change modes, this mode is saved per flight in the persistence file. White backround on altimeter: In orbit (not necessarily a safe orbit, but an apoapsis above the atmosphere(if atmo body)/terrain average sea level(this is the value the current altimeter uses as zero).) Green backround on altimeter: You're in an atmosphere, or you're gunna hit something in this SoI. (I believe that white/green contrast should suffice for anyone color blind, but I might be mistaken.)

Well, real spacecraft do have features to hold on to in space, not necessarily literal "magboots". With the high-level abstraction of fuel lines, power lines, and crew transfer. I'd be willing to allow some type of "grab and crawl anywhere" feature for the outside surfaces of spacecraft below an <arbitrary upper limit of g's of shear force, or wind shear>.

This makes no sense. Each of those 4 calculation "pools" are already running in separate threads. And simulating physics in a chain of rigidbodies is not that simple of a matter; because every rigidbody is affected by the others. The main performance boost in the next Unity version, are just outright PhysX upgrades in the Unity engine itself. As for lowering the accuracy, that's a very bad thing to do. All sorts of weirdness starts to happen, as rounding errors can compound on themselves. I.e. continuous "close enough" temperature measurements could arbitrarily heat or cool parts through no outside cause.

Yes, I agree with OP's suggestion. LFO fuel tanks should inherently be nearly CoM neutral in respect to the tank itself. Currently the LFO tanks act as if it's one big tank, and not 2 tanks in 1 cylinder. Programming this simple thing into the game however, would probably be quite complex. (Calculating CoM for two objects within one rigidbody; which both change according to the LF and O amounts contained.) As for AoA, if you're running more than about 10 degrees off of prograde in-atmo; your rocket should and does aerodynamically stall... just like real aircraft. Aerodynamic forces end up trying to shove your craft in a different direction, which causes failures of both control, and structure. You can get suborbital (and even orbital if you're careful.) With no gimbal, and no fins... on SRBs. It's all about aero and your AoA. Your crafts default state should be aerodynamically stable at speed in atmo, using fins (rightfully) should be a "sledgehammer" approach. If you force your craft off of prograde too much, it should act like a brick. Even the Saturn V had tiny fins (for its size), but that's probably due to the F1 engines being so massive and just being such an inherently massive craft.

I have a weird feeling that some PhysX value is overflowing that causes the launch clamps to act like that. (Infinite break force, with excessive load multiplied by leverage.) And I don't think KSP has a few simple sanity checks to prevent launch clamp weirdness. Honestly, I'd be fine with excessive crafts being able to rip launch clamps from the ground. The only problem comes if they are in-flight; and they rip off pieces because the game assumes they will always be connected to the ground.

After the update to KSP 1.1 with the new, unified, user interface backend. I think this will get a rework anyhow, including a part search. The library of parts is quickly bloating to an extent where a part.cfg MODULE{} & RESOURCE{} tagging system would be required. I would suggest a something like hierarchical tree (Who?, What?, How?): Command Pods - Parts able to control a vessel Utility/Structural - Trusses, size adapters, structural fuselages, service bays, struts (Excluding spaceplane parts) Utility/Aerodynamics - Nosecones, Fairings, Utility/Electricity & Thermal - Solar, Fuel Cells, Batteries, RTG, Radiators, Heatshields Utility/Mobility & Rendezvous - Wheels, docking ports, Landing Legs Utility/Science Recovery & Mining - ISRU, drill, Science, science lab, Antennas, Scanners Utility/Crew Mobility - Non-command pods like the lander can (includes Mk3 plane crewable parts), ladders, anything crewable (Excluding science lab.) Rocketry/Engines (Including the escape system) Rocketry/Fuel Tanks - LFO tanks, Xenon, Fuel Line Rocketry/Control - Reaction Wheels, monoprop tanks, monoprop engines Atmo/Engines - Intakes, engines, LF-only tanks, fuel line Atmo/Control - Control Surfaces, tailfins Atmo/Structural - struts, static wings, wet wings, spaceplane structural fuselages