Stoney3K

I would support this. The science career can be quite a boring grind for the first 2 or 3 tiers until you reach a tipping point, when you unlock the lab and solar panels and you can mine thousands of science points without a lot of effort, making the late tech tree very easy to unlock. Having more variety in the experiments and activities you can do to get science would really make the science career more rewarding. Especially when that's combined with a penalty for using the mobile lab too often or a more challenging tech tree in the late game.

In a career play mode, replacing "obsolete" parts with newer parts which have the same function would make sense, since you can replace parts on existing vessel designs with cheaper, lighter, better functioning models. Much like upgrading the avionics and engines on a 737. Vessels that are already built won't break but they may be more expensive to re-launch with the obsolete parts (which have higher manufacturing and delivery costs) when compared to "upgraded" vessels which do the same. However, in stock it doesn't make a lot of sense because there are no replacement parts which have identical functions. There would be a larger use case for replacement parts if there was a "running cost" dynamic in-game, with replacements having lower running costs than older parts so it would be economic to service them, even on existing missions.

And leave that filter 'on' by default so obsolete parts get hidden. A part file can have a reference to its replacement when an obsolete part is being replaced, so the description would read: "Replaced by part XYZ" or, "Replaces: Part XYZ" when you are looking at the replacement part. It would also mean we need new sets of parts with spiffier specs in the future to replace the obsolete parts, while having the same form factor. An Aerospike or a Vector is not a replacement for a Swivel, it's just a bigger, heavier and more expensive engine in the same form factor. Only obsolete parts if there is a valid replacement with the same use case.

I believe that is not a safety feature but a limitation of the game engine. Switching vessels require the vessel to be "packed", which is not possible when there are forces acting on the vessel (like aerodynamics). Even when those forces are in equilibrium.

I think the information about a planet you have never visited should be limited, but it should be there. Kerbals can look at the sky and get a rough number on planet data simply from telescope readings. After all, if you know nothing about a planet's orbit or its gravity, how are you going to send a probe to it so that it reaches orbit? Just hurl it straight at the planet from LKO and hope it catches a gravity well?

Does the stock SAS have some way to measure the amount of control authority that is actually on a craft? If there is a measure for that, the PID loop can be easily tuned to allow consistent SAS action across all ship designs. In principle, the control loop's P value should be inversely proportional to the amount of authority on a craft. (In lay man's terms: Small wheels need a big push on the stick, huge wheels need a tiny push to move the same amount) Latency is also an issue. Oscillations don't exist unless there is some measure of latency in the SAS control system, which is easiest to notice if you have a craft with both flight control surfaces and reaction wheels on it. The control surfaces are slower than the torque wheels, causing the two to fight each other for control and the craft to wobble along a single axis during atmospheric flight.

The cargo bay doors don't have a proper collider when they're closed. Anything that is attached inside the cargo bay is free to flop around and project through the doors outward, instead of bumping into the inside of them (or knocking them open). The doors also won't hit anything on the way open and happily clip through anything that is in the way, instead of damaging it or pushing it away. I'd be perfectly happy with doors that can't have anything attached to them, as long as they do act like proper doors should instead of just looking like doors.

CoL also doesn't show body lift or lift from actuated control surfaces. So even if you have something that may look stable in the SPH, it may get unstable with higher AoA due to body lift. Center of drag is actually a useful measure for rocket builders for the "Why does my rocket flip" question. It may not be the most accurate way of showing aerodynamics for you FAR gurus, but it's a ballpark figure. In that case the CoP definitely is defined. It is a vector which has zero magnitude, centered at CoM, but it does have a torque component along the pitch axis. If you showed that in-game as a quaternion, not as a linear vector, you would have no trouble displaying that, ie. having a circular arrow that indicates torque along the correct axis. Separating the CoP in a CoL (which we basically already have) and a center of drag would be more useful since it allows you to determine the drag behavior on rockets and SSTOs.

Is modifying them (e.g. Photoshopping the textures to add stickers/decals/hatches etc.) also fair game under the context of building a mod? It would be quite difficult to create a matching 'look and feel' to the stock parts without the possibility to at least partially re-use the stock textures.

