[FIX] Packet Improvement 2026

[YTmaster]

*Descriere:

In implementarea veche, procesarea pachetelor era limitata la un numar fix pe fiecare frame (maxim 8). Daca veneau mai multe pachete decat puteau fi procesate intr-un singur frame, ele se adunau in buffer si crestea latenta in timp.

In implementarea noua, limita nu mai este bazata pe numarul de pachete, ci pe un interval de timp. Fiecare frame proceseaza pachete timp de pana la 15 ms.

Explicatii:
- La 30 FPS (aprox. 33 ms per frame), cam jumatate din timpul unui frame (15 ms) poate fi folosit pentru procesarea pachetelor.
- In acest interval, sistemul goleste bufferul cat poate de mult, in loc sa fie limitat artificial la 8 pachete.
- Ca rezultat, pachetele sunt procesate mai repede si e mai putin probabil sa se adune, ceea ce reduce latenta si varfurile de trafic.


*Link download / Code:

Deschidem PythonNetworkStreamPhaseGame.cpp si cautam:

Code:

	const DWORD MAX_RECV_COUNT = 8;
	const DWORD SAFE_RECV_BUFSIZE = 8192;
	DWORD dwRecvCount = 0;

	while (ret)
	{
		if(dwRecvCount++ >= MAX_RECV_COUNT-1 && GetRecvBufferSize() < SAFE_RECV_BUFSIZE
			&& m_phase == "Game")
			break;

Modificam asa:

Conținut: Ascuns

Reacționează la acest mesaj și conținutul se va afișa automat.

[ZeroS]

This change is not fully safe...

The original logic does not only limit packets by count. It also checks GetRecvBufferSize() < SAFE_RECV_BUFSIZE which means that if the receive buffer is already large the client continues processing packets to avoid backlog. Ur version removes that buffer-size protection and stops after 15 ms no matter how much data is still waiting. Under heavy packet load this can increase packet delay make the client fall behind and cause delayed updates.