However it's a false economy to run expensive code "every X frames" as an optimisation. While it does improve average FPS and frametimes, it doesn't improve the worst-case frametimes, which are the only ones that players notice.

If updates are staggered across frames (i.e. update 25% of turrets each tick), it should improve both average and worst-case frametimes.

Unlike cl_bob, cl_rollangle and cl_rollspeed don't persist across restarts. I use these variables for added visual flair (I personally use cl_rollangle 3; cl_rollspeed 1000).

This is an issue shared in lots of Quake source ports, so this likely needs to be resolved at an engine level.

Can we have a cvar to increase ambient lighting on player models, essentially acting like r_ambient is set to a value like 32 on player models? Multiplying light intensity by multiplying the diffuse texture color is also an option (this would act like gl_modulate in vanilla Quake 2).

This could even be enabled by default to ensure players are always somewhat visible, regardless of the player model/color choice and position in the map.

It might be worth rewriting the stair smoothing algorithm entirely based on Quake 3's, which is excellent in my experience and stands the test of time even today. It deals with both small steps and steep inclines very well.

This likely occurs because that particular rock texture has an extreme height difference across a small range of pixels. This likely needs to be fixed on the texture itself by modifying it to have less extreme height differences in two ways:

• Reduce its contrast, and ensure its peak value is close to what the engine expects (some engines expect the peak value to be pure white, others to be pure black, others expect the average to be (128, 128, 128)). I don't know what DarkPlaces works with ideally.
• Blur the heightmap texture (if it's part of the normal map, decompose it in GIMP using *Colors > Auto > Decompose*, edit it then recompose it). This will make height differences less extreme and reduce the frequency of height changes.

You may need to do a mix of both for best effects.

My guess is that bots generally do better with hitscan weapons, so these should be favored first across all ranges, but especially for mid and long ranges.

Also, this is a more general issue but bots really ought not to engage at all at long ranges if they only have blaster/shotgun, as trying to hit enemies with a blaster from that range is pretty ineffective. This behavior also doesn't feel human-like, as human players almost never do this. They should prioritize looking for a weapon (or ammo for weapons they lack ammo for) instead, as any weapon you can pick up is a better choice in this situation.

After round end, that player on the left stayed transparent.

I believe this occurs on a player if a round ends while that player is spawn-protected.

It may be worth checking whether this behavior depends on sys_ticrate (try with sys_ticrate 0.1, which is the lowest possible tickrate).

I was about to open an issue for this, so here are some things to think about:

Concrete advantages of higher tickrate

• Lower latency for network actions, regardless of how good your connection to the server is (from 33ms to 16ms of average delay enforced by the server). You don't have to lead your shots as much for projectile weapons, as these are not unlagged unlike hitscan weapons.
• Better interpolation for things that are not predicted client-side, such as other players' movement, vehicles (including the one you're controlling), etc.
• More accurate demo playback, especially if viewed in slow motion using the slowmo cvar.

User expectations have changed

While there are diminishing returns to higher tickrates, it's safe to say that player expectations have changed a lot for several reasons:

• The market penetration for high refresh rate monitors is very high among players, especially among multiplayer FPS players. A high refresh rate monitor has lower input lag, but it also makes it easier to notice that a game is running at a low tickrate due to interpolation artifacts.
• The framerate players can reach has also increased a lot, often going in the 300+ range. Many players disable V-Sync and run with a high framerate cap, so they can still benefit from high tickrates. That said, 60 Hz tickrate should still behave well on a 60 Hz V-Synced display.
• Modern FPS games have standardized around tickrates close to 60 Hz, such as Overwatch, Counter-Strike 2, etc.

Hardware and networks have evolved

While single-core CPU performance hasn't evolved as much as multi-core CPU performance, it's still roughly doubled on average between 2013 and 2023. This should suffice to stomach the increased CPU usage resulting from a higher tickrate. If this is not enough, we can consider tweaking cvars to reduce CPU usage out of the box (see the FAQ below).

On the home network connection side, router hardware has evolved a fair bit (even for ISP-provided routers) and connections are much faster than they used to be. FTTH coverage is quite widespread, and while ADSL is still alive, its gaming performance has also improved significantly for various reasons compared to 2013. (Back when I was on an ADSL connection, I was playing on 60 Hz servers in various games without any issues.)

The state of Wi-Fi for gaming has also improved a lot on average, although it will never match a direct Ethernet connection.

At the same time, it should be remembered that many Xonotic players are on mobile connections. This is also an area where things have changed a lot since 2013 – many countries don't even have 3G networks anymore, and 4G is expected to be the norm here (with ever-increasing usage of 5G).

FAQ

Are other tickrates an option?

Tickrate changes should preferably be a multiple (or divisor) of the previous tickrate to ensure consistency. The next option would be 120 Hz tickrate which is likely viable for duel and 2v2 servers, but probably not more unless you have a really fast server. This can be worth considering on a case-by-case basis for competitive servers still, and perhaps also XDF.

