KSP Weekly: Hera Reborn

[JPLRepo]

9 hours ago, XLjedi said:

@JPLRepo  as requested...  Bug Tracker report for the 1.4.4 disappearing craft bug.

https://bugs.kerbalspaceprogram.com/issues/19341

Additionally, I've noticed that once this bug occurs, if I try to Alt-Tab out of the game to the desktop, the game crashes so hard that it completely locks the PC and I can't even end the process with the Ctrl-Alt-Del window.  So I then have to power off the PC and do a complete reboot.  This morning when it happened the game did throw up a notice window stating the game had crashed, and mentioned the following craft report had been generated:  "Crash_2018-07-01_064436"  However, when I tried to find this crash report directory in the KSP root folder, none existed... I suspect the hard PC lockup and reboot caused the report to not actually be generated and/or saved to the root folder as would be expected.

I appreciate your time and willingness to respond, I seem to have lost any ability I may have previously had to set a priority on the bug report; so it seems to have defaulted to "LOW" and not sure if it will get any visibility at all.

I will do some more testing of the issue with exploding struts and the Mk3 cargo bay.  I was indeed able to successfully unload a craft (very slowly) as you suggested without damage.  However, at a minimum, it does seem that the Unity update in 1.4 and/or whatever other changes were implemented, has made the solar and radiator panels far more prone to falling apart when unloading.  So much so that I will have to try to remember to save game every time I unload something now.  So I still consider it in need of fixing, although it may be the tolerance of the deployable panels that just needs to be tweaked and not the Mk3 cargo ramp.

The exploding struts, I will try to test today and see if I can post a video and another bug report.

 

 

I see this in your log:
 Vessel HCS-16 Hurricane was on-rails at 101.2 kPa pressure and was destroyed.

The vessel doesn't disappear. It is destroyed by pressure. What needs to be determined is why (as from your video it is on the surface). I shall ask QA to investigate by priority if they have time. (No guarantees or preferential treatment; all reported bugs are triaged by priority, etc)
Will also ask them to take a look at the panels and radiators. But nothing as I recall has been changed there.

[theJesuit]

Just on the points of mods updating - CurseForge (still the official mod repository?) doesn't seem to have an option to search for 1.4.4 mods.

Will 1.4.5 be added quick smart when the next update drops?

Peace.

[XLjedi]

3 hours ago, JPLRepo said:

I see this in your log:
 Vessel HCS-16 Hurricane was on-rails at 101.2 kPa pressure and was destroyed.

The vessel doesn't disappear. It is destroyed by pressure. What needs to be determined is why (as from your video it is on the surface). I shall ask QA to investigate by priority if they have time. (No guarantees or preferential treatment; all reported bugs are triaged by priority, etc)
Will also ask them to take a look at the panels and radiators. But nothing as I recall has been changed there.

Thank you, I appreciate this...  

Edit: [snip]

After reading the notes in the bug tracker, I get what you're sayin...  thanks for looking into it.

As for the fragile deployable array equipment (solar arrays, including gigantor, and radiators)...  I totally believe you didn't change anything.  I suspect however, that the new Unity engine somehow made them more prone to fall apart.  Maybe adjust the tolerances a bit so they stay together on unload.  I may be forced to phase them out of my Mk3 rover designs to just avoid the issue, but seems a shame to take that approach.

Edited July 2, 2018 by XLjedi

[OHara]

1 minute ago, XLjedi said:

Thank you, I appreciate this...  in the video however, it's not the HCS-16 that disappears, it's the seaplane.  The HCS-16 Hurricane is a ship within about 1500m that gets tabbed to.  Then when you try to come back to the seaplane and rover, the seaplane just disappears with no explosions.  

JPLRepo was not looking at your logs.  I had recently confirmed the bug. and posted excerpts from my logs.  In my case, I saw the Hurricane disappear; trying again, the Barracuda; for me, the seaplane survived. 

Best to talk about the bug on the bug-tracker, rather than here, because the lack of context is confusing.

[XLjedi]

13 minutes ago, OHara said:

JPLRepo was not looking at your logs.  I had recently confirmed the bug. and posted excerpts from my logs.  In my case, I saw the Hurricane disappear; trying again, the Barracuda; for me, the seaplane survived. 

Best to talk about the bug on the bug-tracker, rather than here, because the lack of context is confusing.

