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.

I had actually worked on a KSP1 version of exactly this, as part of a Deadly Reentry version that never actually got released. The problem is that dynamic tank deformations get really tricky, because you have to re-compute all the angles for everything attached to them.

Pause and/or timewarp, with a clock somewhere. I would love to be able to timewarp to dawn *before* I hit the runway, since many of my planes bounce around like crazy on the runway, preventing timewarping.

This feels pretty critical. The current situation - All the Mk2 and Mk3 Spaceplane 'adapter' parts currently only come in Methalox flavors - Having separate Methalox and Methane tank subcategories is going to be a real pain, as more and more parts get added. - The later the devs wait to build a fuel tank switcher, the more likely it is that some other development complicates it. Ideal behavior - There should only be one subcategory for 'Methalox' tanks, and the 'part menu' should have a simple drop-down with Methane, Oxidizer, and Methalox as the 3 options. - Methalox mass ratio should change to 1:3.6, rather than 1:4, because this gives a perfect 1:2 *volume* ratio, for easy balancing (most of the supplied parts come in 1x, 2x, 4x and 8x volume options, so if you have a design that needs separated Oxidizer and Methane tanks, you can easily keep the correct ratio without having to calculate or tweak anything) - Command modules with integrated RCS should be switchable between Monopropellant and Methalox - Command modules *without* integrated RCS should have their integral Monopropellant tanks removed Thus, the total fuel tank part subcategories become: - Methalox (1.00x Methane / 1.80x Oxidizer / 0.33x Methane + 1.20x Oxidizer) - Monopropellant - Hydrogen - Xenon - Whatever future categories are needed Can this please, please be done? Speaking from experience with KSP1 modding (I created the original RealFuels/ModularFuelSystem), it feels like this should be, at most, three days' work for a junior dev, it would *massively* improve QoL, and it's sufficiently foundational that it should probably happen sooner rather than later.

1. When two or more non-decoupler parts are stack-joined together, they should join together into a single rigidbody. The combined rigidbody should have values for maximum shear, maximum compression, and maximum torsion before failure, along with (for each maximum) a 'weakest link' pointer to precisely which part or joint connection will fail if these ratings are exceeded. Ideally these checks are rolled into the standard physics pass. 2. Decouplers and surface attach joins should multi-strut as normal, but with higher rigidity than normal. Rigidity should be increasable (with a slight-to-moderate cost and mass penalty) via tweakable menu, without resorting to additional struts (although additional struts should also stay an option). 3. When a part is repositioned, it should switch to multi-strut (even if it is repositioned off of a stack-join). The multistrut points between the two repositioned parts should ideally be dynamically computed from the intersection of the two part's colliders, unless this would slow the VAB editor to a crawl. 4. A part or joint that is reaching shear, compression or torsion limits should begin emitting horrible metal-on-metal screeching and groaning noises, like in KSP1's Deadly Reentry mod. Players need rapid feedback that something is wrong and it needs to stop. This means that a vertical rocket stack won't "wobble" at all, except where a decoupler or docking port joint exists. They will stay rigid until failure.

This is exactly how you do it. Ideally, Kerbals should have a few SIM-like traits, which you can discover at the Training Facility. Then you can design missions based on the Sociability, Health, Intelligence, and Reflexes of your available crews. - Sociability - determines whether the Kerbal is a net drag or boost on others, as well as their own social needs (slight boost with experience) - Health - determines G-force robustness, endurance, impact tolerance, etc., as well as how quickly they suffer from adverse life support conditions (slight boost with experience) - Intelligence - how capable they are at doing science and engineering type tasks (multiplies with experience) - Reflexes - how capable they are at flying the ship (multiplies with experience) A Kerbal who doesn't have their life support or social needs met will have their performance degraded in all four stats; if Reflexes or Intelligence drops to zero they stop being a functional crewmember, if Sociability drops to zero they start sabotaging the mission, and if Health drops to zero they die.

Nope, I still want smaller planets for ease of play. What I want is smaller planets that are still at all plausible; 6.4x is about the scale at which Kerbin's orbit around a K-type orange dwarf puts it in the habitable zone, and the planet itself can be made out of a plausible mixture of elements and still have the correct density for 1g surface gravity.

I'm hoping KSP2 eventually gives us a 6.4x scaleup option in the 'difficulty' settings

Six months to implement a heat effect CORRECTLY (we hope). I'll take that over something shoddy that glitches out on weird edge-cases.

One thought I've had for a long time: If during assembly, two parts clip into each other that are not node-attached to each other, it would be nice to have the editor automatically auto-strut those parts together at the centroid of where their collision meshes intersect. (This shouldn't be *too* difficult to compute, should it?). Some kind of icon that looks like a squareish purple 'node' icon could serve as the indicator that a weld is going to occur there.

True, we really need a tank switcher that lets any methalox tank be configured to either pure lox, pure ch4, or shared bulkhead methalox.