KSP Weekly: Hera Reborn

[XLjedi]

@Squad you spend your time adding new Steam integration features while the game is pretty much currently broken.

How do you complete any sort of mission when you have to deal with:

1. Your landing struts explode when they touch the ground
2. Mk3 Cargo Bays destroy deployable equipment on exit only (solar and radiator arrays)
3. And now if you even tab between craft, there's a good chance your main craft will just disappear!!! 

Look at this video; your game is unplayable...

I mean, I can deal with most of your bugs...  and continue to recommend the game, but are all the other fanboys just OK with this???  I can't play the game and complete missions.  Right now, all you have is a functional sandbox mode to build craft and test fly them.  Anything beyond that is pretty much a waste of time to even bother with.  

 

Edited June 30, 2018 by XLjedi

[basic.syntax]

8 hours ago, Galileo said:

They could have put a lot of rumors to sleep by being more precise about what the mission builder was going to be.

First answered in the MH announcement thread, March 2017.  Of course, that didn't stop players (including myself) wishing it would enable creating custom contract missions. 

 

[klgraham1013]

42 minutes ago, basic.syntax said:

First answered in the MH announcement thread, March 2017.  Of course, that didn't stop players (including myself) wishing it would enable creating custom contract missions. 

 

I was going to say, I felt like they made it clear.  It was just wishful thinking that career mode might actually be kind of fun with the DLC.

[swjr-swis]

7 hours ago, klgraham1013 said:

An update broke a part of the game that a consumer was relying on.  In my opinion, fixing a piece of the game you broke with an update is pretty important.

In the IT services field, it's part of the standard change protocol to have both a contingency plan and a back-out/revert plan for when a change causes unexpected problems. Changes do not 'stick' until they pass a certain set of pre-arranged tests (*). A certain amount of time is usually calculated as part of the change to try and deal with issues right away, but passing a pre-specified time limit, the whole thing is backed-out and reverted to the previous working version, and a new change isn't planned in until the whole thing is investigated and the cause found/resolved.

When you are used working that way, it becomes second nature and really doesn't create the overhead people think it does. In fact, it tends to *save* time in the long run, not to mention a lot of aggravation.

I keep wondering why this doesn't seem to be the case for game (software?) development. What makes that exempt from proper change protocols?

(*: this is not just internal 'QA', the tests are agreed and shared with the client and they have part in giving the green light)

[StarLord34829]

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.

[TriggerAu]

On 6/30/2018 at 7:33 AM, theJesuit said:

So... no quick fix for the game locking issue when pressing esc from the menu?  Seems like this would have been a slightly more pressing issue for a hot fix even.

...

Not every bug that gets worked on is listed in these, and I'd say that ones an oversight as we do have a fix for that yes.

 

On the too fast/too slow patching cycle (hopes he doesn't get flamed for this) we have been pointedly not making changes in revision releases that affect mods (Unity upgrades, method signature changes, etc). This should mean that I compile a 1.4.x release of my mod and its all good and working as LGG mentioned above. That's not a guarantee, but we do aim to not affect mods and call it out in the release notes if there's a change that could have an effect.

I do know there will always be cases where people will want faster/slower update cycles

[JPLRepo]

11 hours ago, XLjedi said:

@Squad you spend your time adding new Steam integration features while the game is pretty much currently broken.

How do you complete any sort of mission when you have to deal with:

1. Your landing struts explode when they touch the ground
2. Mk3 Cargo Bays destroy deployable equipment on exit only (solar and radiator arrays)
3. And now if you even tab between craft, there's a good chance your main craft will just disappear!!! 

Look at this video; your game is unplayable...

<Snip video>

I mean, I can deal with most of your bugs...  and continue to recommend the game, but are all the other fanboys just OK with this???  I can't play the game and complete missions.  Right now, all you have is a functional sandbox mode to build craft and test fly them.  Anything beyond that is pretty much a waste of time to even bother with.  

 

1) Can you point me at a bug report for that one please in 1.4.4? Thought that had been addressed already.
2) This one has been reported. Know bout this one. (UPDATE) : I tried the supplied craft from the bug report. I can get the rover out without an issue. The problem is the vessel has a wheel base wider than the ramp.. So it bumps and jostles as it exits if going too fast and hits the top and sides and bits break off. If you exit it slowly using the brakes. I can get it out of the ramp quite easily in one piece.
3) Can you point me at a bug report for that one please? I haven't seen that reported.

