[Tutorial] Jogadores dessincronizados e como lidar com eles
#1

Jogadores dessincronizados e como lidar com eles

Vocк provavelmente jб lidou com jogadores dessincronizados antes e sabe o quгo problematico pode ser, especialmente por questгo de falsos-positivos em sistemas de anti-cheat.

Vamos supor que seu anti-cheat expulsa jogadores se a arma nгo for dada pelo servidor. Se vocк fosse disarmar um jogador dessincronizado, suas armas nгo seriam removidas e o mesmo seria uma vнtima de falso-positivo, sendo expulso por algo que nгo fez.

Em geral, vocк nгo pode "spawnar", mudar a vida/colete por funзхes, teleportar, dar/remover armas, mudar a muniзгo, etc desses jogadores. Isso ocorre por que jogadores dessincronizados nгo reagem a alguns RPCs (chamadas de procedimento remoto) mandados pelo servidor, porйm, client messages (SendClientMessage) e game texts ainda funcionam.
A callback OnPlayerUpdate
Esta callback ainda й executada. Isso por que esses jogadores ainda mandam pacotes de sincronizaзгo para o servidor, e esse й o motivo pelo qual vocк ainda pode vк-los movendo/disparando e interagindo com o servidor e possivelmente com outros jogadores.

Jogadores dessincronizados nгo reagem a alguns RPCs, como previamente dito. Eles ainda podem andar por ai, mandar comandos para o servidor, conversar, matar outros jogadores, etc, porйm, eles tambйm notam problemas em seu fim. Existem dois RPCs para fazer o processo de stream in/out com veнculos e jogadores, e esses sгo alguns dos RPCs que nгo vгo ser processados no cliente do jogador dessincronizado, entгo, outros jogadores nгo vгo passar por esse processo, e isso significa que, jogadores que deveriam passar pelo processo de stream-out, nгo seram removidos do jogo, e aqueles que deveriam passar pelo processo de stream-in nгo vгo ser adicionados, nгo se tornando visнveis no jogo do jogador dessincronizado, isso por que seus player-peds ainda nгo foram criados e nгo vгo ser. Jogadores que deveriam ser removidos nгo teram seus player-peds destruidos e vгo permanecer, porйm, nгo serгo sincronizados com o jogador novamente, isso por que o servidor jб reconheзe que esses jogadores nгo estгo na sua area de stream-in, nгo enviando os pacotes de sincronizaзгo para o jogador, entгo esses outros jogadores sгo vistos como se estivessem AFK, o que nгo й a realidade.

Os chamados de "laggers" ainda reagem a essas atualizaзхes, mas ambos os casos sгo diferentes e nгo devem ser confundidos. De qualquer forma, eles tambйm sгo vнtimas de falsos-positivos e tem grandes chances de serem dessincronizados em algum momento.
Como detectar?
Agora vem a parte interessante (Ou talvez nгo).

Agora que vocк sabe que esses jogadores nгo reagem a alguns RPCs, existem algumas coisas que vocк poderia tentar. Eu pessoalmente gosto e uso esta forma para saber de jogadores possivelmente dessincronizados (Leve em consideraзгo que esta й apenas uma parte de meu sistema para que vocк tenha uma idйia de como funciona, nгo й algo pronto para vocк copiar e colar em seu script):

PHP Code:
static 
    
bool:IsPlayerSynced[MAX_PLAYERS char],
    
PlayerAmmo[MAX_PLAYERS char],
    
PlayerUpdateTick[MAX_PLAYERS];
    
public 
OnPlayerUpdate(playerid)
{
    if(
gettime() > PlayerUpdateTick[playerid])
    {
        static 
current_weaponcurrent_ammo;
            
        
PlayerUpdateTick[playerid] = gettime() + 2;
        
GetPlayerWeaponData(playerid0current_weaponcurrent_ammo);
        
        
IsPlayerSynced{playerid} = (current_ammo != PlayerAmmo{playerid});
        
SetPlayerAmmo(playeridcurrent_weapon, !current_ammo);
        
        
PlayerAmmo{playerid} = current_ammo;
    }
    return 
1;
}
//Utilizando IsPlayerSynced{playerid} em algum lugar... 
Como isso funciona exatamente? Este pequeno sistema simplesmente muda a muniзгo na slot 0 (punhos/soco inglкs) entre 1 e 0 (antes que vocк me pergunte, a muniзгo de armas brancas nгo importa, entгo nгo podem ser removidas mudando sua muniзгo para 0), que nгo й notado pelos jogadores. Jб que jogadores dessincronizados nгo podem ter sua muniзгo mudada de alguma forma pelo servidor, ela continuara sendo a mesma, e й assim que funciona.

