daninplainsight

I'm definitely most excited for the colonies and the mechanics of ISRU to make colonies self-sustaining, and eventually so that colonies can manufacture the crafts to make new colonies

Matt Lowne is saying he's posting KSP videos every day this week, starting tomorrow at 2 pm GMT (6 am PST). Awfully specific, and it's the same time KSP2 drops on Friday. Maybe his KSP content this week will actually be KSP2?

Release time map!

I'm asking these questions because I don't think your idea would even make it off the drawing board without them getting answered first. I like the basic concept because I think it'd be great for me to timewarp my first interstellar mission to arrival and not have hundreds or thousands of years pass back in the Kerbolar system, but allowing the user to go back in time without effecting future events that have already been defined is very difficult to even make work outside a few simple cases, where future events can't reasonably be effected by past ones. However this is implemented, if it's going beyond fairly simple, limited cases, it would have to be baked in from the start of development. More than just needing some subsystems for this to work, almost all subsystems would have to be designed with this in mind for them to function correctly, and we have no indication that they've planned a feature like this. Obviously, no evidence that this is planned isn't evidence that they're not planning this, but this is big enough I feel like they might have mentioned something about it by now. We know they're planning on allowing milkrun missions/trade routes to be automated, but we don't even know if that means that we'll see ghosts in the game of traveling cargo ships, or if we'll just get resources periodically deposited. I will grant you that this may be able to piggyback off whatever the devs have planned for implementing time streams in multiplayer. They've said that they've architected the game around making it multiplayer-friendly and that may include unconventional timestreams, but there's no way to know until the devs say something.

How will the user know when they've caused a paradox? Will they know when they've caused it? Like they'll get a notification: "You just caused the mission recording for vehicles A, B, C, D to break, be sure to meet X condition before time T or their recordings won't continue"? Or not until the recording fails?

I'm not sure that's a desirable outcome for the users to find themselves in. Say a new mission A was the flight of a mothership that stopped to refuel at an orbital depot along the way to Jool or something, where it spawned off missions B, C, D as landers, science satellites, etc., which the user records after completing all of them. Then they reverted to the start of mission A, and a utility drone in mission E drained the fuel depot before mission A got to it. It sounds like that would simply cause A-D to fail. It would probably make players, even experienced ones, very angry, because I think that's something a lot of us could just do accidentally. For me, it would garner a similar response as if the game told me it had corrupted my save file and I had to redo the last 6 hours of gameplay.

I'm not sure I'm understanding how this system would handle causality conflicts. For example, suppose you're doing a rescue mission to rescue some Kerbals stranded on Duna. You record mission A as a rescue, where you leave Kerbin, use a Hohmann transfer at the appropriate window, rescue your Kerbals, and then return to Kerbin orbit before reverting to when you first started your mission on the main timeline. Then you decide, oh, I probably could have used this torch ship that was already in orbit around Kerbin, so in mission B you leave Kerbin orbit before mission A and arrive at Duna after only a few days but then botch the landing and kill all of the stranded Kerbals instead of rescuing them. How would the game be able to handle reconciling differences? How would the recording of Mission A respond? Would the game force you, as the player, to choose which sequence of events is preferred?

Are you picturing an in-game tool or just modding support? The devs have promised greater modding support for KSP2 and custom planet packs were always one of the most popular types of mods for KSP1, so I'm sure we'll see plenty of fanmade solar systems in the coming months, though you'd have to learn all the requisite coding and 3D modeling skills if you want to do it yourself. Any kind of in-game tools would be basically impossible to implement without heavy procedural generation, and I'd be surprised if the devs felt they had any reason to pour resources into something like that, especially during Early Access.

I'm guessing they're basically just under a review embargo agreement? Though not as common for streamers, definitely standard for games journalism at this point. Review embargos normally lift between 2-7 days before release, I believe.

One caveat with GeForce Now is that they only allow Steam Workshop mods, and you have to reinstall them each time you reopen a game. So unless there's a mod downloader/manager built in to KSP2, it's unlikely you'll be able to mod it through GeForce Now at all. (Though if you were planning on just playing stock anyway this won't really be a problem.)

I'm also the sort that likes to see all of my craft when the parts window is open, because I haven't always decided what I want next. Having the parts selector cover what I'm working on would be a lot more annoying for me. However, I can see how it having it locked to one side could be annoying for users with ultrawide monitors. Unpinning the selector could be a happy medium. Maybe binding some hotkeys for navigating it could also help? That way you wouldn't necessarily have to move the mouse.

Per NASA, pressure at that altitude would be similar to pressure at Earth's surface. Temperatures still vary from warm to too hot (30-70°C/86-158°F), but presumably at night it would be on the cooler end, and you'd also be shielded from solar wind at that time. Radiation then would be no different than during a nighttime EVA on the Moon, coming primarily from GCRs.

I like Pthigrivi's notion of having unlocked bonuses applied across the board. The way I would envision it is we keep the original 3 classes, but you can unlock class-specific bonuses that would automatically apply to all Kerbals of that class. But, again, I'm of the opinion that the average KSP2 save will likely have many more Kerbals than in the original, so anything we can do to simplify the class system would be beneficial. However, something else that may potentially balance having a more complex class system is having a colonist ("Kolonist"?) class. Kolonists would be entirely autonomous, separate from your main Kerbonaut corps. So you may be able to have hundreds of Kolonists that act as a single mass, and perform day-to-day maintenance tasks in colonies or huge motherships, and then you have maybe a couple dozen Kerbonauts that can run your active missions or do anything else that is directly controlled by the player. Basically, you'd have a smaller group of PCs that would be easier to manage, and then hundreds of NPCs that do automated work.

Your classes have the benefit of all fitting together pretty cohesively, but I don't think functionally increasing the number of classes from 3 to 18 would streamline gameplay. Anticipating that we'll likely have hundreds Kerbals, keeping track of so many specializations would quickly become a massive headache without some major automation. And if you're going to automate away managing so many classes, it begs the question of why you even have that many in the first place.

The devs have said that there will be a persistent resource system working in the background for modules that gather/consume resources, even those that aren't loaded into physics range. The use case you described seems kind of like a natural extension of the system the devs described.