Le mois dernier, nous vous avons expliqué que nous changions la manière dont nous priorisons certains des problèmes les plus persistants de Star Citizen. Aujourd’hui, nous souhaitons faire le point sur les progrès réalisés jusqu’à présent, les problèmes que nous avons résolus et le travail qui a permis de les corriger.

Nous nous concentrons sur les problèmes qui ont le plus grand impact sur votre expérience. Au lieu d’examiner les bugs un par un, nous prenons davantage de recul et nous nous concentrons sur les éléments du jeu dont vous dépendez à chaque session, en regroupant les bugs selon le système qu’ils perturbent. Votre vaisseau doit être là où vous vous attendez à le trouver. Votre inventaire doit se charger. Vos missions doivent fonctionner. Ce sont des attentes fondamentales, et nous savons que lorsqu’elles ne sont pas satisfaites, peu importe à quel point le reste du jeu peut être impressionnant. Si vous ne parvenez pas à récupérer votre vaisseau, si vous perdez l’équipement que vous transportiez ou si vous passez 15 minutes à essayer de dépasser une erreur de connexion, c’est cette expérience-là que vous retiendrez.

Afin de maintenir l’accent sur l’expérience des joueurs, nous avons confié à notre équipe Player Experience la responsabilité d’identifier et de hiérarchiser ces problèmes. L’Alpha 4.10 constitue jusqu’à présent la plus importante mise en application de cette approche, et nous souhaitons aujourd’hui vous montrer concrètement à quoi cela ressemble.

Mise en pratique avec l’Alpha 4.10

Nous nous sommes concentrés sur les domaines fondamentaux suivants :

• IA
• Amarrage et ravitaillement
• Économie et exploits généraux
• Qualité de vie durant la première heure
• Ascenseurs de fret
• Hangars et ASOP
• Inventaire
• Erreurs de connexion et de login
• Voyage quantique et Starmap
• Perte de vaisseaux

Deux fois par semaine, les équipes QA, Production, Player Experience et Community se réunissent afin d’examiner les problèmes ayant le plus grand impact sur les joueurs. Nous comparons ce que nous observons en interne avec vos rapports sur l’Issue Council, en tenant compte de la fréquence à laquelle un problème est signalé, du nombre de joueurs affectés, de son ancienneté et de la gravité de son impact sur le gameplay. Nous regroupons ces facteurs dans ce que nous appelons un « Impact Score », qui nous aide à déterminer ce qui requiert le plus notre attention.

Vos rapports sur l’Issue Council jouent un rôle important dans ce processus. Dans plusieurs cas, des étapes de reproduction détaillées, des informations complémentaires et des preuves vidéo nous ont permis de passer du constat qu’un élément ne fonctionnait pas à la compréhension de la raison pour laquelle il ne fonctionnait pas — et cela fait une énorme différence lorsqu’il s’agit de parvenir à une correction.

Avec l’Alpha 4.10, nous commençons à voir les résultats de cette approche.

Au moment où nous écrivons ces lignes, l’Alpha 4.10 a atteint 1 239 corrections de bugs soumises au cours de son cycle de développement, contre 295 pour l’Alpha 4.9. Ces chiffres varient naturellement en fonction de la taille et de l’ampleur de chaque patch, et la 4.10 est une mise à jour nettement plus importante comportant davantage de contenu, ce qui signifie également davantage de problèmes à identifier et à résoudre.

Cependant, le contexte est plus important que les chiffres eux-mêmes. Parmi ces corrections, 479 concernaient des bugs déjà présents dans l’Alpha 4.9 ou dans des versions antérieures. Il s’agit d’un indicateur bien plus pertinent des progrès que nous réalisons pour améliorer l’expérience Live existante, plutôt que de simplement comptabiliser les problèmes découverts et corrigés pendant le développement de nouveaux contenus.

Nous avons également constaté une amélioration significative des performances côté client. Ces derniers mois, l’ajout de nouveaux contenus sans amélioration correspondante des performances avait contribué à une baisse progressive de celles-ci, Instancing et Siege of Orison ayant rendu cet écart particulièrement visible. Cela a conduit à un effort coordonné entre les équipes Engine, Physics, AI, Gameplay, Rendering et Content afin de traiter certains des éléments ayant le plus lourd impact sur les performances.

Sur l’ensemble des configurations matérielles, en comparant des Landing Zones présentant une population équivalente entre l’Alpha 4.9 et l’Alpha 4.10, le nombre moyen de FPS côté client s’est amélioré de 15,5 %. Votre prochaine visite à Lorville devrait donc montrer une amélioration perceptible !

Dans les coulisses : Alpha 4.10

Une question que nous voyons revenir après presque chaque sortie est, sous une forme ou une autre : si vous connaissiez ces problèmes, pourquoi avoir publié la mise à jour ?

