Kerbal Space Program 1.9: "There’s No Place Like Home” Grand Discussion Thread

[AHHans]

About the KSP on Linux issue: KSP works fine on my Linux computer.

Granted, I don't have a joystick so the missing support for one doesn't affect me. But the graphical issues - that I know of - don't make the game unplayable. And some Linux specific bugs do get fixed, although with the alacrity that SQUAD applies to all bugfixes. So claiming that Linux isn't supported at all is unfair.

I also think that just complaining about how bad it all is and that nothing works is not going to motivate SQUAD to do a better job at supporting Linux.

[steve_v]

5 minutes ago, AHHans said:

Granted, I don't have a joystick so the missing support for one doesn't affect me.

It was fixed with the Unity update in 1.8.0. Finally. And only because they wanted the unity update for other reasons.
 

5 minutes ago, AHHans said:

But the graphical issues - that I know of - don't make the game unplayable.

No they don't. They do make the game look mighty unprofessional though, and they're pretty annoying to boot.

 

5 minutes ago, AHHans said:

So claiming that Linux isn't supported at all is unfair.

I never said it was totally unsupported, I said that Squad let substantial bugs languish for a ridiculous length of time and if I had known they would do that I wouldn't have bought their game.
That they regularly release with such blindingly obvious bugs suggests rather strongly that whether they "support" GNU/Linux or not, they certainly don't test the build. Like at all.

 

5 minutes ago, AHHans said:

I also think that just complaining about how bad it all is and that nothing works is not going to motivate SQUAD to do a better job at supporting Linux.

Probably not. But then reporting bugs hasn't helped, nor has buying DLC. So what's left?

Edited February 24, 2020 by steve_v

[AHHans]

On 2/24/2020 at 6:04 AM, steve_v said:

I never said it was totally unsupported,

Well, that was the message that the tone of what you wrote conveyed to me.

On 2/24/2020 at 6:04 AM, steve_v said:

Probably not. But then reporting bugs hasn't helped, nor has buying DLC. So what's left?

I believe that reporting bugs and reminding the developers of unfixed bugs after a new release in unconfrontational tones is more effective than <snip> about things.

Probably not effective enough to get everything fixed though, but considering the number of longstanding bugs that also affect the Windows platform I don't believe that this will change.

On 2/24/2020 at 6:19 AM, Brikoleur said:

Because Unity's compile to Linux doesn't quite work as advertised, [...]

So my summary is: "because the middleware support for Linux is buggy". Kind of what I was afraid of. Thanks!

Edited February 25, 2020 by Geonovast

[steve_v]

4 minutes ago, AHHans said:

I believe that reporting bugs and reminding the developers of unfixed bugs after a new release in unconfrontational tones is more effective than b*tching about things.

So did I. I tried that for about 4 years, and here we are.

 

4 minutes ago, AHHans said:

considering the number of longstanding bugs that also affect the Windows platform I don't believe that this will change.

My whinging is not at all confined to one specific platform. Leaving input support on GNU/Linux broken for 13 releases despite all our suggestions and example code made it so for a while, but it'll pass.

Edited February 24, 2020 by steve_v

[klgraham1013]

3 hours ago, Hotel26 said:

is there any other delivery avenue these days for KSP other than Steam?

GOG and the website.

[MechBFP]

Joystick support. I am pretty sure its not "input support", as I am fairly certain Linux can use a keyboard and mouse.

[Vanamonde]

A digression about Linux has been trimmed from this thread. Please stick to KSP, guys. 

[steve_v]

15 hours ago, MechBFP said:

Joystick support. I am pretty sure its not "input support", as I am fairly certain Linux can use a keyboard and mouse.

USBHID support, i.e. anything except a keyboard and mouse. Joysticks, gamepads, steering wheels, all those sweet KSP controller contraptions people have built. All non-functional.

Mouse+keyboard is handled by the OS/Window system with almost no support required at the application level.
Anything else requires the application to enumerate available devices and read events from them - something KSP failed miserably at for over a dozen releases, yet I can do using the same middleware (SDL2) in less than 50 lines of code.

HID support is not some esoteric function of KSP, it's a core feature expected of any modern game engine.
If the input stack is suddenly unable to handle anything but a bog-standard keyboard+mouse due to a regression, then input support is broken. Not working properly, broken, borked, bungled, bugged, take your pick.

Now it's fixed, not because Squad fixed it, but because they sat back and did nothing until a Unity update was needed for other reasons... But the first, second, and now third releases to include this upstream fix also have other, new regressions.

