Periple

I think there should still be plain old motors that rotate things. I just think that the specific behaviors propellers and helicopter rotors need to have to make it enjoyable to design and fly them are so complicated that modeling them from first principles gets too fiddly. One possibility would be to have a mode switch in the part configurator: Plain motor -- no blades, no control mappings, attachment points at both ends and 2-8 on the side like in KSP1 Propeller engine -- as described above Helicopter main rotor -- as described above Helicopter tail rotor -- as described above Basically, I'd like an easy way to accomplish the following: Toggle constant-speed/auto-pitch - constant-speed/auto-torque - full manual torque/pitch Bind cyclic to pitch/roll and collective to up/down Bind pitch to yaw and make it work as expected with SAS (tail rotor case) Specify the number and type of blades easily Specify the rotation direction of the whole assembly rather than having to do it separately for the blades and the motor Intuitively handle backward-pointing propellers (reverse direction switch) This should also be easy enough and have good enough defaults that you could assemble a plane or a helicopter, and it would work more or less like you'd naively expect it to work. If you were doing it completely from scratch, the only new thing you'd have to deal with is torque.

Propellers popped up in Dakota's Top Ten Requests thread a few times and I got to thinking about them. I really enjoyed making propeller and rotorcraft in KSP1 but I thought they were really fiddly and I think they need to be re-thought for KSP2, if they decide to implement them. Here's how I'd go about it! We should still have torque It's an important design consideration and getting rid of it would make propellers too similar to jet engines! Blades should be parameters Instead of attaching blades to motors and then fiddling with them, the critical things should be parameters on the motor: Number of blades Size of blade Rotation direction (affects both blade variant and motor direction so they always match) Reverse rotation switch (for backward-facing props) These should have a sensible default for each motor size. Blades should have auto-pitch as the default option We've had constant-speed propellers with automatic pitch for ages and ages and I think we should have them in KSP as well. There should be an option to switch to manual pitch as well because sometimes you want to. Default axis binds for torque and pitch Throttle controls engine torque Up/Down controls blade pitch (if not set to automatic/constant-speed) You could reassign these but you shouldn't have to assign them manually every time. Handle helicopter main rotors separately You would have to explicitly choose to make a propeller a helicopter rotor. This would change its axis/keybinds and behavior. These could be entirely different parts, or a switch you can flip on a part. Constant-speed/automatic pitch would be removed The up/down axis would control pitch The roll and pitch axes (QE/WS) would control cyclic Handle helicopter tail rotors separately Like for the main rotor, the tail rotor should be either a designated part or a mode/switch you can flip. It has auto-torque to keep it constant speed The yaw axis (AD) will control pitch SAS will automatically adjust it to keep the craft's orientation stable In sum If they were designed this way, making a functional propeller plane would be almost as easy as making a jet plane, as you'd only have to deal with torque. Making a functional helicopter would be fairly straightforward too: install a main rotor and tail rotor (or two counterrotating main rotors), and off you go. I know that this may sound too much like "easy mode" for some people, but I really think they were too difficult to get into for most people, and even when you knew how they worked, they needed too much manual tweaking to fly. Single main rotor helicopters in particular were really hard to build and even when built right were really squirrelly. I think that with this kind of approach, lots more people would use them, and you'd still be able to set them to "full manual" if you wanted the advanced stuff. What do you think?

I like the cut of your jib @Master39, our lists have a lot of overlap!

I'd go a step further than that, if you don't make it scale gracefully between 720p, 1080p, 1440p, 4K, and widescreen, you need to up your game. Even 720p is super necessary for low-end machines and potential tablet/handheld ports!

I think it'd be great if we could move the UI elements where we want them! Personally I'm fine with the positioning as it is, but my biggest issue with the UI right now is readability -- the pixelated fonts affect that adversely especially at screen resolutions that aren't "native" for the design, the colors lack contrast (it's not easy to tell at a glance whether SAS is on or off and too many of the markers on the navball look same-y and sometimes don't contrast enough with the navball itself), and there's also too much visual noise, little labels and other flourishes that detract from that.

Electric propellers and rotors (atmo and water) Aerostats Ground effect and water surface physics (seaplanes, ekranoplans) Mission editor integrated into campaign Mission planner assistance (encounters, porkchops, alarms etc) Robotics EVA construction Life support Outer planets in kerbolar system Decals Edit: I'll add a rationale to these even at the risk of making it tl;dr Items 1 and 2 (propellers and aerostats) would be relatively easy (I think) and would greatly extend the range of different vehicles we can build. Item 3 would further extend this through improvements to physics. Items 4 and 5 (mission editor, mission planner) would be partly QoL, partly a new gameplay system with its own incentives; I think it would add a new dimension to gameplay without breaking anything or being all that complicated to do, at least at a basic level. This isn't like Making History where you set up things; it would essentially be setting up a series of objectives by selecting from a list. Items 6 and 7 (robotics and EVA construction) would further build on 1-3. I put it lower in the list because they're probably significantly work (big payoff too). Item 8 (life support) is a big one. If it's effectively ignorable for Mun/Minmus and a relatively simple mass tax for close interplanetary, but increasingly relevant the further out you go as the resource/supply line mechanic comes online, I think it could do a lot to maintain challenge in the mid/late game. One of KSP1's problems was that it's brutally hard to get started with it, but once you know how to play it, "everything becomes easy" unless you mod it. I believe LS could go a long way to fixing this and keeping the game challenging all the way through, even when we have sci-fi engines that make Tylo a doddle. Item 9 (outer planets) would be a stepping stone to interstellar. Item 10 (decals) would just be... nice and fun! The paint scheme is really pretty but I'd like to stencil on some messages and flags and logos onto my craft.

