How to load a script with hotkeys during the game?

[Marco]

Hello everyone,

I ask here since I don't think Steam users know about it. But I figured out how to mitigate the screen tearing/stuttering with yellow spikes (i call them "spaghetti lag" since 2013) occurring when cli_iBufferactions=1 and NO prediction at all.

Basically, what I did was loading a script with prediction enabled, play a few minutes with it and then loading my previous NO prediction script. It worked on Fortress, Hole and Yodeller. It doesn't work on Red Station, unfortunately. But I think that map is definitely broken (might be all of those green/orange lights that the level is filled with?).

Anyway, I'd like to find a way to load it realtime and not going back to the network menu. I tried to use the option "include" with script's path (I've set 'M' as a pressed key in the Common.ctl), but I get an error message on console:

stream handling is not enabled for this thread

What does that ever mean???

I've also tried LoadCommands() and LoadStrings() but they do not work either.

Any other suggestions? Thank you.

[Supersniper98]

You should ask on Steam because only I answer there, I don't check here cuz ded (now a pure coincidence). Those lags appear regardless if you have prediction enabled or disabled, I recommend enabling it because input delay makes it unplayable even at 40 ping. They are caused by a cycle that you may have noticed: The ping in game slowly increases up to +50 from your real ping (in cmd) in the course of a few minutes and then those lags appear and after they are gone the ping in game is back to your real ping. To mitigate the lags while they are happening, you need to switch from cli_iBufferActions=1 to cli_iBufferActions=2. This will fixate the ping in game at +50 from your real ping but it will not stutter. After a bit, you will see that the ping with cli_iBufferActions=2 will be higher than +50, this is a clear sign to switch back to cli_iBufferActions=1 and it will be close to +0 again without screenshaking. There is no discrimination based on map, gamemode and game, it happens everywhere and always (in both TFE and TSE), the only reasons why it may be worse in some places and better in others is because your own client is lagging (low fps, framedrops).
(Disclaimer: you told me that you have a wireless provider now and since cli_iBufferActions=1 is very sensitive to instability, you might have small spikes the whole time with that setting, not just when the cycle happens)
To switch buffer actions with a bind there is a simple code you put in Common.ctl:

Button
 Name: TTRS Buffer Switch
 Key1: M
 Key2: None
 Pressed:  if(cli_iBufferActions>=2) {cli_iBufferActions=1; Echo("cli_iBufferActions = 1\n");} else {cli_iBufferActions=2; Echo("cli_iBufferActions = 2\n");};
 Released:

Follow the instructions above when you are switching, it will show a message in the console so that you know what you have set. Goodluck

[Marco]

You should ask on Steam because only I answer there, I don't check here cuz ded (now a pure coincidence). Those lags appear regardless if you have prediction enabled or disabled, I recommend enabling it because input delay makes it unplayable even at 40 ping. They are caused by a cycle that you may have noticed: The ping in game slowly increases up to +50 from your real ping (in cmd) in the course of a few minutes and then those lags appear and after they are gone the ping in game is back to your real ping. To mitigate the lags while they are happening, you need to switch from cli_iBufferActions=1 to cli_iBufferActions=2. This will fixate the ping in game at +50 from your real ping but it will not stutter. After a bit, you will see that the ping with cli_iBufferActions=2 will be higher than +50, this is a clear sign to switch back to cli_iBufferActions=1 and it will be close to +0 again without screenshaking. There is no discrimination based on map, gamemode and game, it happens everywhere and always (in both TFE and TSE), the only reasons why it may be worse in some places and better in others is because your own client is lagging (low fps, framedrops).
(Disclaimer: you told me that you have a wireless provider now and since cli_iBufferActions=1 is very sensitive to instability, you might have small spikes the whole time with that setting, not just when the cycle happens)
To switch buffer actions with a bind there is a simple code you put in Common.ctl:

Button
 Name: TTRS Buffer Switch
 Key1: M
 Key2: None
 Pressed:  if(cli_iBufferActions>=2) {cli_iBufferActions=1; Echo("cli_iBufferActions = 1\n");} else {cli_iBufferActions=2; Echo("cli_iBufferActions = 2\n");};
 Released:

Follow the instructions above when you are switching, it will show a message in the console so that you know what you have set. Goodluck

Hello Sniper. I've made a script with Prediction ON and maybe I figured out what is causing artifacts when lags occur. Before going into it, I'm no longer using OpenGL as it adds input delay. I managed to increase refresh rate on my monitor to the max it can handle (85hz) so I'm using Direct3D, like you wrote somewhere on this forum 8-9 years ago. I think I won't play on Red Station again, since those stutters happen when looking at the sky (I've also made tests alone). I wonder how Zdzichu and X-Fighter can do insane scores with this problem...



As for the cycle, I've bound two buttons to change buffers from 1 to 2 and switch back. Usually I go back to 1 if my ping with buffers=2 goes from 134 to 163 ms. On RS I noticed a single yellow spike even with buffers at 2.

Yes, I've got a dish pointed to my ISP's tower and it has no obstructions, they call it "wireless fiber". Unfortunately I can't get REAL fiber with cable.
However, SS games act weird, because old Sam shows stable ping (well, maybe except when others at home are on FB or YT...), when HD Sam shows mad ping between 47 and 65 with some jumps to 72 and occasionally 100 or 110 but only for a moment. I noticed that some players cause delay, just like when I had ADSL and very slow speed (4.29/0.86) compared to the 30/5 I get now. It's not just russians with 100+ ms, but it also occurs with some "mid-pingers" like Voshel (55 ms). For some reason, the only low ping (35 ms) that causes me delays is Chlorozom, otherwise I can beat most of 35 ms italian players and I get very good hitreg (BTW, I've set cli_iMaxBPS=3500000 and cli_iMaxOutBPS=625000; with ADSL they were set to 541250 and 103750)...
In normal conditions, old Sam starts spiking if there are some low pings (ПТН / ПНХ, X-Fighter, Zdzichu) or when 800 rockets-grenades are being launched and exploding all over the place (Fortress, Hole). I don't get drops to red frame rate, but admittedly Red Station can drop from 1000 to 200 (note: Lens Flares is OFF).

Quake Live not tested yet.

So, here is the other thing now. I was doing a research about ethernet card buffers and I found some comments to this post by a certain n1kobg. He said lower buffers is not recommended, as the continuous flushing can induce lag (the article says to drop to 96/96) so the highest buffers is better:
https://rejzor.wordpress.com/2015/12...nce-for-games/

By reading that, I think I got what does the PredictionFlushing parameter do in Sam, so for my current script:

cli_bPrediction = 1;
cli_iBufferActions = 2;
cli_iMinBPS = 90000;
cli_iMaxBPS = 100000; (I've set higher values, but I think ping starts to be the lowest possible on this threshold)
cli_iMaxPredictionSteps = 2;
cli_bPredictRemotePlayers = 1;
cli_fPredictEntitiesRange = 5;
cli_fPredictionFilter = 0.2;
cli_tmPredictFoe = 5;
cli_fPredictPlayersRange = 5;

I gave cli_iPredictionFlushing a value of 25. It seemed to work (check the first few mintues of my only game on Fortress), as kills were registered with no teleports or artifacts at all. They eventually occurred in the game I won on Yodeller, but my grandma was playing Duolingo on her phone during that, so in normal conditions that shouldn't happen.
I will give higher (30, 35) as I add co-op prediction (Enemy, Ally).

Also, PersistentSymbols.ini seems to memorize this when I'm not playing the game (even after I switched prediction OFF.. a little experiment).

Then, I ran the ping tests to Cloudflare as you suggested. Tracert included. These are with my ISP's DNS:

C:\Windows\system32>tracert cloudflare.com

Traccia instradamento verso cloudflare.com [104.16.133.229]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.99.1
  2    16 ms    24 ms    24 ms  46.102.189.116
  3    12 ms    14 ms    19 ms  172.18.0.53
  4    33 ms    98 ms    60 ms  stel.mix-it.net [217.29.66.130]
  5    47 ms    74 ms    36 ms  cloudflare.mix-it.net [217.29.66.167]
  6    59 ms    49 ms   109 ms  188.114.100.21
  7    53 ms    43 ms    40 ms  104.16.133.229

Traccia completata.

C:\Windows\system32>ping cloudflare.com -n 25

Esecuzione di Ping cloudflare.com [104.16.133.229] con 32 byte di dati:
Risposta da 104.16.133.229: byte=32 durata=39ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=38ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=42ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=30ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=102ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=35ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=25ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=38ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=53ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=46ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=88ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=31ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=55ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=27ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=50ms TTL=58

Statistiche Ping per 104.16.133.229:
    Pacchetti: Trasmessi = 25, Ricevuti = 25,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 25ms, Massimo =  102ms, Medio =  42ms

These are after switching to 1.1.1.1 DNS:

C:\Windows\system32>tracert cloudflare.com

Traccia instradamento verso cloudflare.com [104.16.133.229]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.99.1
  2    16 ms    24 ms    24 ms  46.102.189.116
  3    16 ms    17 ms    34 ms  172.18.0.53
  4    45 ms    33 ms    34 ms  stel.mix-it.net [217.29.66.130]
  5     *       29 ms     *     cloudflare.mix-it.net [217.29.66.167]
  6    40 ms    34 ms    35 ms  188.114.100.21
  7    36 ms    38 ms    36 ms  104.16.133.229

Traccia completata.

C:\Windows\system32>ping cloudflare.com -n 25

Esecuzione di Ping cloudflare.com [104.16.133.229] con 32 byte di dati:
Risposta da 104.16.133.229: byte=32 durata=25ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=36ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=30ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=37ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=35ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=43ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=65ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=60ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=29ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=54ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=31ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=62ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=36ms TTL=58

Statistiche Ping per 104.16.133.229:
    Pacchetti: Trasmessi = 25, Ricevuti = 25,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 25ms, Massimo =  65ms, Medio =  37ms

How do I read them?

BTW, I found out my Realtek PCIe GBE Family Controller is capped at 128 transmit and 512 receive buffers and there are some from Intel that are capable of 2048. Are other adapters (PCIe or USB ) worth a try?

[Supersniper98]

Hello Sniper. I've made a script with Prediction ON and maybe I figured out what is causing artifacts when lags occur. Before going into it, I'm no longer using OpenGL as it adds input delay. I managed to increase refresh rate on my monitor to the max it can handle (85hz) so I'm using Direct3D, like you wrote somewhere on this forum 8-9 years ago. I think I won't play on Red Station again, since those stutters happen when looking at the sky (I've also made tests alone). I wonder how Zdzichu and X-Fighter can do insane scores with this problem...

Not that it matters too much what you use for input delay in this game because of the ridiculously low tickrate, but Direct3D in particular can be laggy and stuttery... it's probably the cause of this issue. And OpenGL fullscreen is the fastest for input delay if you can get it running at your native monitor refresh rate; you have to edit your driver with CRU and remove every refresh rate below your native one for this to work, because there is a bug with modern OS or something and it picks the lowest available option always instead of the highest one. Zdz and xf are used to this game from playing it too much, whenever I come back to play it, it always feels restraining and you know I am not a noob xd

However, SS games act weird, because old Sam shows stable ping (well, maybe except when others at home are on FB or YT...), when HD Sam shows mad ping between 47 and 65 with some jumps to 72 and occasionally 100 or 110 but only for a moment.

I feel like that would be the case in Classic with cli_iBufferActions=1 too, no? Especially from the ping results you posted below.

I noticed that some players cause delay, just like when I had ADSL and very slow speed (4.29/0.86) compared to the 30/5 I get now. It's not just russians with 100+ ms, but it also occurs with some "mid-pingers" like Voshel (55 ms). For some reason, the only low ping (35 ms) that causes me delays is Chlorozom, otherwise I can beat most of 35 ms italian players and I get very good hitreg (BTW, I've set cli_iMaxBPS=3500000 and cli_iMaxOutBPS=625000; with ADSL they were set to 541250 and 103750)...

The only reasons why delays in register can happen are from server network choke or from local network choke, if you played on the following servers this can happen due to the server: Prague (network sometimes choking due to wireless provider like the one you have), AAH Clan (any, both CPU and network lags on these servers, terrible). On Voshel servers CPU used to choke (this causes discards of the register entirely, not even delay, delay in chat, delay in pickups, delay in spawns/multiple spawns etc) but nowadays it's fixed and performs perfectly, so if it happens it's on your side.

In normal conditions, old Sam starts spiking if there are some low pings (ПТН / ПНХ, X-Fighter, Zdzichu) or when 800 rockets-grenades are being launched and exploding all over the place (Fortress, Hole). I don't get drops to red frame rate, but admittedly Red Station can drop from 1000 to 200 (note: Lens Flares is OFF).

Also doesn't seem rational for players to trigger this, as for lags when explosions happen on bigger maps (especially evident in coop) it comes from prediction + high ping combo and 1 CPU core not being enough for them (prediction will drop the fps more the higher the ping gets in Classic).

So, here is the other thing now. I was doing a research about ethernet card buffers and I found some comments to this post by a certain n1kobg. He said lower buffers is not recommended, as the continuous flushing can induce lag (the article says to drop to 96/96) so the highest buffers is better:
https://rejzor.wordpress.com/2015/12...nce-for-games/

Advice written there is mostly true (involving interrupt moderations flow controls and stuff), though for CS and Source games in general... the netcode is so bad that people are often just playing RNG simulator with those tiny hitboxes and at high level it's a game of tactics, not skills. I dunno about the buffers, I have increased Transmit on my Realtek via regedit to 1024 and Receive is at 1024 also, I don't think buffers cause you delay you can notice and if anything... lower ones will cause packet loss. It's performing good, but from what friends have tried and from personal experience, Realtek seems bad in general, so you should let the CPU handle the offloading (TCP, UDP, IPv4 checksum offloads) as well instead of the adapter: people say it's really as it's supposed to be when they did it. Well gg next time we should buy an Intel card, maybe it's worth a try xD

By reading that, I think I got what does the PredictionFlushing parameter do in Sam, so for my current script:

cli_bPrediction = 1;
cli_iBufferActions = 2;
cli_iMinBPS = 90000;
cli_iMaxBPS = 100000; (I've set higher values, but I think ping starts to be the lowest possible on this threshold)
cli_iMaxPredictionSteps = 2;
cli_bPredictRemotePlayers = 1;
cli_fPredictEntitiesRange = 5;
cli_fPredictionFilter = 0.2;
cli_tmPredictFoe = 5;
cli_fPredictPlayersRange = 5;

I gave cli_iPredictionFlushing a value of 25. It seemed to work (check the first few mintues of my only game on Fortress), as kills were registered with no teleports or artifacts at all. They eventually occurred in the game I won on Yodeller, but my grandma was playing Duolingo on her phone during that, so in normal conditions that shouldn't happen.
I will give higher (30, 35) as I add co-op prediction (Enemy, Ally).

Also, PersistentSymbols.ini seems to memorize this when I'm not playing the game (even after I switched prediction OFF.. a little experiment.

Never got to testing that command, only the filtering command which didn't do too much to help at lower values than default... so it's interesting to hear what you find. I still believe at the core that this netcode is not fit for player movements, though it's great for coop, much more satisfying to play it there than any other game in the series and it can be played at very extreme conditions without much hassle either.

Then, I ran the ping tests to Cloudflare as you suggested. Tracert included. These are with my ISP's DNS:

C:\Windows\system32>tracert cloudflare.com

Traccia instradamento verso cloudflare.com [104.16.133.229]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.99.1
  2    16 ms    24 ms    24 ms  46.102.189.116
  3    12 ms    14 ms    19 ms  172.18.0.53
  4    33 ms    98 ms    60 ms  stel.mix-it.net [217.29.66.130]
  5    47 ms    74 ms    36 ms  cloudflare.mix-it.net [217.29.66.167]
  6    59 ms    49 ms   109 ms  188.114.100.21
  7    53 ms    43 ms    40 ms  104.16.133.229

Traccia completata.

C:\Windows\system32>ping cloudflare.com -n 25

Esecuzione di Ping cloudflare.com [104.16.133.229] con 32 byte di dati:
Risposta da 104.16.133.229: byte=32 durata=39ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=38ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=42ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=30ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=102ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=35ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=25ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=38ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=53ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=46ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=88ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=31ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=55ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=27ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=50ms TTL=58

Statistiche Ping per 104.16.133.229:
    Pacchetti: Trasmessi = 25, Ricevuti = 25,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 25ms, Massimo =  102ms, Medio =  42ms

These are after switching to 1.1.1.1 DNS:

C:\Windows\system32>tracert cloudflare.com

Traccia instradamento verso cloudflare.com [104.16.133.229]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.99.1
  2    16 ms    24 ms    24 ms  46.102.189.116
  3    16 ms    17 ms    34 ms  172.18.0.53
  4    45 ms    33 ms    34 ms  stel.mix-it.net [217.29.66.130]
  5     *       29 ms     *     cloudflare.mix-it.net [217.29.66.167]
  6    40 ms    34 ms    35 ms  188.114.100.21
  7    36 ms    38 ms    36 ms  104.16.133.229

Traccia completata.

C:\Windows\system32>ping cloudflare.com -n 25

Esecuzione di Ping cloudflare.com [104.16.133.229] con 32 byte di dati:
Risposta da 104.16.133.229: byte=32 durata=25ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=36ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=30ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=37ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=35ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=34ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=43ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=65ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=60ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=44ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=29ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=40ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=54ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=31ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=62ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=26ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=33ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=32ms TTL=58
Risposta da 104.16.133.229: byte=32 durata=36ms TTL=58

Statistiche Ping per 104.16.133.229:
    Pacchetti: Trasmessi = 25, Ricevuti = 25,
    Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
    Minimo = 25ms, Massimo =  65ms, Medio =  37ms

How do I read them?

You should have pinged 1.1.1.1 directly but yeah, regardless these results seem pretty terrible... it's not very usable for reliable registration and stability in online games. Here are mine for comparison on fiber:

C:\WINDOWS\system32>ping 1.1.1.1 -n 25

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 5ms, Average = 4ms

BTW, I found out my Realtek PCIe GBE Family Controller is capped at 128 transmit and 512 receive buffers and there are some from Intel that are capable of 2048. Are other adapters (PCIe or USB ) worth a try?

Not USB, but PCIe can be worth trying, especially considering Realtek is questionable at this point. I dunno if it's worth testing low buffers from my current 1024/1024 but I might give it a try... though I believe it would cause adverse effects elsewhere.

but my grandma was playing Duolingo on her phone

P.S. What language is she learning? xD

---------- Post added 31-01-2024 at 21:00 ----------

Ok I just tried and with any value other than 1 I get terrible lags and even desync, are you sure it's the correct command??

[Marco]

Not that it matters too much what you use for input delay in this game because of the ridiculously low tickrate, but Direct3D in particular can be laggy and stuttery... it's probably the cause of this issue. And OpenGL fullscreen is the fastest for input delay if you can get it running at your native monitor refresh rate; you have to edit your driver with CRU and remove every refresh rate below your native one for this to work, because there is a bug with modern OS or something and it picks the lowest available option always instead of the highest one. Zdz and xf are used to this game from playing it too much, whenever I come back to play it, it always feels restraining and you know I am not a noob xd


I feel like that would be the case in Classic with cli_iBufferActions=1 too, no? Especially from the ping results you posted below.


The only reasons why delays in register can happen are from server network choke or from local network choke, if you played on the following servers this can happen due to the server: Prague (network sometimes choking due to wireless provider like the one you have), AAH Clan (any, both CPU and network lags on these servers, terrible). On Voshel servers CPU used to choke (this causes discards of the register entirely, not even delay, delay in chat, delay in pickups, delay in spawns/multiple spawns etc) but nowadays it's fixed and performs perfectly, so if it happens it's on your side.


Also doesn't seem rational for players to trigger this, as for lags when explosions happen on bigger maps (especially evident in coop) it comes from prediction + high ping combo and 1 CPU core not being enough for them (prediction will drop the fps more the higher the ping gets in Classic).


Advice written there is mostly true (involving interrupt moderations flow controls and stuff), though for CS and Source games in general... the netcode is so bad that people are often just playing RNG simulator with those tiny hitboxes and at high level it's a game of tactics, not skills. I dunno about the buffers, I have increased Transmit on my Realtek via regedit to 1024 and Receive is at 1024 also, I don't think buffers cause you delay you can notice and if anything... lower ones will cause packet loss. It's performing good, but from what friends have tried and from personal experience, Realtek seems bad in general, so you should let the CPU handle the offloading (TCP, UDP, IPv4 checksum offloads) as well instead of the adapter: people say it's really as it's supposed to be when they did it. Well gg next time we should buy an Intel card, maybe it's worth a try xD


Never got to testing that command, only the filtering command which didn't do too much to help at lower values than default... so it's interesting to hear what you find. I still believe at the core that this netcode is not fit for player movements, though it's great for coop, much more satisfying to play it there than any other game in the series and it can be played at very extreme conditions without much hassle either.



You should have pinged 1.1.1.1 directly but yeah, regardless these results seem pretty terrible... it's not very usable for reliable registration and stability in online games. Here are mine for comparison on fiber:

C:\WINDOWS\system32>ping 1.1.1.1 -n 25

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=5ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56
Reply from 1.1.1.1: bytes=32 time=4ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 5ms, Average = 4ms

Not USB, but PCIe can be worth trying, especially considering Realtek is questionable at this point. I dunno if it's worth testing low buffers from my current 1024/1024 but I might give it a try... though I believe it would cause adverse effects elsewhere.



P.S. What language is she learning? xD

---------- Post added 31-01-2024 at 21:00 ----------

Ok I just tried and with any value other than 1 I get terrible lags and even desync, are you sure it's the correct command??

So basically I have to remove all 59 and 60 hz refresh rates from 1024x768 and lower resolutions and replace them with 85 hz. Will this eventually fix the "Last set mode failed!" problem or do I still have to select Default after changing native refresh rates?

Alright, so it's just something I have to cope with. If I play vs people like ~K~ fora, who spams minigun even when he sees no target (he was doing that vs Ruki, the other day), I will have to guess when to pop out from a wall. BTW, if it's me lagging, people should see my sprite flickering (especially in mid-air), right?

Also, I get why you said to use frame rates higher than 200. Some days ago I was playing vs an italian player I have on Steam friends and he said he was from his notebook. I won both games, but graphics felt choppy, like it was low FPS (despite showing a constant white 200-300) or low refresh and it also caused some problems in hitreg. We were on Voshel's, so the server was the best available one.

There's another glitch on Medieval Rage: players jumping on the edges of all 4 platforms (rocket launcher, minigun, +50 health and +100 armor) tend to shake hard back and forth. You can see that as observer or when you play against them, but you can't replicate it yourself.


I had the bad sync problem only once when joining Survival of the Sickest. But it happened after I've set realtime priority and unchecked UAC virtualization. Weird it didn't happen when I played on Frag 09 - Hole a few minutes later. However, you see where the problem lies: cli_iPredictionFlushing is undocumented, so I'm still guessing. I should open the sdk and try to find there, if I understand it.

The fact of CPU cores is another thing I want to understand better. I remember there's some batch script or a regedit value that was used to set priority, affinity masks and other things. The game also recognizes only Windows NT if you look at the console on startup. It did when I played from Windows 7 and Windows 8. It does on Windows 10. I've also tried to uncheck all cores and leave two, for example 8 and 9, but I didn't see any difference. I guess the game picks only one core due to engine structure.


Maybe I've read something on /reddit or superuser about overclocking NIC from regedit, but some did not recommend it because it can cause issues with connectivity or even hardware failures. Out of curiosity, how did you manage to increase buffers?

Yes, I think I'll test with all interrupts and offloading enabled to see the difference. Even n1kobg on his blog (there's link in the previous page I posted, look at one of his comments) said CPU is faster than any NIC, so I should give it a shot.

I also followed your advice and asked on Steam a few days ago and they confirmed that USB adapters aren't worth it. Maybe I should try PCIe ones, I just have to see if my mobo allows it or if I have to change GPU, because the AMD RX 580 I have now occupies a lot of space. I don't remember if PCIe slot for NIC is below or above the GPU one.

USB adapters could be good for my brother's cheap notebook, because he got an HP one which is very MINIMAL, with 2 USB ports, a HDMI one and no Ethernet, so if he has to call from webex or enter rooms he is forced to use Wi-Fi and get close to router. But I don't think I'll buy one that suddenly because he is working in a foreign country and comes only for a few days when he can.


Grandma is learning Spanish.

[Supersniper98]

So basically I have to remove all 59 and 60 hz refresh rates from 1024x768 and lower resolutions and replace them with 85 hz. Will this eventually fix the "Last set mode failed!" problem or do I still have to select Default after changing native refresh rates?

Do not use the refresh rate option in game, leave it to Default, otherwise I remember it showed an error like that and it reset other options... not cool.

Alright, so it's just something I have to cope with. If I play vs people like ~K~ fora, who spams minigun even when he sees no target (he was doing that vs Ruki, the other day), I will have to guess when to pop out from a wall. BTW, if it's me lagging, people should see my sprite flickering (especially in mid-air), right?

Yes you also lag for us and sometimes it's more annoying for us than for you, there are some players who would play far worse if they would stop lagging, I know 2 cases actually of people who upgraded their PCs and internet connections and later stopped playing because they found it too hard to play fair. Such examples are Mr. Forbici and Seth, both laggy Italians who stopped playing when they solved their lags cuz everything would go through to them and they would get punished for things they took for granted.

There's another glitch on Medieval Rage: players jumping on the edges of all 4 platforms (rocket launcher, minigun, +50 health and +100 armor) tend to shake hard back and forth. You can see that as observer or when you play against them, but you can't replicate it yourself.

Large portion of it is because of autojump (everyone must turn off this buggy mess), but sometimes happens even without. Just ensure you have high BPS and fps and it will be minimal or go away fast.

The fact of CPU cores is another thing I want to understand better. I remember there's some batch script or a regedit value that was used to set priority, affinity masks and other things. The game also recognizes only Windows NT if you look at the console on startup. It did when I played from Windows 7 and Windows 8. It does on Windows 10. I've also tried to uncheck all cores and leave two, for example 8 and 9, but I didn't see any difference. I guess the game picks only one core due to engine structure.

Use Process Lasso, you can set the affinities and priorities that you want and a background process will enforce them 24/7 (make sure you don't turn it off). For Sam Classic you need 1 physical thread (for each thread pair that belongs to an individual core, pick the first one), find the best one from some static high fps scene in game and job done.

Maybe I've read something on /reddit or superuser about overclocking NIC from regedit, but some did not recommend it because it can cause issues with connectivity or even hardware failures. Out of curiosity, how did you manage to increase buffers?

Yes, I think I'll test with all interrupts and offloading enabled to see the difference. Even n1kobg on his blog (there's link in the previous page I posted, look at one of his comments) said CPU is faster than any NIC, so I should give it a shot.

From the same n1kobg guide you can find the registry keys to increase the max allowed value for buffers, it's at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001\Ndi\Params\

I also followed your advice and asked on Steam a few days ago and they confirmed that USB adapters aren't worth it. Maybe I should try PCIe ones, I just have to see if my mobo allows it or if I have to change GPU, because the AMD RX 580 I have now occupies a lot of space. I don't remember if PCIe slot for NIC is below or above the GPU one.

This is why everyone should own ATX boards for this purpose, mATX and ITX are cancer and only facilitate the bare minimum. Can't put anything other than a graphics card.