C’est une question légitime. La liste des problèmes connus n’est jamais vide. Décider qu’un build est prêt pour les serveurs Live implique donc d’évaluer ce que nous pouvons corriger et vérifier en toute sécurité, et de déterminer si le build dont nous disposons constitue une amélioration par rapport à celui auquel vous jouez actuellement. Nous ne faisons pas toujours le bon choix, notamment parce que, dans certains cas, seule la charge réelle de l’environnement Live permet véritablement de mettre les systèmes à l’épreuve, mais ce sont des décisions que nous prenons très au sérieux.

Plus tard aujourd’hui, nous publierons un épisode pilote d’une potentielle série que nous appelons Inside CIG, qui vous emmènera dans les coulisses de l’Alpha 4.10 afin de vous montrer à quoi ressemble réellement ce processus. Vous assisterez à nos réunions, passerez du temps avec les développeurs à leur poste de travail pendant qu’ils traitent les problèmes et les contenus que vous testez dans le PTU, et découvrirez comment les tests, la télémétrie et vos retours sont réunis dans notre travail en vue d’une sortie sur les serveurs Live.

Regard détaillé sur les corrections

L’objectif de cette initiative n’est pas simplement de corriger rapidement les bugs. Nous voulons que ces corrections restent efficaces dans le temps. Cela signifie adopter une approche plus méthodique pour rechercher les causes profondes des problèmes persistants, plutôt que de ne traiter que les symptômes visibles.

À l’image de l’initiative Transit Bugfix, nous avons appliqué cette philosophie à plusieurs systèmes fondamentaux du jeu, en nous concentrant sur l’amélioration de notre capacité à identifier les causes profondes, à recueillir de meilleures informations de diagnostic et à vérifier que les corrections continuent de fonctionner correctement dans un environnement de jeu Live.

Inventaires vides

STARC-211218 - Inventaires vides

Il s’est finalement avéré qu’il s’agissait de trois problèmes distincts qui se superposaient.

Le symptôme visible était l’accumulation de « pending moves ». Chaque interaction avec l’inventaire en ajoutait une nouvelle, elles ne se résolvaient jamais et, une fois la file d’attente bloquée, l’inventaire apparaissait vide lors de sa prochaine ouverture.

En arrière-plan, la première requête de rangement envoyée au service expirait. La tentative suivante recevait alors une réponse « already exists », ce qui signifiait que la requête initiale avait en réalité réussi, mais que nous n’avions simplement jamais reçu la confirmation. Comme « already exists » n’est pas considéré comme une erreur permettant une nouvelle tentative, le client abandonnait à ce stade et le déplacement restait indéfiniment en attente.

Nous avons corrigé ce problème en modifiant la gestion des événements côté service et en réduisant le délai d’expiration.

Cela dit, deux problèmes plus modestes avaient tout autant d’importance dans la manière dont le problème était perçu par les joueurs. Premièrement, aucun état de chargement n’était affiché : un inventaire en cours de chargement paraissait donc exactement identique à un inventaire défectueux. Deuxièmement, la grille restait interactive pendant le chargement, ce qui permettait aux joueurs d’accumuler de nouvelles requêtes défaillantes par-dessus celles déjà bloquées.

L’ajout d’un indicateur de chargement bloquant les interactions pendant la résolution d’un déplacement a permis de faire passer la perception du problème de « mon inventaire a disparu » à « mon inventaire est en train de charger ».

Vaisseaux disparaissant des hangars

STARC-186319 - Vaisseaux disparaissant des hangars

Avec le Server Meshing, une même entité peut être chargée simultanément sur plusieurs serveurs. Cela n’est pas censé se produire souvent, mais cela arrive à proximité des frontières entre serveurs et autour d’entités possédant de très grands rayons de streaming. Levski s’est révélé particulièrement sujet à ce problème.

Le code chargé de déterminer si un vaisseau devait être rangé dépendait d’une vérification appelée IsAuthorityPossible(). Le problème était que cette vérification renvoyait « true » sur tous les serveurs, et pas uniquement sur celui qui possédait réellement l’autorité sur le hangar.

Identifier cette cause profonde a nécessité deux étapes.

La première a révélé que notre système de traçage n’enregistrait ni la raison pour laquelle un véhicule avait été rangé, ni le serveur qui avait effectué l’opération. Pire encore, plusieurs chemins de code — notamment les saisies de véhicules sans propriétaire et la récupération via ascenseur de fret — rangeaient les véhicules en contournant complètement la fonction standard, ne laissant ainsi aucune trace.

Nous avons commencé par corriger cela, afin que chaque demande de rangement passe désormais par une fonction unique, enregistre une raison et indique quel serveur l’a initiée. C’est cette journalisation supplémentaire qui a finalement permis de mettre en évidence le bug lié à l’autorité.

