Vl3d

Yes please!

Reminder that tomorrow the big reveal day @ PC Gamer, interview included.

It's not clear that the OP is mainly about the initial KSP1 Early Access promotional animations and asking if we're going to see something similar for KSP2?

What you're saying it's very confusing. AFAIK TWR is set as reference to the SOI you are in and varies according to altitude.

This thread can be used for a conversation about the new and old promotional videos for KSP. I really like the animations from 9-10 years ago - they really added to the lore and character development. Hope we get something as entertaining for KSP2. And because we might be getting a new trailer soon, don't forget to rewatch the most epic cinematic ever made.

Are you sure about that? You can change the body frame of reference in the VAB and it updates the DeltaV and TWR values in the staging.

Why? "The law of unintended consequences pushes us ceaselessly through the years, permitting no pause for perspective." - Richard Schickel "Without reflection, we go blindly on our way, creating more unintended consequences, and failing to achieve anything useful." - Margaret J. Wheatley

It's a hybrid system. Keep in mind that there would be 2 types of real-time multiplayer bubbles that can be exited at any time through time-warp and re-entered at will (choosing to sync to server): celestial body + atmosphere / low orbit custom sized (for space stations) Let me give you a proper example. Let's say players A and B are doing a race to the Mun. Phase 1 - Kerbin multiplayer bubble: both players set the Mun as the target. Phase 2 - exiting real-time multiplayer and going into enhanced single-player mode while in Kerbin SOI players time zoom while on the pads to the appropriate launch window (or whenever they want) players launch the rockets (each one sees the star system configuration that is correct for them - it is generally different for each player if they do not launch simultaneously) players use time zoom whenever they want (because they desynced from multiplayer) Phase 3 - orbital maneuvering: let's say the players achieve orbit and they want to do a rendezvous for any reason (get so close that they enter each other's real-time bubble) keep in mind that each of them see a different star system configuration on their local PC, meaning that also the orbital position of each player is desynced (but can be shown on-rails with orbits visible in map view of each player according to server updated orbital parameters, each player craft moving as in a locally controlled Master Warp solution where speeds are proportional to the player controlled time zoom factor as shown in OP)) each of them set the other players vessel as target, perform appropriate maneuvers (they are still in single-player, although they see the other person's craft in map view, it is a local rendition of the on-rails parameters, calculated according to each players local time and updated if another player changes orbit) when they get sufficiently close to each other they enter their respective small real-time multiplayer bubble, at which point the star system configuration would ideally resync to one version for both players (so it's not daytime for one and nighttime for another - meaning the dependent resources like electricity sync to server controlled values) players do whatever they want in multi-player (like dock or fly together) Phase 4 - burning for the Mun and coasting: player A decides to leave, sets the correct target, departs the real-time multiplayer bubble player B sees this in real-time, player A moves at normal speed because he is rendered on player B's PC using the on-rails values of player A's current orbit B decides to leave also, but burn more to get to the Mun faster B sets the Mun as target, plots the maneuver nodes to arrive faster than A, burns remember, A and B are now in single-player mode on their journey to the Mun, each controls time zoom as they wish Phase 5 - arriving in Mun orbit: Desynced in the real world - player A arrives at the Mun in 10 minutes of real gameplay time, player B goes AFK for 2 days and comes back to the game: of course, in the real world, each player arrives whenever they want - this presents us with a paradox - if A arrives first in the real world, he should see in map that B was actually first in-game, but there is no one there to do the actual orbital insertion burn because B is AFK. So the game should know how to automatically perform the burn and insert B into a stable orbit as B planned before exiting the game. A arrives and syncs to the Mun real-time multiplayer bubble, sees B is already in orbit A does the landing when B comes back to the game after 2 days, he sees he stayed in orbit while A landed. Synced in the real world - players continue playing in the real-world, arrive at roughly the same time both players sync to the Mun real-time multiplayer bubble, do a race to see who lands first As you can see, there are problems with: syncing the solar system configuration for all players when they enter a multiplayer bubble (can be hidden / playtested / maybe ignored) correctly updating other players craft orbital positions in the map view rendered on the local PC when in single-player mode (but this should be calculated locally depending on the on-rails parameters for their crafts (that would be updated by the server), but is a source of trouble even if time zoom accelerates movement for all players, as AFK players should be held in a cyclic state like in orbit or landed and their crafts ghosted (unable to interact with)) syncing resources (should a player be able to warp to accelerate resource extraction or maybe extraction should be a continuous real-time action instead) All these can be managed. The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

