Release Date Update from the KSP2 Team

[Vanamonde]

A number of comments have been removed. Whatever your feelings about the game being delayed, posting degrading comments about the game's makers won't make it come out any faster. Whatever your feelings about posts degrading the game's makers, posting degrading comments about the degraders won't make them any happier about the delay. Please remain civil with each other, and toward the development team. 

[Derpiesaurus]

8 minutes ago, PopinFRESH said:

Yeah, Q4 FY2023 for T2 is Q1 calendar 2023 (January - March 2023), which is what I'd also label as "early 2023".

I'd consider early 2023 to be a time within spring, which extends a bit further, but yeah it's not as much new info as I initially thought it could be. I suppose it does guarantee it's before March 31st, and that allows me to concentrate my hype on the time rather than be hyped without knowing how long I will wait (which makes me want to bang my head against stuff).

Here's for March 15th! 

[razark]

[kerbiloid]

53 minutes ago, Superfluous J said:

1 hour ago, kerbiloid said:

1) What have been we watching in 2019?

I don't understand this question. There

The game was looking pretty ready in 2019.

54 minutes ago, Superfluous J said:

However if that source code was ready for release they'd have released it back then

Same.

55 minutes ago, Superfluous J said:

It's possibly not even the same code base they're using today.

Totally changed  the code of already ready and announced game?!

Miracles happen.

56 minutes ago, Superfluous J said:

I don't know between Starship and KSP2, but I would put money on them both being before Orion.

The youngest of us will have a chance to see.

[Johannes]

You got this, I'm rooting for all of you 

Edited May 17, 2022 by Johannes

[Klapaucius]

9 hours ago, Lisias said:

Of course I can't talk for anyone else but me, but I'm going to have a hell of a year - whatever happens to me, however, will be done at the end of the year at most and next year will the the year in which I will start recovering. So, nope. I'm not going to spend too much money on gaming for some time (unless things changes dramatically in the next few months, but experience taught me to be conservative).

I know some people in the exactly same situation, and if people enough are on the same boat as me, this may impact the market for sure.

Whatever it is, best wishes and good luck.  Take care of  yourself.

[Superfluous J]

4 hours ago, kerbiloid said:

The game was looking pretty ready in 2019.

The pre-alpha footage we saw in 2019? I'm sure it would have rivaled KSP 0.7.3 in functionality for sure.

4 hours ago, kerbiloid said:

Totally changed  the code of already ready and announced game?!

Yeah what am I thinking that's never happened before.

(EDIT: I never said it was ready, that was you)

Edited May 17, 2022 by Superfluous J

[The Aziz]

4 hours ago, kerbiloid said:

The game was looking pretty ready in 2019.

Was it?

Spoiler

 

vs

Spoiler

 

I also see no mention of procedural parts back in 2019. NERVUS is also quite a fresh addition, and if I'm not mistaken they were hiring part designers not long ago. In 2019 it looked like KSP with few more planets beyond Kerbol. Not a proper sequel with complex colony/interstellar travel mechanics.

[kerbiloid]

1 hour ago, Superfluous J said:

I'm sure it would have rivaled KSP 0.7.3 in functionality for sure.

Several months before the declared release date? When KSP-1 was already 1.1x?

1 hour ago, Superfluous J said:

6 hours ago, kerbiloid said:

Totally changed  the code of already ready and announced game?!

Yeah what am I thinking that's never happened before.

Same.

[Admiral Fluffy]

While we are waiting, can we have some Mystery Goo™ merch?