La correction proprement dite a remplacé la vérification défaillante par un véritable test de propriété, HasAuthority(), dans la logique de nettoyage de la zone d’atterrissage. Un bon exemple d’une correction relativement simple qui n’est devenue évidente qu’une fois la véritable nature du bug révélée.

Autres corrections

La liste ci-dessous présente une sélection des bugs que nous avons traités dans les Alpha 4.9 et 4.10. Elle n’a pas vocation à constituer une liste exhaustive des corrections intégrées à ces versions, mais plutôt à offrir une vue d’ensemble du travail réalisé dans les principaux domaines ciblés par cette initiative.

Les problèmes marqués d’un ▲ sont directement liés à un rapport actif de l’Issue Council.

Perte de vaisseaux

▲ STARC-186319 - Des vaisseaux pouvaient disparaître et être indiqués comme « stored » sur le terminal ASOP juste après avoir atterri ou quitté les hangars d’une station, comme Levski, faisant tomber le pilote au sol.

La cause était une condition de concurrence dans laquelle deux processus distincts pouvaient tenter simultanément de détruire puis de ranger à nouveau le même véhicule, parfois à cause de vaisseaux apparaissant avec une mauvaise zone ou un mauvais jeton d’accès. La correction ajoute une vérification empêchant la destruction d’un véhicule lorsqu’il est déjà en cours de rangement ailleurs.

▲ STARC-206457 - Lors de la récupération d’un vaisseau dans un hangar, celui-ci pouvait apparaître déjà en plein saut quantique, le propulsant contre la porte ou les parois du hangar dès la fin de l’animation de l’ascenseur.

Le problème sous-jacent était qu’un vaisseau pouvait reprendre un état de voyage quantique encore actif lors de son apparition, même lorsqu’il se matérialisait à l’intérieur d’un hangar fermé. La correction empêche désormais la reprise du voyage quantique pour les vaisseaux apparaissant dans des espaces clos. Les tests de suivi effectués sur plusieurs stations et différents vaisseaux n’ont révélé aucune nouvelle reproduction du problème.

▲ STARC-152514 - Le terminal ASOP dans les halls de station pouvait indiquer à tort qu’un vaisseau devait être « Claimed », alors qu’il était correctement stocké sur son pad.

ASOP ne vérifiait que l’état de stockage direct du vaisseau. Or, un vaisseau stocké est en réalité conservé comme enfant du hangar lui-même. Ainsi, si le rangement du hangar se terminait alors que le joueur s’était trop éloigné, ASOP perdait sa trace. La correction permet désormais à ASOP de vérifier également directement l’inventaire du hangar.

Hangars et ASOP

▲ STARC-128568 - Les portes de hangar de certaines stations pouvaient laisser la porte extérieure fermée alors que la porte intérieure s’ouvrait, enfermant les joueurs à l’extérieur ou à l’intérieur du hangar.

Les portes extérieure et intérieure du hangar n’étaient pas correctement liées dans le backend, ce qui permettait à l’une de s’ouvrir indépendamment de l’autre dans des stations telles que Stanton Gateway, Ruin Station et Orbituary. Les liens entre le hangar et ses portes ont été rétablis afin qu’elles s’ouvrent désormais correctement ensemble.

▲ STARC-205924 - Le minerai extrait pouvait disparaître après le rangement d’un vaisseau minier dans un hangar.

Le problème provenait de la base de données backend chargée du suivi du fret des vaisseaux, qui devenait instable sous forte charge. Le conteneur de fret du vaisseau minier pouvait alors revenir à un état antérieur lors du rangement puis de la récupération du vaisseau. Une correction du backend a résolu cette instabilité et rétabli la persistance du minerai pendant le stockage.

▲ STARC-207340 - Le carburant contenu dans les réservoirs externes pouvait être perdu lors du rangement d’un vaisseau via ASOP.

Ce problème partageait la même cause profonde que la perte de minerai décrite ci-dessus : le backend perdait la trace des données stockées pendant le processus de rangement. Il a été résolu par la même correction.

▲ STARC-186642 - La récupération d’un vaisseau nécessitant une taille de hangar différente de celle déjà utilisée pouvait échouer, provoquer son rangement automatique ou détruire le vaisseau.

Le jeu ne permettait d’avoir qu’une seule taille de hangar instancié active par joueur à la fois. Demander un hangar d’une taille différente alors qu’un autre était déjà utilisé pouvait donc échouer silencieusement ou, dans le pire des cas, détruire le vaisseau entrant.

La correction détruit désormais correctement l’ancienne instance de hangar et génère celle correspondant à la taille requise. Une correction supplémentaire empêche également les ascenseurs d’envoyer les joueurs vers d’anciennes instances de hangars qui avaient déjà été déchargées, ce qui pouvait donner l’impression erronée que les vaisseaux devaient être « claimed ».

