KSP2 is not ready For Science!

[Wheehaw Kerman]

56 minutes ago, MechBFP said:

The game is never going to be perfect, and it desperately needs this content, so it will be what it will be.  Better to release it now than trying to be perfectionists  

If I had to guess I would say that it will need a few patches post science update to get to a decent state for that content, which is going to be disappointing but *shrug*. 
 

I don’t think they are going to fix wheel issues, terrain issues, etc, until they switch to the new terrain system. So those issues will just have to be dealt with for quite some time. 

It’ll be interesting to see whether For Science! comes with improvements to the terrain system.  We are going to be interacting with the terrain a fair bit more now…

[Wheehaw Kerman]

1 hour ago, PDCWolf said:

They probably have a bag of bugs that wasn't ready for 0.1.5 but in the 2 extra months will be ready for 0.2.0. Now, how important or crucial or foundational those bugfixes may be obviously I can't say, but it'd definitely be very rare for a big update do not include bugfixes in it as well.

Remember that before Blackrack, 90% of performance gains came from them hiding, deleting, culling and downgrading stuff on screen, which is not fixing the performance of the game so much as it is a stopgap to make it playable whilst they hopefully actually fix stuff.

Now Blackrack came in and pretty much fixed the clouds which were a huge performance issue, and actually one of the like 10 proper performance fixes we've seen and probably the only one with a measurable, night and day impact as well. This is my way of saying I think we'll be back to meager "we made something worse so the game runs a bit better" type fixes.

With all due respect, it’s all in how one frames it.  Spending eight months in an echo chamber where nobody has any real knowledge of the development process, almost everyone is overstating every possible negative point, understating and omitting the positive ones, getting personally invested in being right about how everything is awful, and losing sight of the big picture would get anybody inferring the worst from any news.

I wound up spending most of August through October away from the game and forums for work and travel reasons, and then I got a bit distracted (and disappointed) by Starfield.  Coming back to 1.5 after a few months, I’m seeing remarkable improvements in most respects.  Regardless of how one characterizes how they got there, it seems pretty clear that the devs are making progress both in terms of fixing sandbox and on the roadmap.  My frame was always optimistic for long term, and 1.5 is reinforcing that impression.  

For Science! is going to be indicative, one way or the other.  I expect continued improvement, some bugs, and snowballing progress.  We shall see.

[Guest]

My 100% purely subjective feeling is that between 0.1.4.1 and 0.1.5 KSP2 passed my fun/frustration break-even point. I'm now playing it for the sake of playing it, rather than testing it to see how it works. Sure, some things are still broken but for the most part things work and I'm finding this enjoyable! I can't wait for 0.2.0!

[Wheehaw Kerman]

56 minutes ago, KUAR said:

My views are that it's got to happen soon as people are "played out" in Sandbox right now. There's no point waiting for things to be perfect before adding features, just stable enough that you're not trying to build a house on shifting sand.

FWIW, one of the only reasons I’m at only slightly over 200 hours since February is that after a decade and 5300+ hours in KSP1, Sandbox is pretty but kind of dull.  After figuring out the EA, playing with the new parts and going most places, there’s not much to do that interests me aside from admiring the new scenery.   I doubt I’ll really start putting serious time in until Interstellar drops.  I wanna explore, not revisit.

 

2 hours ago, Vl3d said:

If the devs had such bug fixes implemented, they would have released them in the current patch and announced that their respective user bug reports are resolved. Fact: they are not.

Well, yes.  But it’s currently October, not December, and 1.5 is what dropped this week, not For Science!.  I expect that they’re working on regular bugfixes in parallel with any foundational work and bugfixes needed to make For Science! work: they’ve implied as much already.

 

[RaBDawG]

Almost a full calendar Year before the FIRST roadmap item.  LOL.

[HebaruSan]

7 hours ago, Vl3d said:

I can't even drive a rover 1000 meters without it flipping over. I can't reliably land or dock without worrying about catastrophic failure. How am I supposed to engineer a sample return mission from Duna?

The devs speak consistently about how "user stories" drive their priorities, meaning that functionality would be built and improved based on what the game needs to do to deliver the intended experiences.

In an ideal world*(asterisk the size of Kerbin), this would mean that after the devs move the "feature/science" branch into testing, the testers would, among many other things, try running a sample return mission from Duna with rovers and docking, note the flips and explosions, and then update the existing bug reports for those problems in the internal bug tracker to indicate, "Severity increased because this impedes For Science! User Story #3." Then those bugs would percolate to the top of one of the fixing queues, be assigned to a developer, and get fixed before release.