[Vanamonde]

18 hours ago, Galileo said:

You say this as if the developers aren’t on the forums and reading the assumptions that were out there prior to release. They could have put a lot of rumors to sleep by being more precise about what the mission builder was going to be. They failed the community in that regard.

Would you really want the Squad guys devoting time they could be spending on the game instead going through the forum and correcting all the stuff people erroneously assume? You'd have a far longer wait between updates if they were wasting their time on that Sisyphean chore. 

Could someone please tell me what a "finished" update would be? Until the game has no bugs for any players and all intended features are included, isn't every update going to leave something unfinished? What exactly are you folks expecting an update to do in order to be considered finished? 

[XLjedi]

23 minutes ago, JPLRepo said:

1) Can you point me at a bug report for that one please in 1.4.4? Thought that had been addressed already.
2) This one has been reported. Know bout this one.
3) Can you point me at a bug report for that one please? I haven't seen that reported.

I'll post bug reports for 1 and 3 this weekend and link to them here. 

For item 1, I can post a video example of that one as well, it's 100% reproduceable every time.  Basically, if you dock/undock anything while a strut is in contact with the ground (or at least the KSC facility) the struts instantly explode.  I figured it was tied to the well known exploding strut bug and assumed it was just not fixed yet.

For item 3, I'm just now running into that one so no idea how long it's been around or if it just recently cropped up with the 1.4.4 update?  The 25 second video above pretty much tells the story.  You drive up within maybe 1000-to-1500-ish meters from another craft.  Disembark a rover, tab over to the ship that is further away, and when you tab back, the large craft that undocked the rover has just disappeared.

I know you all are busy and all, but when the only bug report I put up there gets basically ignored for 4 months, with no progress beyond 30%.   I'm not too inclined to waste my time posting more stuff, I think I've mentioned 3 or 4 times that the Mk3 cargo bay is still broken on the bug report as new updates are released and all that's happened is someone recategorized it as a LOW priority.  ...but I'll add two more bug reports for these.

[theJesuit]

1 hour ago, TriggerAu said:

Not every bug that gets worked on is listed in these, and I'd say that ones an oversight as we do have a fix for that yes.

 

