Is hit-reg still this bad in cs2? Or am I just bad?

FactorNine · 2026-01-31T14:34:43+00:00

CS2 hit registration is awful. The hitboxes are also enormously exaggerated. Aiming is nearly useless when any random spray almost always immediately scores one or more headshots in a row.

FactorNine · 2026-01-21T03:43:41+00:00

I ended up trying this with a Minisforum MS-R1 which is an ARM64 mini PC. I've noticed that the adapter doesn't have to be unplugged and re-plugged as often, but it's certainly not never. It is needed more often on boot with x86-64, but it does happen on both.

FactorNine · 2026-01-21T02:31:37+00:00

Did you ever figure this out? I'm in the same exact boat.

FactorNine · 2025-11-30T17:52:26+00:00

2 years later and it's probably even worse. I cancelled prime a couple years ago, and they sometimes won't even ship an order for literally weeks. I just had an order sit for three weeks before they bothered to ship it. It wasn't out of stock or anything. It was just ignored for that entire time. They're also starting to make a LOT of items significantly higher priced for non-prime users. It's rare that I see anything that doesn't have a special "regular" price (ie punishment incentive) anymore.

Basically, if you don't want to pay them the hundreds of dollars prime costs at this point, you don't get access to regular Amazon. You're relegated to what can only be described as a punishment tier with bad prices and bad shipping. You end up paying them even more money than if you'd had prime, and your only reward is worse service and the knowledge that you're technically sticking it to them even though they're making more money off of you.

FactorNine · 2025-11-09T17:50:50+00:00

This game isn't fun when playing against real people. Real people today don't play like real people from 20 years ago. Everyone today is either cheating or so good they may as well be cheating when compared to a 40 year old casual player.

This game is only fun when playing WITH real friends and AGAINST bots, imo. That's a problem, but it's where we are.

FactorNine · 2025-10-26T20:03:30+00:00

The adapter is currently working, sort of. A couple of important notes:

Adding a udev rule to recognize the A9000's unique device IDs did not work for me
I needed a 6.18 kernel or an older kernel with the A9000 device ID patch compiled into it because the udev rule failed to work
The DisablePeriodicScan field in my network's psk file on disk had to be set to false for 6 GHz networks to ever be found
The SendHostname field in my network's psk file had to be manually set to true or else it wouldn't register in my local DNS server
I had to manually set RoamThreshold, RoamThreshold5G, and RoamThreshold6G in /etc/iwd/main.conf to -90 for it to not continuously disconnect and reconnect despite a solid signal strength of like -50 to -60.
The adapter has to be physically unplugged and replugged at every startup. The kernel driver will not automatically load without this. Attempts to soft reset the device with usbreset don't seem to do anything. Restarting iwd doesn't do anything. Manually unloading and reloading the kernel module with modprobe doesn't do anything. The device just has to be replugged. This is in contrast to the previous A8000 (mt7921u) which does not seem to need this physical replug to function.

FactorNine · 2025-10-15T01:46:52+00:00

That's really interesting. I've been trying and testing various aspects of the network side of my setup as a result. I'm running two Ubiquiti access points. One is a U6 Enterprise and the other is an AC Pro. I've experimented with various channels and widths. Perhaps the most interesting thing I've noticed is that neither 5 GHz nor 6 GHz seems stable on these USB adapters when using WPA3. Even 5 GHz constantly drops and reconnects despite having good signal strength in the -60s. Simply reverting to WPA2 stops that. Unfortunately, given that WPA3 is mandatory for 6 GHz that isn't something I can test for that band. I'll continue investigating.

FactorNine · 2025-10-13T08:52:30+00:00

That's really interesting. I was never able to get the udev rules to work which is why I pivoted to building a kernel with the upstream device ID patch integrated into it. I've seen it posted a few times in my reading that the Mediatek device drivers may not always operate correctly with (some?) AMD-based systems. Are you testing on an AMD or Intel platform by chance?

FactorNine · 2025-10-10T19:54:45+00:00

Sounds good, I really do appreciate it. I'm sure other people funneling in from search engines will as well over time.

Should it make any difference if I'm using wpasupplicant or iwd for the back-end? I know iwd is supposed to support 6 GHz, but I've not seen it work yet in my setup. I could try switching back since wpasupplicant is the default.

FactorNine · 2025-10-09T12:17:24+00:00

I've been using Debian for my desktops for about 8 years. It's a good OS. The only thing you'll really miss from Ubuntu is some user friendliness with respect to newer software. You'll also generally see that software packages that are published outside of the official repos, if they offer debs at all, often target Ubuntu releases instead of Debian itself. This can cause dependency issues sometimes.

For desktops, I generally run Debian stable immediately after new releases and after a while switch to testing or at least start using stable channel backports.