Les joueurs sans casque pouvaient suffoquer dans certaines zones de service et d’ascenseur des hangars de Levski.

Certaines zones de service des hangars n’étaient pas couvertes par une atmosphère. Cette couverture a désormais été étendue à ces zones afin de corriger le problème.

Ascenseurs de fret

Les plateformes des ascenseurs de fret pouvaient rester définitivement bloquées sur l’écran « Transferring... » après plusieurs montées et descentes de fret de mission, rendant l’ascenseur totalement inutilisable.

La cause profonde provenait du fait que l’objectif de collecte d’une mission était considéré comme terminé après une récupération partielle des objets, et non complète. Remettre ensuite les objets ne réinitialisait pas cet objectif, ce qui corrompait l’état de transfert de l’ascenseur.

La correction dirige désormais les objets de mission restockés vers l’inventaire personnel au lieu de les réintégrer à la mission, afin d’éviter ce conflit. Une correction ultérieure a également supprimé un cas particulier pouvant mettre en file d’attente une demande de transfert vide.

Après cela, les tests réalisés dans de nombreux lieux et avec plusieurs types de missions n’ont pas permis de reproduire le problème.

▲ STARC-153267 - Le fret d’une mission de transport pouvait être totalement absent du lieu de récupération, rendant la mission impossible à terminer.

Le problème provenait d’une condition de concurrence dans le backend : une mise à jour du nombre d’objets présents dans l’inventaire pouvait écraser des données de fret plus récentes avec une copie obsolète provenant du cache.

Le Warehouse Manager, qui gère ce processus, a été retravaillé et traite désormais ces mises à jour dans le bon ordre afin d’empêcher cet écrasement. Les tests n’ont ensuite révélé aucun nouvel échec.

Le message « Elevator Overloaded » n’indiquait pas clairement qu’un transfert partiel de fret avait effectivement eu lieu, laissant les joueurs dans le doute quant aux objets qui avaient réellement atteint la plateforme.

Le texte du message a été corrigé afin d’indiquer clairement qu’un transfert partiel a eu lieu. Un autre problème, toujours ouvert, concerne le calcul de capacité sous-jacent qui peut provoquer inutilement l’apparition de ce message.

▲ STARC-199979 - Le dépôt d’œufs de Boreal Quasi Grazer dans un Freight Elevator pendant le contenu Nyx Mission Pack 2 ne permettait pas de terminer la mission de collecte de ressources.

La cause était l’absence de données de configuration par défaut sur l’objet sous-jacent de la créature, après qu’une précédente tentative de correction se soit révélée inefficace. Une correction appropriée a depuis été vérifiée.

Inventaire

▲ STARC-211218 - L’inventaire personnel, celui d’une station ou celui du butin pouvait devenir complètement vide et inaccessible pendant plusieurs minutes, empêchant la récupération et le dépôt des objets de mission.

La cause profonde était que certaines requêtes backend de rangement d’inventaire expiraient parfois sans se terminer correctement, provoquant une accumulation des déplacements en attente et donnant l’impression que l’inventaire était vide.

Une correction côté client ajoute désormais un état de chargement avec indicateur pendant la résolution du problème.

▲ STARC-204415 - Un double-clic sur une pièce d’armure dans l’inventaire pouvait équiper simultanément un objet adjacent et parfois faire disparaître complètement l’emplacement de sous-combinaison, empêchant ensuite le personnage de retirer son équipement.

Ce problème s’est révélé être causé par la même anomalie qu’une précédente correction concernant l’équipement des armures. Une fois cette correction entièrement déployée, les tests ont confirmé que le problème ne se produisait plus.

▲ STARC-200719 - Équiper certaines sous-combinaisons, notamment après une sortie de Klescher, faisait disparaître l’icône de l’emplacement de sous-combinaison dans l’interface d’inventaire, empêchant le joueur de changer de sous-combinaison.

La cause était qu’une chemise portée avant l’entrée à Klescher n’était jamais réellement déséquipée, ce qui entrait en conflit avec l’emplacement de sous-combinaison. Une correction retire désormais correctement cette chemise lors de l’entrée en prison.

Certaines cartes d’accès et certains disques durs pouvaient disparaître lors d’une interaction, restant cachés jusqu’à ce qu’un autre objet soit ramassé.

Ces objets destinés uniquement à être transportés disposaient à tort d’une interaction « Equip », qui les envoyait dans un état intermédiaire au lieu de permettre leur transport normal. La correction supprime l’option Equip des cartes et disques concernés.

▲ STARC-202297 - Cliquer sur « Carry » sur un objet d’inventaire alors que le joueur tenait déjà quelque chose, comme un multitool, déclenchait une animation de rangement mais faisait complètement disparaître l’objet tenu.