Yeah, I went over and read the notes...  and was going to come back and edit my post, but you beat me to it.

[steve_v]

8 hours ago, 5thHorseman said:

Can you at least concede that it's possible that they simply don't know what the problem is or how to fix it? We don't even know if they're able to recreate it.

I guess anything is possible.
It's possible that Squad somehow missed the year-old discussion over on the unity forums.
It's possible they also missed the memo that unity 2017 is using SDL2s GameController API exclusively and therefore won't even attempt to initialise devices that SDL didn't identify as a gamepad. Hell, maybe everybody failed to notice that the GameController API itself is still a draft, and has a boatload of missing features.
It's possible that Squads linux test boxes (if they even bother) somehow don't exhibit this problem, despite so many users with different hardware and distributions confirming it.
It's possible that nobody at Squad has bothered to look at the AFBW code or read the SDL2 API docs to learn how to fix this.

It's also possible that Squad was aware of some or all of this and decided to go ahead anyway, because linux users are a minority and are probably accustomed to being treated like this.
IMO, given the apparent lack of progress or updates and the thinly veiled blame-open-source attitude in the bug report, this is far more likely. I'd be happy to be proven wrong.

We have not one but two mods here that can access an ordinary joystick just fine on linux, and they're free for the copying. So either Squad is not competent enough to do the same, or they're simply not trying. Again, please show me some evidence to the contrary.

 

8 hours ago, 5thHorseman said:

99% of the time bugs go unfixed because they only happen to a tiny subset of people and nobody else - including everybody in the company - can recreate it.

As the vast majority of input devices out there do not work with SDLs GameController API (no, I'm not going to accept some idiotic mapping of my joystick to an Xbox controller, and it doesn't work anyway), I expect this to be extremely easy to reproduce, and there are many joystick models mentioned in the bug report that will do it.
I have reproduced it myself with 2 different linux distributions and 4 different controllers. That's just what I had lying around.

GNU/Linux users who own joysticks may be a small subset of users, but they're users who paid the same as everyone else for a game that supposedly runs on their OS.
Having joystick support borked by an update and ignored for months, regardless of whose fault  it supposedly is, is a slap in the face - particularly as work is currently being done to improve steam controller support on windows.

 

"Unity's fault", "Linux's fault", "SDL's fault", I've heard it all before and it's horsecrap. Unity screwed up input support and Squad decided to use it in their product anyway. Squads product, squads problem.

Edited July 2, 2018 by steve_v

[Superfluous J]

2 hours ago, steve_v said:

It's possible that Squad somehow missed the year-old discussion over on the unity forums.
It's possible they also missed the memo that unity 2017 is using SDL2s GameController API exclusively and therefore won't even attempt to initialise devices that SDL didn't identify as a gamepad. Hell, maybe everybody failed to notice that the GameController API itself is still a draft, and has a boatload of missing features.
It's possible that Squads linux test boxes (if they even bother) somehow don't exhibit this problem, despite so many users with different hardware and distributions confirming it.
It's possible that nobody at Squad has bothered to look at the AFBW code or read the SDL2 API docs to learn how to fix this.

It's also possible that Squad was aware of some or all of this and decided to go ahead anyway, because linux users are a minority and are probably accustomed to being treated like this.
IMO, given the apparent lack of progress or updates and the thinly veiled blame-open-source attitude in the bug report, this is far more likely. I'd be happy to be proven wrong.

We have not one but two mods here that can access an ordinary joystick just fine on linux, and they're free for the copying.

These are all things I didn't know because all I know about this problem is the bug report. Other than the snide tone in the bug report that I didn't notice, but it was veiled.

Do those mods that totally fix this problem with no downsides come with licenses that allow Squad to copy the code as-is and integrate it into the game without changing their own license? Have the modders (or users) updated the bug report with descriptions and links to these mods and their licenses? And if they exist, are you not using them?

[steve_v]

1 hour ago, 5thHorseman said:

These are all things I didn't know because all I know about this problem is the bug report.

Okay... so why are you arguing wrt things you don't know about again? A few moments with a search engine would have saved me much typing.

 

1 hour ago, 5thHorseman said:

Do those mods that totally fix this problem with no downsides come with licenses that allow Squad to copy the code as-is and integrate it into the game without changing their own license?

