GDFireFrog

A fix for this will be released soon, hopefully before the weekend.

When testing the 20 shotgun rays, after one would hit the rest would also count as hitting due to a dirty state programming error. Centre pellet goes first (they spiral out) hence the snipper shotgun effect where if you land the centre ray you get max damage. The issue has been there for months. Because of unrelated changes yesterday it surfaced arbitrarily (things shifting around in the assembly make these issues come up) which is why we didn't notice it in testing, we weren't expecting any change in hit registration.

Sorry about that. After the update servers were having this issue for about an hour. It should be fixed now, no need to update, any game starting from this point onwards should be completely updated.

Not sure if this is what's going on here but sometimes it happens that we get someone with terrible fps in DBT but not in other games because they are overclocking too much or have a faulty GPU/setup that either has bad thermals or it's breaking down. They do not notice anything until they play DBT (or any modern game that is GPU-bottlenecked, which would give the same results). The games that you mention may be CPU bottlenecked for you, some because their CPU part is heavy and the older ones because their GPU workload runs so fast that the CPU side becomes the bottleneck by default.

I would suggest you run a pure GPU benchmark of your choice and I suspect you will get a terrible score which will point to some hardware issue.

If that isn't the case feel free to DM me in Discord, I'm in our official server, and we can look into your case.

No, this was a very noticeable bug as seen here for example: https://clips.twitch.tv/PunchySuccessfulCrocodileOSsloth

We tried a HRTF implementation back in the day, Phonon by Valve's, but we didn't quite like what it did to the timbre of the sounds. We plan to test different implementations in the future as we have more options now. This would be an option that people can choose. I don't think it would be a default as some people may not think that's worth the latency increase (which I assume would be there, I'm purely speculating with regards to the latency thing just from my understanding of how HRTF works, which may be wrong, and I've never measured this back in the day).

Regarding the thread, we are aware the sounds need improvement, we have a few open threads of development at the moment with audio. For example, we should have a specific fix in our environment intersection query system for a bug that is probably affecting vertical localization (I just haven't had time to confirm yet 100% but it matches some issues that people are reporting).

Besides that we'll probably be re-...

I wrote a bit in here about priorities and patch notes and I think it's worth bringing up: https://www.reddit.com/r/Diabotical/comments/izvoxm/patch_notes_version_020358_september_25_2020/g6lwqvy/

An important thing to emphasize is that you are not seeing just the result of a day's work on a day's patch. We are still working on important things on the background and they are released (hopefully) when they are ready. This one optimization thing took a month of changes and testing here and there...

369e indeed :)

Good now since 396e I hope?

We are going to explain this in the next patch notes, but there were temporary (massive) leaks due to a bug in Gameface (menu UI engine), we tracked them down to the video vignettes that we have in the interface, which is why they are disabled now since 369e*. So things should be back to normal.

Ah no, in that case I don't think it's a scaling issue. I think the texture is just a bit too low-res and it may even be a bit more noticeable for you because you play at x2160. We can increase them two-fold.

If you play with the texture quality setting to low, that halves the resolution of every texture, and this includes these icons used in UI elements like this too. Do you use this setting?

This is unexpected. PNCR settings would be clean because it's a new slot and you'll have to fill them in, but Crossbow ones should have remained as they were. Are you sure this was not the case?

Let's fix the waypoints' size. IMO their size should not change depending on the distance. Sometimes they are huge, sometimes they are really tiny and barely noticeable.

We plan to add some more options for this. But there is also an issue with the waypoints for pings, they don't scale in the same way the other waypoints do, we'll fix this in the next patch.

Let's fix the image quality of waypoints. It seems that you use bitmaps rather than vectors or there is something wrong with scaling because they are not always sharp, especially when resolution scaling is enabled.

Vectors are still going to look very similar if you play with resolution downscaling as long as they are rendered at the downscaled resolution. We need to render those elements in native resolution. I'm not even sure why it's not that way at the moment, it may have regressed by accident at some point and I didn't notice. We'll try to fix th...

Sorry we actually made this issue way more frequent for a brief period of time this morning. It should be fixed now.

Pushed a tentative actual fix for this at 13:40 CEST to all servers. I'll update if we can confirm the issue is gone.

UPDATE: Seems to be fixed now, sorry about that, we were trying to fix a fairly rare issue that only happened in a very few instances and we made it way more frequent.

UPDATE2: Minor version 366d which is going out now brings the same fix that's live on our servers to LAN.

If you DM me on discord I can send you some things for diagnostics and look into it.

Really sorry about that. That's a crash on a 3rd party dependency, the HTML UI engine we use to render the menu screens. We sent them info about the crash and they fixed it, but the version in which it's fixed introduced a performance regression that prevents us from updating. We are looking into it with them. We'll fix this as soon as we can, it's a top priority. (We also have long term plans to reduce our exposure to this sort of thing.)

In general, if we expect things to work we won't get into much detail intentionally. If we are transparent about things (explaining just in case we have created this expectation), it's usually in the context of explaining what we are doing about an issue for the sake of productive communication with the community or to give some technical context on things so that the feedback that we get on a particular area is more focused. Ideally things just work so that people don't even need to discuss it. There're reasons for this discretion that involve often-unfounded anticheat fears, competitive-edge protection, not giving fodder to patent trolls, time constraints, embarrassment because an issue was too dumb, a desire for conciseness to not waste people's time or a general sense of modesty. Also netcode may be the kind of thing where you don't want to explain too much or people start reporting ghosts because you colour their experience introducing concepts for which the scope can't be com...

We date them to American time for very silly reasons. This started happening because we would write patch notes during the evening, then there would be delays due to some last minute issue and it ended up bleeding into the next date. Now we intentionally date them to American time. This works better with the work schedule of the core technical development team where we release around midnight, sometimes before, most of the times much later. (Our messed up schedules are also convenient right now as it means that we can reach our American partners any time, so we don't have much incentive to fix them though we'll try to do that in the future). That way we get patches for days 11th, 12th, 13th, 14th that each correspond to a day of work instead of something like 11th, 11th, 13th, 13th. The neater dates make more sense in retrospect, and personally I'd like to be able to look back and see that we have released a substantial patch every day for however long and at least the date makes s...