Some more KSP2 footage

[Kerbart]

1 hour ago, GoldForest said:

The game releases in 7 months more than likely and at worst 10 months. Not 2 years. Unless you mean something else.

Software, and schedules. I do admire your optimism for truly believing the 2020 deadline.

[GoldForest]

4 minutes ago, Kerbart said:

Software, and schedules. I do admire your optimism for truly believing the 2020 deadline.

They've been working on it for 2 years now. I'm confident at the end of 2 years and 7 months, it will be ready. Ksp isnt a big game in retrospect.

[TheKSPBeginner]

I am excited for KSP 2 and am wondering if all the current parts will be included

[Kerbart]

4 minutes ago, GoldForest said:

They've been working on it for 2 years now. I'm confident at the end of 2 years and 7 months, it will be ready. Ksp isnt a big game in retrospect.

Tom Cargill, Bell Labs:

Quote

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Your talking about the version 2, written from scratch, of a game that has been under active development for 8 years. They’re not even in Alpha yet (or we wouldn’t see “pre-alpha release” videos). By a company that has no track record of delivering on time. If anything is released in 2020 it’s going to be an Early Access version and I certainly hope they go down that route, but I will be very surprised if the official gold version is released in 2020, and if it is, it will be unfinished and full of bugs.

[GoldForest]

14 minutes ago, Kerbart said:

Tom Cargill, Bell Labs:

Your talking about the version 2, written from scratch, of a game that has been under active development for 8 years. They’re not even in Alpha yet (or we wouldn’t see “pre-alpha release” videos). By a company that has no track record of delivering on time. If anything is released in 2020 it’s going to be an Early Access version and I certainly hope they go down that route, but I will be very surprised if the official gold version is released in 2020, and if it is, it will be unfinished and full of bugs.

They haven't even considered early access, if the German interview is anything to go by.

But like I said, I'm confident. 

[Guest]

9 hours ago, Kerbart said:

Software, and schedules. I do admire your optimism for truly believing the 2020 deadline.

Teams also have budgets. If it doesn't release in 2020 it likely won't release at all.

[GoldForest]

Just now, Brikoleur said:

Teams also have budgets. If it doesn't release in 2020 it likely won't release at all.

Star Theory kind of has a hard limit. Not due to budget or software... but because Take Two has set a time limit for them to get KSP 2 out, at least that's the theory going around. 

Take-Two wants KSP 2 out before the fiscal year is up, which ends in March. So, Star Theory is more than likely going to push hard for a March Release to keep their corporate overlords happy. 

[nikokespprfan]

ABout the german interview, I made a mistake in translation:

About the performance section:

Quote

Wir haben da tatsächlich noch die ein oder andere Stellschraube an der wir drehen können um die Physikberechnungen noch weiter zu optimieren, nämlich genau diese Physikberechnungen die früher auf der CPU abliefen und dafür gesorgt haben dass die Framerate im ersten Teil doch relativ häufig sehr stark eingebrochen ist. In unserem pre-alpha gameplay dass wir veröffentlicht haben sieht man durchaus ein paar Framerateprobleme. Allerdings sind wir sehr zuversichtlich dass wir diese auch noch in den Griff kriegen bis das Spiel dann letztendlich veröffentlicht wird.

should translate to

Quote

We actually have a few knobs that we can turn to optimize the physics calculations even further, namely exactly these physics calculations that used to run on the CPU and made sure that the frame rate in the first game was relatively often very strong(ly broken).

where everything between parentheses was not added the first time. Sorry for the inconvenience.

[Talavar]

14 hours ago, nikokespprfan said:

But still, have you ever seen the milky way, I've never seen the milky way, and tried it at the telescope park at La Palma when I was there. And that was at night. During the day, which also happens sometimes, you'll be hard-pressed to see any stars at all. All of this, even though I know that the sky is seeded with stars of the milky way.

 

A variable skybox would still matter, even if you posit that eyes, not camera's, are seeing them.

 I live in the Appalachian mountains in a place where there is barely any light pollution. Yes, we can see the milkyway when there's a clear night with no moon.

Edited August 27, 2019 by Talavar

[lajoswinkler]

21 hours ago, juanml82 said:

Keep in mind that's a limit of photo cameras. The human eye can deal with much higher contrasts than cameras, both film and digital

Eyes are somewhat better, but they also can not possibly see the stars in these conditions, let alone Milky way.

[nikokespprfan]

21 hours ago, Kerbart said:

Tom Cargill, Bell Labs:

Quote

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

True, and I'm inclined to believe you. However, unlike squad with KSP 1, STar.theory has the advantage of hindsight. The code is developed from scratch, but they know for at least 50% how each system will interact with other systems. They can see pitfalls coming, they know the big issues. That is all time you aren't trying to figure stuff out, from how it should work (barring changes) to what to look out for. And figuring stuff out tends to be a big part of software development, next to testing.

[Kerbart]

12 minutes ago, nikokespprfan said:

