Kerbal Space Program 2: Master Post

[dprostock]

2 hours ago, ShuttlePilot said:

You are making a good point. But think about others, not everyone can afford 2 GPU's to do that job. There are people who play with Intel HD Graphics 4000 (like me). A better idea would be to optimize the game itself, because KSP1 is a pile of bugs and it was published while being unfinished. KSP1 was rushed to release and they couldn't defeat all of the performance issues out there. We should better give the developers more time to fully finish the game. You don't want KSP2 to be glitchy, buggy, laggy, stuttery like KSP1. Don't you?

Mmmm.... You're sure they're working for a solution???? Do you have a project leader in charge of that task? You've been looking at the following page lately: https://bugs.kerbalspaceprogram.com/issues?

[MechBFP]

1 hour ago, dprostock said:

Mmmm.... You're sure they're working for a solution???? Do you have a project leader in charge of that task? You've been looking at the following page lately: https://bugs.kerbalspaceprogram.com/issues?

The KSP 2 devs are  a completely different team of developers, but they are also using a few KSP devs as consultants on KSP 2. It's really no surprise KSP 1 isn't getting much attention at this point.

[Kerbart]

27 minutes ago, MechBFP said:

The KSP 2 devs are  a completely different team of developers, but they are also using a few KSP devs as consultants on KSP 2. It's really no surprise KSP 1 isn't getting much attention at this point.

1.11 just came out with a brand new feature (at least for stock), texture upgrades and bug fixes. I'm not convinced that it's not getting much attention.

[MechBFP]

28 minutes ago, Kerbart said:

1.11 just came out with a brand new feature (at least for stock), texture upgrades and bug fixes. I'm not convinced that it's not getting much attention.

As much attention as it would be getting otherwise, I suppose is a better way to phrase it.

Although if KSP 2 didn't exist, it is entirely possible KSP 1 wouldn't be getting ANY attention anymore, so... *shrug*.

Edited April 9, 2021 by MechBFP

[Kerbart]

2 hours ago, MechBFP said:

As much attention as it would be getting otherwise, I suppose is a better way to phrase it.

Although if KSP 2 didn't exist, it is entirely possible KSP 1 wouldn't be getting ANY attention anymore, so... *shrug*.

You mean from "the world?" I thought you meant from the developers.

[MechBFP]

19 minutes ago, Kerbart said:

You mean from "the world?" I thought you meant from the developers.

I do mean the developers.

As much attention as it would be getting otherwise from the KSP 1 developers, I suppose is an even better way to phrase it.

Edited April 9, 2021 by MechBFP

[dprostock]

15 minutes ago, MechBFP said:

I do mean the developers.

As much attention as it would be getting otherwise from the KSP 1 developers, I suppose is an even better way to phrase it.

So technically we're talking about a "discontinued"... something that presents its latest screeds...

[Lisias]

12 hours ago, ShuttlePilot said:

You are making a good point. But think about others, not everyone can afford 2 GPU's to do that job. There are people who play with Intel HD Graphics 4000 (like me). 

You don't need a too modern GPU to have a good KSP experience - I'm running too on a HD 4000 graphics, and was using a HD 3000 until recently. Got some decent playing, the bottleneck is VRAM. You need to keep your VRAM consumption under tight control, everything works fine after.

Problem  - lowering the Texture's Quality will do it for everything, including the widgets' gryphs! So, if you lower the texture's graphics too much, the User Interface's widgets become so diffused that you can't tell if a check box is checked or not!!!

Not to mention the time for loading them. The textures are downsized on loading time, every load. So you waste time on loading an unnecessarily big texture (if you are using spinning disks this is specially annoying - not to mention wasting space on expensive SSDs), and also on post-processing the textures on memory to the desired quality level.

A simple precomputed cache for the textures would drop the loading times a lot - and avoiding mipmapping textures used for widgets would be a huge benefit for users with modest rigs.

 

13 hours ago, ShuttlePilot said:

A better idea would be to optimize the game itself, because KSP1 is a pile of bugs and it was published while being unfinished. 

"Premature optimisation is the root of all evil" - Sir Tony Hoare. You can bet your mouse that a lot of problems we have nowadays were due premature optimisations - and not only on KSP itself - some core add'ons are also sinners on this.

Fix the bugs first. Then try to find out bottlenecks and optimise the worst ones.

[dprostock]

11 minutes ago, Lisias said:

You don't need a too modern GPU to have a good KSP experience - I'm running too on a HD 4000 graphics, and was using a HD 3000 until recently. Got some decent playing, the bottleneck is VRAM. You need to keep your VRAM consumption under tight control, everything works fine after.

Problem  - lowering the Texture's Quality will do it for everything, including the widgets' gryphs! So, if you lower the texture's graphics too much, the User Interface's widgets become so diffused that you can't tell if a check box is checked or not!!!

Not to mention the time for loading them. The textures are downsized on loading time, every load. So you waste time on loading an unnecessarily big texture (if you are using spinning disks this is specially annoying - not to mention wasting space on expensive SSDs), and also on post-processing the textures on memory to the desired quality level.

