HephaistosFnord

So, the proper additional values for an engine to have, which could easily be overridden by difficulty settings, are: - flow minimum ("0% throttle" isn't "0% thrust" - if a rocket's flow minimum is half its flow maximum, then setting throttle to 0% means the rocket operates at half power) - throttle inertia (if the throttle is currently at 25%, and you increase it to 100%, how many seconds does it take for the engine to throttle up to the new setting?) - cold start time (the amount of time between activating an engine and it being ready to provide thrust) - RCS-capable (boolean for whether the engine provides an "advanced controls" sub-panel that lets you tie it to RCS) At low to medium difficulties, flow minimum and cold start time can both be 0, and throttle inertia can be set to infinity, duplicating the current settings. At high difficulty, flow minimum, throttle inertia and cold start time can all be based on the engine's size and turbopump technology, so that engines like the Puff can be instant-on/instant-off with infinite no-worries restarts, and engines like the Mainsail can be "fire up on the pad, stay at near-100% throttle all the way into space, and then once it's shut down it's done for this mission". RCS-capable should be based on flow minimum/throttle inertia/cold start time, but if difficulty settings disable those features the engine still keeps its RCS-capable boolean. (Snip)

Well yes, Terriers definitely should have RCS control. The reason I object to the Mainsail in particular is that anything with a long spinup /spindown should be precluded from RCS, bc it simply wouldnt be able to respond in real-time. Basically RCS capability for an engine should be a tradeoff against thrust, based on the size and design of the engine's turbopumps.

My phone isnt letting me reply point-by-point, but: - "Skip Countdown" should just timewarp past the spool-up phase, so you dont have to sit through the process every time - "fore by throttle" already lets you tie rcs to throttle, its pretty great - "maneuvering engine" should definitely be a whole category, which includes all current RCS modules + the Puff + most of the radial methalox engines. All of them should get the full RCS advanced controls; other engines shouldnt. (This also would let the Puff be used as a REALLY BIG linear RCS port)

I can already anticipate most of the objections, but ultimately we need a reason for lower-performance engines to continue to exist, and the higher-performing engines already typically get used at mostly full throttle in most applications.

KSP2 engines should probably have more realistic power-on sequence times, to differentiate engines like the Puff (instant-on, full throttle range, no lag) from say the Mammoth (probably at 60% thrust minimum and several seconds of spin-up time and a maximum throttle change of 10% per second or so). Any engines that are sufficiently "instantaneous" (so all the monoprop some of the smaller methalox) should have the RCS "advanced controls" button so they can be tied to yaw/pitch/roll, lateral/dorsal/fore/aft, and forward throttle controls.

Can we please get an "advanced controls" checkbox for wheels, that lets me choose whether to wire a wheel to the 'forward' key (at 100% power), or the main throttle (matched to throttle %)?

Oh this is so, so beautiful. I am sad to report a few bugs, however: 1. The game locks up on the loading screen, at "Loading Kerbal roster data" 2. If it doesn't, then when I place Kerbals in pods and new Kerbals are generated, the new Kerbals are frequently completely missing their 'mugshot' picture. I will try and get you a screenshot of bug #2 if I can ever get past bug #1 again.

Oh yeah, and can we PLEASE get KSP1's vessel naming system, where each pod has a "vessel name" string and a "name priority" integer, and the vessel name is automatically inherited from that whenever docking/undocking occurs? PLEASE?

So, had an opportunity to play around w some fun little rovers all week, on Kerbin, the Mun, and Duna. Some things that need attention: Last-Chance "Bedrock" Collider - Physics-enabled entities should NEVER be allowed to fall through the planet's actual surface. You already have easy ways to calculate this; somewhere appropriate in the physics pass, any object within N meters of the ground needs a check to verify that it is not BELOW the ground; if it is, it needs to STOP FALLING, and be placed so that its lowest-Z collider vertex is at something like ground-z minus 0.5m or so. Kerbals falling through the ground to infinity should be a *mathematical impossibility* within the physics engine. Ground Friction Physics - Everyone knows wheels are a bit bugged. - But did you know you can take a single XS square plate, slap a seat on it, put four sepratrons in a pinwheel-pattern around it, and when you fire it off *the plate will never stop spinning*? It eventually goes up on one corner, and then it's an Inception top until the sun burns out of the sky. Physical Interaction - I flip my little one-man rover-buggies *a lot*. It would be nice if, in addition to the 'climb up' action, there was some way to "grab ahold" of a part lying within arm's reach of an actively-controlled pedestrian Kerbal, and the Kerbal could then apply forces to that part - perpendicular to the vector between the kerbal's CoM and the part's CoM - with the WASD controls. So I could, say, grab a corner of a flipped buggy, and hit 'W' to flip it back upright if it's light enough.

Yep, lots of parts have weird weights.

A cargo bay with doors has a full metal skin, actuators, all sorts of clever gubbins. A payload truss is just a bunch of steel pipes welded together. What gives?

I think that hydrolox and hydrogen should be kept separate - the manufacturing methods and insulation requirements for hydrogen tankage are very different than for methalox. Again, there are many specific and technical reasons why my proposal is what it is. That said, allowing methalox tanks (and nosecones) to hold 100% oxidizer would allow for hydrolox engines - this is incidentally exactly how the space shuttle worked. The big orange tank had hydrogen in the cylindrical part, and oxidizer in the nose cone part.

Sure, but that's actual "procedural tanks", and is probably a bigger deal than just switching contents. There are lots of technical reasons why I described the request precisely the way I did.

If this is done, nosecones and structural adapters should also get a 'Service Tank' fuel switcher, with 'None (structural)' as the default.

Switching between models/materials would be awesome, but isn't really necessary for a "round one" pass. If switching models/materials *is* doable, though, then it would be nice to have a fourth category of fuel tank, which combines the foil-covered Methalox pills/spheres/donuts + all the Monoprop tanks + all the Xenon tanks, into a single tank subcategory called "Service tanks", which can hold Methane, Oxidizer, Monopropellant, Xenon, or Hydrogen (with a different model/material based on what it's holding). EDIT: That said, I wouldn't want any time spent on that project if it has any chance of delaying other current improvements, while my OP suggestion cluster genuinely does feel high-priority in comparison.