True, and I'm inclined to believe you. However, unlike squad with KSP 1, STar.theory has the advantage of hindsight. The code is developed from scratch, but they know for at least 50% how each system will interact with other systems. They can see pitfalls coming, they know the big issues. That is all time you aren't trying to figure stuff out, from how it should work (barring changes) to what to look out for. And figuring stuff out tends to be a big part of software development, next to testing.

I don’t disagree with you. The KSP1 team had to overcome a couple of challenges during the project. Most importantly scope, but also the double-precision issue, and as the project continued, decoupling various object hierarchies from each other. That leaves you with an increasingly difficult structure to work with.

Even with zero access to the KSP1 code (and I assume Star Helix does have access, if only for the orbital mechanics calculations and 3D models), they have the superior advantage of hindsight in regards to where to end up. Preservation of angular momentum is one of those; axial tilt of planets is another.

Still, completing a product takes more time, and I hope there will be an early access program. If there is, it most certainly will be in 2020. Without it, chances are  (a) that a 2020 deadline will not be met (with mathematical certainty a deadline of early 2020, and with that I mean H1), or (b) a version 2.0 will be delivered that for all intents and purposes is an early access version but simply not called that way.

 

[DrRansom]

On 8/26/2019 at 4:03 PM, HebaruSan said:

Stability does not come from 10 nerds hacking on something in secret for 2 years; new code always contains bugs! Stability comes from iteratively crashing code up against the reality of users over and over until all the bugs you didn't know about are exposed and fixed. This "deep code fixing" idea is highly dubious, especially for things that already work "well enough."

We know they're using Unity. We also know they already have (access to) a successful product that already does a huge amount that they need, also using Unity. SQUAD have been improving KSP1 for years, working out kinks, solving tricky problems, and it would be utter lunacy to throw that all away and start over from scratch. Why bet the farm that you can beat the code quality of a years-long effort on your first try, when you can stand on the shoulders of giants instead?

What is more likely? They'll start with the KSP1 code, then make the changes they think are needed to deliver their design goals and vision, including backwards-compatibility-breaking changes that could not be made for KSP1:

With software, it seems to be the case that it is easier and better to throw everything out and start over than to refactor existing code. Basically, by the time you finish a project you realize all the ways you could have architectured it better - that better architecture usually requires a complete rebuild. This is certainly the case with KSP2, the entire game has been rebuilt from scratch by a professional development team. It will be better for that. 

 

 

[chaos_forge]

6 hours ago, Kerbart said:

Star Helix

I see you're also a fan of The Expanse

[XLjedi]

On 8/26/2019 at 3:04 PM, magnemoe said:

4:20 was weird an Kerbal in an one seat cocpit with shadows passing over him. 
to far to slow to be an helicopter rotor or similar, he is in atmosphere it looks like so it could not be an rotating habitat next to him

I was thinking it was maybe some sort of rotating fixture on the airframe of whatever he was flying... but it did leave me wondering.

[Kerbart]

13 hours ago, DrRansom said:

With software, it seems to be the case that it is easier and better to throw everything out and start over than to refactor existing code. Basically, by the time you finish a project you realize all the ways you could have architectured it better - that better architecture usually requires a complete rebuild. This is certainly the case with KSP2, the entire game has been rebuilt from scratch by a professional development team. It will be better for that. 

That is not the general prevailing wisdom, and the road of history is paved with the corpses of ill-fated software projects that made such a decision (dbase, netscape, lotus for windoes, to name a few infamous ones).

While you do get the benefit of building an arguably better architecture, you also throw out years of experience in catching all kinds of edge cases, and KSP seems full of them. Workarounds for double-precision limis, edge cases for calculations, Unity bugs...

From a performance perspective it is likely a no-brainer, and years of expanding features on top of expanded features have made the KSP1  code base for sure an interesting contraption (or maybe not... I haven’t seen it). From a bug  perspective it will guaranteed to be the worst version in years, especially if 2.0 goes live in 7 months, as some on the forum claim.

I will keep referring to Astroneer, as I’m familiar with it, and it’s very similar in its development, looking at team size, time scale, scope, genre, etc. They went through early access, which revealed a ton of bugs and performance issues that were fixed. Even then, the “live” version contains some very interesting and annoying bugs (rovers sinking in the ground or flying away, pretty devastating when they are your local life support system) and updates are rolled out on a regular basis to fix them.

These are professional developers, building a game from scratch. The game will be good. But riddled with bugs.

Edited August 28, 2019 by Kerbart

[DrRansom]

1 hour ago, Kerbart said:

That is not the general prevailing wisdom, and the road of history is paved with the corpses of ill-fated software projects that made such a decision (dbase, netscape, lotus for windoes, to name a few infamous ones).

While you do get the benefit of building an arguably better architecture, you also throw out years of experience in catching all kinds of edge cases, and KSP seems full of them. Workarounds for double-precision limis, edge cases for calculations, Unity bugs...

From a performance perspective it is likely a no-brainer, and years of expanding features on top of expanded features have made the KSP1  code base for sure an interesting contraption (or maybe not... I haven’t seen it). From a bug  perspective it will guaranteed to be the worst version in years, especially if 2.0 goes live in 7 months, as some on the forum claim.

