Bug Status [10/4]

[chefsbrian]

1 minute ago, Kerbart said:

Well you have to contact the lead on each bug and get an update. I'm not a professional software engineer and I'd think they'd have a "bug list" with the status that gets updated on a daily basis, but what do I know.

Speaking as a professional software engineer, If I'm busy chasing bugs down the last thing I want to do is write a daily status update that amounts to saying "I have no idea whats going on" - even if its accurate, fair, and everyone knows to expect 90% of it to be that, we don't want to say it because it makes us feel like we're bad at our jobs.

As a result, you usually have to actively pursue us to get updates that aren't 'positive'. Especially when we feel like the solution should be right around the corner, and if I spend just five more minutes maybe I'll find the real answers.

[Pyritin]

2 hours ago, chefsbrian said:

Speaking as a professional software engineer, If I'm busy chasing bugs down the last thing I want to do is write a daily status update that amounts to saying "I have no idea whats going on" - even if its accurate, fair, and everyone knows to expect 90% of it to be that, we don't want to say it because it makes us feel like we're bad at our jobs.

Yeah, but if you have proper internal tools to track down tasks assigned to you, it'd be fairly easy to set the status of said goal to "Investigating" then put what ever information you wanted to in it. As long as you do it at least once in a bi-weekly time period you have now fulfilled the bare minimum obligation of what we see on the KERB report.

[gluckez]

4 minutes ago, Pyritin said:

Yeah, but if you have proper internal tools to track down tasks assigned to you, it'd be fairly easy to set the status of said goal to "Investigating" then put what ever information you wanted to in it. As long as you do it at least once in a bi-weekly time period you have now fulfilled the bare minimum obligation of what we see on the KERB report.

That's not how that works. Daily scrums are something that every dev team does these days, and when the entire team sees that you've been investigating that same item for weeks or even months, they'll ask questions. eventually, you'll be held accountable for "just putting whatever information you want in it". Daily scrums exist exactly for that kind of situation, to unblock someone as fast as possible. so there's no doubt that multiple people are working together on solving the same issue if it's been open for so long.

[chefsbrian]

5 minutes ago, Pyritin said:

Yeah, but if you have proper internal tools to track down tasks assigned to you, it'd be fairly easy to set the status of said goal to "Investigating" then put what ever information you wanted to in it. As long as you do it at least once in a bi-weekly time period you have now fulfilled the bare minimum obligation of what we see on the KERB report.

You'd really think that, but then that requires me to stop pulling my hair out over why this isn't working for five minutes to actually provide a meaningful status update of any sort. Trust me, its like herding cats in software development. When it comes to bug fixing, anything more substantial than knowing who's working on what at a given time is usually pulling teeth, because I can't effectively explain what I don't understand, and if I understood it I'd have already fixed it.

[Kerbart]

2 hours ago, chefsbrian said:

Speaking as a professional software engineer, If I'm busy chasing bugs down the last thing I want to do is write a daily status update that amounts to saying "I have no idea whats going on" - even if its accurate, fair, and everyone knows to expect 90% of it to be that, we don't want to say it because it makes us feel like we're bad at our jobs.

As a result, you usually have to actively pursue us to get updates that aren't 'positive'. Especially when we feel like the solution should be right around the corner, and if I spend just five more minutes maybe I'll find the real answers.

Plot twist: you know your stakeholders want a regular update on the bug status. Is it that hard to have a central document that gets updated as work on the bug progresses? It doesn't even have to be daily, just update the status as appropriate. "Investigating," "Replicating succesfully," "Root cause analysis," "Considering Solution," "Testing Solution," "Sent to QA for final testing" something along those lines?

They know there's a boat load of bugs. They know it's the biggest pain point of the product right now. They know that fixing the bugs is under the magnifying glass of their customers. They know those customers want to get an update on the progress of fixing those bugs. So why the surprised Pikachu face when it's time to actually publish the status update?

[chefsbrian]

Just now, Kerbart said:

Is it that hard to have a central document that gets updated as work on the bug progresses? It doesn't even have to be daily, just update the status as appropriate. "Investigating," "Replicating succesfully," "Root cause analysis," "Considering Solution," "Testing Solution," "Sent to QA for final testing" something along those lines?