This is why I complain. Nothing is getting fixed without breaking something else, and old regressions are going unaddressed for multiple major releases.

Can we please have some 1.9.x bugfix-only releases to address the multitude of issues in the bugtracker before adding more borkage?

Edited February 25, 2020 by steve_v

[Dafni]

2 hours ago, steve_v said:

Can we please have some 1.9.x bugfix-only releases to address the multitude of issues in the bugtracker before adding more borkage?

I agree with this. Please focus on fixing bugs before introducing new content (that is available to us in the form of mods anyway, arguably in even better quality)

[Superfluous J]

23 hours ago, steve_v said:

 

Self-redacted, I commented before reading Vanamonde's post.

Edited February 25, 2020 by 5thHorseman

[maceemiller]

I'm gutted I dont have the time to play KSP anymore as it looks like its progressed well.....maybe one day I'll fire it up again....maybe

[Jesusthebird]

On 2/25/2020 at 1:12 AM, Dafni said:

I agree with this. Please focus on fixing bugs before introducing new content (that is available to us in the form of mods anyway, arguably in even better quality)

bug fixes normally get done after content addition as adding content can easily backtrack to...more bugs introduced. It can be the reverse...but at the end of it...it takes more time to release a bunch of bug fixes..introduce more content..then fix more bugs. This cannot be avoided especially with DLC or if they did do a build test with a conclusion there isnt any way around not introducing a bug without adding the content. sometimes it cannot be helped

[Arugela]

16 minutes ago, Jesusthebird said:

bug fixes normally get done after content addition as adding content can easily backtrack to...more bugs introduced. It can be the reverse...but at the end of it...it takes more time to release a bunch of bug fixes..introduce more content..then fix more bugs. This cannot be avoided especially with DLC or if they did do a build test with a conclusion there isnt any way around not introducing a bug without adding the content. sometimes it cannot be helped

No, that isn't actually how it works. That is just how they do it.

You know they should actually and do know about the bugs before hand. It's not a mystery that just pops up to people who actually know what they are doing. Programming and other design fields are application fields. That means forethought is the basis of the work. They know about the bugs. If not those are the areas they need to learn more until it is known. And if done enough they can more easily get rid of them without others having to deal with it. That is how actual programming works. If they aren't fixing bugs it means the chose not to or they don't know how to. Both of which down to they don't know something well enough on some level or they would have thought it out more ahead of time. This is a common problems now because of decades of education issues all over the board.

They are to always be held to the standard of knowing fully what they are doing. It's not really that hard either.

They should easily understand what the entire point of the code base is pretty easily. If not they have a big problem. The game is not that complicated and what it is doing should be easily discernible. Anyone saying otherwise is lieing, ignorant, or helping cover up the problems. They should have fixed the base problems in this game a long time ago. If they have done so for KSP2 they have no excuse not to have done so for KSP1... This stuff is not rocket science.

From the stuff I've seen half the problem is their refusal to do any real coding to begin with and get rid of the use of the garbage collection from unity and do the coding themselves properly. This means there is a big problem with their ability to code. Which means they don't know what they are doing. Even laziness is just an excuse for a lack of knowledge. It always works the same way. There is only ever one issue when it comes to programming. And with that one easy solution.

Edited February 26, 2020 by Arugela

[Lisias]

6 hours ago, Arugela said:

You know they should actually and do know about the bugs before hand. It's not a mystery that just pops up to people who actually know what they are doing. 

Agreed. However, there's something that you may be missing. Culture.

It's perfectly possible to gather some excellent professionals together just to see them failing miserably because they didn't managed to work out a culture that would allow them to fulfil their potentials.

A group of professionals doesn't makes a Team necessarily. You need more.

 

6 hours ago, Arugela said:

They know about the bugs. If not those are the areas they need to learn more until it is known. And if done enough they can more easily get rid of them without others having to deal with it. 

Ideally, yes. But on a Culture where failing is an individual demerit, and success is arbitrarily distributed, you will quickly realise that it's better to avoid handling bugs (you can't be blamed by failing if you don't even try) and focus instead on writing new things, no matter how buggy - it looks better on the performance report at the end of the sprint.

You may be interested on reading this, by the way.

 

6 hours ago, Arugela said:

This stuff is not rocket science.

I beg to differ!

 

6 hours ago, Arugela said:

From the stuff I've seen half the problem is their refusal to do any real coding to begin with and get rid of the use of the garbage collection from unity and do the coding themselves properly. This means there is a big problem with their ability to code. Which means they don't know what they are doing. 

It's a possible reading about the current status quo, but not the only one. My past on some corporations taught me that Reality is usually more complex than we can imagine.