A simple precomputed cache for the textures would drop the loading times a lot - and avoiding mipmapping textures used for widgets would be a huge benefit for users with modest rigs.

 

"Premature optimisation is the root of all evil" - Sir Tony Hoare. You can bet your mouse that a lot of problems we have nowadays were due premature optimisations - and not only on KSP itself - some core add'ons are also sinners on this.

Fix the bugs first. Then try to find out bottlenecks and optimise the worst ones.

Do you try to say that you should diagram, standardize and analyze the work to be done with already known and old solutions?

Stop and optimize the product, smoothing roughness and fixing bugs?????

You know how crazy that sounds????
 

[ShuttlePilot]

8 hours ago, Lisias said:

You don't need a too modern GPU to have a good KSP experience - I'm running too on a HD 4000 graphics, and was using a HD 3000 until recently. Got some decent playing, the bottleneck is VRAM. You need to keep your VRAM consumption under tight control, everything works fine after.

Problem  - lowering the Texture's Quality will do it for everything, including the widgets' gryphs! So, if you lower the texture's graphics too much, the User Interface's widgets become so diffused that you can't tell if a check box is checked or not!!!

Not to mention the time for loading them. The textures are downsized on loading time, every load. So you waste time on loading an unnecessarily big texture (if you are using spinning disks this is specially annoying - not to mention wasting space on expensive SSDs), and also on post-processing the textures on memory to the desired quality level.

A simple precomputed cache for the textures would drop the loading times a lot - and avoiding mipmapping textures used for widgets would be a huge benefit for users with modest rigs.

 

"Premature optimisation is the root of all evil" - Sir Tony Hoare. You can bet your mouse that a lot of problems we have nowadays were due premature optimisations - and not only on KSP itself - some core add'ons are also sinners on this.

Fix the bugs first. Then try to find out bottlenecks and optimise the worst ones.

I like your idea. And yes, the loading times are so annoying. There's mods for that, thankfully. There are texture compressors, loading managers to prevent the game from loading unnecessary things. BUT the game itself should have those features though.

[Lisias]

1 hour ago, ShuttlePilot said:

There are texture compressors, loading managers to prevent the game from loading unnecessary things. BUT the game itself should have those features though.

Load managers to prevent loading unwanted things is a solution for a problem on modded instalments, not stock.

And the textures are already compressed - the problem is the DPI used on them, aimed to high end computers by default, and these are the Achilles heel on the loading process: people playing on 1080p are loading 4K textures, that are horribly over-dimensioned to be used on 1080p. So, the user that knows how to set the texture quality to save VRAM e GPU's juice, rapidly finds the loading time slower (as now the textures need to reprocessed on loading), not to mention the U.I. elements being terribly blurred. (some of them beyond recognition).

That's the thing: these things are necessary, they are assets that will be used in the game - eventually. Long time ago, on a time where KSP still run on 32 buts and had a pretty small palette of parts, they decided to preload everything in memory because KSP had no "game stages" - the user could jump to anywhere in the "Universe", and they didn't wanted to annoy the user experience with loading times on a insertion burn.

Made sense at that time. But we are not on that time anymore, the stunts and tricks that worked fine on small scale will bite you on the back badly on large scale.

SSDs and transparent file system compression (BTRFS, APFS and NTFS) helps a lot, but don't fix the extra burden on downsizing textures on loading time to match the selected Texture Quality.

Clearly, some thinking are being utterly missed on the whole process.

Caching the downsized textures to be reused next load will hugely benefit these users (at expense of some disk space, granted) - and a way to prevent mipmapping glyphs used on the User Interface are terribly needed too.

Edited April 10, 2021 by Lisias
I'll take the Fifth on this.

[Lisias]

On 4/9/2021 at 12:12 PM, MechBFP said:

The KSP 2 devs are  a completely different team of developers, but they are also using a few KSP devs as consultants on KSP 2. 

(emphasis are mine).

And exactly how this is supposed to be reassuring?

[linuxgurugamer]

On 4/9/2021 at 11:12 AM, MechBFP said:

The KSP 2 devs are  a completely different team of developers, but they are also using a few KSP devs as consultants on KSP 2. It's really no surprise KSP 1 isn't getting much attention at this point.

How do you know?

[MechBFP]

28 minutes ago, linuxgurugamer said:

How do you know?

Because they have mentioned numerous KSP1 devs working on KSP2, like RoverDude. 

35 minutes ago, Lisias said:

(emphasis are mine).

And exactly how this is supposed to be reassuring?

I never said it was?

[Lisias]

7 minutes ago, MechBFP said:

I never said it was?

Being so, why this post:

would be an appropriated response to this other one?

Being yet more explicit, as perhaps you didn't paid enough attention to the discussion at hand:

On 4/9/2021 at 8:48 AM, ShuttlePilot said:

<cut by me> We should better give the developers more time to fully finish the game. You don't want KSP2 to be glitchy, buggy, laggy, stuttery like KSP1. Don't you?\