On the too fast/too slow patching cycle (hopes he doesn't get flamed for this) we have been pointedly not making changes in revision releases that affect mods (Unity upgrades, method signature changes, etc). This should mean that I compile a 1.4.x release of my mod and its all good and working as LGG mentioned above. That's not a guarantee, but we do aim to not affect mods and call it out in the release notes if there's a change that could have an effect.

I do know there will always be cases where people will want faster/slower update cycles

Totally get it. These was an update once and only once that was a hot fix I think just after 1.0.  I mean I have no idea what caused this bug in the first place and what it takes to correct it, and if you hot fix one I guess people call for blood if they don't get their favourite bug sorted too. 

I for one prefer longer wait for updates ie two months? But with these little CTD or game locks then a much shorter time frame for a subpatch ie 1.4.4.x. It isn't as if you can avoid landing legs for a while... then again I could retrain myself to avoid using the esc button.  That's only IMHO. 

Thanks for the response.  Peace.

[XLjedi]

23 minutes ago, Vanamonde said:

Could someone please tell me what a "finished" update would be? Until the game has no bugs for any players and all intended features are included, isn't every update going to leave something unfinished? What exactly are you folks expecting an update to do in order to be considered finished? 

Agreed, the folks expecting perfection are a tad out of touch with reality...

For me, I'd just be content to be able to play through a complete mission.  Ever since the goofy bouncing landing gear bug showed up in 1.3 (what? 6 to 9 months ago?) I haven't been able to visit or use any moon/planet bases without catastrophic results.  Once the landing gear got fixed (that bug seems fixed) then the issue with Mk3 loading bays cropped up in 1.4.  Now the bases and landed craft maybe don't explode or bounce 20 meters into the air, but I can't deliver rovers to the surface without damaging them.  Ya know, so fine I pulled back on my mission expectations to just do some simple missions on the surface of Kerbin and wait patiently for a fix, and now tabbing between craft is causing them to disappear.  So I can't even do a simple splashdown recovery mission.

I would consider an update finished, if I can safely deliver one rover to the surface of Minmus with a Mk3 spaceplane without damage or the craft disappearing.  Alternatively, I would settle for just taking a rover over to the island base and unloading it without parts falling off and tabbing between craft without them disappearing.

[JPLRepo]

14 minutes ago, XLjedi said:

I'll post bug reports for 1 and 3 this weekend and link to them here. 

For item 1, I can post a video example of that one as well, it's 100% reproduceable every time.  Basically, if you dock/undock anything while a strut is in contact with the ground (or at least the KSC facility) the struts instantly explode.  I figured it was tied to the well known exploding strut bug and assumed it was just not fixed yet.

For item 3, I'm just now running into that one so no idea how long it's been around or if it just recently cropped up with the 1.4.4 update?  The 25 second video above pretty much tells the story.  You drive up within maybe 1000-to-1500-ish meters from another craft.  Disembark a rover, tab over to the ship that is further away, and when you tab back, the large craft that undocked the rover has just disappeared.

I know you all are busy and all, but when the only bug report I put up there gets basically ignored for 4 months, with no progress beyond 30%.   I'm not too inclined to waste my time posting more stuff, I think I've mentioned 3 or 4 times that the Mk3 cargo bay is still broken on the bug report as new updates are released and all that's happened is someone recategorized it as a LOW priority.  ...but I'll add two more bug reports for these.

Thanks.
Devs don't usually look at the public tracker, if they did, they'd never have time to actually do dev work. Rather the QA team triages these bugs and confirms if they are issues etc before they are assigned internally to a queue. It would seem in the case of item 2 - the QA team were having a difficult time identifying that there is any issue at all with the part... and as I had some spare time today (my own time - because it's a weekend - I took a look) and I find no evidence for item 2 that the cargo bay is broken at all.  Works fine for me. I can get parts to break if I have a large rover that barely fits and attempt to exit too quickly causing it to contact the walls and roof of the ramp. If I exit slowly and carefully I can exit just fine. So works as designed.

[XLjedi]

1 minute ago, JPLRepo said:

Thanks.
Devs don't usually look at the public tracker, if they did, they'd never have time to actually do dev work. Rather the QA team triages these bugs and confirms if they are issues etc before they are assigned internally to a queue. It would seem in the case of item 2 - the QA team were having a difficult time identifying that there is any issue at all with the part... and as I had some spare time today (my own time - because it's a weekend - I took a look) and I find no evidence for item 2 that the cargo bay is broken at all.  Works fine for me. I can get parts to break if I have a large rover that barely fits and attempt to exit too quickly causing it to contact the walls and roof of the ramp. If I exit slowly and carefully I can exit just fine. So works as designed.

Try it like this...  don't open the Mk3 cargo bay all the way.  It's the only way to get reasonable sized rovers through the door.  Look at what I do in this simple video.  You can see I pull in the cargo bay with no problems at all.  Then it rolls out slowly and the parts fall off.  This only became a problem with the 1.4 update.

How is this working as designed?  The rover goes in fine every time, then on exit every time, the deployable solar arrays and/or radiators just fall off. It's like a one-way collision mesh that only picks off deployable arrays on exit.

 

[JPLRepo]

2 minutes ago, XLjedi said:

Try it like this...  don't open the Mk3 cargo bay all the way.  It's the only way to get reasonable sized rovers through the door.  Look at what I do in this simple video.  You can see I pull in the cargo bay with no problems at all.  Then it rolls out slowly and the parts fall off.  This only became a problem with the 1.4 update.

How is this working as designed?  The rover goes in fine every time, then on exit every time, the deployable solar arrays and/or radiators just fall off. It's like a one-way collision mesh that only picks off deployable arrays on exit.

<snip>

I have that exact setup as per the bug report. It works fine for me when I roll it out slowly. There is no issue with the colliders on the part at all. The wheels are too wide which causes the rover to jostle to one side or the other and the parts come in contact with the walls/side... regarding the solar panels falling off... they do that when the break force is exceeded.. which is what happens. There is no invisible - wrong collider at all.

[XLjedi]

7 minutes ago, JPLRepo said:

I have that exact setup as per the bug report. It works fine for me when I roll it out slowly. There is no issue with the colliders on the part at all. The wheels are too wide which causes the rover to jostle to one side or the other and the parts come in contact with the walls/side... regarding the solar panels falling off... they do that when the break force is exceeded.. which is what happens. There is no invisible - wrong collider at all.

Well...  it started doing this in 1.4.  It works absolutely fine in my 1.3 install.  There is no jostling to one side in the video above, the rover comes out smooth as glass and the parts fall off.

No matter how slow I try to back out the arrays fall off in 1.4.  I'll test again this weekend on my time as well.  

Edited July 1, 2018 by XLjedi

[Galileo]

5 hours ago, Vanamonde said:

Would you really want the Squad guys devoting time they could be spending on the game instead going through the forum and correcting all the stuff people erroneously assume? You'd have a far longer wait between updates if they were wasting their time on that Sisyphean chore. 

Could someone please tell me what a "finished" update would be? Until the game has no bugs for any players and all intended features are included, isn't every update going to leave something unfinished? What exactly are you folks expecting an update to do in order to be considered finished? 

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? 

Edited July 1, 2018 by Galileo

[steve_v]

On 6/30/2018 at 5:25 PM, 5thHorseman said:

There are almost 400 bugs of the same severity level that are older than it (It's bug 17984). And there are 80 higher level bugs on the tracker, ALL older than it. I know it is your personal most important bug but you're not the only one playing the game with a personal bug that they'd very much prefer was fixed.

Normal is the default priority, no surprise that there are many bugs tagged as such.
Minor graphical glitches and obscure corner-cases get tagged "normal" all the time. Things that have been janky since 0.21 are still tagged "normal".
This is irrelevant, I'm talking about a new regression in 1.4.x, a  problem Squad introduced with the last major update and appear to have no interest in fixing. I'm talking about basic game-engine functionality that is now FUBAR on one of the officially "supported" platforms.

Unlike the vast majority of "older" bugs you mention, this one has multiple confirmations, logs, system information and device tests. It's a perfectly usable bug-report, and everything that has been asked of reporting users has been provided.
It's easily reproducible on any GNU/Linux system, the cause is well known, and open-source code that will solve the problem is readily available. Yet it still sits at "investigating", with no mention of ongoing work or possible solutions and not a word in the weekly dev-notes.


The current development focus appears to be selling DLC and pandering to Windows+Steam users.
Windows users get steam controller support, while Linux users get totally broken controller support. Care to guess why I'm not real excited about these updates?

There is no "prefer". I'm simply not going to support SQUAD in any way, for as long as they are willing to casually shaft linux users. I'll also continue to grouse about it.

Edited July 1, 2018 by steve_v
fscking ridiculous filter.

[theJesuit]

30 minutes ago, 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. 

,<snip> This release schedule is a huge turn off for me and I’m sure I’m not alone with that feeling.

This.  Thanks Galileo!

I've updated my steam install, but really I'm still working off a 1.4.3 backup.  The longest progress I ever made in a save was in 1.3.1.

Peace.

[klgraham1013]

8 hours ago, Vanamonde said:

Would you really want the Squad guys devoting time they could be spending on the game instead going through the forum and correcting all the stuff people erroneously assume? You'd have a far longer wait between updates if they were wasting their time on that Sisyphean chore. 

Could someone please tell me what a "finished" update would be? Until the game has no bugs for any players and all intended features are included, isn't every update going to leave something unfinished? What exactly are you folks expecting an update to do in order to be considered finished? 

How long did it take you to make that post?  Surely you have something in dire need of doing.  How dare you procrastinate on something so important.

Also...they, supposedly, have a community and/or PR manager.

[Just Jim]

56 minutes ago, klgraham1013 said:

How long did it take you to make that post?  Surely you have something in dire need of doing.  How dare you procrastinate on something so important.

Also...they, supposedly, have a community and/or PR manager.

But @Vanamonde is a moderator, not a developer. Watching over the forum community is his job.  

[XLjedi]

@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.

 

 

Edited July 1, 2018 by XLjedi

[Superfluous J]

7 hours ago, steve_v said:

This is irrelevant, I'm talking about a new regression in 1.4.x, a  problem Squad introduced with the last major update and appear to have no interest in fixing. I'm talking about basic game-engine functionality that is now FUBAR on one of the officially "supported" platforms.

I have not followed this bug so the only information I now about is on the bug report, and from reading there it looks like Unity - not Squad - is the cause of the change. It is possible that - other than dropping Unity for another engine which of course isn't going to happen - Squad doesn't have much say in whether or not it works.

I've used Linux. I used it exclusively for years in spite of numerous issues and wrinkles that made my life harder. I've specifically had issues with hardware on it. Not controllers as I don't use controllers on a computer; I've tried that too (in Windows) and had enough problems to not bother anymore. The incessant hardware problems when you step outside the mouse/keyboard box is one of the reasons I don't use Linux anymore. It sucks but it's a fact.

[Gameslinx]

13 hours ago, Vanamonde said:

Could someone please tell me what a "finished" update would be

Alright, so I didn't use the correct term when I said this update is "unfinished", but this update is more "unnecessary" if you want me to put it bluntly. As @Galileo said above, mentioning another update in the patch notes makes this one pretty much pointless. Frankly, I think it's a waste of Squad's time. Why spend so much time releasing an update when there's another one right around the corner when they could use that time to actually fix the bugs that are supposedly "held back to work on them more"?

And I'll say again: Nobody with half a brain is going to bother updating their mods knowing that another update is about to come out. That means the rest of the community is going to have to wait for yet another update before they can actually enjoy their favourite mods again. So because there's word of yet another update, the community is also going to be poorly affected because there will never be any mods to support 1.4.4 (and those people that do support 1.4.4 have probably just wasted their time). And yes, they could "roll back to 1.4.3 to use their mods" but that defeats the purpose of the update in the first place, meaning Squad has wasted even more time.

Another update doesn't automatically mean everything is sunshine and rainbows. I understand the whole "too quick/too slow update cycles" argument, but I see nearly no justification as to why this SPECIFIC update is even necessary!

In short I may be grumpy, but I have my reasons for being so.

Edited July 1, 2018 by Gameslinx

[steve_v]

4 hours ago, 5thHorseman said:

it looks like Unity - not Squad - is the cause of the change.

Squad decided on this Unity version for 1.4.

4 hours ago, 5thHorseman said:

The incessant hardware problems when you step outside the mouse/keyboard box is one of the reasons I don't use Linux anymore. It sucks but it's a fact.

My "outside the box" hardware works perfectly with everything else, on Linux. The only application I have that corroborates your "fact" is KSP, and only since 1.4.
This is not the fault of Linux or SDL, somebody is simply using it wrong.

[Superfluous J]

1 hour ago, steve_v said:

Squad decided on this Unity version for 1.4.

And none of us knows why. However I'm pretty sure breaking Linux controllers isn't the only change. Rolling back to the previous version of Unity for them is like rolling back to the last controller-friendly version of KSP is to you. It fixes this one problem but then you don't get any of the new stuff.

I guess my main problem is that you're assuming they're ignoring you out of spite or disinterest. 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 take bug reports like this at work all the time (not for games, but for a very specific software product that has to work on innumerable hardware configurations and that's as far as I'll explain my job on an online forum) and 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.