Bonjour,
Il y a des soucis particuliers ce soir ?
A deux reprise, je lance un cow level (avec la halebarde) et après environ 300 kills j’obtiens une boîte d’erreur (code changeant) et retour à l’écran de connexion.
Merci
Edit : Le pb s’est uniquement déclaré en cow level ; j’ai pu jouer de façon stable en failles et pactoles.
Bonjour,
As-tu pris en note le code ou pris un screenshot de la boîte d’erreur ?
Si oui, tu pourrais contacter l’assistance-clientèle pour vérifier s’ils peuvent déterminer d’où vient le problème.
Contactez l’assistance clientèle - Assistance Blizzard et cliques sur le bouton Contactez-nous
Bonjour à vous tous.
@Neo31320, avez-vous déjà essayé les solutions de dépannage présentées pour les problèmes de plantage ?
Bonjour,
Je n’ai pas essayé davantage car, à court de halebarde et je n’avais pas noté le code d’erreur.
Ce soir c’est festival de 1016… Impossible de trier le courrier de fin de saison. A priori plutôt lié à la connexion. Bref…
Edit : note pour l’avenir. J’espère réellement qu’il y aura un mécanisme quelconque pour rendre Diablo IV moins tributaire de la connexion (puisque pas de retour mode offline) sinon ça sera sans moi… qui hache menu du pixel depuis D1.
Pareil aujourd’hui plein de deco serveur que ce soit en partie publique ou privé…
Message qui me disait que les serveurs de D3 étaient surchargés …lol 
Je voudrais signaler un point en particulier.
Si le lag en soirée était régulier et pouvait être attribué à mon fournisseur d’accès, les déconnexions franches sur erreur 1016 sont par contre très récentes.
Et ce qui change par rapport à d’habitude, ce saut là dans le MTR :
| ae1-br02-eqam1 .as57976 .net - 18 | 257 | 212 | 0 | 200 | 4251 | 52 |
A chaque fois que je me fais déconnecter, c’est là que ce hop se tape un worst de l’espace. Là c’est 4250 (scusez du peu) mais ça va jusqu’à du 6000+
En terme de packets loss c’est pas la joie et tous les sauts en sont +/- au même point mais ça n’a jamais que provoqué du lag (parfois chiant mais ça tenait).
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| FBXSRV - 0 | 442 | 442 | 0 | 0 | 19 | 0 |
| c2s31-2-83-152-89-254 .fbx .proxad .net - 0 | 441 | 441 | 15 | 16 | 68 | 15 |
| No response from host - 100 | 90 | 0 | 0 | 0 | 0 | 0 |
| 194.149.170.121 - 28 | 215 | 156 | 31 | 37 | 153 | 31 |
|amsterdam-9k-1-be1004 .intf.routers.proxad.net - 21 | 247 | 197 | 45 | 51 | 147 | 51 |
| 80.249.208.83 - 23 | 238 | 185 | 45 | 55 | 132 | 46 |
| ae1-br02-eqam1.as57976 .net - 18 | 257 | 212 | 0 | 200 | 4251 | 52 |
| 137.221.78.83 - 18 | 266 | 220 | 45 | 53 | 119 | 46 |
| 185.60.112.157 - 22 | 242 | 190 | 0 | 52 | 123 | 46 |
svp, épargnez moi le saut 3 dans vos éventuelles réponses. C’est simplement un routeur de mon opérateur qui est en rate limiting.
Je répète, je sais que c’est très loin d’être merveilleux sur l’ensemble. Je voudrais toutefois que vous preniez au sérieux ce saut qui délire à 4k+ de latence de façon aléatoire (wahou, j’arrive presque à une moitié de faille, parfois)
S’il faut vous en convaincre, voici un MTR initié depuis le réseau online dedibox… tout ce passe bien pendant 200+ pings et puis, c’est la cata : du loss et de la latence qui part en live pour rester poli :
myhost (51.15.xxx.xxx) 2020-03-27T23:29:11+0100
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 51-15----.rev.poneytelecom.eu 0.0% 290 0.5 0.5 0.4 1.6 0.1
2. 51.158.8.58 0.0% 290 0.5 0.4 0.4 1.2 0.1
3. 195.154.2.170 0.0% 290 1.3 1.3 1.1 1.8 0.2
4. blizzard-1.equinix-am1.nl-ix .net 0.0% 290 16.7 20.5 16.6 84.5 11.0
5. ae1-br02-eqam1.as57976 .net 28.4% 289 4410. 495.7 14.0 9756. 1787.
6. 137.221.78.83 0.0% 289 13.8 17.9 13.7 139.2 15.9
J’ai volontairement ciblé l’ip qui suit directement car si je cible l’ip 185.60.112.157 je passe par une autre route.
A noter également, qu’avec un MTR lancé en même temps sur mon adsl ET sur la dedibox, les latences de l’espace surviennent au même moment.
Merci par avance pour votre attention portée sur ce saut de l’enfer.
Un dernier pour la route :
http://lokanova.free.fr/upload/files/tempsnip.jpg
Edit : je précise par « très récentes » que cela a commencé avant le confinement et qu’il n’y avait donc pas encore l’engorgement que peuvent connaître les fournisseurs d’accès.
Ce serveur appartient à Blizzard; le ping élevé que tu voies est dû à la basse priorité qu’il accorde aux messages ICMP – ces messages sont utilisés par divers utilitaires tels que traceroute, pathping et WinMTR. Les données, cependant, sont traitées en priorité.
Pour ce qui est de ton WinMTR, je ne suis pas un expert mais je serais plus inquiet par la perte de 28% des paquets sur le 4ième saut (194.149.170.121). Comme tu peux le constater, cette perte se continue également sur les sauts suivants. Selon http://194.149.170.121.ip-address-location.com/, ce serveur appartient à Proxad (ton FAI, peut-être ??).
En l’absence de réponse par un technicien de Blizzard sur ce forum, je recommenderais que tu demandes une 2ième opinion au Assistance Blizzard - Contactez l’assistance clientèle (cliques le bouton Contactez-nous au bas de l’écran). Fournit autant de détails que possible.
Boubou,
J’apprécie le temps que vous investissez ici mais, en l’occurrence, vous ne réagissez pas à l’ensemble de mon message.
je rappelle que les latences élevées existent de longue date et sont dues à des problèmes de FAI mais que je peux m’en accomoder (une série d’actions qui se débloquent d’un coup, finalement on s’y fait)
je mets en évidence que les déconnexions (1016) sont elles beaucoup plus récentes et coïncident systématiquement au moment précis où le saut blizzard se met à atteindre des latences où, logiquement, le jeu considère qu’il y a déconnexion (10 secondes dans ma dernière capture).
Je (re)précise une dernière chose : en temps normal le serveur que j’ai utilisé pour faire le MTR sur 137.221.78.83 passe par une autre route si je cible directement les ip blizzard conseillées pour le diag.
Dans ces conditions normales, lorsque je me connecte à diablo via une connexion vpn établie sur ce serveur, il n’y a pas de déconnexion MALGRE le fait que j’ai toujours des chiffres pas « glorieux » entre mon adsl et mon serveur… mais, à ce moment là, force est de constater qu’il n’y pas de saut blizzard qui monte à des latences telles que produit celui que je mets en évidence ici de deux façons :
Un MTR se lit en globalité et il faut cumuler loss et latence.
Je souhaite (euphémisme) qu’il y ait une réelle prise en compte de cette problématique spécifique à ce saut (cf mon test vpn) car il y a une différence nette entre subir de la latence et ne pas pouvoir jouer.
Mon serveur ne peut pas me servir de pont aérien de façon pérenne, il s’agit d’un front web voué à d’autres tâches et je ne vais pas prendre un abonnement vpn payant uniquement pour éviter un saut blizzard problématique.
Merci par avance à l’équipe Blizzard.
Edit du 30/3 :
Bonsoir,
Je dois revenir sur ce que j’ai affirmé concernant l’accès au jeu via VPN.
Il se trouve que la route (qui est différente que celle qu’empreinte mon adsl sans vpn) subit elle aussi des instabilités, je viens justement de subir des déconnexions sur erreur 1016 et le MTR réalisé en tâche de fond est le suivant :
myhost (51.15.166.xxx) 2020-03-30T20:48:28+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 51-15-166-1.rev.poneytelecom.eu 0.0% 575 0.5 0.4 0.4 3.7 0.2
2. 51.158.8.56 0.0% 575 0.5 0.4 0.4 7.2 0.3
3. 195.154.2.168 0.0% 575 1.6 1.2 1.1 1.8 0.2
4. ae53.edge7.Paris1.Level3.net 0.0% 574 4.1 4.9 1.7 44.8 6.5
5. BLIZZARD-EN.edge7.Paris1.Level3.net 0.0% 574 2.4 5.4 2.3 61.6 9.2
6. ae1-br02-eqpa4.as57976.net 11.0% 574 14.5 263.6 14.4 9987. 1289.
7. et-0-0-3-br02-eqam1.as57976.net 18.5% 574 11.4 297.2 11.3 9533. 1291.
8. 137.221.78.87 0.0% 574 11.1 13.0 11.0 73.5 9.1
9. 185.60.112.157 0.0% 574 11.3 11.6 11.2 20.9 0.7
Je vais tenter prochainement de suivre votre lien de contact, Boubou, je l’avais déjà suivi par le passé et le retour n’était pas franchement « avançant ».
Edit du 17 avril :
Bonsoir,
Une maintenance chez Free a eu lieu ce mercredi 21h ; je n’ai pas pu en connaître la nature de façon officielle mais, compte tenu des observations (tempête dans les routes avant retour à la normale, notamment), il semble qu’un (ou plusieurs) matériel ait été remplacé.
Une défaillance matérielle et non une simple saturation explique pourquoi certains MTR montraient parfois un seul saut (eqam) en évidence… La situation existant depuis assez longtemps, je n’ai pas imaginé que l’opérateur ait pu la laisser se dégrader autant.
Depuis le retour à la normale des routes, un peu plus tard en soirée du mercredi, il n’y a plus aucun problème de MTR avec du %loss ou avec des latences de fou furieux.
Cordialement