*(asterisk the size of Kerbin) - We do not live in that world, so some degree of falling short is to be expected. In particular, their failure to reproduce the old "re-entry accelerates pods back out of the atmosphere if they've ever been staged" bug after very clear and specific user reports indicates that the testers take shortcuts (and don't realize when it might be a good idea to avoid them), so a full end-to-end test mission may not happen. The prioritization system they're using may not cause the right bugs to be assigned out as needed. The devs may not be able to fix such bugs in the allotted time.

But those are questions of adequate dev/testing practices, not whether the next release should include new features. If Intercept manage to get their processes to a point where they can be relied upon, it should be perfectly feasible to ship new features alongside whatever bug fixes are most needed for them to be enjoyed.

In other words...

3 hours ago, Wheehaw Kerman said:

It’ll be interesting to see whether For Science! comes with improvements to the terrain system.  We are going to be interacting with the terrain a fair bit more now…

 

3 hours ago, Periple said:

My 100% purely subjective feeling is that between 0.1.4.1 and 0.1.5 KSP2 passed my fun/frustration break-even point. I'm now playing it for the sake of playing it

Same here. Now when I rage-quit, the period of never-wanting-to-play-again is much shorter; before I know it, I can't help thinking "What if I tried X instead?", then I try it, and half the time I'm able to move past the previous showstopper problem. (This is somewhat helped by the changes to the save system, which ensure that "persistent.sfs" doesn't trap me in a post-bug state anymore. I can pretty reliably return to the last-good state.)

Edited October 27, 2023 by HebaruSan

[WelshSteW]

 

Might bring the issues front and centre!

 

[Guest]

7 minutes ago, WelshSteW said:

Might bring the issues front and centre!

 

The challenge should have been to drive to Kerbin's north pole. You'll very quickly learn all the issues with rovers.

[Superfluous J]

3 minutes ago, regex said:

 

... drive to Kerbin's north pole ... quickly ...

Those do not belong together

[Guest]

1 minute ago, Superfluous J said:

Those do not belong together

I mean, after an hour of driving north you won't want to continue anyway, so it'll be over fairly quickly.

[jnbspace]

Arguably KSP2 isn't ready without science.

Without science KSP2 is just a sandbox with not enough elements to make it into a game. If the next big release delivers the science, tech tree, physics improvements and performance upgrades they promise then I will go back to KSP2. But right now they are trying to  limit the damage they have done to their own reputation and the simple fact is that I don't really think that they will deliver. I hope I'm wrong but their recent track record isn't great.

 

 

[Vl3d]

4 hours ago, WelshSteW said:

 

Might bring the issues front and centre!

 

I really don't understand how such a challenge can be set without first attempting to complete it themselves and seeing the bugs with the wheel colliders and the flipping.

[Strawberry]

9 hours ago, PDCWolf said:

Remember that before Blackrack, 90% of performance gains came from them hiding, deleting, culling and downgrading stuff on screen, which is not fixing the performance of the game so much as it is a stopgap to make it playable whilst they hopefully actually fix stuff.

Now Blackrack came in and pretty much fixed the clouds which were a huge performance issue

tbh this just isnt really true. There were a few stuff disabled 1.1/1.2 for , but stuff like parts manager, resource manager and terrain optimization is like, proper optimization. Like, you cant really make the parts manager run better and still have all its functionality by just brute forcing delete stuff. Also clouds were never that laggy (relatively of course), the bulk of the lag has always been from the terrain system/shaders. 

Edited October 27, 2023 by Strawberry

[jacksawild]

The more playable the game becomes, the bugs the community will find. This is because it becomes more tolerable to go further and do more. As long as bugs are continuing to be fixed then we are incrementally moving towards perfection.

[PDCWolf]

5 hours ago, Strawberry said:

tbh this just isnt really true. There were a few stuff disabled 1.1/1.2 for , but stuff like parts manager, resource manager and terrain optimization is like, proper optimization. Like, you cant really make the parts manager run better and still have all its functionality by just brute forcing delete stuff. Also clouds were never that laggy (relatively of course), the bulk of the lag has always been from the terrain system/shaders. 

Except it is true. Don't get me wrong, there are a lot of proper optimizations where something has been fixed without sacrificing quality or having to hide it. Also culling is very appropriate in some places, but has caused pop-in in others (namely scatter, for example).

From 0.1.2

• Optimized orbital nodes in map by not processing non-visible ones  < Culling
• Anti-tile is now disabled when low quality is  selected  < Graphical downgrade
• Optimization on Kerbal IVA cameras  < Culling

From 0.1.3

• Adjusted PQS transition range for Vall  < Downgrade
• Added level of detail to aviation lights at KSC < Downgrade
• Replaced raycast-based lens flare occlusion with depth-based occlusion  < Graphical Downgrade
• Added new compute kernel to improve terrain performance by reducing rendering of non-visible detail  < Culling
• Optimized cloud rendering when camera is below cloud layer  < Culling
• Optimized per-engine point lights by turning off shadows  < Graphical Downgrade
• Optimized PQS terrain textures to reduce memory usage  < Graphical Downgrade
• Optimized tesselation factor for medium and low quality water to improve GPU performance < Graphical Downgrade
• Optimized water tesselation factor for water viewed from high altitude < Graphical Downgrade
• Optimized runtime CPU performance for water rendering by updating some properties less than once per frame"  < Graphical Downgrade
• Reduced low- and medium-quality cloud texture sizes for Kerbin, Duna, Eve, and Laythe   < Graphical Downgrade

From 0.1.4

• Added LODs to some KSC buildings < Downgrade
• Added LODs to spotlight shadows at KSC < Downgrade

Now compare that to 0.1.5 where the game both looks and performs better.

[Strawberry]

3 minutes ago, PDCWolf said:

Except it is true. Don't get me wrong, there are a lot of proper optimizations where something has been fixed without sacrificing quality or having to hide it.

Most of the stuff listed here has either 1. Literally no effect on graphics (such as not processing non visible nodes or the terrain memory optimization.) 2. A non noticable impact on graphics (like the ksp2 water looks the same, no one was complaining wow the water looks worse now). If you cleanup a texture, technically it may lose some detail, but like youre not gonna notice that lost detail so who cares. 3.  Completely optional as you can just turn the settings up, or 4. Visual upgrades (the lens flare for example was shown off in an “upnate”.) 

Its very much not a new trend for the game to look and perform better. Im not saying blackrack hasnt done amazing work when it comes to visuals, because he has made the atmospheres look far better and i think its fair to credit him for that considering thats his thing. But performance wise the improvement this patch is pretty comparable to other patches, which makes me feel like while blackrack probably helped with the performance optimizations, he wasnt the primary dictator of them.

[Guest]

5 minutes ago, PDCWolf said:

Except it is true. Don't get me wrong, there are a lot of proper optimizations where something has been fixed without sacrificing quality or having to hide it. Also culling is very appropriate in some places, but has caused pop-in in others (namely scatter, for example).

Culling isn’t the only way to not render things unnecessarily, it’s not even the most important one.  You also have to optimize texture resolutions, vertex counts, LoD, and assets so you’re not rendering more detail than you can see, and if you determine that a rendering technique is too costly you need to switch to something faster that has more or less the same result. Often you also make a trade-off in one area to be able to do something with more impact in another. It’s only a downgrade if you can see it! Version 0.1.0 was using high-poly models for the navball and kerbals, was switching those to low-poly a “downgrade” too?

If you think they downgraded the graphics, you need to show it — post a couple of video clips from each version and show that it looks worse. Pointing at release notes and proclaiming DOWNGRADE! is like telling a race car driver that they would go faster if they stopped braking into corners!

[magnemoe]

17 hours ago, Kerbart said:

The coordinate reset jitter that occurs every 1000m depends on mass. A light rover will be tossed in the air, a heavy rover will change its direction a couple degrees,

when you venture around the KSC grounds it’s not a big deal but it’s an issue with a lightweight rover on Minmus.

Yes because gravity is so low any forces will give you airtime.  Have an feeling this is not an very hard bug to fix but stuff like noddle rockets and reentry had priority. 
Now with science rovers become more useful. 

[PicoSpace]

My take-away is this, "FOR SCIENCE" is 100% marketing driven for the Christmas holidays. If they didn't release SOMETHING they would get almost no sales as anyone who googles KSP2 right now is going to see the *&#^%@ unless they are watching the 3 big youtubers who get early access to "For science!".  <rant> So they will have ~1.5 months of positive press before it drops and we find out how many bugs and broken things exist, cause who doesn't like livestreaming KSP2 and having it crash on them??? But at least you the viewer see the game for what it is unabriged without quick-saves to hide all the issues. </rant>

I'm confident that 0.2.0 will be better than 0.1.# but I worry that its a marketing "need" than programmer "choice" and the whole thing could unravel to 0.2.5 ??? where they get it "working" to a point that things like sample return from Duna relies on player skill and not "how good is your computer to run this game and not break?". 

Also I just completed the Rover race challange and had to use some large panels to keep the rover from "hoping" too much on the flat surface that it either slides off the runway at 100m/s+ speeds or the smaller rover, bounce/fly. So Rovers are doable but compared to KSP1... significant design considerations need to be made.

 

Edited October 28, 2023 by PicoSpace

[Lebraquemart]

Despite having a really gloomy opinion of KSP2 and it's future, I believe they are on the right track releasing the science update.

As bugs tend to decrease, it becomes more and more costly to find and fix them,  additionally, new updates might even break stuff that had been fixed.

It becomes smart to keep a small baseline level of bugs and start to improve the whole game with updates instead of fixes.

Edited October 28, 2023 by Lebraquemart

[kdaviper]

23 hours ago, PDCWolf said:

They probably have a bag of bugs that wasn't ready for 0.1.5 but in the 2 extra months will be ready for 0.2.0. Now, how important or crucial or foundational those bugfixes may be obviously I can't say, but it'd definitely be very rare for a big update do not include bugfixes in it as well.

Remember that before Blackrack, 90% of performance gains came from them hiding, deleting, culling and downgrading stuff on screen, which is not fixing the performance of the game so much as it is a stopgap to make it playable whilst they hopefully actually fix stuff.

Now Blackrack came in and pretty much fixed the clouds which were a huge performance issue, and actually one of the like 10 proper performance fixes we've seen and probably the only one with a measurable, night and day impact as well. This is my way of saying I think we'll be back to meager "we made something worse so the game runs a bit better" type fixes.

Culling and reducing unnecessary renders is literally an important step in optimizing graphics. Not to say that these are the only methods, but there is no need to draw geometry that can't be seen.

[kdaviper]

19 hours ago, HebaruSan said:

The devs speak consistently about how "user stories" drive their priorities, meaning that functionality would be built and improved based on what the game needs to do to deliver the intended experiences.

In an ideal world*(asterisk the size of Kerbin), this would mean that after the devs move the "feature/science" branch into testing, the testers would, among many other things, try running a sample return mission from Duna with rovers and docking, note the flips and explosions, and then update the existing bug reports for those problems in the internal bug tracker to indicate, "Severity increased because this impedes For Science! User Story #3." Then those bugs would percolate to the top of one of the fixing queues, be assigned to a developer, and get fixed before release.

*(asterisk the size of Kerbin) - We do not live in that world, so some degree of falling short is to be expected. In particular, their failure to reproduce the old "re-entry accelerates pods back out of the atmosphere if they've ever been staged" bug after very clear and specific user reports indicates that the testers take shortcuts (and don't realize when it might be a good idea to avoid them), so a full end-to-end test mission may not happen. The prioritization system they're using may not cause the right bugs to be assigned out as needed. The devs may not be able to fix such bugs in the allotted time.

But those are questions of adequate dev/testing practices, not whether the next release should include new features. If Intercept manage to get their processes to a point where they can be relied upon, it should be perfectly feasible to ship new features alongside whatever bug fixes are most needed for them to be enjoyed.

In other words...

 

Same here. Now when I rage-quit, the period of never-wanting-to-play-again is much shorter; before I know it, I can't help thinking "What if I tried X instead?", then I try it, and half the time I'm able to move past the previous showstopper problem. (This is somewhat helped by the changes to the save system, which ensure that "persistent.sfs" doesn't trap me in a post-bug state anymore. I can pretty reliably return to the last-good state.)

It's news to me that they were unable to recreate the drag bug you mentioned after reported. 

Also I can see how the bug possibly came into existence. They were fixing another bug that involved drag cubes being improperly oriented depending on how the part was placed in the VAB (or something like that).

This was primarily affecting vehicles assembled in a horizontal configuration and launched via runway. 

So I imagine they rotated the drag cubes for a number of parts, then tested their performance in atmospheric flight.  

Where I suspect the mk1 bug came from was an accidental inclusion into the effected drag cubes. Then I imagine they did not test it at all in qc because it was not supposed to have had any changes made in the first place.

The fix was likely as simple as rotating an array 90 degrees

[HebaruSan]

1 hour ago, kdaviper said:

It's news to me that they were unable to recreate the drag bug you mentioned after reported.

Here are the community manager's replies stating they were still trying to reproduce it and asking for saves and craft files:

• https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295765
• https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295831

Edited October 28, 2023 by HebaruSan

[MechBFP]

1 hour ago, HebaruSan said:

Here are the community manager's replies stating they were still trying to reproduce it and asking for saves and craft files:

• https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295765
• https://forum.kerbalspaceprogram.com/topic/217838-not-slowing-down-on-reentry/?do=findComment&comment=4295831

I am a bit confused, that issue is fixed as far as I have seen? Following the reply chain above doesn’t help. 
 

EDIT: Nevermind i understand the context now.  Been sick and tired.  I wouldn’t say the CM asking for examples in that case is indicative of anything but poor internal communication. 
I am sure once the person who worked on that piece of the game saw the issue report that they knew almost immediately what was going on. 

Edited October 28, 2023 by MechBFP

[Astroneer08]

Don't forget that there is a chance of an update in November. And there is definitely gonna be bug fixes on release day for 0.2