I will keep referring to Astroneer, as I’m familiar with it, and it’s very similar in its development, looking at team size, time scale, scope, genre, etc. They went through early access, which revealed a ton of bugs and performance issues that were fixed. Even then, the “live” version contains some very interesting and annoying bugs (rovers sinking in the ground or flying away, pretty devastating when they are your local life support system) and updates are rolled out on a regular basis to fix them.

These are professional developers, building a game from scratch. The game will be good. But riddled with bugs.

Huh - I was pretty sure (and from experience and observation) thought it was the other way around. (Doing more research leads to the answer: rewrite vs. refactor -- it depends on how bad things are). In the case of Kerbal, a rewrite is basically mandatory because the original structure is limited. But yes, now that you describe it, I agree there will be far more bugs in KSP v2.0.

I am curious about the numerics; I get why they were a problem for the original team. (Going from a rocket simulation to a solar-system simulation jumps numerical requirements by quite a bit). But if a team knows what they're getting into, the numerical implementation should be relatively straightforward. Astrodynamic and high-precision trajectory simulations are topics of active research and they should be able to copy the numerical stuff from them. 

[Guest]

The answer to the "refactor or rewrite" question is "yes."

Meaning, sometimes it's better to refactor and sometimes it's better to rewrite, and the outcome is largely contingent on who's doing the work. Software does tend to become more entropic over time, but like with thermodynamics it's possible to decrease entropy by doing work. I haven't looked at the KSP codebase so I couldn't say what the situation is there, but there certainly seem to be some problems that are really hard to fix in it since they're constantly griped about yet still with us.

Whether KSP 2.0 will be more or less buggy than KSP 1.7.3 is anyone's guess. But I do think that the people holding the purse strings wouldn't have made the decision to rewrite lightly, it's generally pretty hard to get the budget for that if refactoring is a realistic option.

[Drakenred65]

Well let’s face it. You can get what is basicaly a completely new new team working with an existing it’s always worked for us engine....like what happened with fallout 76

 

or

 

They can build a new engine from the ground up. Like Blizzard did with Diablo 3...

[Technical Ben]

On 8/24/2019 at 1:33 PM, coyotesfrontier said:

Here's a video that not many people are talking about, but with some valuable information:

https://m.youtube.com/watch?v=tRewAKMllVo

Most notable is confirmation that Kerbin has clouds, better looks at the new engines, a new ringed rocky planet that might be the super-earth talked about, and a sound effect showcase.

They need to shorten those fingers, or make them mittens again.

 

[KerbMav]

@chaos_forge @pschlik

Regarding metallic hydrogen:

Sadly I cannot find a recording of the interview without the bad and omitting translation of the interviewer ...

Right after he mentions the Mun lander, he shuts up for a few seconds and you can hear the developer say something about a magnetic nozzle.

(Also the close up of the engine looks different than the wider shot of the lander?)

[chaos_forge]

1 hour ago, KerbMav said:

@chaos_forge @pschlik

Regarding metallic hydrogen:

Sadly I cannot find a recording of the interview without the bad and omitting translation of the interviewer ...

Right after he mentions the Mun lander, he shuts up for a few seconds and you can hear the developer say something about a magnetic nozzle.

(Also the close up of the engine looks different than the wider shot of the lander?)

As far as I know, metallic hydrogen engines wouldn't involve magnetic nozzles. The way they (theoretically) operate is very similar to chemical engines, since the energy does come from a chemical process after all.

[KerbMav]

2 minutes ago, chaos_forge said:

As far as I know, metallic hydrogen engines wouldn't involve magnetic nozzles. The way they (theoretically) operate is very similar to chemical engines, since the energy does come from a chemical process after all.

Just quoting what I heard Nate Simpson say in the video.

[Kerbart]

6 hours ago, DrRansom said:

I am curious about the numerics; I get why they were a problem for the original team. (Going from a rocket simulation to a solar-system simulation jumps numerical requirements by quite a bit). But if a team knows what they're getting into, the numerical implementation should be relatively straightforward. Astrodynamic and high-precision trajectory simulations are topics of active research and they should be able to copy the numerical stuff from them. 

It’s not the calculations per sé, but the implementation in the game. For instance, if you use double precision floats, you’d have around 15 decimals... but only when you’re close to zero. Squad had to learn about the implications of that and find a workaround. With starting from scratch you run the risk having to reinvent the wheel, and what’s worse, having to learn why you’d have to reinvent it.

This is especially the case for Unity. “Don’t use wheels, for reason x, y and z” You may start out using wheels and be pretty far committed to it before learning why it’s such a bad idea and by then your code ends up similar to V1 as it contains all kinds of patches and fixes to work around a problem (using “wheels” as an arbitrary example).

Again, I’m not saying that writing KSP2 from scratch is bad, it will probably benefit from it; just that it will come at the price of extensive debugging.

 

[Superfluous J]

On 8/27/2019 at 3:53 AM, GoldForest said:

Take-Two wants KSP 2 out before the fiscal year is up, which ends in March. So, Star Theory is more than likely going to push hard for a March Release to keep their corporate overlords happy.

Actually Fiscal 2020 ends September 30th 2020.