AFBW is MIT. Don't see a problem here.
Of course the real reason  is that AFBW uses non-unity APIs. and includes *gasp* platform-specific code. Which Squad is apparently incapable of even looking at.

 

1 hour ago, 5thHorseman said:

Have the modders (or users) updated the bug report with descriptions and links to these mods and their licenses?

Squad have not asked, and they can use a search engine just as well as I can. They are likely more capable than I of finding things on their own official forum.

I'm not going to put such links there myself, as that will just encourage the "fixed by mod, case closed" attitude.

 

1 hour ago, 5thHorseman said:

And if they exist, are you not using them?

No. I'm not buying the DLC until this is sorted, so I have no use for 1.4.

Besides, it's Squad's problem to fix, work around or hassle unity about. Whether or not I'm willing to use mods to work around stock bugs, I'll still bag Squad for not fixing them. It's their game.

I'm perfectly okay with mods adding new functionality, but I'm not at all impressed when "there's a mod for that" is used to excuse a bug - especially one as ridiculous as this.
 

Edited July 2, 2018 by steve_v
Avoid repeating text available elsewhere.

[Superfluous J]

1 hour ago, steve_v said:

Okay... so why are you arguing wrt things you don't know about again? A few moments with a search engine would have saved me much typing.

Frankly? I'm sick of hearing about it in the comments of every KSP weekly.

Luckily for you they fixed custom feeds in the forums so I can go back to my "no actual news" feed that I used to use when all the complaining about "this is the most important thing ever and the game is literally broken because of it" problems drove me away. It was actually a little nice to come back and see news for a bit but all this repetitive complaining has obviously built up in my system like a toxin and now I need another break. So you can yell into this void as long as you'd like criticism-free. At least from me. I can't guarantee no one else will criticize of course.

Edited July 2, 2018 by 5thHorseman

[steve_v]

13 minutes ago, 5thHorseman said:

I'm sick of hearing about it in the comments of every KSP weekly.

Your eyes have lids, and I can't stop you from using them if you wish not to see something.
You're also quite entitled to use the ignore function of this forum, 'tis no loss to me.
OTOH, since this appears to be the same old complaining about complaining, I might avail myself of those options too.

Ed. I'll be sure to complain in every weekly from now on, until this is fixed. I think I missed a couple back there, how lax of me.

Edited July 2, 2018 by steve_v

[XLjedi]

I really don't understand the uproar over Linux joystick support?

I haven't been able to use my Saitek X52 FCS on my Windows machine for as long as I've been playing.  I did see there was some support added in 1.4.4 for basic FCS support, so will have to give that a try now.  I've gotten so use to working around the Unity/Saitek Controller Joystick Lag bug by flying with the keyboard, the joystick (if it doesn't still lag a full second or two) would feel odd now anyway. 

Flying with a joystick right now is least of my concerns regardless of operating systems.

Edited July 2, 2018 by XLjedi

[AVaughan]

@steve_v  Your whole attitude to this bug is still toxic.  Linux users are probably around 1-2% of the entire player base.  Linux users with joysticks are probably less than 1%.  Steam users on windows are probably closer to 80-90%.  According to Valve's hardware survey Linux users are definitely less than 1% of the entire potential set of people who might be convinced to buy KSP on Steam.   So of course Squad and Take Two care more about Steam users on Windows than Linux users with joysticks.  (And don't forget, Take Two Interactive own Squad.   If they say add steam workshop support asap, then we get steam workshop support asap).   

Also for all we know Steam controller support on windows might be the start of ksp moving away from using Unity's API for joystick/controller input.  The next step might be native OSX and/or linux controller support.  (Unity has more reason to care about controllers than joysticks, since more unity games will benefit from controller support, than will want joystick support).  But regardless, if I was in charge of KSP development atm, I would fix this problem right now by adding 1 line to the changelog for 1.4.5  

Quote

Until further notice, joysticks are no longer supported on linux.

Would that make you happy?

More seriously, though, given the small proportion of ksp users who are playing on linux, any linux specific bug that isn't a reproducible crash or a lockup or a failure to load ksp (ie any bug that doesn't prevent you from actually playing) is a normal severity bug, and will get fixed if/when they get around to it.    A linux specific bug that only affect a subset of linux users has even less reason to be a priority.    

On 7/1/2018 at 7:04 AM, StarLord34829 said:

Can we not just get a monthly update for the consoles? It just seems really weird to wait five months until there's a second update for the game.