La cause était que l’interaction Carry ne gérait pas correctement les objets déjà tenus et les rangeait dans un conteneur interne au lieu de l’inventaire personnel. La correction modifie ce comportement et ajoute une validation afin d’éviter que des objets ne puissent être perdus de cette manière.

▲ STARC-200139 - Les menus de filtrage par catégorie des inventaires, ascenseurs de fret et kiosques de fabrication pouvaient rester ouverts et se superposer lors de survols ou de clics rapides, encombrant l’interface de plusieurs menus empilés.

La cause était un état de survol qui ne se réinitialisait pas lorsque le curseur quittait trop rapidement le bouton de filtre, laissant les anciens menus affichés. Une correction ferme désormais automatiquement les autres menus ouverts lorsqu’un nouveau menu est affiché.

▲ STARC-204772 - Certaines armes apparaissaient sous forme de silhouettes noires dans les emplacements d’équipement et dans l’interface de récupération de butin immédiatement après avoir été équipées, jusqu’à ce que l’inventaire soit fermé puis rouvert.

Une correction du rendu a résolu le problème.

▲ STARC-213375 - Le glisser-déposer ou le transfert avec Maj-clic d’objets récupérés vers les emplacements du sac à dos ou de l’armure centrale échouait dans de nombreux endroits.

Le panneau d’interface concerné nécessitait un mode de rendu différent afin d’enregistrer correctement les événements de glisser-déposer.

Le bouton Buy du kiosque de la raffinerie de Nyx à Levski était visuellement mal aligné, ce qui le rendait difficile à cliquer précisément.

Le problème a été corrigé en ajustant la position du bouton à l’écran.

Diviser une pile d’objets dans l’inventaire personnel puis les regrouper pouvait laisser l’inventaire dans un état défectueux.

La cause était que les objets séparés conservaient temporairement des identifiants internes en double jusqu’à la mise à jour du cache local. Le problème était aggravé par les loadouts, qui pouvaient laisser des objets sans ordre de tri approprié.

Plusieurs corrections ont traité ces deux problèmes, et des tests approfondis ont confirmé leur efficacité.

Les objets nouvellement ramassés, comme les fusibles ou le minerai, ne pouvaient pas être placés depuis l’inventaire tant que le joueur n’avait pas ouvert puis refermé une première fois son inventaire.

La cause était un cache d’inventaire obsolète. Les corrections mettent désormais correctement le cache à jour lorsqu’un objet est ramassé et suppriment un ancien contournement qui provoquait l’invalidation du cache lorsqu’on appuyait sur Échap.

Le réapprovisionnement en munitions ne récupérait les chargeurs que depuis les emplacements de l’armure centrale, ignorant les chargeurs de rechange stockés dans le sac à dos.

Le problème était causé par le même cache d’inventaire obsolète que celui affectant le placement depuis l’inventaire, et a été résolu par la même correction.

Erreurs de connexion et de login

▲ STARC-178776 - Les joueurs pouvaient être renvoyés au menu principal avec une erreur 64008 « Spawn Resolver Error » lorsqu’ils tentaient de rejoindre le Persistent Universe.

Deux causes distinctes se sont succédé au fil du temps : une première vague provenait d’un bug incorrect d’exclusion de données, tandis qu’une réapparition ultérieure a été attribuée à une désynchronisation du backend dans l’état des comptes joueurs, qui pouvait également provoquer des déconnexions 64006.

Une correction du service backend a traité la cause principale.

▲ STARC-162848 - Les joueurs pouvaient rester bloqués avec une erreur 60029 et être incapables de rejoindre le Persistent Universe.

Les comptes concernés avaient leurs données de personnage laissées dans un état défectueux dans le backend, le personnage étant en quelque sorte « rangé » simultanément à deux endroits.

Une correction du service backend a résolu le problème sous-jacent, et des outils de support ont été utilisés afin de réparer manuellement les comptes déjà bloqués.

▲ STARC-177979 - Une erreur d’apparition 64010 pouvait survenir après plus de 12 minutes d’attente pendant que le serveur tentait de retrouver la dernière position connue du joueur.

La cause profonde était liée aux limites de débit et de disponibilité du service backend chargé de déterminer la position des joueurs, et non à un problème côté client. Le problème est traité par des améliorations du service backend.

▲ STARC-210544 - Une déconnexion 64006 (« Location Resolution Request failed ») pouvait se produire lorsque le backend ne parvenait pas à retrouver les données du personnage d’un joueur afin de le reconnecter lors du login.

Il s’agissait d’une désynchronisation temporaire du suivi de l’état des comptes dans le backend, et non d’une véritable perte des données du personnage. Le problème pouvait se résoudre de lui-même après quelques secondes ou jusqu’à environ 15 heures plus tard.

