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.

The KSP Instagram posted a couple videos to their story, basically of a some sheet music and a live orchestra setting up, then recording.

Actually that's not quite right If your measured velocity approaches c in reference to an inertial observer, the equation v = a t (t = v / a) doesn't hold, so it takes longer than 354.4 days to accelerate to v = c - 458m/s. It's basically due to how spacetime appears to bend to you, as @t_v said. No matter what you measured local "gravity" due to acceleration is, your velocity will never reach c, and your velocity increases less and less with the same energy added to your system. Which is why it takes 6.7 years of proper time (tau) to accelerate to v (actually w according to normal GR convention) = c - 458m/s with an apparent acceleration of alpha = 1g. It's a hyperbolic relation, following tau = (c / alpha) cosh-1(gammamax)

In the original KSP RCS thrusters or the Dawn engine currently fill that niche. I imagine that they won't leave that thrust class unrepresented in the sequel ¯\_ (ツ)_/¯

It's, once again, likely to be miniscule. One of the biggest design considerations of a nuclear reactor is making sure that most of the radiation stays inside shielding, and I would actually make an assumption that escaping radiation would leave in a symmetrical set of directions, so there wouldn't be a net "radiation pressure" in any particular direction. In real life over the course of many years an orbiting reactor might drift a little due to the momentum of escaping radiation, depending heavily on the exact design of and wear on the reactor but it would be absurdly difficult to model in the context of KSP.

Care to clarify? We can already accelerate time up to 100,000x in KSP 1 - focusing on a vessel going 458m/s below c (unlikely scenario) would cause the background to accelerate 500-600x. How is that any more "wild" than just accelerating time a smidge in KSP 1? I did some number crunching (which I failed to do before asserting things would break in the background, oops), and yeah, you can get to a very large fraction of c without your Lorentz factoring breaking 100,000, so from a gameplay perspective any alarms you set could pause the game in a fairly straightforward way and let you deal with it before returning to your relativistic ship (probably). But to reach a Lorentz factor of 100,000 your vessel would have to be going 99.999999995% of c, or just 15 millimeters/s below c. Reaching those speeds (or even even the c - 458m/s) by accelerating constantly in one direction at 1g would take years from the perspective of the traveler and decades or centuries from the perspective of an inertial observer. I won't comment on the technical feasibility of implementing a system that can handle time dilation. However, especially with cheats enabled (like infinite fuel), the devs wouldn't want to rule out the possibility of very high Lorentz factors, even though the vast majority of players would experience a more physically realistic max Lorentz factor on the order of 1.03 or less, like what whatsEJstandfor said. An added wrinkle to any implementation of relativistic physics that I don't think anyone has brought up before is length contraction; at high fractions of c that would be extremely jarring to players that have never visualized it before. In my limited experience it would also probably be more difficult to implement than a simple time dilation system since, after all, we already have time warp.

I think that planets orbiting stars won't ever get fast enough to experience serious relativistic effects. As for ships, I actually don't know how things would be affected. If space is compressed, do you experience stronger attraction along the axis that you are traveling along relative to the axes that you are not traveling along? In either case, by the time you are moving that fast, your orbit isn't going to deflect much at all. Blondai was probably not thinking of objects orbits going really fast, but was instead referring to the real-life perturbations on the orbit of Mercury accounted for by general relativity. The likely issue with that, though, is that relativistic effects only account for minute differences in how orbits change over long periods of time, and it would be really resource-intensive to simulate those for low payoff. Using the Mercury example, effects predicted by general relativity only account for 43 arcsec of perihelion precession per century (periapsis shifts in orbit by 0.00012° per year), and having that level of precision wouldn't be all that helpful from a gameplay perspective, and certainly not worth the computational cost to achieve it. Since I believe the plan is to keep planets on rails like in KSP1 and not dynamically calculate planetary positions, this would add a mountain of computational cost. The issue of time dilation does seem to come up a lot on this forum, though, and the consensus seems to be that while it would be cool if time dilation got implemented, there's a lot of questions as to how you could actually implement it in a way that makes for fun gameplay and wouldn't cause all of your stuff in the background go wild when you were focused on a vessel moving at a high fraction of c. The devs haven't commented on time dilation at all, as far as I know.

I'd say it could be for more alignment, but there was some fairly wild speculation when these first started that the alignment dots at the top actually represented 12 star systems. The bottom left could indicate one is Kerbol with 11 new star systems? Seems like alignment would be more likely to me, tho.

It's definitely a continuation of an Arecibo-style message, like the previous ones were. I'm taking a stab at trying to decode it now.

T2's fiscal year 2022 ended March 31, 2022. FY23 started April 1, 2022 and goes until March 31, 2023.