What about servers with large player/bot counts?

If this is an issue, we have two solutions:

• Document in the server configuration file that the tickrate should be set to 30 Hz for servers with slow CPUs. This would be my preferred solution.
• Add two cvars that defines an alternate tickrate to use, as well as a minimum player/bot threshold that must be reached for this tickrate to be used.

What about XDF?

I'd personally want this change to be effective within race modes too, which may result in subtle physics differences due to the intricacies of floating-point precision. It remains to be seen how much records could potentially be affected by this (do we have XDF servers running at 60 Hz currently)?

Can we go further to improve the singleplayer/LAN play experience?

For singleplayer campaign play (and perhaps LAN after making sure this behaves well on Wi-Fi), we can default to sys_ticrate 0 which uses the highest possible ticrate (determined how fast the client hosting the server is). This will provide an even better experience than 60 Hz ticrate by making things feel pretty much instantaneous. It no longer feels like you're playing on a local server, but it feels like a true singleplayer experience.

If we consider this to be excessive, we can settle for a low fixed value such as 0.00833333 (120 Hz). This already makes a noticeable difference compared to 60 Hz for singleplayer in my experience.

CPU usage can likely be lowered in singleplayer/LAN scenarios by disabling some server cvars automatically such as trace-based entity culling, which is expensive.

Can we do other things to make gameplay feel smoother?

Many other ways exist to make gameplay feel more reactive to player input, but these can be implemented in tandem with increasing the tickrate:

• Increase default cl_netfps value to 120 or higher, so that input packets are sent more frequently. This reduces latency and jitter in input acknowledgement, which is why I suggest a value that is at least 2× the default tickrate. Increase the range of the setting in the menu to allow higher values (perhaps up to 240).
• Predict weapon model animations and effects related to firing the weapon.
• Predict hitscan effects (not too difficult).
• Predict projectile effects (difficult, especially for mortar/electro secondary and guided devastator).
• Improve client-side prediction to be less jittery when running with a framerate cap. It may be worth playing with cl_nettimesyncboundmode* cvars.

This is a qmake-based project, with the OpenRGB source cloned as a submodule. You don't need to install CMake, but you need to install Qt 5 development tools (as of writing). In Fedora, this is provided as qt5-qtbase-devel (the executable name is qmake-qt5, not just qmake). Remember to also install lm_sensors-devel.

After cloning this repository, run git submodule init && git submodule update. Then run qt5-qmake and make -j$(nproc).

If anyone needs the .so I built for Fedora 38, here it is: libOpenRGBHardwareSyncPlugin.zip

Wired:

[ i2c busses ]
10DE:2684 1462:5102 - /dev/i2c-3
8086:7A23 1849:7A23 - /dev/i2c-1
10DE:2684 1462:5102 - /dev/i2c-6
10DE:2684 1462:5102 - /dev/i2c-4
10DE:2684 1462:5102 - /dev/i2c-2
0000:0000 0000:0000 - /dev/i2c-0
10DE:2684 1462:5102 - /dev/i2c-5

[ i2c devices ]
[26CE:01A2 U=0000 P=0x0001 I=0] ASRock - LED Controller
[31E3:1222 U=0001 P=0xFF00 I=0] Wooting - WootingTwoHE
[31E3:1222 U=0006 P=0x0001 I=1] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x1337 I=2] Wooting - WootingTwoHE
[31E3:1222 U=0006 P=0x0001 I=3] Wooting - WootingTwoHE
[31E3:1222 U=0080 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x000C I=4] Wooting - WootingTwoHE
[31E3:1222 U=0002 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0xFF54 I=5] Wooting - WootingTwoHE
[26CE:0A06 U=0001 P=0xFFC0 I=6] Generic - USB Audio
[0B05:1A92 U=0001 P=0xFF01 I=0] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0002 P=0x0001 I=1] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0001 P=0x0001 I=1] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0001 P=0x000C I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0080 P=0x0001 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0001 P=0xFFC1 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A92 U=0006 P=0x0001 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0D8C:016C U=0001 P=0x000C I=3] C-Media Electronics Inc. - USB Advanced Audio Device
[0D8C:016C U=0005 P=0x000B I=3] C-Media Electronics Inc. - USB Advanced Audio Device

[ LibUSB devices ]
1D6B:0003
0D8C:016C
0B05:1A92
1D6B:0002
1D6B:0003
1D6B:0002
174C:3074
1D6B:0003
174C:2074
26CE:0A06
05E3:0608
31E3:1222
8087:0033
26CE:01A2
1B1C:1C11
05E3:0608
1D6B:0002

Wireless 2.4GHz:

[ i2c busses ]
10DE:2684 1462:5102 - /dev/i2c-3
8086:7A23 1849:7A23 - /dev/i2c-1
10DE:2684 1462:5102 - /dev/i2c-6
10DE:2684 1462:5102 - /dev/i2c-4
10DE:2684 1462:5102 - /dev/i2c-2
0000:0000 0000:0000 - /dev/i2c-0
10DE:2684 1462:5102 - /dev/i2c-5

