Another Another Tweet from the team

[moeggz]

https://x.com/kerbalspacep/status/1692673295118983551?s=46&t=YxJFOflCg4HjqV9Xt6XGIA
 

[The Aziz]

I don't think the x domain works well with embeds

But it means the QA was doing their job well.

[moeggz]

25 minutes ago, The Aziz said:

I don't think the x domain works well with embeds

But it means the QA was doing their job well.

I noticed that too. Tweets used to embed but I fiddled with it and couldn’t get it to appear.

[Furniture]

Honestly? I'd rather have this delay than the whole fiasco with 0.1.3 where things were disastrously broken. Better to wait a few days and get something that's actually an improvement.

[Stoup]

5 hours ago, Furniture said:

Honestly? I'd rather have this delay than the whole fiasco with 0.1.3 where things were disastrously broken. Better to wait a few days and get something that's actually an improvement.

Me too. The issue I have is the fact that this is the same logic that lead to hype for the game's EA release, and that sadly did still come out half baked 

[Alexoff]

due to a critical performance issue that was identified over the past few days

 

First, how was 0.1.0 released then? Secondly, how can fixing bugs ruin performance?

[PDCWolf]

The good first: The reentry effects look good. 

I do feel it still is a bit underwhelming. I'd say they're a good first step in the right direction. From my perspective they're missing some flair, and clearly some scale:

Spoiler

 

As for the delay... Remember when I said they were only able to make compromises two weeks into the future? Scratch that. Should I be glad QA caught this one? or should I be disappointed QA is catching such terminal stuff 2 weeks before release on a multiple months dev cycle?

[Mutex]

3 hours ago, PDCWolf said:

The good first: The reentry effects look good.

Wait, there's more than one tweet in the thread? Seems recently you can only see one tweet unless you have an account.

Is there anywhere else the stuff in the tweet is available? EDIT: Never mind, spotted it in the Discord tracker.

Edited August 19, 2023 by Mutex

[Periple]

4 hours ago, Alexoff said:

Secondly, how can fixing bugs ruin performance?

Easily. 

For example, suppose there’s an optimization in the code that precomputes and caches a result, and the bug is in a part of the code that determines when the cache needs to be invalidated. It could easily happen that you fixed the bug but inadvertently bypassed the cache altogether, or made the cache invalidation code so inefficient under some specific circumstances that it broke performance. 

Performance is fragile. It just takes one bottleneck  and it’s hard not to introduce them.

[Alexoff]

8 minutes ago, Periple said:

Easily. 

For example, suppose there’s an optimization in the code that precomputes and caches a result, and the bug is in a part of the code that determines when the cache needs to be invalidated. It could easily happen that you fixed the bug but inadvertently bypassed the cache altogether, or made the cache invalidation code so inefficient under some specific circumstances that it broke performance. 

Performance is fragile. It just takes one bottleneck  and it’s hard not to introduce them.

It seems to me that the KSP2 code that needs to be fixed lies quite far from the cache and hardware, the unity engine does this. I have a hard time imagining how changing the name of a craft or inverting the work of copied wings can have such a profound effect on the game.

[MechBFP]

35 minutes ago, Alexoff said:

It seems to me that the KSP2 code that needs to be fixed lies quite far from the cache and hardware, the unity engine does this. I have a hard time imagining how changing the name of a craft or inverting the work of copied wings can have such a profound effect on the game.

Presumably the issue is with work related to one of the top 3 bugs and they would rather delay the patch than pull out the fix for one of those issues.

[Alexoff]

2 minutes ago, MechBFP said:

Presumably the issue is with work related to one of the top 3 bugs and they would rather delay the patch than pull out the fix for one of those issues.

It's more of your wish. I remember for every delay of the game before, many also said that this was due to the perfectionism of the developers and the desire to add more to the game. We were clearly informed about the drop in performance.

[GGG-GoodGuyGreg]

10 hours ago, Furniture said:

Honestly? I'd rather have this delay than the whole fiasco with 0.1.3 where things were disastrously broken. Better to wait a few days and get something that's actually an improvement.

You seem to forget it was already delayed even with the updated extended cadence.

So unless this patch is groundbreaking compared to the previous ones, I don't see how it's worth it to get patches 2 times slower.

It's good this performance issue was identified before pushing the patch, but what in the world is going on over there?

Edited August 19, 2023 by GGG-GoodGuyGreg

[cocoscacao]

1 hour ago, Alexoff said:

It seems to me that the KSP2 code that needs to be fixed lies quite far from the cache and hardware,

Hardware maybe. There's only so much ways platforms/frameworks can shield you from your own stupidity. Cache most certainly not, since what needs to be cashed and how, differs in every piece of software. 

Of course, none of this is related to KSP since it's just an example made by @Periple

Hopefully we'll get some additional info. Unless it gets fixed quickly. 

[Alexoff]

22 minutes ago, cocoscacao said:

Hardware maybe. There's only so much ways platforms/frameworks can shield you from your own stupidity. Cache most certainly not, since what needs to be cashed and how, differs in every piece of software. 