Yes, because I can tell you this right now, as I'm currently lurking in a meeting about exactly this in my dayjob, that if you have a "General" status report your customers will immediately come down the pipe and ask for explanations on what this means, in detail, because most people do not understand how this stuff works - especially with external customers. People want details, because details are to them understanding and the opportunity to try and 'help', as useless as it tends to be in bugfixing.

And thats not to mention how you can, at no fault of anyone involved, regress from any of the above states immediately back to 'Investigating' because bugfixing is not a checklist, it is a nightmare morass of discovering the guts of your software don't behave right. You can easily make it almost to the end run and think you fixed it until you discover at the last moment there's multiple parallel ways for an issue to trigger, occur, and progress, and you just spend the last weeks having only discovered and iterated on one of them.

[regex]

1 hour ago, chefsbrian said:

And thats not to mention how you can, at no fault of anyone involved, regress from any of the above states immediately back to 'Investigating' because bugfixing is not a checklist, it is a nightmare morass of discovering the guts of your software don't behave right. You can easily make it almost to the end run and think you fixed it until you discover at the last moment there's multiple parallel ways for an issue to trigger, occur, and progress, and you just spend the last weeks having only discovered and iterated on one of them.

This person knows. Bug-fixing can be a very simple affair or an incredibly detailed deep dive into weird logic for days that gets derailed every time someone takes you out of your concentration. And that simple fix can be a new multi-line method which requires a couple days refactoring while the days-long deep dive requires a one-line fix. I've seen both and everything in-between. The status update on the simple but tedious fix will be very clear ("Implementing fix, should be out with the next update") while that deep dive one-liner remains "investigating" until it suddenly shows up in the next patch notes without warning.

[Pyritin]

I understand how the development process works and agree in part with what @chefsbrian and @regex are stating about dev's not wanting to get interrupted and end users potentially not understanding information given. It'd make even more sense if KERB was done by the development team directly, but it isn't. It's handled by the CM team who massages some of the details to hopefully eliminate some of the points you two bring up. If no progress has been made fine, some stuff does take time but not sure how any of that affects the ability to simply hit send on the report and provide it in a timely manner.  Even if information couldn't be gathered by the developer to change a "Investigating" flag to a more detailed item, it's still entirely possible to leave the flag as is and publish the report accurately stating it as the most up-to-depth information they have for us at the time..

My complaints aren't so much about the content of the report. My complaint is the fact they can't even perform THIS commitment on time... IG made a commitment to getting the report out at a scheduled interval that THEY came up with, and once again missed the mark... This point it's pretty clear the IG policy is overpromise and underdeliver and it's frankly gotten old...

[chefsbrian]

26 minutes ago, Pyritin said:

My complaints aren't so much about the content of the report. My complaint is the fact they can't even perform THIS commitment on time... IG made a commitment to getting the report out at a scheduled interval that THEY came up with, and once again missed the mark... This point it's pretty clear the IG policy is overpromise and underdeliver and it's frankly gotten old...

I'm somewhat in agreement here - The commitment not being met sucks. But I think its because they chose a really, really bad metric to try and report on. Very few games use their bug log as their major development communications for a reason. Most games do some regularly scheduled feature blog, or developer touchpoint or design talk. But Intercept is extremely reluctant to talk about that due to prior delivery promises slipping, and the longer they go without talking about them, the worse the potential response gets. After all, if they come talking now about the absolute barebone basic design principles of science, people will assume that they're only now just nailing them down. And god forbid if they're playtesting and find out something they designed isn't fun and needs rework (this is a common occurance) and the community gets it in their heads that they're incompetent at gameplay design.

I've mentioned before how the relationship has gotten adversarial. Every communication is carefully crafted, curated, and reviewed because they're frankly afraid of making it worse by saying something wrong, and a lot of us are seeking blood in the water - we're mad, some of us probably excessively so, and we're looking for justifications for that anger. We're well past the point that we could get a post from a science guy talking about this cool part he's messing with, because next week it'll be scrapped cuz it wasn't fun to design missions around, and the community will riot.

