Traduction proposée par la communauté SquadHub.fr et réalisée par Yuma

Salut les Squaddies,

La mise à jour d’aujourd’hui apporte un correctif de plantage de serveur urgent dont nous avons été informés depuis la sortie de la V2.9, ainsi que quelques correctifs pour certains plantages du client présents depuis longtemps.

Voir ci-dessous pour des explications complètes de ces problèmes. Merci encore à celles et ceux qui nous transmettent les logs de crash des serveurs, cela nous aide à résoudre ces derniers dès que possible.

Faites nous savoir si vous continuez à subir l’un de ces problèmes par nos canaux dédiés et essayer de vider votre cache dans le jeu si vous rencontrer toujours des problèmes résiduels.

Hotfixes

Correction du plantage de serveur lié au backblast de l’UB32 Rocketpod & du SPG9

Correction d’un crash du client problématique et difficile à reproduire lié au système de particules et aux changements de map. Le système de particule réutilisait une instance d’émetteur de particule à partir d’un pool qui est lié au système FX de la map actuelle, après un changement de map, celui-ci persistait en réutilisant l’une de ces instances à partir du pool malgré le fait que le système FX avec lequel il avait été créé n’était plus valide. Il y a eu une tentative de résoudre le même problème (ou similaire) avec le rendu de particule qui itère essentiellement tous les systèmes de particules à la fin de la correspondance et force leur désactivation. Ce correctif a été étendu pour également réinitialiser les particules et donc effacer le pool d’instance. De cette manière, le problème devrait être corrigé. Comme nous n’avons toujours pas de mesures de reproduction appropriées pour cela, il n’est pas facile de tester ou d’être certain que le problème est totalement résolu. Si le souci persiste, la totalité des logs de crash sont appréciés pour étudier le problème plus en profondeur.
Correction d’un crash du client lors du changement de map lié à la configuration des pneus des véhicules. Après une enquête, il a été déterminé que le crash du client était causé par une condition de course dans la configuration des pneus. Les configurations de pneus sont modifiées lors de l’initialisation et de la destruction de ces derniers, cependant, l’initialisation de chargement asynchrone peut se produire sur un fil séparé et ses fonctions ne sont pas sécurisées. Un ajout de verrous autour de l’accès au tableau de configuration des pneumatiques pour s’assurer qu’il est sans danger pour le fil. Cela devrait résoudre le problème fondamental à l’origine du crash. Certains rapports de crash mentionnent que cela se passait spécifiquement au moment d’un Atl-Tab, mais ce n’est pas concluant.