From what I have heard on forums for other games, every console patch has to go through Microsoft's and Sony's testing and validation.  That costs significant mounts of money for every patch.  With steam they can push patches much more often without paying for the console validation processes.   

[steve_v]

24 minutes ago, AVaughan said:

Linux users are probably around 1-2% of the entire player base.

If your product is advertised as running on linux, you support linux. If you do not, I don't buy or endorse your product.
If KSP on linux gets 1% of the support, I expect to pay 1% of the price. Otherwise, percentages are of no interest to me whatsoever.

The same goes for any other "supported" platform, I was critical of the console port debacle as well, for much the same reasons.

I'm also real, real tired of hearing "Unity problem, wont fix". It's been going on since alpha.
 

24 minutes ago, AVaughan said:

Would that make you happy?

It'd make me not purchase anything from Squad again, and a lot less likely to support any other game in early access.

Edited July 2, 2018 by steve_v

[Tyko]

On 6/30/2018 at 11:46 PM, Galileo said:

I’d be perfectly fine with longer wait times between updates. Perhaps mod users could actually make some progress in a career for once. One thing that made 1.3.1 so great was it’s life span. So far, every iteration of 1.4.x has just caused frustration for many players. 

I refuse to touch ksp or my mods until the updates slow down. This release schedule is a huge turn off for me and I’m sure I’m not alone with that feeling.

I can’t tell you what a “finished” update is, but thinking about this makes me wonder how Squad determines what a good stopping point is for an update to be released. If 1.4.5 is already mentioned in the dev notes for the 1.4.4 update, why not just roll them in together? What was the point? It’s ridiculous.

 

Side note: I stand corrected in that squad actually did say exactly what the mission builder did in a dev note once. But that’s easy to miss and it’s up to the user to go back and read on it. I just find it odd that so many people just happened to miss that bit of info. Perhaps it was emphasized enough? 

The most frustrating thing for me in the 1.4.x updates has been that Squad keeps adding more features in these releases which is a) taking time away from bug fixes and b) creating new bugs.

I'd much rather see them stick to standard versioning naming and use maintenance releases for maintenance - i.e. fixing what's already there, not adding more stuff. This means that 1.4.0 would have had the new features and 1.4.1, .2, .3 & .4 would have only been bug fixes. The updates could have potentially been released quicker and maybe we'd have needed less updates because all the effort would have been solving bugs.

Doing it this way would have given us a more solid game to play for now and freed up squad resources earlier to start working on 1.5 and any new features / enhancements. Instead we have 4 updates with a mixed bag of some bugs fixed, some new features and some new bugs.

TL:DR If you're house has a crack in the foundation, a flooding basement and a gas leak you don't call in contractors and assign half of them to adding a fireplace and a hot tub to the house. Fix what you've got first.

Edited July 2, 2018 by Tyko

[_stilgar_]

8 hours ago, AVaughan said:

And don't forget, Take Two Interactive own Squad.   

It doesn't. Take Two only bought KSP and hired Squad to keep working on it. Squad is still independent. 

[Mako]

10 hours ago, steve_v said:

If your product is advertised as running on linux, you support linux.

But it DOES run on linux. It just doesn't support a joystick. Look, I get your point about it was working and now it's not, and I completely understand your frustration. The thing is, if the devs have interacted with the bug report then they're aware of the situation, and by now any one from Squad who cares about the situation knows how you feel.

If bringing it up with relative frequency provides you some amount of positive feeling(s), then I guess you keep doing you, but otherwise I'm just not sure what you hope to get out of it. After all, you're 

10 hours ago, steve_v said:

also real, real tired of hearing "Unity problem, wont fix". It's been going on since alpha.

, so you should already know what to expect.

 

Maybe if you complain enough Squad will remove joystick support for everyone. It's probably far easier, and more believable, than fixing joystick support for linux, at any rate. Then everyone is equal again, except the console folks, of course.

[Vanamonde]

Tempers are running hot this week. Please try to disagree with each other without getting personal about it. 

[KerbMav]

5 hours ago, Vanamonde said:

Tempers are running hot this week.

Must be the weather. Even southern England was cooking when I visited last weekend.

[XLjedi]

