Ashandalar

Colonies should function just fine in sandbox, without any resources or money. You'll still be able to found colonies, get used to the colony building system and physics, and launch rockets from the colonies. That's more than enough to include in the update without having to design a stopgap economy system that you intend to remove later anyway.

Behind the camera.

That diagram is explaining that the direction of the velocity vector (prograde) rotates during a gravity turn, not that the craft itself rotates.

We've known they are using Unity since 2019.

Some new images from the Discord screenshots channel:

And how does it do that? By using a lookup table: https://discord.com/api/v8/applications/detectable (KSP1 is entry 171).

Fwiw, I still think Matt was just trolling. I find it very unlikely that Discord would automatically recognise a KSP2 executable at present, nevermind a version with "Closed Beta" in the file path.

The colour-coding makes it clear that Eeloo is the grey planet before the "???". Dres is the missing planet in the clip (perhaps a reference to the well-known in-joke).

This was also my guess, considering a new planet was also teased in the third feature video: With what's visible on the surface, I was also sceptical, but with camera clipping revealing that the green light at the right has five satellites, I now think it's pretty incontrovertibly a map of the Kerbolar system.

It's a trivial enough thing that I would expect it to have been implemented several years ago (it's probably just a flag they can set in Unity's rendering engine). It is definitely weird that they don't seem to have it turned on for promotional screenshots.

No one is suggesting "checking various statistics in the computer's performance" to automatically detect when to save. The suggestion is that the program responds to a signal by saving the game. Ever played a game which saves your progress (up to the last moment) when you exit with Alt+F4 without you explicitly pressing any "save" button? That's the game process responding to the SIGINT signal by first saving, then exiting.

A few people here don't seem to know how signals work in modern operating systems and CPUs, which I don't blame them for, but they really should understand what OP's suggestion actually means if they're going to engage with it. The suggestion doesn't require Intercept to manually fork a new thread that constantly polls for a specific signal, taking up CPU cycles. Signal-handling functionality is implemented by interrupts at the operating system level, and signal-handling code will already be present in the KSP2 executable (for example, it's how programs react to you pressing Alt+F4, or Ctrl+C in a terminal). OP is suggesting they add a quicksave call to the signal-handler for a particular signal. This additional code is only executed when that specific signal is caught and adds no overhead at all (aside from a trivial increase in executable size) when the process is running normally. Because the signal-handler is run as an interrupt, it can progress even if the main process is completely locked-up for whatever reason.

This can be resolved by synchronising not actually showing the fast-forwarding of time as we're used to in KSP1, but instantaneously jumping to the synchronisation point in the future. This is easy to implement with pure, stable Keplerian orbits (and maybe even under thrust with the new non-impulsive manoeuvres) , so as long as your orbits are stable, it could be as easy as clicking a button and being instantly in-sync.

It would be a terrible gameplay experience not because one of the players is griefing, but because of the constant waiting you'll have to endure during normal gameplay. If two players aren't in complete lockstep, always viewing / flying the same craft, one will have to wait for the other execute their manoeuvres before they get to do theirs. Obviously, with competing agencies, players won't be flying the same craft at the same time. From ShadowZone's developer interview coinciding with the early access reveal, he got a quote that Intercept are "very confident with the timewarp solution". If I were a KSP2 developer, and the above described the best timewarp solution we were able to come up with, I certainly wouldn't be very confident in it.

Yes, I agree that is possible. It's also possible that it was just a placeholder / test object that's long been removed from the game, or maybe it's a transitory asteroid with a procedural name, or any number of other scenarios. Until the developers tell us, or the interstellar update is released, we don't know which of these scenarios is the case.

An interesting video, but I wouldn't take anything not explicitly stated by the developers overly seriously. Most of the footage being analysed here are from test builds inserted into the background of videos, essentially as a flavour of the development process, not gameplay of a final build. For example, maybe Gurdamma will have a moon called Gop, maybe it won't, I don't know, but its velocity of "9999" and its altitude of "9999999999" suggests to me that any information from that clip can't really be relied upon.