They chose bug fixes to report on because nobody can get mad at a bugfix, and then I'm guessing the delivery keeps slipping because they're holding out for every last possible little fix - it may be seen as preferable to delay an update so that the update has at least one changed status, over posting an update early that just shows nothing moving 'cross the board.

[Alexoff]

To explain the difficulty of fixing bugs, developers could show with a specific example what was done wrong, what difficulties there were and how to get out of them. Since the focus of game development has moved from showing screenshots of new features to fixing bugs, why not expand on this topic?

[NoMrBond]

Is part of the plan with the switch up to Unity 2022LTS being able to use DOTS (considered 'production ready' in said 2022LTS) for parallelization/threading these sorts of background (out of focus) processing elements?

[chefsbrian]

43 minutes ago, NoMrBond said:

Is part of the plan with the switch up to Unity 2022LTS being able to use DOTS (considered 'production ready' in said 2022LTS) for parallelization/threading these sorts of background (out of focus) processing elements?

Extremely unlikely. DOTS isn't really something you 'turn on', its a series of tools that you use ground up to solve certain problems that engines might otherwise struggle with. Any of the problems that they have had that also could be solved by use of the DOTS tools, is something that I really hope they've already solved themselves, like better multithreading for background processing. I guess they could maybe try using the burst compiler, but its optimized to work side by side with the Jobs system, not whatever homebrew threading they're running. Might help, probably won't, doubt its worth the time to explore it so late in development.

DOTS is one of those things you start using at the beginning of a project, because its so foundational.

3 hours ago, Alexoff said:

To explain the difficulty of fixing bugs, developers could show with a specific example what was done wrong, what difficulties there were and how to get out of them. Since the focus of game development has moved from showing screenshots of new features to fixing bugs, why not expand on this topic?

They could, but I'm not sure it'd help. Most bugs are, frankly, simple solutions while the problem is often just a simple human mistake or assumption. The difficulty is really in finding and often reproducing them. Trying to describe why this is difficult to someone who has never programmed, never tried to debug decoupled code, is like trying to explain why space travel is difficult to someone who doesn't know how orbits work. To them, you just turn your engine on and point at the target. To us, we're figuring out launch windows and phasing orbits, which mean nothing to that person without explaining the foundational reasons for it.

[Alexoff]

48 minutes ago, chefsbrian said:

They could, but I'm not sure it'd help. Most bugs are, frankly, simple solutions while the problem is often just a simple human mistake or assumption. The difficulty is really in finding and often reproducing them. Trying to describe why this is difficult to someone who has never programmed, never tried to debug decoupled code, is like trying to explain why space travel is difficult to someone who doesn't know how orbits work. To them, you just turn your engine on and point at the target. To us, we're figuring out launch windows and phasing orbits, which mean nothing to that person without explaining the foundational reasons for it.

Since the release, about half a thousand bugs have been fixed (and how many are left?), some of them probably have an interesting story to tell

[Scarecrow71]

On 10/4/2023 at 8:16 PM, Superfluous J said:

I don't see how, once you have regular interplanetary deliveries being made.

Maybe it could be estimated but then there will be an entire metagame for tricking the estimation calculations.

I guess my point here was that there calculations being done on objects that are nowhere near the current SOI, and maybe it's possible that those calculations don't need to be done.  I get the interplanetary deliveries and colonies and, at some point in the future, interstellar flights, and there are pieces and parts all over the place.  But do we need to do the calculations on all of them all the time?  Is there any way to narrow this down to the current SOI, or even a grouping of SOI's, so that we don't have these major system resource limitations?

I'm just spit-balling here.  I may be a developer IRL for my day job, but not to the capacity of the devs of this game.  So I'm just throwing out stuff that comes into my mind whether or not it is sound logically. 

[Stewcooker]

So, wobbly fix is sometime after 1.5.0, and science is sometime after that? Just making sure I read that properly. 

If that's indeed the case....science next summer sometime?

[chefsbrian]

1 hour ago, Scarecrow71 said:

I'm just spit-balling here.  I may be a developer IRL for my day job, but not to the capacity of the devs of this game.  So I'm just throwing out stuff that comes into my mind whether or not it is sound logically. 

Nothing wrong with that, we're all spitballin' since we don't really have a full architecture doc for how it all should work.

