Info about the first patch

[Periple]

11 minutes ago, EvelynThe Dragon said:

I have worked on gigantic programs with hardware and software integration, I actually do know how it CAN work. So please do not try to explain engineering to me.

You need very mature DevOps for that. It takes time and effort to set up and maintain. I don’t think Intercept do. (If they did I think the game would be in a better state than it is.)

[BobbyDausus]

On 3/1/2023 at 8:45 PM, Mutex said:

Posted on Twitter about an hour ago:

Fixes include:

- Stuck on loading screen
- Maneuver node irregularity
- Docking controls misconfiguration
- Save files corruption

And will arrive in the "coming weeks". Hoping that means in the next week or so, and they're being vague to avoid over-promising in case things slip.

Not a bad set of issues to focus on first, although I'm not 100% sure what "Docking controls misconfiguration" refers to - we have issues with not being able to undock, and undocking craft exploding or becoming debris, hopefully it covers some of those issues. And having the manoeuvre node not get messed up switching between map view would be nice.

Many would agree that the list should've been something like this : 

Fixes included:

-Performance

-Performance Optimization

-More FPS

-Performance

Since the majority can't even play it

[whatsEJstandfor]

1 minute ago, BobbyDausus said:

Many would agree that the list should've been something like this : 

Fixes included:

-Performance

-Performance Optimization

-More FPS

-Performance

Since the majority can't even play it

I certainly wouldn't agree. The performance is bad, but there are game-breaking bugs that should be prioritized. I don't think optimization comes until after stuff is already working as expected. Otherwise, all you're optimizing is something that might need to be reworked later, and all of that work was for naught

[Lisias]

30 minutes ago, EvelynThe Dragon said:

I have worked on gigantic programs with hardware and software integration, I actually do know how it CAN work. So please do not try to explain engineering to me.

Me too. But let me tell you, the whole project was partitioned in a lot of individual components integrated with very well defined interfaces. No development team was bigger than 5 to 10 guys, being it hardware or software.

Under that monstrous development process Siemens had paid someone to create for them (IBM? I forgot) at that time - when I blew a fuse doing a stupid thing, they made me fill a form and I spent the whole morning on the warehouse to get the replacement. This was the level of control they had over the whole process.

You won't believe how small details caused huge, really huge problems on the pipeline completely defeating the Process - like when someone forgot to connect the mass ground on the cable that connected the JIG into the iPod, and we burn a couple until I got liquided off, disassembled the cable and noticed the mishap.

No matter how mature is your development process, it will fail now and then due the Imponderable. Sooner or later someone will forget or twist a wire, the testing process will miss it and you will get the whole team hold back for a month because you blew up all the development toys due the crap.

That said, you are not wrong. It only happens that you are not the only one right on this discussion.

Edited March 3, 2023 by Lisias
Tyop! Surprised?

[BobbyDausus]

1 minute ago, whatsEJstandfor said:

I certainly wouldn't agree. The performance is bad, but there are game-breaking bugs that should be prioritized. I don't think optimization comes until after stuff is already working as expected. Otherwise, all you're optimizing is something that might need to be reworked later, and all of that work was for naught

No,because that might fit your cause and not the majority.We can agree that the majority can't play the game right?The few that can play the game at an acceptable performance are few and far between.We can't even play it,let alone encountering bugs :)) . So whats more important?

[whatsEJstandfor]

1 minute ago, BobbyDausus said:

No,because that might fit your cause and not the majority.We can agree that the majority can't play the game right?The few that can play the game at an acceptable performance are few and far between.We can't even play it,let alone encountering bugs :)) . So whats more important?

I'm confused. Are you saying you can get into the game but the performance/FPS makes it unplayable? Or are you saying you literally can't load the game? Because the latter is a real problem a significant amount of people are having, and that should obviously be prioritized.

Also, what do you consider acceptable performance? At 5120x1440 on High on my RX 5700, I get about 20 fps, which is acceptable to me given the amount of pixels I'm pushing. At lower resolutions, I can get around 30-40 consistently, which is also acceptable to me. But there are many Gamers™ for whom 40fps would be considered unplayable.

[Grimmas]

14 minutes ago, BobbyDausus said:

No,because that might fit your cause and not the majority.We can agree that the majority can't play the game right?The few that can play the game at an acceptable performance are few and far between.We can't even play it,let alone encountering bugs :)) . So whats more important?

Bugs are more important. You can still play the game with semi-decent framerate on a potato PC at low settings and low resolution, but you can't play if your saves get corrupted all the time. 

That said, the performance is obviously not great. Nowhere near as bad as people make it out to be, but still bad.

[Homer_S]

I agree... performance will come. First, fix things like spinning out of control, pushing a soggy noodle and other game breaking bugs so at least I can enjoy/get somewhere while I'm watching a slide show!

 

Homer

[Kerbart]

45 minutes ago, BobbyDausus said:

Many would agree that the list should've been something like this : 

Fixes included:

-Performance

-Performance Optimization

-More FPS

-Performance

Since the majority can't even play it

The question is not what "should" be done — that's open to opinion and we know how that goes. Put yourself in IG shoes and approach this rationally, which some people will call "cynically":

• We want the number of happy players to go up
• We want to number of unhappy players go down

With all the issues going on, fixing performance will do nothing for them. It will merely increase the number of people that can play KSP2 and then will be unhappy about it. Surely if there's low hanging fruit to improve performance they'll go for it, but in terms of player satisfaction, the ROI on performance improvement is going to be absolutely horrific,

Their priority is to stop the bleeding. Stop people from rage quitting the game. That doesn't mean every single bug, like the "don't use M for ship names" bug, but the rage quitting bugs. Only when those are addressed it makes sense to go after performance, otherwise they will just be increasing the number of people that have practical experience in disliking the game.

[RocketRockington]

1 hour ago, EvelynThe Dragon said:

I have worked on gigantic programs with hardware and software integration, I actually do know how it CAN work. So please do not try to explain engineering to me.

Based on the statement you made, that was very not obvious.  Which project do you know, of any size, that releases single-bug patches?

[Sea_Kerman]

Factorio

[Periple]

1 hour ago, BobbyDausus said:

No,because that might fit your cause and not the majority.We can agree that the majority can't play the game right?The few that can play the game at an acceptable performance are few and far between.We can't even play it,let alone encountering bugs :)) . So whats more important?

I can play it. 

There's a bunch of stuff I can't do (or can't do in a way that's at all fun) because of performance issues. There's even more stuff that I can't do in a way that's fun because of bugs. I did a Duna landing in a spaceplane, which was an uphill battle due to a bunch of bugs, and when I finally got there, made a soft landing, and saved, the next time I loaded, my wing fell off. And I haven't even experienced any crashes! Of the game, that is. 

It's fairly obvious to me that crashes and major bugs in core systems need to go first. Performance is super important but it does come in second. It's always possible that they can be working on both in parallel, for example the fuel flow algorithm is buggy and performs terribly; I don't think it makes sense to try to solve these problems separately than just to throw it out and write a new one. 

[Lisias]

14 minutes ago, RocketRockington said:

Based on the statement you made, that was very not obvious.  Which project do you know, of any size, that releases single-bug patches?

Volvo just made a Recall for 106k vehicles due a bug in the brakes.

if the problem is big enough, you not only do a single-bug release, you even pay for the installation of the replacement on the customer's product.

World is way bigger than you think. And some dudes around here live there.  ;)

[LameLefty]

47 minutes ago, RocketRockington said:

Which project do you know, of any size, that releases single-bug patches?

SpaceX just did it last night, in near-real time, to suppress the results of a faulty sensor in an actual honest-to-$DEITY spacecraft. 

So very focused software development CAN occur very rapidly, for very well defined hardware, very well defined software, and under very well controlled conditions.

None of the above applies to KSP2 at the moment, and never will because the universe of possible consumer computer hardware is fundamentally indistinguishable from infinite. 

Edited March 3, 2023 by LameLefty

[Haustvindr]

Everyone talking about performance, and here I am, as many others, hoping to have at least bad performance. Welcome to the "pumping sim" world, where we get zero performance... or maybe infinite, dunno 

To be fair, the main menu is buttery smooth, but it's the only thing I can touch. Some people don't even get to see that.

So yeah, my vote goes to fixing critical bugs like these, performance can wait.

[Dakota]

Hey all, popping in to say that Nate just shared some details about the first patch over here.

[RocketRockington]

2 hours ago, Lisias said:

Volvo just made a Recall for 106k vehicles due a bug in the brakes.

if the problem is big enough, you not only do a single-bug release, you even pay for the installation of the replacement on the customer's product.

World is way bigger than you think. And some dudes around here live there. 

Yeah that's totally analogous to a software project.  Man people really manage to stretch the limits of credibility to support thier desire to argue about things.

[BobbyDausus]

6 hours ago, Grimmas said:

Bugs are more important. You can still play the game with semi-decent framerate on a potato PC at low settings and low resolution, but you can't play if your saves get corrupted all the time. 

That said, the performance is obviously not great. Nowhere near as bad as people make it out to be, but still bad.

you sure? Bring me that potato PC,i would love to give it a try.I play everything at 60+ FPS ,this one gives me under 10. How come? So can i still play the game? No

[Lisias]

4 hours ago, RocketRockington said:

Yeah that's totally analogous to a software project.  Man people really manage to stretch the limits of credibility to support thier desire to argue about things.

And it is. ABS is software controlled. Been there, seen that - I was working on an autoradio with CAN integration, and so I had to cope with electric steering, ABS, ECU, you name it.