(I have seen so many people here that I haven't seen before.)

[kerbiloid]

Liquid silicone?

[RayneCloud]

2 hours ago, kerbiloid said:

Several months before the declared release date? When KSP-1 was already 1.1x?

Same.

Yes actually, code bases can and do change, a lot over a the course of the whole development cycle. Re-writes, Forks, Engine Updates and Changes, Code Cleanup passes after an Audit, etc. This does in fact happen, often. 

[kerbiloid]

20 minutes ago, RayneCloud said:

Yes actually, code bases can and do change, a lot over a the course of the whole development cycle. Re-writes, Forks, Engine Updates and Changes, Code Cleanup passes after an Audit, etc. This does in fact happen, often. 

From scratch? Right before the release?

Any project codebase usually gets "frozen" before the release, afair. Changes get done in branches.

[RayneCloud]

7 minutes ago, kerbiloid said:

From scratch? Right before the release?

Any project codebase usually gets "frozen" before the release, afair. Changes get done in branches.

Oh? That? No. That doesn't happen. Especially when a project "goes gold" yeah, thought you were talking about something else. 

[Spaceman.Spiff]

10 hours ago, PopinFRESH said:

number 315...  So officially it looks like the launch date is March 15th 2023.

Maybe they’ll do it on 3/14 for pi day!

[whatsEJstandfor]

This thread reminded me that I had a dream a few weeks ago where they announced that the release date would be pi day, March 14th. I woke up and was like "dang i wonder if thats true" and then remembered it was currently April. However, that's now a possible release date, so I'm calling it: March 14, 2023, and you can take that to the bank

EDIT: I see that @Spaceman.Spiff has sussed out this correct date as well

Edited May 17, 2022 by whatsEJstandfor

[JoeSchmuckatelli]

5 hours ago, The Aziz said:

In 2019 it looked like KSP with few more planets beyond Kerbol. Not a proper sequel with complex colony/interstellar travel mechanics.

That's the thing I'm coming to grips with. 

In retrospect, the 2019 version looks like an updated KSP with some colonies / outposts and likely a single 'other star system to visit' (which I'd have been fine with - and was excited for) 

Lately I'm getting the impression that for all you good players who can visit every planet and moon and do SSTO grand tours - the 'end game content' is going to be massive! 

Thus - instead of a modern refresh of a classic we will get a legitimate successor and effectively a whole new experience 

[PopinFRESH]

53 minutes ago, Spaceman.Spiff said:

Maybe they’ll do it on 3/14 for pi day!

Nope, the ouija board inside the crystal ball clearly pointed to 315 

[kerbiloid]

1 hour ago, RayneCloud said:

1 hour ago, kerbiloid said:

Any project codebase usually gets "frozen" before the release, afair. Changes get done in branches.

Oh? That? No. That doesn't happen. Especially when a project "goes gold" yeah, thought you were talking about something else. 

Am shocked.

Was sure, it's basics.
When you prepare to deliver a 1.4.2 version of a software, you stop changing the 1.4.2 branch code, making only urgent bug fixes, and moving new features and other bug tickets to the 1.4.3 branch schedule.
So, while one programmer is debugging the 1.4.2, another one feels free to start working on the 1.4.3 features.

Thus, the code exists in many branches, with LTS version ones among them, and thus no new code can break the almost-ready-for-release version.

[Arco123]

Half-life 3 x Ksp 2. In all seriousness, this will be the space game that me and many more will play for a long time. 

[obnox twin]

2 hours ago, Arco123 said:

Half-life 3 x Ksp 2. In all seriousness, this will be the space game that me and many more will play for a long time. 

I think majority of ksp players will agree with this me included. Play it for a long time.

[MKI]

7 hours ago, kerbiloid said:

Several months before the declared release date? When KSP-1 was already 1.1x?

Software versioning can be weird. Just because its "1.1" before/at/after release doesn't really mean anything besides whatever subjective metric is being applied to the versions, hopefully its at least consistent. 

 

2 hours ago, kerbiloid said:

Was sure, it's basics.
When you prepare to deliver a 1.4.2 version of a software, you stop changing the 1.4.2 branch code, making only urgent bug fixes, and moving new features and other bug tickets to the 1.4.3 branch schedule.
So, while one programmer is debugging the 1.4.2, another one feels free to start working on the 1.4.3 features.

Thus, the code exists in many branches, with LTS version ones among them, and thus no new code can break the almost-ready-for-release version.

This is the traditional "branch release model", that in a utopia always works, makes for sable on-time software and  "doesn't break".

Except we don't live in a utopia. Whats in branches could change, and even the smallest innocent change could break things.  This also only assumes everything related to software is tied to the codebase, which isn't the case even for a game. 

This model even when used correctly can still create problems. If 1.4.2 issued a patch that fixed the Kraken in a specific scenario, as 1.4.0 got delayed a full physics engine overhaul until 1.5.0. Now when 1.5.0 rolls around you have 2 different changes you need to consolidate due to "divergent branches". If this sounds confusing, its because it is. This usually just results in delays while consolidation is going on to verify everything works with the "new" changes, but it does add complexity and does add more gaps where issues could occur with "fixed" code.

 

 

[kerbiloid]

4 minutes ago, MKI said:

This is the traditional "branch release model", that in a utopia always works

From our real practice. Works perfectly.

5 minutes ago, MKI said:

Whats in branches could change

In the closed (released, abandoned) branches - nothing.

In the active branches - whatever is needed.

6 minutes ago, MKI said:

and even the smallest innocent change could break things. 

That's exactly why the branches exist.
To not damage what already works and should be released soon in the day before the release.

7 minutes ago, MKI said:

This also only assumes everything related to software is tied to the codebase, which isn't the case even for a game. 

?
Obviously the database version and the resources should match the client code version.

That's why several instances of DB exist on SQL server (MS SQL) when needed, and same about the resource copies.
Happily, MSSQL has rather handy database management system, unlike the multi-file ones.
Also, the database should have a creation/filling set of scripts, which save efforts a lot and allows to include the database structure and test data into the versioning system.
But KSP doesn't use a DB at all, so that's not releveant here (and probably this is not an advantage, as, say, sqlite, would be useful in some cases).

Of course, this means that every version content should exist in its own folder. No problem with this except the storage volume. Happily, 7z exists for the inactive stuff.

15 minutes ago, MKI said:

If 1.4.2 issued a patch that fixed the Kraken in a specific scenario, as 1.4.0 got delayed a full physics engine overhaul until 1.5.0. Now when 1.5.0 rolls around you have 2 different changes you need to consolidate due to "divergent branches".

1.4.2, 1.4.0, 1.5.0 are the release names. You may use as many subversions as you need, 1.4.2a, 1.4.2.b, etc.

In case of KSP (and other games) things are even simpler than when you have a ten of customer companies with their specifics in same versions.
Unlike that, a game has just one release sequence.

18 minutes ago, MKI said:

 This usually just results in delays while consolidation is going on to verify everything works with the "new" changes, but it does add complexity and does add more gaps where issues could occur with "fixed" code.

Never caused.

[Snark]

A gentle reminder to try to stay approximately on topic, folks?

Discussion of software release models, branching, etc. is an interesting topic well worthy of discussion, but unless you're tying directly to the topic here-- which is "KSP2 release date in early 2023"-- perhaps better to delve into the details elsewhere?

[BuranAce]

Bruh

Still, Early 2023 is better than 2023