Ramjets/scramjets would fit in the same paradigm without any trouble. A ramjet intake would just be a 'generator' part which generates nearly zero ExhaustAir or flames out below a certain speed and above a certain speed, as opposed to a turbojet which can generate ExhaustAir at lower speeds (subsonic) as well. Both subsonic ramjets and turbojets can share the same exhaust nozzle. Scramjets would work in a similar way but only generate ExhaustAir with supersonic airflow, and their exhaust nozzles would be horribly inefficient when you go subsonic with them (making it a better choice to close the intakes/exhausts and switch over to subsonic jets if you have both). You can even go crazy and make the scramjets overheat when you try to push too much air down their throats. Even a hybrid enigine like the RAPIER/SABRE would function like it *actually* does, with the precooler cooling the air so the jet will not overheat. A seamless transition where a scramjet is injected with more and more Oxidizer at higher altitudes would also be possible. Or nuclear jets, fusion jets, arcjets, anything that burns your favorite fuel and generates the ExhaustAir at the appropriate rate would be fair game. The same goes with consumer parts like generators, turboprops, life support (air conditioning) or maybe even ship turbines. BTW, there is a big difference between a turbojet and a turbofan: A turbojet will only use its exhaust air as thrust, while a turbofan uses a part of the exhaust air to drive the massive fan (much like a turboprop), so in game mechanics terms, a turbofan would generate thrust from both ExhaustAir and IntakeAir at a proportional ratio (the bypass ratio), while a pure turbojet nozzle is basically a rocket that runs on ExhaustAir.

I already toyed with this idea as well, with having separate parts to make up turbine engine components. You would have "source" parts which generate ExhaustAir and BleedAir resources from IntakeAir and LF, or maybe even from LF and O, or from MonoPropellant (like on the Shuttle APUs). These gas generators would simply run at a certain speed according to pressure demand, or at maximum if they cannot keep up with that demand. On the other side, you would have "sink" parts which could either generate thrust (RCS or primary nozzles) at various rates of consumption, or generate other resources like ElectricCharge or ShaftPower for arrangements like APUs, stationary generators and turboshaft engines. The sink parts would periodically consume ExhaustAir or BleedAir resources to do their work, and these would be topped up by the generator parts. The player would not have to worry about any of the internal plumbing, just about having enough LF and IntakeAir to keep the gas generators going, and installing enough gas generators to supply their nozzles with exhaust air. In a typical "intake-compressor-nozzle" arrangement where each part is matched 1-on-1 with its corresponding set, that would match up perfectly. However, attaching mismatched engines with more demanding nozzles would, for example, push an underpowered engine to its limits, consuming excessive fuel and causing overheats. The Panther afterburner can also be simulated in a sink (rocket) part which consumes both LF and ExhaustAir as propellants. I'm already cooking up some modded parts which use this principle, including a high-thrust VTOL engine and a stationary APU. I'm also working on animated air intakes which animate when you close or open them. Jet RCS nozzles (Harrier-style "puffer ducts") are already working.

So much THIS! The notion of having a space-faring species like the Kerbals while the entire planet is completely unpopulated, save for the KSC, really makes no sense. You would at least expect SOME buildings to be spread around all over Kerbin. Having more cities, roads, airports and other general objects would make flying aircraft a lot more interesting, as you could have missions to air-taxi a VIP from airport to airport in early career. Even without adding gameplay, a populated Kerbin would really add to the suspension of disbelief.

Jet engines that you can slap underneath your ship to make it a VTOL craft, with lightning fast throttle control and a large gimbal range. I'm all for the inflatable fuel tanks as well, and a nuclear reactor that does nothing but spew out a crapton of ElectricCharge and heat when you switch it on.