Il était responsable de la majorité d’une vague associée d’erreurs 64008. Les deux problèmes sont traités par la même correction du service backend.

Voyage quantique et Starmap

Le calcul d’un itinéraire de voyage quantique depuis l’intérieur d’un hangar de station échouait lorsque la destination n’était pas directement visible.

La station elle-même bloquait le calcul de l’itinéraire car les stations étaient définies comme un type d’objet de carte sur lequel les points de navigation étaient désactivés. L’activation des points de navigation sur les stations a résolu le calcul des itinéraires depuis les hangars.

Cliquer sur le marqueur d’une mission suivie dans la Starmap faisait beaucoup trop zoomer la caméra.

La distance de zoom était calculée à partir du minuscule rayon du marqueur lui-même au lieu d’un objet voisin de taille appropriée. La correction calcule désormais la distance de zoom et de mise au point à partir d’un objet de référence plus pertinent.

▲ STARC-170842 - Les membres d’un groupe recevaient une notification « connected » à chaque changement d’autorité serveur d’un coéquipier, et pas seulement lorsqu’il rejoignait le groupe pour la première fois.

Le service de messagerie backend envoyait la notification à chaque transfert entre serveurs lié au Server Meshing, au lieu de le faire uniquement lors de la première connexion du joueur à un shard. La notification a pour le moment été désactivée grâce à un paramètre de configuration.

Les vaisseaux pouvaient effectuer un voyage quantique directement à travers des lunes qui auraient dû bloquer leur trajectoire.

Le contrôle de collision utilisé pour valider les points d’arrivée du voyage quantique ne prenait pas en compte l’occultation par les lunes, permettant aux vaisseaux de les traverser. Ce contrôle détecte désormais correctement les lunes bloquant la trajectoire.

IA

Comportement erratique des vaisseaux ennemis en combat, notamment des IA se figeant en plein affrontement ou fonçant directement sur le joueur.

Les causes comprenaient l’absence d’un tag de classe de chasseur sur un type de vaisseau, une manœuvre défectueuse provoquant une oscillation visible ainsi qu’une commande d’arrêt exécutée sans condition et immobilisant l’IA.

Chaque cause a été traitée individuellement et les tests de suivi ont confirmé que les manœuvres fonctionnent désormais correctement, sans nouveaux cas de blocage ou de collision volontaire.

Des chasseurs Vanduul Scythe apparaissaient passifs au lieu d’engager le combat sur le site d’une mission.

La configuration de l’IA du pilote pointait par erreur vers une ancienne activité par défaut provenant d’un projet sans rapport, au lieu du comportement correct consistant à rester en attente puis à engager le combat. La correction de cette référence a résolu le problème.

Yormandi pouvait rester bloqué dans un état inactif et refuser de reprendre ses attaques après avoir été déstabilisé.

Une correction combinant logique et données a traité la motivation de l’IA de la créature ainsi que la gestion des interruptions liées aux réactions à la douleur. Le problème est brièvement réapparu dans un cas particulier en pleine attaque, mais une correction supplémentaire l’a également résolu.

Amarrage et ravitaillement

▲ STARC-203449 - Les vaisseaux auxquels l’ATC attribuait un collier d’amarrage pouvaient ne pas parvenir à s’amarrer même lorsqu’ils étaient parfaitement alignés.

Dans Stanton, Nyx et Pyro, des vaisseaux pouvaient parfois se retrouver dans l’impossibilité d’accéder aux hangars et aux stations parce qu’un second joueur situé à proximité pouvait interférer avec le processus d’amarrage. Les tubes d’amarrage pouvaient également rester bloqués dans un état « already associated », empêchant toute nouvelle tentative.

Une correction a été confirmée comme fonctionnelle dans de nombreuses stations et avec plusieurs types de vaisseaux.

Les services ATC dédiés au fret pouvaient cesser de répondre, empêchant les demandes de zone de chargement.

Contacter Cargo Services dans les stations de Stanton, Nyx et Pyro pouvait parfois ne produire aucune réponse, empêchant les joueurs d’obtenir une zone de chargement pour le chargement automatique du fret.

Première heure

STARC-177016 - Les joueurs pouvaient rester coincés à l’intérieur du cockpit d’un vaisseau après sa destruction lors d’une collision.

La cause était qu’un siège pouvait parfois se détacher d’un vaisseau détruit avant que la séquence de destruction ne soit entièrement terminée, laissant le pilote vivant mais prisonnier, sans possibilité de sortir ou de s’éjecter, parfois indéfiniment.

La correction fait désormais en sorte que ce type de détachement de siège termine correctement la séquence de destruction au lieu de laisser le joueur bloqué.

