Envie de parler avec les autres membres de la communauté ? Alors venez vous connecter, vous vous sentirez moins seul !
Forums Échanges et discussions entre membres de la communauté
unhit et rate ?
En lisant les deux topics précédents, je me demandais si le Unhit et la rate n'était pas au final le même problème que ce que l'on rencontre par exemple sous counter strike Source au travers du TickRate.
Je m'explique:
Sous counter strike source, on emploi le terme de tickrate la fréquence a lequel le serveur envoie les paquets au client selon 3 valeurs ( 33,66 , 100 )
Un tickrate de 33 sur un serveur CSS crée un décalage entre la Boite d'impact ( shootbox ) d'un joueur et sont affichage a l'écran et un tickrate 100 synchronise les 2. Donc on utilise la valeur 100 en match.
De manière imagé, en tickrate 33 , pour tuer un joueur qui court, vous devez viser 1 m derrière pour le tuer , on utilise ce bug en faisant des G/D comme le problème évoqué pour devenir Unhits.
En tickrate 100 pas de hunhits
Le désavantage du tickrate 100 est le lag et la perte de packet de données qui force a avoir un bon serveur et une bonne connexion.
Au final le unhits ne serait il pas du aussi par exemple a des joueurs baissant leur rate très bas de manières a fournir très peux d'informations de déplacement aux serveurs générant un décalage d'informations et d'impacts entre le serveurs, le tireur et le blessé potentiel.
Le unhits n'est il pas au final une faille exploitable in game .
Techniquement, il suffirait a un programmeur de générer par exemple une lenteur volontaire d'envoi de packet ( générant des shock ) et par contre dans les réglages du jeux, de maximiser la réception de packet afin d'obtenir rapidement les positions exacte des joueurs.
Après, il y a le hasard, la connexion qui 'est pas fiable etc... et la on peut pas y faire grand chose.
J'ai l'air sortie de nul part mais sa fait des années que je m'intéresse au phénomène Données/Packet/Rate/Shootbox car même si celui de CSS a été mis a la vue de tous, je me demande si cela ne touche pas d'autre FPS.
y'a t il un moyen de faire affiché les shootboxs du moteur quake pour voir si in game elles sont syncros avec l'image du joueur?
cordialement
Je m'explique:
Sous counter strike source, on emploi le terme de tickrate la fréquence a lequel le serveur envoie les paquets au client selon 3 valeurs ( 33,66 , 100 )
Un tickrate de 33 sur un serveur CSS crée un décalage entre la Boite d'impact ( shootbox ) d'un joueur et sont affichage a l'écran et un tickrate 100 synchronise les 2. Donc on utilise la valeur 100 en match.
De manière imagé, en tickrate 33 , pour tuer un joueur qui court, vous devez viser 1 m derrière pour le tuer , on utilise ce bug en faisant des G/D comme le problème évoqué pour devenir Unhits.
En tickrate 100 pas de hunhits
Le désavantage du tickrate 100 est le lag et la perte de packet de données qui force a avoir un bon serveur et une bonne connexion.
Au final le unhits ne serait il pas du aussi par exemple a des joueurs baissant leur rate très bas de manières a fournir très peux d'informations de déplacement aux serveurs générant un décalage d'informations et d'impacts entre le serveurs, le tireur et le blessé potentiel.
Le unhits n'est il pas au final une faille exploitable in game .
Techniquement, il suffirait a un programmeur de générer par exemple une lenteur volontaire d'envoi de packet ( générant des shock ) et par contre dans les réglages du jeux, de maximiser la réception de packet afin d'obtenir rapidement les positions exacte des joueurs.
Après, il y a le hasard, la connexion qui 'est pas fiable etc... et la on peut pas y faire grand chose.
J'ai l'air sortie de nul part mais sa fait des années que je m'intéresse au phénomène Données/Packet/Rate/Shootbox car même si celui de CSS a été mis a la vue de tous, je me demande si cela ne touche pas d'autre FPS.
y'a t il un moyen de faire affiché les shootboxs du moteur quake pour voir si in game elles sont syncros avec l'image du joueur?
cordialement
Voila ce qu'un developpeur UrT a posté mainte de fois :
Donc une petite difference de rate ou prob de connection fera une tres tres grande difference. car enfin de compte la balle est trop petite et quand la personne est en mouvement la difference de ce que tu vois et la realite devient de plus en plus grande.woekele a écrit :Remember that what you see is not necessarily exactly what the game 'does'.
Kenny: If the hit and net code was better, good players would become excellent players, excellent players would be come pro gamers, and shitty players would become shittier players.
[17:58] <ironzorg> joram je le trouve pas si bon que ca
[17:58] <ironzorg> joram je le trouve pas si bon que ca
Mouais..............., je pense qu'il existe une explication plus technique sur le sujet du unhit en particulierSomeOne a écrit :Voila ce qu'un developpeur UrT a posté mainte de fois :
Donc une petite difference de rate ou prob de connection fera une tres tres grande difference. car enfin de compte la balle est trop petite et quand la personne est en mouvement la difference de ce que tu vois et la realite devient de plus en plus grande.woekele a écrit :Remember that what you see is not necessarily exactly what the game 'does'.
Car parler de Réalité, on parle de quoi?, de celle que nous voyons?, de celle du serveur? ou celle de l'ennemi?
Il y a le temps et la masse transmise certes mais que fait le serveur dans tous cela? Certains jeux disposent d'anti-lag par anticipation de mouvement mais le joueur dans sa réalité peux tromper aussi le système par hasard en changeant de vecteur de direction au moment d'un lag et pourtant prendre aussi une balle.
Je crois que c'est plus complexe que cela. je vais voir si je peux trouver le même souci sur d'autres FPS et vers quoi ils pointent leur doigts.