You see, you was replying to someone openly stating they had work on a huge project involving hardware and software. And then you ask him about a single project that had issued a single fix patch. You was the one forcing your hand on the subject.

But, since you now is defining better the scope of your argument… In 2021 Mercedes had recalled millions of cars due a software bug on a device responsible to locate the vehicle to emergencial services. It was a software only bug. No hardware involved on this one.

(and yes, now I'm being picky ).

I think you should refrain yourself from doing this kind of judment about people you don't know. The World is bigger than you.

[RocketRockington]

12 minutes ago, Lisias said:

And it is. ABS is software controlled. Been there, seen that - I was working on an autoradio with CAN integration, and so I had to cope with electric steering, ABS, ECU, you name it.

You see, you was replying to someone openly stating they had work on a huge project involving hardware and software. And then you ask him about a single project that had issued a single fix patch. You was the one forcing your hand on the subject.

But, since you now is defining better the scope of your argument… In 2021 Mercedes had recalled millions of cars due a software bug on a device responsible to locate the vehicle to emergencial services. It was a software only bug. No hardware involved on this one.

(and yes, now I'm being picky ).

I think you should refrain yourself from doing this kind of judment about people you don't know. The World is bigger than you.

I didn't ask someone about a hardware and software project.  Just software.  Releasing patches for a game is not the same at all as release point fixes for a critical issue in a car.  First of all, because if any car had been released in the state KSP2 was - early access or not - it would have killed half the people who tried to drive it, and the other half would be ok only because the car couldn't get over 5km/h.

But again, I don't think you're arguing in good faith.  

[Lisias]

2 hours ago, RocketRockington said:

First of all, because if any car had been released in the state KSP2 was - early access or not - it would have killed half the people who tried to drive it, and the other half would be ok only because the car couldn't get over 5km/h.

And that's the whole point. What decides if you will issue a single-fix-only release is the damage the bug is doing in the field. Non critical bugs can wait a large release to save some money in the process, but really critical bugs should be fixed on the spot.

KSP2 is a game, so no people are going to die due a software glitch (right, Tesla?), but some bugs are seriously affecting the revenue - and this is similar to being killed from the Publisher's point of view.

Doesn't really matter if we are talking software, hardware or embedded (a combination of two). The decision on releasing a single-fix-patch or a multiple-fixes-patch is made based on the damage the bug(s) is(are) doing on the field, and anyone ignoring such criteria is going to loose some money in the long run.

It's all about the money. It's always about the money.

Edited March 4, 2023 by Lisias
Entertaining grammars made less entertaining

[Periple]

It's also about what kind of DevOps process you want to build. Full CICD (Continuous Integration Continuous Deployment)  isn't easy to set up and you also need to get the team to follow very disciplined practices, like maintaining fairly comprehensive integration tests (not just unit tests). This can be a real problem early in development when things are still moving a lot -- you might end up spending more time maintaining the integration tests than developing the product, which is not what you want. Once the product is stable enough and CICD is also mature, it can be a really pleasant way to work!

Because of this reason I don't think many studios do CICD unless they're making an MMO or other game as a service where you really need to roll out updates fast sometimes.

The usual way is release-based, where you branch off a release branch, put that through QA, fix any bugs found by QA and merge those back into the development branch while continuing work on development branches, and once QA signs off, release it. You can get to approximately a weekly release cycle this way once things are settled down and that's usually enough for most projects.

It usually takes longer earlier in the process as you work out where the bottlenecks are, for example if your QA team isn't able to verify the issues as fast as your developers are implementing them, that'll slow things down a lot. 

Either way once you release the product to the public and have to start doing this stuff, it will slow down development. Later on that can be a good thing but if you do it too soon you might end up getting bogged down fixing bugs when you really ought to be implementing systems or refactoring things. It's not so easy!

Edited March 4, 2023 by Periple

[Lisias]

54 minutes ago, Periple said:

Either way once you release the product to the public and have to start doing this stuff, it will slow down development. Later on that can be a good thing but if you do it too soon you might end up getting bogged down fixing bugs when you really ought to be implementing systems or refactoring things. It's not so easy!

Agreed. But in the mean time you need to keep the cash cows happy, otherwise they may pull the plug on you.

It's tricky, and treacherous to tell you the true.

Projects rarely die due technical issues, most of the time it's the internal politics that kills you when you are reaching the beach.

[tstein]

17 hours ago, whatsEJstandfor said:

I certainly wouldn't agree. The performance is bad, but there are game-breaking bugs that should be prioritized. I don't think optimization comes until after stuff is already working as expected. Otherwise, all you're optimizing is something that might need to be reworked later, and all of that work was for naught

Except that some people  are facing crashes of their  whoel machines exactly because of the excess resource usage.  The  stupid resource usage is as critical as any other source of crashes...

[Fullmetal Analyst]

ShadowZone doing a better job than the community managers  

Edited March 6, 2023 by Fullmetal Analyst