Les véhicules récupérés pouvaient apparaître avec leur train d’atterrissage encastré dans le sol du hangar, empêchant le décollage.

Récupérer un véhicule tout en quittant la zone pendant son animation de rangement pouvait entraîner son apparition avec le train d’atterrissage coincé dans le sol. Le récupérer une nouvelle fois pouvait ensuite bloquer le bouton Retrieve du terminal ASOP.

Une correction ajoute une phase de validation et de réparation qui corrige le positionnement du véhicule lorsque cela se produit.

Le radar du vaisseau et d’autres systèmes restaient éteints après un cycle d’alimentation.

Couper puis rétablir l’alimentation d’un vaisseau pouvait laisser le radar et d’autres systèmes hors service, ce qui constituait une mauvaise première impression pour les nouveaux pilotes.

La cause profonde était une condition de concurrence liée au timing dans le système d’alimentation. La correction suit désormais les systèmes qui n’ont pas réussi à se rallumer et les réactive automatiquement.

▲ STARC-179201 - Les missions de patrouille comportant un objectif de scan satellite pouvaient se bloquer lorsqu’un satellite n’apparaissait pas.

Certaines missions de patrouille demandent de scanner une zone déterminée à l’aide d’un satellite, mais il pouvait arriver qu’aucun satellite n’apparaisse dans cette zone, bloquant définitivement l’objectif et donc la mission.

La logique de mission ne recevait pas la confirmation que l’apparition du satellite avait réellement réussi. La correction ajoute une position d’apparition de secours afin que l’objectif puisse tout de même être terminé si l’emplacement initial échoue.

Les scans Ping affichaient le nom et la faction d’une cible comme « Unavailable ».

Scanner une cible avec l’onde Ping du vaisseau ou via le MFD Target Status affichait son nom et sa faction comme « Unavailable », même lorsque ces données auraient dû être connues.

Une correction affiche désormais immédiatement le nom du modèle du véhicule scanné.

Les tourelles habitées et télécommandées utilisaient par défaut des modes de visée différents et incohérents.

Les tourelles habitées utilisaient par défaut le mode gimbal/visée automatique, alors que la même tourelle contrôlée à distance utilisait par défaut une visée par PIP. Le comportement dépendait donc de la manière dont la tourelle était contrôlée.

La logique du mode de visée de la tourelle ne se réinitialisait pas correctement lors du passage entre contrôle habité et contrôle à distance.

Sélectionner Repair sur un pad d’atterrissage ne bloquait pas assez rapidement les autres services.

Lorsque Repair était sélectionné dans les services d’atterrissage, les autres options n’étaient pas désactivées suffisamment rapidement. Une requête de service concurrente pouvait donc être envoyée et annuler silencieusement la réparation.

La condition de concurrence sous-jacente entre les deux requêtes a été corrigée.

▲ STARC-214209 - Demander plusieurs services d’atterrissage simultanément pouvait obliger à demander Repair une seconde fois.

Demander Repair en même temps que Restock ou Refuel affichait tous les services comme étant en cours de traitement, mais la réparation pouvait échouer silencieusement et devoir être demandée une nouvelle fois.

▲ STARC-131916 - Définir un itinéraire sur la minimap n’affichait aucune ligne de trajet.

Tracer un itinéraire personnalisé à travers la minimap ne produisait aucune ligne de guidage visible, laissant les joueurs sans chemin à suivre jusqu’à leur destination.

Le calcul d’itinéraire n’était disponible que côté serveur. La correction appelle désormais directement la logique de pathfinding afin que la ligne d’itinéraire s’affiche correctement.

De nombreuses armes FPS étaient affichées sous forme de modèles grossiers et peu détaillés à des distances modérées.

Les fusils, SMG, fusils à pompe et fusils de précision présentaient des modèles LOD manifestement trop peu détaillés dans les miniatures de l’inventaire et des kiosques de fabrication, ainsi que dans le monde du jeu à des distances pourtant modérées.

Les paramètres de transition LOD de ces armes ont été ajustés afin que les modèles à plus haut niveau de détail s’affichent comme prévu.

▲ STARC-127424 - Le kiosque Ore Deposit de Klescher échouait systématiquement lors de l’échange de pierres précieuses contre des merits.

Les détenus du Klescher Rehabilitation Facility ne pouvaient pas échanger leur minerai extrait contre des merits permettant de réduire leur peine : le kiosque Ore Deposit affichait systématiquement une erreur « Transaction Failed ».

Le kiosque déterminait incorrectement si le minerai était stocké dans un sac à dos et envoyait la demande de vente vers la mauvaise liste d’inventaire. Cette recherche a été corrigée.

▲ STARC-214870 - La vente de minerai depuis un ascenseur de fret via un kiosque de marchandises échouait avec une erreur de requête d’entité.