And what exactly are you saying you can't do?

First of all, my proposed solution is missing from the list, so I will link it: All versions in OP break causality, only 3/ 4 are kind of functional but introduce FTL or arbitrarily powerful engines (completely unacceptable). The idea of 1 is good only if the server controls resyncing. I really don't get why everyone wants to force time zoom to work in a multiplayer setting. Just separate the two - you only get to warp when not synced to multiplayer. You always play multiplayer in real-time. Problem solved. If you can time warp only when desynced from multiplayer, everything you do while warping is basically single player and is in accordance to the rules of physics, you do not use FTL because you are traveling as a single player. The main idea is that players can control either speed of time or speed of movement. Both of these are unacceptable in a multiplayer setting. So in the real time bubbles all gameplay time should be controlled by the server. Period. So, of course, the main issue is: how do you explain the universal time jump when syncing to the multiplayer real time bubbles for all observers without using crutches like FTL? Easy, do not show Universal Time, instead focus on mission time, syncing star system configuration (everything on rails is cyclic). Time becomes an ordered sequence of actions and milestones players have reached. The most fundamental problem is the refusal of players to give up on controlling time zoom in multiplayer. These concepts are absolutely incompatible because of paradoxes. Separate them with a journey planner and desyncing from MP when going to (deep) space and all problems are solved.

Well, that's the point. We don't know if we're getting the interface of KerbNet 2 or that of a ScanSat system. It's going to be a big reveal (hopefully before Feb. 24).

I just don't play like that, I want to pick interesting places to land after analysis of the maps.

We need some kind of Altimetry and Slope maps from the beginning so we know where to land, also we need something to detect Biomes and Anomalies. I think we should have telescopes from the start (to detect atmosphere, temperature, initial topography, bodies of liquid). Other maps should come in the first big Science update (maps that integrate information from the experiments and sensors). As an afterthought, should Radiation be a thing in Early Access from the start?

I think initially having limited information about celestial bodies and having to orbit and scan them first is a really good idea from ScanSat: generating 2D maps and high resolution 3D overlays shown directly on the celestial body. Telescopes should also help with this as the game progresses. Is there any use for KerbNet as it was in KSP1? I found hunting for anomalies kind of interactive / interesting and annoying at the same time. Maybe automating the process like ScanSat does and then analyzing maps / overlays would be better. Also I think a tool like the Trajectories mod should be in the game as a high tech part to unlock. And I have not seen anything about spiraling orbits displayed in map view (as KSP2 should display orbits that change while under constant acceleration, and maneuver nodes should care about where the acceleration phase starts and where it ends). PS: Are we going to have a system similar to Research Bodies where we progressively discover celestial bodies (and improve the way they look in map view) with telescopes? Any info about these topics?

I told you guys this game has a big budget from Private Division (Take Two). AAA baby, Early Access AAA!

https://instagram.com/stories/kerbalspacep/2968488352659521884

Big budget soundtrack incoming! See recent stories on social media.

It should be point-to-point autopilot unlocked as late game tech only for previously flown craft and mission profiles. Look, I have big plans for crafts and colonies.. I really don't have time to waste flying the same rocket to orbit 10 times in a row. It's grindy.

Any new info about the game landing today?

I've been reading some old interviews and I believe each colony will have it's own tech level (tech tree tier). I think that's great - you can only build and launch ships for which you have or are able to manufacture components. This couples great with needing material resources for everything.

Not completely replacing, just progressively making it less manually intensive, after doing the thing a couple of times. Like SAS / target hold in KSP1, or maneuver nodes (would you play the game if you had to calculate orbits, targets and burn times?)

Autopilot should be available for any previously flown journey / mission profile. This would also allow the integration of part failures (get notified to intervene if necessary to save a mission, not getting frustrated by too many failures when piloting manually, only some to keep things interesting).

You either abstract away the journey and just show a recorded takeoff and landing at the right time or you automate using consecutive waypoints autopilot. This would allow you to also plan the journey and make modifications to a route.