Jump to content

KSP2 Release Notes - Update v0.1.5.0


Intercept Games

Recommended Posts

19 minutes ago, Dakota said:

If you experience a bug, fill out the bug report forum. Anth and I will merge new reports that already have archived threads and bring them back out. For now this is the best way for this workflow to work, though we know it's a headache. Hopefully will have news about new K.E.R.B. processes soon. 

Hmm, that's not just a headache, it's a pretty significant duplication and waste of effort to re-submit an identical description of something that has already been filled out. I hope you won't be too offended if I say that I feel I have better ways to spend my free time.

Maybe bugs that haven't been worked on shouldn't be auto-archived as if they had been?

Link to comment
Share on other sites

Patch 1.5: 
Win 10 21H2, Ryzen 5800X +3080ti (280W & 1900Mhz max), all settings MEDIUM 1080P + Low Antialiasing on PCIE 4 NVME

K1 VAB: 210 FPS (From 160FPS Patch 4)
K1 Pad: 120 FPS (from 100fps)
K1 Launch (low alt): 95-100FPS (from 90fps)
K1 Orbit (75x75 or so stable): 160-185fps (from 130-150fps)

K1:
VAB: +35% perf
Pad: +20% perf
Launch: +10% perf
Orbit: +23% perf

K2 VAB: 195-200fps (from 155fps Patch4)
K2 Pad: 105fps (from 88fps)
K2 Launch (low alt): 86-90fps (from 65fps)
K2 Orbit: 155-165fps (from 130fps)

K2:
VAB: +26% perf
Pad: +20% perf
Launch: +35% perf
Orbit: +23% perf

Some really quick testing for this patch on my main PC vs Patch 4. New save/campaign for both mind you.

Really good improvements across the board if this scales to larger ships, though RCS engine calculations still eat up a lot of performance from my tests for the orbital ships. like,  180fps turns to 160fps etc. Have not tested the bugfixes yet, but will do a Mun mission with one of my NERV / Blue Origin like crafts 

 

Also question, why is the Map view FPS so much lower than the ship cam view, even with Kerbin rendering?

I'm getting say, 130fps with the engines firing for a maneuver, but when I go to the map view, with only the ship, trajectory lines and the Mun visible, it drops to 55fps?

 

3NMmLua.png

Edited by HyenaDae
Link to comment
Share on other sites

19 minutes ago, HebaruSan said:

Hmm, that's not just a headache, it's a pretty significant duplication and waste of effort to re-submit an identical description of something that has already been filled out. I hope you won't be too offended if I say that I feel I have better ways to spend my free time.

Maybe bugs that haven't been worked on shouldn't be auto-archived as if they had been?

its a catch-22 sorta deal: players may think they're the exact same bug report because the symptom is the same, but from the developer perspective it could be an entirely different bug report for tracking purposes because the root cause is the same. Having everything submit separately and be merged after review if determined to be indeed duplicates is the best way to handle it, usually.

Your experience shows the other side - users aren't workers, and are entirely capable of saying "not worth it" and just not bothering with a report. Ease of report submission alongside quality of report submission are two metrics that are forever at odds, especially since ease of reporting influences quantity of reports as well.

For what its worth @Dakota, The way you do it now is probably the best way. The number of hours I've wasted as a developer hunting down a bug in a completely wrong avenue because the bug that "returned" only happens in entirely different reproduction circumstances that were never documented because the user just reopened the last incident instead of a new one have probably cost my company a fortune.

Link to comment
Share on other sites

3 minutes ago, chefsbrian said:

its a catch-22 sorta deal: players may think they're the exact same bug report because the symptom is the same, but from the developer perspective it could be an entirely different bug report for tracking purposes because the root cause is the same.

That's true if an issue is complex and has been worked on. In this case, a very simple UI issue (a label in the settings says "auto-hide" instead of "show") has been auto-closed at a new release after not being worked on. That's simply no way to run a bug tracker.