Por que a callback OnPlayerUpdate? Como previamente dito, jogadores dessincronizados ainda mandam pacotes de sincronizaзгo para o servidor, entгo a callback continua sendo executada. Logo, fazer a verificaзгo ai й bom, especialmente por que jogadores AFK nгo seram "marcados" como dessincronizados, nгo interferindo com sua verificaзгo.
O que fazer apуs confirmado?
Vocк pode expulsar o jogador com um aviso dizendo para conectar novamente. Por que? Por que mesmo que seu servidor nгo se constitua de sistemas onde jogadores dessincronizados sгo potenciais vнtimas de falsos-positivos, isso sу resulta em confusгo e geralmente em denъncias falsas por parte de outros jogadores, especialmente pelo fato de que pessoas que deveriam passar pelo processo de stream-in, nгo vгo aparecer no jogo do jogador dessincronizado, sendo impossнvel causar dano, pois o mesmo nгo vк esses jogadores e nгo vai registrar o dano por sua parte em seu cliente.
Reply
#2

Muito bom (:
Reply
#3

Bom tutorial, parabйns.
Reply
#4

Quote:
Originally Posted by Marllun
View Post
Muito bom (:
Quote:
Originally Posted by Malandrin
View Post
Bom tutorial, parabйns.
Obrigado.
Reply
#5

Уtimo conteъdo, parabйns.
Reply
#6

Muito bom.
Reply
#7

Obrigado pela informaзгo.
Reply
#8

PHP Code:
SetPlayerAmmo(playeridcurrent_weapon, !current_ammo);
PlayerAmmo{playerid} = current_ammo
Nгo teria de ser:


PHP Code:
SetPlayerAmmo(playeridcurrent_weapon, !current_ammo);
PlayerAmmo{playerid} = !current_ammo//<------ 
Reply
#9

Quote:
Originally Posted by PlayBack
View Post
PHP Code:
SetPlayerAmmo(playeridcurrent_weapon, !current_ammo);
PlayerAmmo{playerid} = current_ammo
Nгo teria de ser:


PHP Code:
SetPlayerAmmo(playeridcurrent_weapon, !current_ammo);
PlayerAmmo{playerid} = !current_ammo//<------ 
Nгo, й assim mesmo.

PlayerAmmo contйm a muniзгo anterior para ser comparada com a atual na prуxima verificaзгo. Com a sua mudanзa, PlayerAmmo terб a mesma muniзгo que foi "setada" na slot 0, e nas prуximas verificaзхes a muniзгo na slot 0 serб a mesma que em PlayerAmmo, logo todos os jogadores vгo ser considerados dessincronizados, o que mostra que vocк nгo tem idйia de como o exemplo acima funciona.
Reply
#10

Quote:
Originally Posted by BrunoBM23
View Post
Nгo, й assim mesmo.

PlayerAmmo contйm a muniзгo anterior para ser comparada com a atual na prуxima verificaзгo. Com a sua mudanзa, PlayerAmmo terб a mesma muniзгo que foi "setada" na slot 0, e nas prуximas verificaзхes a muniзгo na slot 0 serб a mesma que em PlayerAmmo, logo todos os jogadores vгo ser considerados dessincronizados, o que mostra que vocк nгo tem idйia como o exemplo acima funciona.
Saquei.
Reply
#11

Muito bom tutorial.
Reply
#12

й possнvel fazer pelo nнvel de bкbado?
Reply
#13

Nгo seria mais fбcil utilizar um comando para dar “tapa” no jogador? Visto que quando o mesmo nгo estб sincronizado, ele nгo sobe ao utilizar o comando.
Reply
#14

Quote:
Originally Posted by Marlboro18
View Post
Nгo seria mais fбcil utilizar um comando para dar “tapa” no jogador? Visto que quando o mesmo nгo estб sincronizado, ele nгo sobe ao utilizar o comando.
Se vocк pretende verificar manualmente, sim.
Reply
#15

Muito boa a explicaзгo, pro tуpico ficar perfeito sу faltou um exemplo de cуdigo para copiar e colar para lidar com esses jogadores.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)