@JPLRepo  As promised, here's a 100% reproduceable example video of the Exploding Strut Bug  (Oh and as a bonus, it likes to eat wheels too!)

 The complete bug report (along with sample craft) can be found here:  https://bugs.kerbalspaceprogram.com/issues/19402

It has to do with docking/undocking when a craft is on the ground.  In this case, I'm triggering the dock/undock by simply entering/leaving the external command seat on top of the basic rover.  As noted in the bug report, it occurs with any part that would cause a dock/undock:  Docking Ports, Claw Grabbing Unit, the External Command Chair

These bugs really do make the game aggravatingly hard to play a LOT of missions.  It's depressing...  Anything you all could do to address the bugs that I've posted both in this thread and on your community bug tracker (in the next update or two?) would be most appreciated!

 

Edited July 12, 2018 by XLjedi

[KerikBalm]

On 7/1/2018 at 11:32 PM, JPLRepo said:

I see this in your log:
 Vessel HCS-16 Hurricane was on-rails at 101.2 kPa pressure and was destroyed.

The vessel doesn't disappear. It is destroyed by pressure. What needs to be determined is why (as from your video it is on the surface). I shall ask QA to investigate by priority if they have time. (No guarantees or preferential treatment; all reported bugs are triaged by priority, etc)
Will also ask them to take a look at the panels and radiators. But nothing as I recall has been changed there.

It seems quite clear when I read this the first time. The vessel was put on rails while not in the landed state. Vessels on rails that go too deep in the atmosphere get destroyed unless they are in the landed state (or pre-launch). Its not a depth into the atmosphere per se, but a pressure threshold. IIRC it happens at 23km on kerbin (somewhere between 1 kPa and 2.5 kPa), much lower on Duna, and much higher on Eve.

To diagnose further, he should switch vessels and see if the vessel is deleted (via map view, when still focused on the distant vessel) when he switches away, or when he switches back to the craft. Then you'll know when the vessel lost its "landed" state

[Aquaticfantastic]

@SQUAD Thank you for acknowledging us console folks!

Whilst the information is lacking, just hearing from you that work is being done is appreciated!

One thing I would like addressing is when or if we are likely to see 'making history' on consoles?

I'd be more than happy to part with some $$ for it!

[JPLRepo]

8 hours ago, KerikBalm said:

It seems quite clear when I read this the first time. The vessel was put on rails while not in the landed state. Vessels on rails that go too deep in the atmosphere get destroyed unless they are in the landed state (or pre-launch). Its not a depth into the atmosphere per se, but a pressure threshold. IIRC it happens at 23km on kerbin (somewhere between 1 kPa and 2.5 kPa), much lower on Duna, and much higher on Eve.

To diagnose further, he should switch vessels and see if the vessel is deleted (via map view, when still focused on the distant vessel) when he switches away, or when he switches back to the craft. Then you'll know when the vessel lost its "landed" state

This was fixed in KSP 1.4.5. From the changelog:
* Fix vessels splashed inside another splashed vessel being removed when outside physics bubble.

[XLjedi]

55 minutes ago, JPLRepo said:

This was fixed in KSP 1.4.5. From the changelog:
* Fix vessels splashed inside another splashed vessel being removed when outside physics bubble.

This is true...  I did also acknowledge I was happy to see that was fixed!

Although, that fix description did seem to get some ridicule from folks who thought it was a totally obscure/unlikely situation to have vessels splashed inside another splashed vessel.

[JPLRepo]

30 minutes ago, XLjedi said:

This is true...  I did also acknowledge I was happy to see that was fixed!

Although, that fix description did seem to get some ridicule from folks who thought it was a totally obscure/unlikely situation to have vessels splashed inside another splashed vessel.

Whilst perhaps being obscure... which I take to mean as - not common. It is very likely.. given that a vessel splashed indicator has no relationship to it also being landed. They are independent indicators in the code.
So I can be splashed and landed... by being landed on another vessel with part of the vessel being within the water - and therefore splashed.

[XLjedi]

39 minutes ago, JPLRepo said:

Whilst perhaps being obscure... which I take to mean as - not common. It is very likely.. given that a vessel splashed indicator has no relationship to it also being landed. They are independent indicators in the code.
So I can be splashed and landed... by being landed on another vessel with part of the vessel being within the water - and therefore splashed.

No argument from me...  I was the one that was complaining my craft were disappearing!  

This one seems to work just fine since the 1.4.5 fix.  thank you!