But on paper, it really shouldn't be this bad. Objects not under active acceleration can be packed up and put on rails with a static orbit until they reach a SOI intersection, assuming their orbit is capable of one. The entire physics load of it should be nil, with the actual compute overhead coming from deriving where it should be right now for display on the map. In practice, there's some overhead for checking those SOI transitions and probably a few other things, but nothing that should be making a performance impact without hitting absurd levels of independent tracked objects. Objects under active acceleration are a bit more complex in that your constantly adjusting that orbit, but unless they're unpacking and loading the full physics of the object to allow for bad designs to fail to go in the direction you wanted them to go (Spin out, etc), its a fairly constant overhead to deal with.

The other half of the packed objects is calculating the whole resource flow for them. This is the one that could get exponentially bad if its not designed cleverly, but also has very flexible granularity - you could check every second, but in reality you can likely get away with most resource flows operating on a courser timescale - doing something less often is one of the easiest ways to make it more performant . However, right now, we're not equipped with the tools as players to really stress this part. All we really have for passives is fuel and electricity, so unless you've got a fleet of ion probes at full burn in the background, neither should have any appreciable impact.

If I were to speculate, orbital decay and these performance bugs may be hand in hand - if ships are holding onto phantom forces, however trivially small they are, then the on-rails system is going to be doing constant trajectory updates for what it thinks are vessels under acceleration. So instead of going hands off, the systems treating everything as close to live as it can be. Its also possible the resource system is dealing with ghosts - If it has an outflow, and the outflow goes to 0 resources out but never actually gets removed, and then another outflow is added later, they might stack up and add up. Its easy to forget to deregister things, and while a check that ends up doing nothing is fairly cheap, having a lot of them can get expensive fast. And its easy to assume that resources will just be responsible for their own mess, because the alternative is trying to second guess every calculation, which is worse.

[Superfluous J]

17 hours ago, Stewcooker said:

So, wobbly fix is sometime after 1.5.0, and science is sometime after that? Just making sure I read that properly. 

If that's indeed the case....science next summer sometime?

Your first paragraph is correct to my knowledge.

Your second one is conjecture and therefore neither true nor false.

Edited October 7, 2023 by Superfluous J

[Alexoff]

Science in the summer sounds like a good horror movie. If the science does not appear before February, then it seems to me that it is better not to release it at all.

[NoMrBond]

On 10/6/2023 at 12:12 PM, chefsbrian said:

doubt its worth the time to explore it so late in development.

I don't know, they've already talked about switching from their own legacy multi camera custom render pipeline to HDRP, and from PQS to CBT, which both sound pretty in-depth as to game systems they'll touch

For all we know it was already in the plan to use it for colonies and the like, which exist, but we haven't seen any of yet

Or maybe they're just updating from 2020LTS to 2022LTS because the '20 is falling out of support, I was hoping they'd be planning on using some of the new features and capabilities which were coming along with the engine update

[chefsbrian]

On 10/6/2023 at 7:11 PM, NoMrBond said:

Or maybe they're just updating from 2020LTS to 2022LTS because the '20 is falling out of support, I was hoping they'd be planning on using some of the new features and capabilities which were coming along with the engine update

The most likely reason is that, unless they've got a special contract, you need to be on 2021LTS for console development and come April that requirement is going to jump to 2022LTS assuming that 2023LTS launches in that time window. This isn't a Unity requirement specifically, this is part of the requirements and contract with Microsoft and Sony to get access to their SDK's.

[Quasar2007]

I think that I have found a new bug.

 

When I was in orbit of Kerbin, I wanted to switch to the celestial camera, but the game refused to, it switched between the views, but it stayed the same, the planet kept being underneath me. 

 

Is anyone else experiencing these issues?

[The Aziz]

Search for it in bug reports. If it ain't there, report it.

[Quasar2007]

Thanks for responding The Aziz, it's not in the bug reports.

 

Could you please tell me where to report it? I am new here :D.

[James Kerman]

Welcome to the forum @Quasar2007, please use this page to create a bug report:
https://forum.kerbalspaceprogram.com/forms/2-ksp2br/

[Quasar2007]

Thanks, ok I will report it. Hope it improves the game