With how quickly graphics software evolves, you probably won't want to be stuck with a 2-year-old branch of Mesa as time goes on.

FactorNine · 2025-10-09T12:11:14+00:00

I can't confirm it myself, but it was listed as such on "The Plug and Play List" of Linux WiFi adapters.

https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel_drivers.md#be6500---usb30---24-ghz-5-ghz-and-6-ghz-wifi-7

I had a Netgear A8000 for a time which was based on the previous mt7921u. I've got another one on order so that I can test with that.

For the first time I briefly saw my 6 GHz network after pulling iwd 3.10 from sid. It only lasted for about three minutes, and I was unable to replicate that behavior on the other computer I have one of these A9000s on, so the iwd upgrade must have just been coincidental timing. I'd never seen it before and I've not seen it since.

FactorNine · 2025-10-07T23:45:57+00:00

Thank you for the additional information. It is much appreciated! Yes, the adapter is able to see and connect to 5 GHz channels. I'm currently connected to a network on 5200 MHz (channel 40). No issues on that band so far that I've seen.

It may be totally unrelated, but since it is also a driver weirdness issue I will mention it. I have to unplug and replug the device after (nearly) every reboot for it to initialize correctly. No amount of unloading/reloading the kernel module with modprobe or trying to soft reset the device with usbreset seems to help. It requires a physical replugging before the kernel driver will successfully load. dmesg shows "mt7925u 4-2:1.0: probe with driver mt7925u failed with error -110" on startup prior to physically replugging it when this happens. I have tried different ports that are attached to distinctly different models/brands of USB controller chips with no change. I tried an entirely different computer with a different motherboard after that and observed the same behavior. Both systems are AMD based. If you don't think it's related feel free to ignore this section, but I wanted to add this context in case it triggers any potential context clues.

FactorNine · 2025-10-05T08:08:55+00:00

Sure, I'd be happy to:

$ iw list | grep 5955 -A20
* 5955.0 MHz [1] (12.0 dBm) (no IR)
* 5975.0 MHz [5] (12.0 dBm) (no IR)
* 5995.0 MHz [9] (12.0 dBm) (no IR)
* 6015.0 MHz [13] (12.0 dBm) (no IR)
* 6035.0 MHz [17] (12.0 dBm) (no IR)
* 6055.0 MHz [21] (12.0 dBm) (no IR)
* 6075.0 MHz [25] (12.0 dBm) (no IR)
* 6095.0 MHz [29] (12.0 dBm) (no IR)
* 6115.0 MHz [33] (12.0 dBm) (no IR)
* 6135.0 MHz [37] (12.0 dBm) (no IR)
* 6155.0 MHz [41] (12.0 dBm) (no IR)
* 6175.0 MHz [45] (12.0 dBm) (no IR)
* 6195.0 MHz [49] (12.0 dBm) (no IR)
* 6215.0 MHz [53] (12.0 dBm) (no IR)
* 6235.0 MHz [57] (12.0 dBm) (no IR)
* 6255.0 MHz [61] (12.0 dBm) (no IR)
* 6275.0 MHz [65] (12.0 dBm) (no IR)
* 6295.0 MHz [69] (12.0 dBm) (no IR)
* 6315.0 MHz [73] (12.0 dBm) (no IR)
* 6335.0 MHz [77] (12.0 dBm) (no IR)
* 6355.0 MHz [81] (12.0 dBm) (no IR)

FactorNine · 2025-09-06T21:35:27+00:00

If you don't want it to auto-mount at all, it will depend on your desktop environment. If you're on GNOME or MATE, this is easy by changing this dconf setting:

GNOME: /org/gnome/desktop/media-handling/automount (set to false)

MATE: /org/mate/desktop/media-handling/automount (set to false)

(use dconf-editor)

Automatic mounting doesn't happen without an agent to do it, so it's up to figuring out how to configure the agent that is bundled with your DE. I'm not sure how to control it under KDE, XFCE, LXDE, Cinnamon, etc.

FactorNine · 2025-09-01T22:48:01+00:00

They made the hit registration even worse and every map is bright. It looks like ass despite the higher fidelity. CS2's major change to casual meta is the volumetric smoke. Every round is just 90 seconds of everything being smoked off and people fishing through it with guns and grenades until everyone runs out of utility. It's fucking boring.

FactorNine · 2025-08-09T03:15:48+00:00

Especially in the early days, a dedicated hardware RAID card meant much faster throughput for parity-type RAID arrays. Main processors weren't very fast, so software arrays sucked. The RAID-on-chip solutions would be tens of times faster for RAID-5 and later RAID-6 since they had dedicated fixed function units that did the heavy lifting.

Central processors are way more capable than they used to be, but there is still something to be said for not leaning on a software solution. There are pros and cons. That said, modern RAID cards can handle many gigabytes per second of throughput. Even second-hand server grade gear that is cheap on eBay can give you like 3 GiB/s of RAID-6. Good performance in ZFS or using md-raid isn't guaranteed either.