I found that, when using a mod like TCA, the stock jet engines are still too slow to act as any kind of RCS when trying to maintain a decent hover. Even the "Yellowjacket" VTOL jet (from Nertea's Mk4 mod) which is supposedly faster on throttle response wasn't much use in that area either. Some parts that allow for decent VTOL without having to resort to a crapton of mods would be immensely popular I guess. Along with RCS thrusters that can run on atmospheric air (like the ones on the Harrier) so we can fly true VTOL missions on jet engines. IMO, a mechanism like TCA which ties into the engine thrust control should be part of the stock gameplay. A LOT of rockets use that as their primary means for attitude control so it would make sense to implement it, even through a separate part you can bolt on and/or by activating RCS.

I suspect that towing a cart through docking ports will work *better* with a mechanism like that. Right now, when docking ports are docked, their connection is rigid no matter what happens, with no force being strong enough to tear the two docked pieces apart without ripping the docking port off first. That's not how real docking ports work. Sure, when a hard dock is achieved there will be limited room for movement, but this is normal since a real spacecraft also needs to take care not to apply any huge forces which may tear the docked combination apart. You can also put a technical spin on it like saying the port has a built-in safety mechanism that undocks or reverts to soft dock if any of the forces on the port are too big to prevent the port(s) from being torn off the ship. Using KAS you can already connect up or tow two separate vessels which *remain* separate. The only KAS part that acts as a docking port is the fuel line, and even that is flexible.

Multiple ships in the same physics bubble affect each other right now anyway, what happens when you bump into a piece of debris with your active vessel? It explodes or gets nudged out of the way. If two vessels are docked, it only means they are in some way constrained together when it comes to movement, but can still be calculated as being two different vessels (just like in real life). Right now, KSP recalculates the part tree when a vessel docks or undocks, which poses its own set of specific problems, most notably with the root part changing causing controls to go haywire.

One thing I am really missing on RemoteTech and I would suspect add for interesting gameplay: If you have a manned ship in range of one of your drones, while out of range from the KSC, the drone is still impossible to control. You would expect it to be controllable from the manned ship if both vessels have an active antenna, with the comms delay being no longer than the delay between these two ships. Imagine a manned mission to Duna with an unmanned rover which is controlled from the manned station in orbit. You would have less difficulty landing the rover since the delay time is a lot shorter from Duna orbit than it is from KSC, with Jeb piloting the rover from orbit. The same would hold for transmitting science from any science-gathering vessel to a nearby lab in orbit. This would add for some interesting gameplay and an extra reason to add manned ships to accompany unmanned ones, or for rescue missions to pick up derelict vessels which are out of communication range. You can send a manned mission to revive a rover which does not have enough range to reach the KSC, or send a manned crew to conduct complicated maneuvers which would be virtually unpilotable from the KSC because of signal delay. For example, flying aircraft.

How do you suppose to fly manned science flights (on planes) without a cockpit available? If there *was* a cockpit available from the very start the Stayputnik would be useless since you can do manned space flights again. We'd need either a cockpit (mk0, open topped maybe?) which is flimsy so it will be destroyed once you take it to space, or have some means of flying unmanned planes, like using the Fly-By-Wire Avionics Hub. The avionics hub is pretty useless right now anyway since it is later in the tree than the OKTO which can do the exact same thing, plus work as a remote guidance unit.

I was talking about SCIENCE career, not contracts.

Flying on the Kerbin surface could use some love, IMO. Planes are pretty useless in science career since the science payoff from Kerbin's surface is next to nothing. That's not worth the effort of flying an hour to get halfway around the globe and land. A higher science bonus on hitting hard-to-find easter eggs and anomalies would be great here.

Even if they were to go for a Greco-Roman name, I suspect Vulcan and Cronus are definitely off the list because it would confuse the fans of a moderately popular science fiction show. In that respect I'd lean towards names like Atlas.

I figure adding an artificial aerodynamics UI where the player can set altitude and velocity (much like the dV display in KER) would serve a second purpose as well: Calculate the thrust and Isp values for rocket and jet engines at altitude, much like KER does now. Right now there is no way, at least in stock, to determine how much oompfh your Whiplash is going to produce when you're flying Mach 3 at 15000m, other than just trying it out.

When are we ever going to convice Squad that they need to calculate the center of drag (and body lift) as well so we can actually check them in the VAB? In other words, how can we even predict where the center of drag is going to be? Right now, when drag is concerned, we're just guessing and flying blind when constructing our ships.

I remember the Space Shuttle has a quite high-alpha re-entry at about 20-40 degrees of AoA which I always found to work well in KSP too. If the shuttle was too fast in the lower atmosphere, it would do a series of "S"-shaped turns (banking left and right) to create a longer, curved path, bleeding off more speed. The bottom of the wings is fairly heat-resistant and it occludes the critical components which are usually mounted on the top.

90 degrees? Why not just make the amount of leg extension and the folding angle tweakable in the VAB? That way it doesn't matter if you strap them to a rocket or put them into an inverted cargo bay for your VTOL craft.