Ha!

Same for multiplayer! Literally anyone with any game development experience would tell you that you simply cannot engineer multiplayer in after the fact, you have to design for it from the start. That SQUAD didn't know this because KSP was their first game is totally understandable, but it was still a big mistake to promise it! It's also not reasonable to expect that T2/PD would be willing to bankroll effectively a complete rewrite of the game for free. It still remains to be seen whether and to what extent KSP2 will eventually deliver on the multiplayer promise, but at least ST/IG has taken it into account from the start!

Now you're just being silly! That's an edge case causing a CTD. It would be nice if you could dock with two ports at the same time but it's hardly surprising that something like that doesn't figure on the QA checklist.

So what was in it? I'm don't feel like watching 75 minutes of handheld mobile phone video

Oh? What do you think these are, hmm?

Happened to me too on a Mun mission -- taking off from the Munar surface left my lander in the Landed state. No trajectory lines. Additionally, after I had reached orbit I saved, quit, and reloaded; after this, the craft's velocity relative to the surface was zero, causing it to drop straight down and crash.

I expect they’ll want to go through the roadmap at A priority level before starting to implement B or C priority stuff. So I’d be surprised if Science gets major expansions before they’ve gotten to multiplayer, unless it’s something that explicitly ties into the new milestone (like scanning for resources). You never know but it’s always a trade-off!

Performance shouldn’t be an issue, the little blurry window is a design decision.

KSP aerodynamics aren't all that realistic to start with. I think a simple fudge would do it. There's a KSP1 ground effect mod that does this and it's good enough for the user story. Just add a coefficient to the vertical component of lift when approaching the ground and call it a day...

Unrealistic expectations set you up for disappointments!

Then I think you need to recalibrate your expectations, as the KSP2 general design paradigm has been to go broader rather than deeper. Why do you think CommNet would be any different? There was a suggestion that instead of being able to transmit/retrieve anything, science experiments will have a flag for "can transmit." If I had to hazard a guess, I'd expect that experiments that involve taking readings can be transmitted back with no loss of reward, but experiments that involve material samples will have to be returned. If that's the case, then the only thing about comms is that for them to work, you need to have a connection. If you're expecting something deeper or more detailed than that, I think you're setting yourself up for a disappointment again.

We don't know anything at all about their other project though, so anything we come up with about it right now is just pure fantasy!

I would've gone a bit deeper on the simulation side: FAR-like aerodynamics and a life support system that's ignorable in the Kerbin system but starts to become relevant for interplanetary missions and is crucial for colonization and outer Kerbolar system missions and a core part of interstellar. I would also have at least explored the possibility of turning the contract/mission system on its head: instead of the game giving you missions, you could plan them yourself, setting your own objectives. You would then get rewards for meeting these objectives, with bigger payoffs for combining harder objectives, and diminishing payoffs for repeat missions. (You'd still be able to do ad-hoc missions as now, you just wouldn't get the extra payoff for making the plan and sticking to it.) For the tech tree, I would have used cost/reward as an incentive for outward exploration: higher tiers should cost exponentially more than lower tiers, and you could only get the currency for them by exploring outwards. On the parts side, I would've tried to cut down the number of similar parts pretty drastically by making things parameterized or procedural -- for example, have one tank of each diameter and let you pick the length as a variant, and then specify what it contains. Still keep it legos but cut down on the clutter. I also have a pretty clear idea of what I'd want to do with the resource system and multiplayer but since we know very little about that at this point, I don't think there's much point to get into that.

I do too, but I do recognize that if it had been me, I would have made a different KSP2 than they are!

No they're not, these are design decisions! Exactly, it's part of your vision, but it's not part of Nate's vision! They're not the same!

That's all perfectly fine, but how can you do all that and at the same time say that Nate's vision is your vision? It clearly isn't, Nate is making choices you don't like! There will be no life support, radiation management is a very hazy "maybe some day," science will not be like Kerbalism, there's no indication they have any intention of doing anything with CommNet beyond a reimplementation of KSP1, the multiplayer game will be nothing like the persistent-world MMO with giant busy player-created colonies, and so on and so on. Your vision of the game is just really different from Nate's!

Then how come you’re on the science thread arguing that 0.2.0 ought to be like Kerbalism when it’s clear it’s not?

I expect that there will be missions with science objectives pushing you to explore ever further, unlocked by unlocking various nodes in the tech tree. I hope there will be a possibility to design my own missions, or at the very least that there will be a menu of missions to choose from, so that I can set my own objectives rather than be led through the game on a predetermined path.

I think it's pretty unlikely that KSP2's multiplayer will be anything like that. Most likely you'll only be able to do stuff like have a fun session with a friend doing a collaborative Mun mission, or a space race where the first one to the Mun wins (real time, not game time). You might also be able to invite a couple of friends to drop in on your game. But I don't think they have the team to make something that would allow servers with persistent worlds that would really give you that experience. Please remember that the game they're making is their vision, not your vision, and it is really likely that they're actually different visions aren't meant to meet!