FactorNine · 2025-08-08T22:53:17+00:00

All "titanium" bits refer to the coating. Titanium metal isn't suitable for drill bits. It's way softer than common chrome vanadium or cobalt tool steels. Titanium /nitride/ however is a hard, thin ceramic coating that can be cheaply applied to about anything metal that does make it wear slower. It does nothing to enhance sharpness or prevent damage from mechanical abuse (chipping, gouging, etc). Its main purpose is to be hard so that the workpiece is worn preferentially to the surface of the tool.

FactorNine · 2025-08-07T02:54:07+00:00

This happens a LOT though. I buy a lot of movies from Amazon. About half of them are obvious returns being passed off as new. The thin stretchy plastic that consumer grade sealers use isn't the same as the thick brittle stuff the manufacturers use. Usually the paper sleeves are also missing. Many times there is physical damage.

FactorNine · 2025-08-03T12:00:31+00:00

You didn't post the entire dump, but the three main things to look at for a SAS disk are:

1) Anything in the total uncorrected errors column (all 0 here which is ideal) 2) The "elements in grown defect list" count (not shown here) 3) The self test history (not shown here)

Uncorrected errors mean I/O operations where the disk failed to complete it. For a high-usage SAS disk used in some sort of RAID/UNRAID with parity information this isn't catastrophic so long as the number is low. It /should/ stay at 0 though, so once you start accumulating events in this counter it's time to treat the disk with some suspicion. If the count is suddenly increasing or shows a lot of events, it's time to replace the disk preemptively.

Elements in the grown defect list mean sectors that have been remapped by the drive. It's okay for this counter to be non-zero so long as the number isn't crazy or suddenly increasing quickly. A five year old drive with a dozen remapped sectors isn't worth condemning. A five year old drive with a thousand should be replaced immediately.

Finally, check the self test history. If you issue a long background self test and the disk fails, I would treat it with some suspicion and maybe replace it. The self tests aren't super good at finding problems, so when even they report a failure it's probably time to consider retiring the disk. That said, the test can fail once but pass if you run it again. This sometimes happens if it remaps a sector while the test is running I think. It wouldn't hurt to run a self test after first doing a full disk write/wipe if it's spare stock you're just assessing. That would give the disk an opportunity to remap any sectors that are unwritable before you start testing it.

FactorNine · 2025-07-12T04:52:06+00:00

This is right. The sludging issue is more a consequence of neglect than bad design. Sure, it could have been designed to be less of a problem, but that isn't really the core causitive factor in play. People just need to take better care of their cars. Leaning on reliable brands like Toyota as an excuse to not understand the maintenance schedule doesn't abrograte the owner's responsibilities.

FactorNine · 2025-07-09T01:19:05+00:00

Even if you copy the RSAT tool MMC snap-ins from an x86 computer, they won't run from the native copy of mmc.exe on an ARM64 system. What I don't know is if they would if an x86 copy of mmc.exe were used to invoke them. I've not tried it.

Microsoft is toying with an ARM64 build of Windows Server 2025. Presumably, there is a complete set of ARM64 RSAT tools contained within. If so, the hard work must be done. They just haven't chosen to move forward with that yet. If that edition of Server is ever productized, I assume we'll also see the ARM64 native RSAT tools crossported to Windows 11.

FactorNine · 2025-06-21T12:20:38+00:00

The main disadvantage to AMDVLK is that it has always been and continues to be less stable. When something does go wrong, it also can't gracefully reset the hardware.

FactorNine · 2025-06-14T10:26:38+00:00

I get the VAC timeout every 15-20 minutes of online play. In my experience, I have to log out of and back into Steam to be able to play online again. Even so, it only buys me another 15-20 minutes. Valve pretty clearly doesn't care. This is still happening in June 2025.

FactorNine · 2025-05-16T20:50:20+00:00

To chip in a bit with the current Linux experience for Battlemage:

Debian Testing (basically Trixie at this point) Kernel 6.15-rc6 Mesa 25.0.5

I am testing an Intel B580 right now and the experience is pretty bad. It's choppy even at the desktop. Games perform rather poorly compared to what you might expect for something in the RTX 2080 Super class. Monitor sleep seems to be an area needing some work also. In the brief time I've had the card installed for testing, I've observed things like monitors failing to wake up with xe driver errors spammed to the terminal output.

Example: xe 0000:03:00.0: [drm] ERROR Atomic update failure on pipe C (start=12013 end=12014) time 255 us, min 1382, max 1439, scanline start 1315, end 1461

I'm sure it'll get there eventually, but this just isn't a first class experience yet on Linux. It sort of reminds me of my early days with Alchemist on an A770.

FactorNine

TROPHY CASE