3 minutes ago, chefsbrian said:

The number of hours I've wasted as a developer hunting down a bug in a completely wrong avenue because the bug that "returned" only happens in entirely different reproduction circumstances 

"Returned" applies only to bugs the developers think they fixed. That's not what happened here.

Link to comment
Share on other sites

2 minutes ago, HebaruSan said:

In this case, a very simple UI issue (a label in the settings says "auto-hide" instead of "show") has been auto-closed at a new release after not being worked on. That's simply no way to run a bug tracker.

The problem with offering multiple potential paths for submission is that users tend to take the path of least resistance, even if its not correct. Again, I get that in your situation its an unneeded PITA, but multiple processes is a much greater PITA on the rest of the team, I've been there and it sucks lol.

Link to comment
Share on other sites

1 hour ago, Dakota said:

If you can find it, I'll add it to the notes!

https://forum.kerbalspaceprogram.com/topic/219225-first-stage-engine-is-controllable-without-a-probe-core/

For this:

22 hours ago, Intercept Games said:

Fixed: decoupled stage without probe core/pod is controllable

 

Edited by Vl3d
Link to comment
Share on other sites

PS: Glad to see the "revert while paused" bugs seem to be fixed!
Also performance is clearly improved. And the clouds / atmospheric lighting look much better! Kudos!

Edited by Vl3d
Link to comment
Share on other sites

11 minutes ago, chefsbrian said:

The problem with offering multiple potential paths for submission is that users tend to take the path of least resistance, even if its not correct. Again, I get that in your situation its an unneeded PITA, but multiple processes is a much greater PITA on the rest of the team, I've been there and it sucks lol.

What "multiple paths" and "multiple processes" are you referring to, exactly? I'm not quite following the point you're making.

If you mean a user having the option to revive an old issue versus starting from scratch, then sure, I've seen plenty of drive-by comments on the CKAN bug tracker that in fact had nothing to do with the original issue. But if there's not going to be a quick and easy way to revive a report, then when a user puts in the effort to clearly and completely document a problem (another recently auto-closed bug report of a still-current issue, Incorrect/Buggy Units and Values in CB Information, is particularly good here), it probably shouldn't be archived by an automated process without anyone marking it as probably-fixed.

Edited by HebaruSan
Link to comment
Share on other sites

4 minutes ago, HebaruSan said:

What "multiple paths" and "multiple processes" are you referring to, exactly? I'm not quite following the point you're making.

If you mean a user having the option to revive an old issue versus starting from scratch, then sure, I've seen plenty of drive-by comments on the CKAN bug tracker that in fact had nothing to do with the original issue. But if there's not going to be a quick and easy way to revive a report, then when a user puts in the effort to clearly and completely document a problem (another recently auto-closed bug report, Incorrect/Buggy Units and Values in CB Information, is particularly good here), it probably shouldn't be archived by an automated process without anyone marking it as probably-fixed.

This is exactly how I've felt ever since the new archiving system got put in. It puts a lot of impetus of work onto users who are donating their time to try to make a game they care about that much better!

Link to comment
Share on other sites

Solid performance improvements, most noticeable in the earlier phases of flight, there is no zero stuttering at engine ignition and launch, the ascent is smooth, transition from atmosphere is silky smooth and the new scatterer effects look great. Did a mission out to the Mun (due to amount of time I had), launched on SLS like rocket, went out to the Mun, went into a low orbit. Went back to Tracking Station and time warped for a significant period of time. Zero orbital decay, jumped right back to orbiter, performed a Mun escape burn and went home. Zero stuttering or loss of performance upon arrival at Kerbin, I used to get some obvious frame rate drops at that point.

 

All in all good patch, and as a fantastic extra we get grid-fins that work and do as advertised, airbrakes which deploy in VAB and do as advertised and the absolute standout for me, being a fiend for modular missions the bug where docking ports aren't targetable is not gone! Thank you to the team, this is a great patch and just when it was needed and it's done wonders for the overall mood of the community. :prograde:

Link to comment
Share on other sites

15 minutes ago, HebaruSan said:

What "multiple paths" and "multiple processes" are you referring to, exactly? I'm not quite following the point you're making.

Sorry, I'll elaborate then. Its all about the various ways a user can try and bring attention to a problem. Forcing users to submit new reports rather than resurrecting old reports themselves ensures that your having users go through the whole process, and ensuring that you leave behind any potentially irrelevant and stale information from the old report that could merely muddy the waters of an issue. Allowing reopens also opens avenues for misuse, via users finding old items 'easier' to reply to as the requirements are not as strict to just say "its happening again", when it very well may be entirely different. This leads to you having one way to handle one report, and one completely different way to handle another report, just based on how the user decided to submit it, hence multiple paths and multiple processes.

This problem gets worse as you open more avenues for people to submit issues - Such as a stripped down report to just present a seeming UI only issue, and so forth. The people managing and triaging the queue have to keep up with all these different avenues and the appropriate way to treat them, and the User has to somehow be educated on how to use the right one in the right situation - Which frankly, isn't their job and is just asking for mistakes, that waste everyones time and confuse the whole system.

So at the end of the day, the best way to go is one user, one issue, one report, full reporting expectations, and if its determined to be a duplicate by the team, then they can merge it in. Opening any way for someone to bypass that just adds confusion, difficulty to maintain, and a risk of things just being straight up wrong due to assumptions made on either side of the equation.

Edited by chefsbrian
Link to comment
Share on other sites

Cool, in that case I can just refer you to everything else I've written after the first sentence.

And back on topic, I am also seeing much higher FPS in this patch. I never thought this PC would last this long. Bravo!

Edited by HebaruSan
Link to comment
Share on other sites

1 hour ago, 3Cents said:

The game doesn't load for me, I can't pass the loading screen with the message "Loading localizations from Addressables..."

 

Had this issue too on 0.1.4. If you wait for while it launches. (sometimes it took me  a couple of minutes)

Link to comment
Share on other sites

I'm pleasantly surprised by the performance improvement we've seen in 1.0.5.0.!

I'm gonna leave a couple videos here as reference. Both are different clean new saves on 1.0.5.0, maximum graphic settings.

Atmospheric scattering looks incredibly better, and so does cloud shading and clouds in general. More nice to the eyes. Also noticed that their ghostly movement is basically gone! (like, in the recent past when you moved the camera you could see the clouds lagging behind a little), they feel solid now. Can't wait to see Blackrack improve upon it.

First video is based around KSC and general Kerbin performance. I can say that most of the performance losses when looking down to the ground are mostly gone (only tested in Mun and Kerbin, but wanna play more now that performance is good!). I'm sure they'll be able to optimize everything even more, but it feels really good.

Second video uses this craft , 100 parts, for a normal mission to (fail) land on the Mun. In past patches, using a 100+ parts vehicle would drop me to the 20s fps. Keep in mind that recording eats about 3-4 fps from my general framerate. Also wanted to check how many bugs I would find on such a trivial mission, and so far only got one (added the 4 solar panels to AG1, only 2 of them deployed, the other 2 were unresponsive).

For performance reference sake, my PC specs are:

AMD Ryzen 5 5600
Sapphire RX 6700XT
16Gb DDR4 3200
SSD Install
 

Just to add a bit of contrast, this is a comparison I made back in the release of 1.0.1.0., comparing the Early Access release build performance with 1.0.1.0. (Graphics were on Medium, clouds were on Low, same PC)
 



Even if it looks like Intercept is taking their time, 1.0.5.0. gave me some hope they can pull it out.

Please, lets let them cook. :)

Link to comment
Share on other sites

I'm hella excited to try KSP2 again, but I think I'm going to try and hold on 'till the For Science! update. It's great though to see so many improvements made to the game lately. Phenomenal job to all those on the team for working hard to make Kerbal great again lol

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...