Regarding toggles, of course I agree life support should be toggleable in KSP2, but in the same tier of toggleable that "infinite electricity" is in KSP1. That is, if you really want to play without batteries, solar panels, and RTGs, you can change the setting whenever you like, but it's on by default, and is a core component of spacecraft design that's assumed to be active for all balancing. That's how core I think life support should be.

Nate actually said, about agencies: "each of which is located at a different location on Kerbin", so it sounds like they will each have their own space centre, not just their own launch pad. Whether there will be a few pre-set locations for hand-crafted space centres, or whether it will be more free-form, perhaps utilising colony tech, remains to be seen.

N̶o̶t̶h̶i̶n̶g̶ ̶a̶b̶o̶u̶t̶ ̶w̶h̶a̶t̶ ̶w̶a̶s̶ ̶s̶a̶i̶d̶ ̶e̶v̶e̶n̶ ̶h̶i̶n̶t̶e̶d̶ ̶a̶t̶ ̶b̶e̶i̶n̶g̶ ̶a̶n̶ ̶M̶M̶O̶;̶ ̶I̶̶̶'̶̶̶m̶̶̶ ̶̶̶n̶̶̶o̶̶̶t̶̶̶ ̶̶̶s̶̶̶u̶̶̶r̶̶̶e̶̶̶ ̶̶̶w̶̶̶h̶̶̶e̶̶̶r̶̶̶e̶̶̶ ̶̶̶y̶̶̶o̶̶̶u̶̶̶ ̶̶̶g̶̶̶e̶̶̶t̶̶̶ ̶̶̶t̶̶̶h̶̶̶a̶̶̶t̶̶̶.̶̶̶ Edit: I had only seen the stream when I wrote this post. I now see that the article mentions "MMO", but as others have pointed out, this seems to be speculation by the author or the article, not directly from the interview with Nate. All that was really said is that there will be the option for players to work for different agencies as well as the option to work cooperatively for the same agency. Factorio also has this option with different forces having separate tech trees, for example, but this is all still within the private client-server paradigm. If this counts as an MMO, the term is almost meaningless. I don't see where the "massively" part comes in.

And if you don't trust the 2019 information after all of the delays, it was also reconfirmed in the early access roadmap...

I'd guess a moon of Jool, judging by the green planetshine.

Because we want to do more in multiplayer than racing rovers.

Reminder that the game is being developed by Intercept Games, who have many (former?) SQUAD members on staff, not by some other beleaguered T2 studio you might point to as an example. Different studios, even if they ultimately have the same owner, are not interchangeable. I make no claims about how buggy or bug-free KSP2 will be, because I have no idea, but neither do you.

Factorio is an excellent example I'd point to for mod integration in the official game client. Mod developers can submit their mods at mods.factorio.com (a subdomain of the official Factorio domain) and are then searchable in-game via the mods menu. The menu handles all the relevant package management, such as downloading dependencies, determining version compatibilities, and updating mods, like CKAN does for KSP, but built-into the game client itself. Single-player saves and multi-player servers can have their own set of mods independent of one another, and the client prompts you when you attempt to load a game with different mods than the active client, giving a button to automatically synchronise with the save or server. And with all of this, you can still manually copy mod files into the appropriate directory, for example if you're mid-way through developing a mod, or don't want to use the in-game menu for whatever reason.

No. Why would you? Since you bought the DLCs, you have access to the DLCs (a̶n̶d̶ ̶h̶a̶v̶e̶ ̶h̶a̶d̶ ̶a̶c̶c̶e̶s̶s̶ ̶t̶o̶ ̶t̶h̶e̶m̶ ̶f̶o̶r̶ ̶o̶v̶e̶r̶ ̶t̶h̶r̶e̶e̶ ̶y̶e̶a̶r̶s̶ ̶a̶t̶ ̶t̶h̶i̶s̶ ̶p̶o̶i̶n̶t̶) - that's where the transaction ended. Edit: I was assuming you meant you bought them in August 2019, when the game was first announced. If you meant that you bought them recently, when early access was announced, nothing changes. You still have access to the DLCs that you bought, and still will when KSP2 is released.