GDFireFrog

From the information that we've gathered I think your issue and pogzis' are different issues. Pogzi's issue should have gotten better in 266, and hopefully be completely gone since 268. We are now focusing on your issue now that the other one is out of the way. Could you tell me if you have an AMD card?

We did some fixes last weekend for surround headsets that made it work for some people. Not sure what could be going on with yours or BBQuake's, could you send me your Log.txt file on Discord to see if it's correctly detecting your device as having 8 channels?

We tried to repro this but we are not seeing the same on arena. If this is something that you can reproduce consistently, would you mind DM'ing me in our Discord and I'll send you something to try? UPDATE: Nvm, try 266 and see if that fixes your issue.

Yes, there's something definitely wrong with multi-threaded input.

During the weekend we did a small survey of pros: 2 of them felt multi-threaded input was clearly better, 2 said it felt a bit better, 1 said it feels different but couldn't tell how, 1 said it felt the same. I think this probably means it's working as expected if conditions are right (all of these people have decent setups).

But there is obviously something about it that creates a requirement gate and in some systems it's causing high latency in the input thread. High latency in the input thread would feel really bad so I understand the feedback. I suspect it's going to be something very trivial causing some timer to accumulate excessively. We never caught this during development because we just needed to have the engine exposed to a larger variety of specs. Now we have to do some A/B testing with systems like this and it should be easy to make it work correctly.

So if you have a really not...

This is correct, we'll bring that element back. We need to implement a few features into our UI scripting language to be able to do that again (or redo it completely on the native side, we'll see).

Hijacking this to leave some quick notes, mainly on stability.

• Sorry that some very obvious bugs like that are still there from the last week, we spent most of the week working on a new game mode, implementing voip in our audio engine (we replaced FMOD with our custom audio engine between closed beta and the first stress test weekend, and our voip implementation hadn't been ported to this engine yet) and fixing some game-breaking issues, like lack of feedback in some scenarios. We'll fix this bug as soon as we can.

• 90% of the crashes we are receiving from reports are again on a 3rd party dependency, which during the week got updated to a new version (to get a fix for another issue), so we didn't have time to experience it internally and it surprised us today. I'll do what I can to get them to do a hotfix release before next weekend.

• There's another crash that stands for 5% of reports that usually happens during alt+tabbing that seems...

Make sure you are in v215, fixes the leak. UPDATE: No, you were right, I made a typo before going to sleep and the particles weren't being deleted at all, resulting in tens of thousands of particles being alive by the end of the game, fixed in v217.

EQU8 fixed an issue during the evening that prevented some people from playing. I'm not sure if this is your issue because it manifests in different ways, were you able to play eventually?

So we keep having this issue, we had exactly the same issue in our first closed weekend. It's a leak in Gameface which is the UI engine that we use for the menu, not the in-game hud elements, but not something that we want to blame on them. Gameface is apparently designed to be always running, but we want to keep the game light on the CPU and we don't want the menu taking 100 microseconds just for being there when it's not even being used during the game, so we keep trying to find ways to suspend the menu view completely while in game without having it explode. I thought w...

As you have identified, bots don't collide with props right now. We plan to fix that relatively soon.

The game has been very unstable today. There was one crash that's on us that received three failed fixes through the evening, where I thought I was fixing different things but I was just covering symptoms of a root problem that was finally fixed in v212 or v213. We are not receiving reports of that crash any longer and that has been the most significant one. Unfortunately we are also seeing two crashes of lesser frequency that we cannot address because they are happening on 3rd party dependencies, so unfortunately those have to way until the parties responsible can contact us back and couldn't be fixed today, sorry!

This bug was fixed in v214. We missed this even though it's very obvious because it was the byproduct of last-minute fixes to get rid of some hiccups. Sorry!

This shouldn't be happening anymore. The extreme slowdowns were caused by looking at a volumetric light. We were using old middleware from Nvidia for this as a placeholder, and apparently it doesn't play nice at all with certain GPU's or driver versions. We have taken this out and we will replace this with a custom implementation that won't be anywhere as slow, consisting of either proper volumetric lights or something more efficient and archaic that does the job. The idea was always to replace this as we've done with many other unsuitable dependencies over the years, because it was always quite slow, although this catastrophic level of performance was obviously new to us and we didn't see it in our private testing group. You do report a bunch of things in there, though, and some of these may be different issues that we have yet to identify, though I'm pretty sure most of that can be attributed to this issue.

We'll fix that, as a workaround do: /bind mouse_wheel_up noop

Fixed for v0.19.12.

Here are some brief updates on some ongoing concerns of a more technical nature.

Master server issues

The master server experience will not be terrible going forward. Much of our concern before release was that our dedicated game server component could handle any capacity we wanted to throw at it. This is the executable that actually serves gameplay that we run thousands of instances of globally. Instead, the server component turned out to be very efficient and scale very well, plus the fact that we accidentally over-provisioned servers helped even more with that. With the master server on the other hand we have been struggling from the start, the main problem being one of those silly programming things that are hard to see. Between weekend two and three we did a massive refactoring to simplify things and see things clearly. This caused some crashes initially because sometimes getting rid of leaks exposes issues that were previously hidden. We do ha...

Context and TL;DR

A thread was started in this subreddit that started a bit of a scare regarding our announced anti-cheat solution EQU8, which is a new solution made by Swedish startup Int3 Software. The main reasons why we chose EQU8 were that we experienced a high level of engagement and support, they were very receptive to our suggestions and their product doesn’t suffer from excessive loading times, unlike the only other solution that fit our requirements. In the thread it was claimed that EQU8 is excessively intrusive and some people were uncomfortable with a new product. We made as thorough an investigation into the claims as we possibly could with our limited time and resources, and we have resolved those concerns to our satisfaction. We found both the EQU8 product and their company to be as privacy-mindful as they could be given their product’s function. In this thread we will go through our findings and other background information.

...

Ah, I see what you mean now. You won't be able to play until you turn it back on, just like Apex.

I talked to EQU8 who were kind enough to help me on a Saturday and asked them about the issues raised in this post and yesterday’s one.

Will the driver collect data (such as keystrokes when game window is not in focus, memory contents of other processes or of the kernel, files on the disk etc.) and if so what does it do with it? Does it anonymize and encrypt personal data before sending it over the network?

About what exactly is read I’ve asked for a full list and they will get back to me on Monday (but they confirmed no keystrokes of unfocused windows). No personal data is transmitted. An exception would be filenames. If you named your cheat “tekn0z_wallhack.dll”, they would see that string. Even the username in a path would be stripped, so “C:\Users\Tekn0z\aimbot.dll” would become “5\aimbot.dll”. All communication is encrypted. Also, EQU8 is a Swedish company and subject to all EU data protection legislation. We inquired about privacy be...

We’ll be showing Equ8 all of this stuff as we have in the past when somebody brings something like this to our attention. I will update this post with what I learn. We will obviously drop Equ8 if it’s not up to the task. False positives are obviously concerning. The level of inspection that you mention, although not great, it seems to me like it could be the same in all other anticheat solutions with any degree of effectiveness, but I don’t want to speculate and we’ll look into that too. Feel free to correct me if you have inspected different anticheats and have more information in the privacy area. TL;DR: We are gonna look into this and change anticheat vendor if necessary.

I’ll share the full rationale for going with Equ8 at the risk of being a bit too open. With the technical information I extracted from the vendors we talked to, I expect it to be a bit lighter on performance than other competitors and just as good in terms of detection. This is just an educated guess, b...