I was ordered once to accept taking the blame for a problem I had diagnosed myself. And since I had signed a pretty nasty NDA, I could not even defend myself to colleagues from other Teams in the company I was working. I didn't liked it, but I needed the money (my kid had just been born at that time). And it's not impossible that some of the people that I had worked with at that time would talk trash about me even nowadays. [as well it's not impossible I'm a liar trying to cover a nasty mishap by telling nice stories]

Hanlon's razor says "Never attribute to malice that which can be adequately explained by stupidity", and I want to add "never take as incompetence what can be easier explained as miscommunication".

We just don't know all the facts. We can't make any serious statements.

But we can do some educated guesses: you can be right, you just can't say you are sure you are right.

 

6 hours ago, Arugela said:

Even laziness is just an excuse for a lack of knowledge. It always works the same way. 

Hanlon's razor.

Hidden knowledge is usually misunderstood as lack if it. You need a culture where you can exercise your knowledge in a profitable way. Remember, we do it for a reason, and if by exercising our knowledge we see anyone else profiting on it at our expense, the only reasonable line of action is to stop exercising the knowledge.

 

6 hours ago, Arugela said:

There is only ever one issue when it comes to programming. And with that one easy solution.

"For every complex problem, there's a solution that is simple, neat, and wrong." H.L. Mencken

When you need to work over layers of abstractions made by third parties and on which you don't have control neither enough lifetime to completely understand the whole shebang, you need to delegate and trust. Knowing when to delegate and who to trust is anything but simple.

The only real simplicity on this industry is what follows:

Spoiler

And I think this is all what really matters at the end of the day.

 

Edited February 27, 2020 by Lisias
Completing a line of though - on brackets and italics

[fragtzack]

The valve drain's mass is out of whack. For example, the  FTE-1 drain valve has a mass of 0.01, but the part dimensions  is tiny compared to other parts in the game. Other parts meaning in particular the tanks. In real life, valves are tiny fractions of the mass of the tank attached too and a tiny fraction of the dimensions also. The FTE-1 and all the drain parts have the same mass regardless of the mass or dimensions of the  tank attached to.

A FTE-1 with a mass of 0.01 feels about correct when attached to a Rockomax-64 jumbo tank, a tank with a dry mass of 4.0 T. Maybe math is wrong, but that appears to be about 0.25% ratio . 0.25% mass ratio of tank->valve about right. Maybe a tad high still for the valve mass.

However, take that same FTE-1 for smaller rocked design say a FL-T200 which has a dry  mass of 0.125.  This comes out to mass ratio of 8% mass ratio using the same mass as above. That is an insanely huge valve.

Making a part having a variable amount of mass depending on part(s) attached to drain might be difficult to code, but would seem better to lower the base mass value if cannot change the valve mass to be a variable mass size depending on attached to.

These issues with the valve drain mass has made me decide not to use the valve drain in a rocket design, except 1 time: On a Kerbin jet plane.  On the larger tank designs I have made, just never found a good use for needing to drain the fuel. I keep wanting to use the valve drains in small tanks setup, but keep deciding no cause of the mass ratio.

 

 

 

 

[TheJoolian]

Helicopters are a thing now...

[Curveball Anders]

47 minutes ago, TheJoolian said:

Helicopters are a thing now...

They've been a thing since about 1906

 

[qromodynmc]

Does anyone get shadows like this? only happening at takeoff and low alt flight

Edited March 3, 2020 by qromodynmc

[Zabloo]

I can't see your screenshot, @qromodynmc. Maybe you can try re-placing it?

[qromodynmc]

5 hours ago, Zabloo said:

I can't see your screenshot, @qromodynmc. Maybe you can try re-placing it?

sorry, can you check it again?

[Zabloo]

Now I see it. I don't know what this issue is, but I believe it has to do with your graphics settings. Do you have any mods installed?

[kerbiloid]

Btw, Alt-F12/SetPosition teleporting along the runway makes the craft stay on ground beneath the runway.

[MechBFP]

1 minute ago, kerbiloid said:

Btw, Alt-F12/SetPosition teleporting along the runway makes the craft stay on ground beneath the runway.

Set your altitude higher then.

[kerbiloid]

Just now, MechBFP said:

Set your altitude higher then.

It happened suddenly, I don't need it. Probably, as the runway is an object put on ground, it places the craft beneath this object.

[MechBFP]

Just now, kerbiloid said:

It happened suddenly, I don't need it. Probably, as the runway is an object put on ground, it places the craft beneath this object.

Hence, set your altitude higher when using the set position cheat.