[ i2c devices ]
[26CE:01A2 U=0000 P=0x0001 I=0] ASRock - LED Controller
[31E3:1222 U=0001 P=0xFF00 I=0] Wooting - WootingTwoHE
[31E3:1222 U=0006 P=0x0001 I=1] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x1337 I=2] Wooting - WootingTwoHE
[31E3:1222 U=0006 P=0x0001 I=3] Wooting - WootingTwoHE
[31E3:1222 U=0080 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x000C I=4] Wooting - WootingTwoHE
[31E3:1222 U=0002 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0x0001 I=4] Wooting - WootingTwoHE
[31E3:1222 U=0001 P=0xFF54 I=5] Wooting - WootingTwoHE
[26CE:0A06 U=0001 P=0xFFC0 I=6] Generic - USB Audio
[0B05:1A94 U=0001 P=0xFF01 I=0] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0002 P=0x0001 I=1] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0001 P=0x0001 I=1] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0001 P=0x000C I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0080 P=0x0001 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0001 P=0xFFC1 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0B05:1A94 U=0006 P=0x0001 I=2] ASUSTeK - ROG HARPE ACE AIM LAB EDITION
[0D8C:016C U=0001 P=0x000C I=3] C-Media Electronics Inc. - USB Advanced Audio Device
[0D8C:016C U=0005 P=0x000B I=3] C-Media Electronics Inc. - USB Advanced Audio Device

[ LibUSB devices ]
1D6B:0003
0D8C:016C
0B05:1A94
1D6B:0002
1D6B:0003
1D6B:0002
174C:3074
1D6B:0003
174C:2074
26CE:0A06
05E3:0608
31E3:1222
8087:0033
26CE:01A2
1B1C:1C11
05E3:0608
1D6B:0002

but i need the hardware id info for both 2.4 GHz and wired

How can I get this information on Linux?

Name of device:

ASUS ROG Harpe Ace Aim Lab Edition (mouse)

Link to manufacturer's product page:

https://rog.asus.com/mice-mouse-pads/mice/ambidextrous/rog-harpe-ace-aim-lab-edition-model/

Please select what type of device/interface the device uses:

DeviceTypeUSB

ID information:

Wired USB:

0b05:1a92

Wireless USB (2.4 GHz):

Bus 005 Device 002: ID 0b05:1a94 ASUSTek Computer, Inc. ROG HARPE ACE AIM LAB EDITION

Bluetooth:

Device E3:B7:C6:73:06:EF (random)
	Name: ROG HARPE ACE AIM LAB
	Alias: ROG HARPE ACE AIM LAB
	Appearance: 0x03c2
	Icon: input-mouse
	Paired: yes
	Bonded: yes
	Trusted: yes
	Blocked: no
	Connected: yes
	LegacyPairing: no
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
	UUID: Unknown                   (0000fff0-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v0B05p1A96d0001
	ManufacturerData Key: 0x0006
	ManufacturerData Value:
  03 00 80                                         ...             
	Battery Percentage: 0x49 (73)

Please attach screenshots of the device's official control application here:

It's controlled via ASUS Armory Crate, but I'm not on my Windows setup right now and don't have it installed there. The mouse features one RGB lighting control for the mouse wheel.

Please attach device captures here:

Checklist for Step2

• Name of device
• A link to the vendors product page has been included
• The transport bus has been identified and the appropriate label added to the issue.
• The device ID's have been included for USB or PCI
• Screenshots of the OEM Application are included
• There is either, appropriate code examples linked or suitable device captures attached

DP master dedicated: cl_maxfps 128 sys_ticrate 0.0078125

Out of curiosity, why did you use 128 FPS/128 Hz tickrate instead of 125 for the comparison?

Something similar to https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.MangoHud can likely be done for libstrangle.

Forcing MSAA/anisotropic filtering on OpenGL applications requires the NVIDIA proprietary driver, as Mesa lacks equivalent environment variables (see https://www.reddit.com/r/linux_gaming/comments/93e8c7/forcing_antialiasing_with_mesa_drivers/).

For reference, here's the full command like I'm using for Anachronox via WINE. This forces 4× SSAA + 4× MSAA, 16× anisotropic filtering, 117 FPS limit with in-game V-Sync enabled for low-latency VRR:

__GL_FSAA_MODE=11 __GL_LOG_MAX_ANISO=4 strangle 117 mangohud wine anox

Hugo Locurcio (db60f905) at 26 Mar 00:09

I'm not sure whether implicit layers allow using multiple variables but that would probably be desirable for backcompat.

I think you can list multiple variables in a Vulkan layer (list of variables is a JSON dictionary after all). It makes sense to add ENABLE_LIBSTRANGLE=1 and DISABLE_LIBSTRANGLE=1 to explicitly enable/disable libstrange on a specific Vulkan app.