La vente de minerai extrait — Dolivine, Aphorite ou Hadanite — stocké sur un ascenseur de fret via un kiosque de marchandises échouait avec une erreur « Failed Entity Query » au lieu d’effectuer la transaction.

Le client calculait incorrectement le prix de la transaction, ce qui entraînait son rejet lors de la validation côté serveur. Le calcul a été corrigé.

Les bases des gisements miniers épuisés n’étaient pas supprimées lors de la réapparition du gisement.

Les bases des ressources exploitables et des gisements miniers restaient indéfiniment après leur épuisement, encombrant les zones minières même après la réapparition d’un nouveau gisement au même endroit.

La file d’attente des délais d’expiration du système de nettoyage était triée dans le mauvais ordre, empêchant les minuteries de disparition de se déclencher. Cet ordre a été corrigé.

L’indication de ravitaillement pouvait rester bloquée à l’écran après une réapparition en cours de mission, empêchant l’affichage d’autres notifications.

Il s’agissait d’une variante du problème où l’indication « Dock with Refueler » restait bloquée à l’écran, cette fois après une réapparition en cours d’une mission de ravitaillement.

Les grenades actives et armées n’affichaient pas leur marqueur d’avertissement sur le HUD.

Les grenades lancées encore armées n’affichaient pas le marqueur HUD destiné à avertir les joueurs proches du danger.

Le radar FPS dont dépend ce marqueur avait été entièrement désactivé en tant qu’ancien contournement d’un précédent exploit. La suppression de ce contournement a rétabli l’indicateur d’avertissement des grenades.

▲ STARC-191377 - Les marqueurs HUD des membres du groupe n’affichaient qu’un chevron et la distance, sans le nom du membre.

Le marqueur HUD des membres du groupe affichait une flèche de direction et la distance, mais pas le nom de la personne.

Une liaison de données de l’interface contrôlant la visibilité du nom renvoyait constamment zéro. Cette liaison a été corrigée.

Économie et exploits généraux

Même si nous ne communiquons pas publiquement sur toutes les corrections d’exploits, nous souhaitions tout de même préciser que nous en avons corrigé 17 dans l’Alpha 4.10.

Cela comprend notamment l’exploit économique le plus signalé du jeu, qui injectait une quantité importante d’aUEC dans l’économie et nécessitait des ajustements répétés de la part de notre équipe Game Security.

Et ensuite ?

L’Alpha 4.10 ne signifie pas que ce travail est terminé. Certains problèmes sont toujours en cours de traitement, certaines corrections sont déjà en développement, et d’autres problèmes ne se révéleront qu’une fois la 4.10 utilisée à l’échelle des serveurs Live.

Cette initiative se poursuit, et la liste des priorités continuera d’évoluer à mesure que des problèmes seront résolus et que de nouveaux apparaîtront.

Vous pouvez également vous attendre à davantage de hotfixes après la sortie, tandis que nous continuerons à traiter les problèmes au fur et à mesure de leur apparition. Certains sont déjà prévus pour plus tard cette semaine.

Notre objectif est d’atteindre un stade où ces systèmes fondamentaux seront suffisamment stables et fiables pour que vous n’ayez plus à y penser ni à organiser votre session de jeu en fonction des problèmes à éviter.

Ces systèmes doivent simplement fonctionner.

Maintenir cette priorité signifie également devoir prendre des décisions difficiles concernant d’autres travaux. Pour le moment, nous avons réduit la priorité d’un certain nombre d’autres initiatives et fonctionnalités afin de conserver notre élan sur ces problèmes fondamentaux et de leur accorder l’attention qu’ils méritent.

Et nous avons besoin de votre aide pour poursuivre ce travail.

Les rapports de l’Issue Council ainsi que vos retours sur les autres plateformes nous permettent de comprendre quels problèmes affectent le plus grand nombre de joueurs et dans quels domaines nos efforts peuvent avoir le plus d’impact.

Des étapes de reproduction détaillées, des vidéos et des informations complémentaires font une énorme différence entre simplement savoir qu’un bug existe et réellement comprendre pourquoi il se produit.

Et si un problème que nous avons indiqué comme corrigé ne l’est toujours pas pour vous, nous avons également besoin de le savoir.

Mais surtout, merci à toutes les personnes qui ont pris le temps de signaler des problèmes, de partager des vidéos, de fournir des étapes de reproduction et de nous aider à retrouver l’origine de ces bugs.

Nous savons que certains d’entre vous subissent certains de ces problèmes depuis bien plus longtemps qu’ils n’auraient dû.

Vos retours font une énorme différence pour nos équipes et nous aident à mettre en place des corrections qui tiennent dans la durée.

Il reste encore du travail à accomplir, et nous continuerons à vous tenir informés de nos avancées.