Of course, none of this is related to KSP since it's just an example made by @Periple

Hopefully we'll get some additional info. Unless it gets fixed quickly. 

I don't remember this happening in KSP1. There, performance after patches could fall due to the addition of new features, but not due to bug fixes.

[Delay]

2 hours ago, Alexoff said:

I don't remember this happening in KSP1.

Well, it does happen right now, in a product that isn't KSP1. Aside from the nature of the game as a space sim I don't see how "but it didn't happen in this other game" could be relevant here.

Edited August 19, 2023 by Delay

[PDCWolf]

37 minutes ago, Delay said:

Well, it does happen right now, in a product that isn't KSP1. Aside from the nature of the game as a space sim I don't see how "but it didn't happen in this other game" could be relevant here.

Try as hard as one might, KSP2 will never be its own separate thing from KSP1. The comparisons will be there for as long as the product exists. If they'll always be negative... that's something that could change.

[Delay]

2 minutes ago, PDCWolf said:

Try as hard as one might, KSP2 will never be its own separate thing from KSP1.

This isn't about the game's name or gameplay though. This is inherently about how the game is coded. So it's kinda ironic that given KSP 2 has bugs KSP 1 doesn't, they are in fact not the same.

Look, all I'm saying is that just because KSP 1 never had a performance problem after a bug fix (which I'm uncertain of in the first place) doesn't at all imply that this couldn't be the case for KSP 2.

[Periple]

5 hours ago, Alexoff said:

It seems to me that the KSP2 code that needs to be fixed lies quite far from the cache and hardware, the unity engine does this. I have a hard time imagining how changing the name of a craft or inverting the work of copied wings can have such a profound effect on the game.

I wasn’t thinking about the processor cache, most of the time you’re working several abstraction levels above that anyway. You cache things all the time if you want to write something performant; the best optimization is usually to not compute things unnecessarily. There’s bound to be a lot of computations related to craft configuration and you will want to cache the results of those until something changes that requires recomputing! 

In any case it was just an example to illustrate the fact that fixing a bug can easily have unintended side effects, including with performance. Sometimes you only catch it in QA. Or even later. It happens.

I would be surprised if the specific bugs you listed were related to performance although sometimes there are surprising interdependencies, but it’s not like there’s a shortage of bugs to fix — and some of them are bound to be in performance-critical areas.

[KerbolExplorer]

They actually played the game for once

[K^2]

12 hours ago, Alexoff said:

It seems to me that the KSP2 code that needs to be fixed lies quite far from the cache and hardware

Did you just google "cache" and read the first definition that came up? There is a CPU cache, a GPU cache, asset caches, prefetch caches, memoization caches, iteration caches, lookup caches... Only a few of these are hardware related, only some of these are managed by the game engine, and absolutely all of these will be interacted with by gameplay code. Yeah, you can even screw up CPU cache performance by writing a for loop in a stupid way by mistake. Not to mention all the caches that the game code is directly managing.

There are a number of people on this forum who are domain experts in this. But honestly, a student taking some programming courses in university will have a good coverage of this. If you want to be militantly and confidently wrong about something, picking a topic that's a current, verifiable fact, rather than a prediction or subjective opinion, is a very bad move. It's very easy to see through.

[LoSBoL]

14 hours ago, GGG-GoodGuyGreg said:

You seem to forget it was already delayed even with the updated extended cadence.

So unless this patch is groundbreaking compared to the previous ones, I don't see how it's worth it to get patches 2 times slower.

I don't expect a groundbreaking patch. Milestones or bugs, they chose working on both and I can see why. Both bugs and lack of content are things people aren't happy with. One thinks it's more worthy to focus on bugs first, while others want more content. Somewhat stuck between a rock and a hard place until both gets to a better state.

[WelshSteW]

Not even surprised.

[Alexoff]

7 hours ago, K^2 said:

There are a number of people on this forum who are domain experts in this. But honestly, a student taking some programming courses in university will have a good coverage of this. If you want to be militantly and confidently wrong about something, picking a topic that's a current, verifiable fact, rather than a prediction or subjective opinion, is a very bad move. It's very easy to see through.

So how can fixing the bugs indicated by the developers achieve a significant drop in performance? I only imagine this if they introduced a software crutch to bypass some situation, and this raises questions about whether the game code is spaghetti code. It seems that the developers were unable to find out the essence of the problem in a short time, since a new patch date has not been announced.

[cocoscacao]

21 minutes ago, Alexoff said:

So how can fixing the bugs indicated by the developers achieve a significant drop in performance? I only imagine this if they introduced a software crutch to bypass some situation, and this raises questions about whether the game code is spaghetti code.

Jumping to the worst possible conclusion, without any evidence? Getting tiresome... 

Nothing mentioned what caused performance drops. New feature (heating), fixing old bugs, or if this bottleneck was already present, but identified just now. Feel free to correct me on this.

Not a game dev, but from a perpective of puny web dev, gaming looks like an absolute nightmare to work with. A bunch of stateful objects communicating with each other and obeying common underlying logic. Plenty of room for errors in any case.