How your conter argument to @dprostock's reply to @ShuttlePilot's statement I quoted above should be understood?

 

 

[Kerbart]

15 hours ago, dprostock said:

Do you try to say that you should diagram, standardize and analyze the work to be done with already known and old solutions?

Stop and optimize the product, smoothing roughness and fixing bugs?????

You know how crazy that sounds????
 

None of us wants to see bugs. However, no bugs get fixed if development of the product is completely halted. It amazes me that something that glaringly obvious is never taken in consideration.

If you don’t introduce new features, interest wanes. When interest wanes, sales dry up (and there’s precious little left of that for starters). If sales dry up, income dries up. If income dries up, developers don’t get paid. If developers don’t get paid, bugs don’t get fixed.

If only it were so simple to say after the 1.0 release “from now on, only fix bugs.” But I doubt a 1.1 version would ever have seen the daylight with that priority mindset.

[ShuttlePilot]

12 minutes ago, Kerbart said:

None of us wants to see bugs. However, no bugs get fixed if development of the product is completely halted. It amazes me that something that glaringly obvious is never taken in consideration.

That's true. I think that this is kind of funny for a particular reason.

[MechBFP]

28 minutes ago, Lisias said:

Being so, why this post:

would be an appropriated response to this other one?

Being yet more explicit, as perhaps you didn't paid enough attention to the discussion at hand:

How your conter argument to @dprostock's reply to @ShuttlePilot's statement I quoted above should be understood?

 

 

I am not making an argument, just stating a fact as I am not sure if dprostock understands the current situation or not. 

[dprostock]

1 hour ago, Kerbart said:

None of us wants to see bugs. However, no bugs get fixed if development of the product is completely halted. It amazes me that something that glaringly obvious is never taken in consideration.

If you don’t introduce new features, interest wanes. When interest wanes, sales dry up (and there’s precious little left of that for starters). If sales dry up, income dries up. If income dries up, developers don’t get paid. If developers don’t get paid, bugs don’t get fixed.

If only it were so simple to say after the 1.0 release “from now on, only fix bugs.” But I doubt a 1.1 version would ever have seen the daylight with that priority mindset.

WOW!!!!!!

This is quite a statement!!!! 

It is a topical recognition that since version 1.0 a damaged product is sold and that it is not a priority to fix the problem!!!!!

A news story for specialized news agencies!!!!!!!

Are you acknowledging that a damaged product is sold and that there is no intention of correcting it?

So you know it's mediocre but with a change in paint color every three months you justify the income and that's enough?

Boy, you'd be the enlife of Steve Job and Bill Gates!!!!!

I've already taken a screenshot in case it's deleted, you see?
 

 

 

 

1 hour ago, MechBFP said:

I am not making an argument, just stating a fact as I am not sure if dprostock understands the current situation or not. 

TTI bought rotten fish?

[MechBFP]

@dprostock I don’t think you understand how non-trivial software development works. Bug free non-trivial software is impossible.

Your expectations are the equivalent of manufacturing a gear that is exactly  540.000000000mm in diameter and getting mad at the company when it is 540.01mm instead, despite the fact they gave no guarantee on their manufacturing specifications. 

[HebaruSan]

17 minutes ago, MechBFP said:

Bug free non-trivial software is impossible.

Another relevant point to contemplate:  The software in question is a video game.

Medical device makers and aerospace manufacturers go to extreme, expensive lengths to purge all the bugs they can from their software because lives are at stake (or, for non-crewed missions, because the hardware is expensive and one-of-a-kind). And sometimes they still have errors slip through.

KSP is just trying to edutain folks with some fun graphics and diagrams and explosions. Yes, it's impressive and inspirational. Yes, some of its fans take it very seriously. That doesn't mean it should be expected to satisfy the quality standards of the medical or aerospace software markets.

[Lisias]

57 minutes ago, HebaruSan said:

Another relevant point to contemplate:  The software in question is a video game.

Stake Holders don't care. Shareholders less yet.

All they care is about the money. See CD Projekt Red recent fiasco.

[dprostock]

1 hour ago, MechBFP said:

@dprostock I don’t think you understand how non-trivial software development works. Bug free non-trivial software is impossible.

Your expectations are the equivalent of manufacturing a gear that is exactly  540.000000000mm in diameter and getting mad at the company when it is 540.01mm instead, despite the fact they gave no guarantee on their manufacturing specifications. 

When I purchased the product I have not read anywhere that there were warnings that since 1.0 no errors are fixed.
Really high business they put together, pyramid type.
It still smells like rotten fish.

Bah,I'm going to waste my time again with AoE, D.E. and his collection of bugs.

[dprostock]

33 minutes ago, Lisias said:

Stake Holders don't care. Shareholders less yet.

All they care is about the money. See CD Projekt Red recent fiasco.

Class action? interesting...

[MechBFP]

48 minutes ago, dprostock said:

Class action? interesting...

Feel free to waste your money. I’m sure some ambulance chaser somewhere would be more than happy to assist lol.