LooPing

Que l'on soit vacciné ou pas, nous sommes tout à fait en droit de nous poser des questions sur l'injection que nous avons reçue ou que l'on envisage de recevoir. il n'y a pas beaucoup d'études qui parlent des effets de la protéine Spike amené par le vaccin. Une étude vient de sortir en Suède elle a été présentée le 20 août 2021, révisée le 8 septembre 2021 et elle a été acceptée le 8 octobre et publié le 13. tout cela pour vous dire que cette étude est tout à fait sérieuse, elle vient du département de bio science moléculaire de Stockholm et du département de microbiologie clinique, virologie de l'université d'Umeå. si ça vous intéresse vous pouvez la retrouver à cette adresse : https://www.mdpi.com/1999-4915/13/10/2056/htm MDPI (Multidisciplinary Digital Publishing Institute) : est un éditeur de revues scientifiques en libre accès. MDPI publie plus de 300 revues couvrant une grande variété de champs scientifiques, et lance environ dix nouvelles revues chaque mois. je ne vais pas m'improviser biologiste moléculaire, du coup, pas de résumé dans ce post je ne prendrai pas le risque de vous induire en erreur. Faites-vous votre propre idée avec le résumé et l'introduction de l'étude qui sont assez compréhensibles et pour les plus aguerris ils pourront se balader dans l'étude complète pour en tirer leurs conclusions.

A : RECRUES DE SQUADRON 42 SUBJ : MISE À JOUR DU DÉVELOPPEMENT 10:06:2021 REF : CIG UK, CIG DE, CIG LA, CIG TX FAO recrues de Squadron 42 Bienvenue au rapport de développement de Squadron 42 du mois d'octobre. Vous y trouverez des détails sur les derniers progrès réalisés dans le cadre de la campagne, notamment les mises à jour des services backend essentiels, des comportements de l'IA et des communications dans le cockpit. Sincèrement, CIG COMMUNICATIONS Contenu de l'IA Parallèlement au travail sur le statut des acteurs partagé avec le PU, l'équipe chargée du contenu de l'IA a progressé sur des tâches spécifiques à Squadron 42, notamment les utilisables Cryopod et Simpod. L'utilisable Simpod est un poste de travail où le joueur ou les PNJ peuvent s'entraîner. Une fois terminé, il sera disponible pour les artilleurs des PNJ qui pourront s'entraîner à manier leur tourelle dans un espace sécurisé. Le Cryopod utilisable est un conteneur de stockage au froid pour préserver les humanoïdes, avec des signes vitaux affichés sur des écrans externes. La première itération permet aux PNJ de vérifier la santé de l'occupant sur le terminal et de dégager le givre de la fenêtre du pod. Les animateurs ont également peaufiné les données de capture de mouvement recueillies plus tôt dans l'année. C'est la dernière étape pour fournir les interactions utilisables initialement demandées pour le niveau Aciedo. Fonctions d'IA Tout au long du mois d'octobre, l'équipe chargée des fonctions d'IA s'est principalement concentrée sur le comportement de combat des Vanduul, qui est fortement axé sur la mêlée, ce qui a permis à l'équipe de progresser avec le système d'attaques combinées précédemment détaillé. Les nouveaux ajouts incluent des paramètres aux attaques combo pour prototyper rapidement des animations de mêlée plus rapides en ajustant un facteur d'échelle. Cela leur permet d'équilibrer rapidement la vitesse des animations, de sorte que le rythme du combat rapproché peut être modifié pour augmenter ou diminuer le défi pour le joueur. Le ciblage des mouvements se met désormais à jour tout au long des attaques de mêlée afin que les personnages puissent réajuster leur positionnement pour atteindre correctement leurs cibles. L'équipe a également amélioré la façon dont les staggers peuvent être déclenchés. Désormais, les personnages de grande taille peuvent déclencher des staggers après un tir de balle soutenu pour interrompre leurs attaques de mêlée. L'équipe a également travaillé sur la prévisualisation de l'expérience cinématique des Vanduul, sur les animations d'une configuration de navigation spécifique permettant aux PNJ de s'esquiver sous les obstacles, ainsi que sur la reddition et l'utilisation de la couverture non entraînée. Animation Le mois dernier, l'équipe d'animation a travaillé sur divers comportements d'IA, y compris des interactions volontaires et affolées avec des consoles, la navigation sous des portes cassées, le bris de serveurs informatiques et de conduits d'aération, et la recherche par-dessus des rampes et autour de boîtes et de conduits d'aération. Ils ont également passé du temps à travailler sur le combat contre les Vanduul aux côtés de l'équipe d'IA, en fixant des animations pour les Vanduul passant à travers des portes fermées ou partiellement fermées et cassant des équipements. Les améliorations se sont poursuivies sur le gameplay en zéro-g et les animations des joueurs au sol. Du côté des visages, l'équipe a poursuivi sa passe d'amélioration sur la prochaine série de personnages. Le développement des scènes de jeu s'est poursuivi afin de donner une vie narrative à l'environnement, en incluant la capture de mouvement si nécessaire. Art (Personnages) L'équipe Character Art and Tech a passé le mois à peaufiner la faction Navy de SQ42, en retravaillant de nombreuses anciennes tenues pour les adapter aux normes de qualité actuelles. Il s'agissait notamment des vestes d'officier de pont, des pulls d'uniforme de combat et des tenues du personnel médical de la Navy. Ils ont également peaufiné les têtes et les cheveux de personnages importants comme Bishop et Trejo. Art (Environnement) L'équipe Art (Environnement) a soutenu l'étape importante du projet, en contribuant à apporter une qualité visuelle au travail présenté par les autres équipes. Par ailleurs, l'équipe a poursuivi le travail sur de nombreux chapitres, notamment les chapitres 5, 12 et 13, et a poussé les découpes verticales à un niveau visuel élevé sur les chapitres 7 et 19. De nouveaux progrès ont été réalisés dans la création de paysages spatiaux d'une qualité exceptionnelle, afin d'apporter plus de dynamisme et d'éclat aux scènes spatiales cinématiques. Audio L'audio a continué à étudier les systèmes de SQ42 et a planifié son soutien futur à la campagne. Cinématique L'équipe Cinematics a beaucoup travaillé sur le chapitre d'ouverture du jeu, qui a reçu une révision bien méritée de la technologie des planètes et des vues. En raison de la nouvelle configuration de l'espace, l'équipe a dû évaluer si certains plans étaient toujours valables ou si des repérages supplémentaires étaient nécessaires pour tirer le meilleur parti de la nouvelle nébuleuse géante du mur de tempête. Les concepteurs cinématographiques anticipent toujours les éléments futurs et cadrent leurs caméras en fonction de ceux-ci, mais le fait de voir les vues réelles dans la caméra peut parfois nécessiter de reconsidérer le cadrage. Le soleil a également changé de position de quelques degrés en raison de l'accumulation artistique. Des variantes de vaisseaux existants comme le Bengal ont été conçues, construites et livrées, tandis que de nouveaux vaisseaux ont été créés pour la flotte Vanduul. Toutes les scènes de pont mettant en scène l'amiral Bishop et son homologue vanduul ont également progressé. La plupart des scènes ont reçu leur "passe de contact pour les accessoires et les doigts". Désormais, tous les officiers sont correctement placés dans leur siège, leurs mains touchant les commandes réactives et bougeant selon les besoins. Par exemple, les doigts saisissent correctement un écran pivotant. Nous avons également consacré du temps à la création de séquences de cascades réutilisables de vaisseaux en train de se battre ou d'être détruits, que le joueur peut voir depuis la fenêtre d'un couloir ou sur le pont d'un vaisseau pendant la bataille. Une séquence clé de la tourelle a été étoffée, avec des coupes créées pour distinguer les vagues et les différents défis. Cela a conduit à l'élaboration et à l'amélioration de nombreux plans de navigation. Enfin, en ce qui concerne les cinématiques, le récent aménagement de l'espace, les ajouts de flotte, le polissage de la mo-cap et le soleil modifié ont permis de repenser le plan d'ouverture du jeu, en le rendant meilleur et plus dynamique. Moteur Le mois dernier, l'équipe de physique a consacré du temps à diverses optimisations. Le processus de voxélisation des maillages triangulaires a été accéléré en utilisant une structure d'accélération basée sur les lignes de balayage au lieu d'une structure basée sur les voxels lors du remplissage des cellules. L'équipe a également aidé AI Code à optimiser sa routine de mise à jour de la carte audio en regroupant le traitement des stimuli. De plus, le tri des événements de collision a été optimisé, et la physique des brosses par défaut est maintenant créée progressivement. Une visualisation de débogage pour l'historique des collisions a également été implémentée. Enfin, en ce qui concerne la physique, une grille quantique arborescente a été implémentée. Elle sera utilisée pendant le boosting du voyage quantique et le voyage quantique normal pour détecter les collisions et les obstacles le long du chemin. Pour le moteur de rendu, des efforts considérables ont été consacrés à l'amélioration des résultats du profileur de pipeline pour les chemins de rendu Gen12 et anciens. Cela a été fait pour obtenir une évaluation précise de la durée de traitement des passes de rendu et de calcul sur les CPU et GPU sans trop affecter le taux d'images réel (profilage en temps réel). Des progrès significatifs ont également été réalisés dans la transition vers la Gen12 : Les objets d'état du pipeline sont désormais compilés à la demande pour améliorer les temps de chargement, l'instanciation massive est désormais prise en charge et la gestion des tampons d'instance a été optimisée. La scène de rendu Scaleform utilisée pour le menu et l'interface utilisateur dans le monde du jeu a été optimisée pour réduire le nombre moyen de scènes de 2000 à un maximum de 60, l'état du pipeline étant également créé à la demande. En outre, le code des particules, l'atlas de lumière et l'analyseur de shaders ont été remaniés. L'intégrité du contenu a été renforcée en ajoutant des alertes de données pour les shaders invalides utilisés dans les matériaux. La prise en charge des mises à jour de la texture des matériaux (animation de la texture) a également été ajoutée. Des améliorations ont continué à être apportées à l'éclairage indirect des nuages et de l'atmosphère en fonction de la présence de nuages dans l'atmosphère. La partie initiale de ce travail a été achevée (génération LUT), le travail reprenant une fois que les optimisations de performance prévues seront en place. Pour mettre en place ces dernières, le travail sur la chaîne de reprojection et de filtrage a commencé afin de permettre la réutilisation temporelle et spatiale des résultats de raymarch. À cette fin, la R&D a commencé à travailler sur la reprojection sans vecteurs de mouvement (car ceux-ci ne peuvent pas représenter correctement les médias participants). L'équipe du noyau du moteur a également travaillé sur le code du flux d'entités, qui prend désormais en charge l'élimination des sphères nécessaire à SQ42. Une refonte importante a été soumise au planificateur de mise à jour des composants d'entité. Cela inclut une nouvelle API qui utilise les ID de mise à jour au lieu des passes pour permettre plusieurs mises à jour par passe. Le frame profiler du moteur a été mis à jour pour inclure diverses statistiques provenant des événements Heartbeat ainsi qu'un résumé du temps CPU et de l'utilisation de la mémoire par les équipes de développement, des informations sur la construction et une capture d'écran dans la capture. Le gestionnaire de mémoire a été étendu pour prendre en charge des arènes d'allocation et des caches de threads séparés par équipe de développement. En cas d'accès mémoire invalide, le gestionnaire d'exception peut maintenant indiquer à quelle arène une adresse mémoire inaccessible correspond. Cela permet de déboguer les crashs mémoire avec une vérification plus fine de la mémoire, ce qui signifie généralement que la compilation s'exécute beaucoup plus rapidement et utilise moins de mémoire que si le débogage de la mémoire était activé globalement. En outre, le travail s'est poursuivi sur l'amélioration de l'élimination des frustums et la fonctionnalité de capture et de transmission des lambdas C++ sans allocations de tas a été ajoutée. Fonctionnalités (Gameplay) Gameplay Features a accompli de petites tâches de soutien tout en progressant sur plusieurs séquences cinématiques très complexes. Une grande partie de ces tâches concernait des problèmes techniques liés à la façon dont le moteur a dû être modifié pour prendre en charge le streaming des conteneurs d'objets. Comme certains systèmes existants ne sont pas conscients du streaming, l'équipe a dû trouver des moyens de corriger les références aux véhicules qui ne sont pas chargés par défaut mais qui apparaissent plus tard dans une mission. Le personnalisateur de personnage de base fonctionnant dans le jeu, l'équipe a continué à travailler en liaison avec les équipes concernées pour prototyper l'expérience utilisateur. Plusieurs modifications ont été apportées pour supprimer certaines limites codées en dur, comme le nombre de zones du visage que les joueurs peuvent modifier ou le nombre de têtes entre lesquelles ils peuvent se fondre. L'équipe note qu'il peut être difficile de créer une interface utilisateur intuitive sans entraver la puissance et la liberté du système. Histoire du jeu Tout au long du mois d'octobre, Gameplay Story a travaillé sur une grande variété de scènes et de chapitres. Un travail de polissage a été effectué sur le chapitre 1, avec plusieurs scènes mises à jour avec de nouveaux sons, tandis que le walk-and-talk de Graves au chapitre 5 a bien progressé. Une scène de briefing du chapitre 8 a reçu une nouvelle mo-cap, tandis qu'une scène compliquée du chapitre 12 a été complètement remaniée. L'interaction tactile a également progressé, ce qui, bien que difficile à mettre en œuvre, permet aux personnages de se sentir plus vivants et présents dans le monde. Graphisme et programmation VFX L'équipe graphique a continué à améliorer les volumes d'eau, en se concentrant cette fois sur la façon de simuler correctement l'éclairage volumétrique sous la surface. Deux approches ont été adoptées : La première utilise le système général de brouillard voxel, bien qu'il présente plusieurs limitations qui le rendent inapplicable aux volumes d'eau très grands ou très petits. La seconde approche consiste à réutiliser le modèle d'éclairage par particules, qui est moins précis mais peut fonctionner à des échelles plus extrêmes. Nous avons également commencé à travailler sur les changements à apporter au système de matériaux pour permettre aux shaders de devenir plus modulaires. Il s'agit d'un tremplin vers la construction d'une nouvelle suite de shaders qui offrent plus de puissance et de flexibilité aux artistes sans nécessiter une réingénierie complexe de la part des programmeurs graphiques. Le travail sur Gen12 s'est poursuivi, avec la conversion d'autres systèmes. L'équipe cherche également à achever une vaste refonte des échantillonneurs de texture pour les rendre compatibles avec Gen12/Vulkan. Parmi les autres tâches accomplies, citons les nouvelles fonctions d'animation de la lumière, le travail de conception technique pour l'utilisation des cartes de dégâts pour la récupération, les corrections de gamma et le support général de la fonction feu. Conception des niveaux L'équipe Space/Dogfight a poursuivi son travail sur les espaces de patrouille étendus. Le mois dernier, elle a incorporé davantage de points d'intérêt optionnels dans les premières parties du jeu, certaines actions du joueur dans ces zones pouvant avoir des ramifications dans les chapitres suivants. Ils ont également travaillé en étroite collaboration avec l'équipe chargée de l'IA des vaisseaux pour créer des comportements d'IA plus réalistes et plus stimulants afin de permettre de meilleurs combats rapprochés en dogfight. Après avoir parcouru l'ensemble des zones terrestres du jeu jusqu'au niveau des ouvertures de portes, l'équipe FPS a commencé à étoffer les espaces avec l'IA et de nouveaux mécanismes. L'équipe de conception sociale a poursuivi l'important travail d'implémentation de toutes les scènes de jeu pour les différents chapitres afin qu'elles soient examinées et approuvées, ce qui sera le cas pendant de nombreux mois à venir. Narration Le mois dernier, l'équipe chargée de la narration a mis en œuvre, aux côtés des équipes chargées du dialogue et de la conception, les améliorations apportées au pipeline des dialogues de remplacement décrites dans le rapport de septembre. Ce processus révisé permet à l'équipe de placer rapidement les dialogues nouvellement écrits dans le jeu pour les tester. Au fur et à mesure que le jeu s'affine, c'est souvent une seule ligne de dialogue qui doit être ajustée plutôt qu'une scène entière. Une documentation de suivi révisée a donc été élaborée pour aider l'équipe à mieux suivre le statut des demandes de dialogues supplémentaires au fur et à mesure qu'elles arrivent. L'équipe a également amélioré quelques scènes de tutoriel afin de mieux instruire le joueur sur les éléments clés du gameplay. Les scènes qui sont étroitement liées au gameplay sont souvent améliorées en permanence au fur et à mesure que le développement progresse. QA Les cinématiques ont continué à s'appuyer sur l'AQ pour les tests réguliers des chapitres. Le mois dernier a également été consacré aux tests des outils de cinématique et à la correction de nombreux défauts des outils lors du rendu des scènes. Ils ont également continué à soutenir les implémentations de comportement de l'équipe IA, le mois dernier se concentrant sur les améliorations de l'IA Vanduul et la mise à niveau des fonctions IA existantes. Tech Animation En octobre, Tech Animation a achevé sa longue tâche de mise à niveau du pipeline de création et d'animation de têtes. "Nous avons réécrit des parties importantes du système d'ADN utilisé pour créer nos acteurs dans le jeu. En plus de cela, nous avons ajouté un support pour la création et l'édition de ces assets de tête dans Maya par le biais d'un plugin qui partage la même base de code et une grande quantité d'outils pour l'utiliser efficacement. Cela nous a permis de dépasser les limites actuelles de notre pool de gènes et de nous tourner vers l'avenir." - Animation technique Désormais, tous les types de rigs de visage sont viables (y compris les animaux et les extraterrestres), avec la perspective de mettre à niveau ou de personnaliser les rigs d'animation faciale pour tout ce qui sera nécessaire à l'avenir. Cette technologie est également en cours de perfectionnement pour des formes plus complexes de déformation. Tech Animation est presque prêt à présenter le pipeline de création de têtes qu'il a créé en tandem avec le système ADN. Cela leur donnera la possibilité de créer de nouveaux rigs de visage pour les pools de gènes ADN et de contrôler étroitement la qualité des assets. Des outils supplémentaires ont été créés au cours du trimestre pour inclure l'exportation de cache d'alambic dans le pipeline d'animation. Cette fonction a toujours été prise en charge, mais le fait de l'inclure de cette manière a ouvert de nouvelles possibilités pour les équipes d'animation et de technologie, qui ont pu l'inclure directement dans leurs pipelines d'animation en tant que préférence d'exportation. L'équipe prévoit de tirer parti de cette technologie pour réaliser d'impressionnants spectacles durant Squadron 42. L'animation a également poursuivi le développement du pipeline d'outils et a affiné certains codes et outils plus anciens pour qu'ils continuent à fonctionner comme prévu. UI L'équipe UI a créé des décalcomanies pour un niveau spécifique et de nouveaux styles de Building Blocks à utiliser sur des écrans interactifs dans certains des environnements clés du jeu. VFX L'équipe VFX a poursuivi le travail détaillé le mois dernier, l'équipe d'intervention travaillant en étroite collaboration avec l'équipe Cinematics en particulier, l'aidant à remplir une scène de bataille épique avec des effets visuels. CONCLUSION ON SE VOIT LE MOIS PROCHAIN.... Traduction : @Maarkreidi Swiss Starships

MAILLAGE DE SERVEURS ET STREAMING PERSISTANT Q&A Lors de la CitizenCon 2951, nous avons plongé dans les technologies de changement que sont le Server Meshing et le Persistent Streaming, avec Paul Reindell (directeur de l'ingénierie, Online Technology) et Benoit Beausejour (directeur de la technologie chez Turbulent). Après le panel, nous avons constaté que de nombreuses personnes avaient des questions à poser à nos panélistes, et nous voulons nous assurer qu'elles reçoivent une réponse. Nous vous invitons à lire la suite de notre entretien avec Paul, Benoit, Roger Godfrey (producteur principal) et Clive Johnson (programmeur réseau principal). Quand verrons-nous le Streaming persistant et le Server Meshing dans le PU ? Notre objectif actuel est de publier le streaming persistant et la première version de la couche de réplication, idéalement entre le premier et le deuxième trimestre de l'année prochaine. Nous poursuivrons ensuite avec la première version d'un maillage de serveurs statiques, sauf complications techniques imprévues, entre le troisième et le quatrième trimestre de l'année prochaine. Quel est l'état actuel de la technologie de maillage de serveurs et quels sont les principaux problèmes qui la freinent ? La plupart des gens, lorsqu'ils parlent de maillage de serveurs, pensent généralement à l'étape finale de cette technologie qui consiste à "mailler les serveurs ensemble". La vérité est qu'avant cette étape finale, une très longue chaîne de pré-requis et de changements technologiques fondamentaux doivent être apportés à notre moteur de jeu. En gardant cela à l'esprit, je vais essayer de répondre à cette question en tenant compte de l'ensemble du tableau. La réponse courte est que l'état est en fait très avancé. Maintenant, la version longue. La route vers le maillage de serveurs a commencé en 2017/2018 : Streaming de conteneurs d'objets Pour que le Server Meshing fonctionne, nous avions d'abord besoin d'une technologie qui nous permette de lier/délier dynamiquement des entités via le système de streaming, car ce n'est pas quelque chose que le moteur prenait en charge lorsque nous avons commencé. Ainsi, lorsque nous avons lancé le "Client Side Object Container Streaming" (OCS) en 2018, nous avons également lancé la toute première étape vers le maillage de serveur ! Une fois ce premier pas franchi, la technologie qui nous permet de lier/délier dynamiquement des entités sur le client devait être activée sur le serveur également (car, en fin de compte, les nœuds de serveur dans le maillage devront diffuser des entités en entrée/sortie de manière dynamique). Cette technologie est appelée "Server Side Object Container Streaming" (S-OCS), et la première version de S-OCS a été publiée à la fin de 2019. Il s'agissait de la prochaine grande étape vers le maillage de serveur. Autorité des entités et transfert d'autorité Alors que nous disposions de la technologie nous permettant de diffuser dynamiquement des entités sur le serveur, il n'y a toujours qu'un seul serveur qui " possède " toutes les entités simulées. Dans un maillage où plusieurs nœuds de serveur partagent la simulation, nous avons besoin du concept d'"autorité des entités". Cela signifie qu'une entité donnée n'est plus la propriété d'un seul serveur de jeu dédié, mais qu'il existe plusieurs nœuds de serveur dans le maillage. Ainsi, un nœud de serveur qui contrôle l'entité, et plusieurs autres nœuds de serveur qui ont une vue client de cette entité. Cette autorité doit également pouvoir être transférée entre les nœuds de serveur. Une bonne partie du temps de développement a été consacrée au concept d'"autorité de l'entité" et de "transfert d'autorité" au cours du premier semestre de 2020. C'est la première fois que l'ensemble de l'entreprise a dû travailler sur le maillage des serveurs, car une grande partie du code de jeu a dû être modifiée pour fonctionner avec le nouveau concept d'entité-autorité. À la fin de l'année 2020, la plupart du code (de jeu) a été modifié pour prendre en charge le concept, donc une autre grande étape a été franchie, mais il n'y a pas encore de maillage réel en vue. Couche de réplication et flux persistant L'étape suivante a consisté à déplacer la réplication des entités dans un endroit central où nous pouvons contrôler le streaming et la logique de liaison au réseau. Cela nous permet ensuite de répliquer l'état du réseau sur plusieurs nœuds de serveur. Pour ce faire, nous avons dû déplacer la logique de streaming et de réplication du serveur dédié vers la couche "Réplication", qui héberge désormais le code de réplication du réseau et de streaming des entités. Dans le même temps, nous avons également implémenté le streaming persistant, qui permet à la couche de réplication de faire persister l'état des entités dans une base de données de graphes qui stocke l'état de chaque entité répliquée en réseau. L'année 2021 a été consacrée au travail sur la couche de réplication et l'EntityGraph, qui nous permet de contrôler le streaming et la réplication des entités à partir d'un processus distinct (séparé du serveur de jeu traditionnel dédié). Ce travail est presque terminé et se trouve dans sa phase finale. Maillages de serveurs statiques et dynamiques Cependant, il ne s'agit pas encore d'un "maillage". Le travail sur le maillage réel a commencé et il nous faudra une bonne partie de l'année prochaine pour le terminer, et toutes les conditions préalables que j'ai décrites ci-dessus étaient nécessaires pour en arriver à ce point. La première version de cette technologie sera un maillage de serveurs statiques et constitue le prochain grand pas en avant. Cependant, ce ne sera pas non plus la dernière ! Avec le maillage statique, nous disposerons de la première version d'un véritable maillage mais, comme le nom "statique" l'indique, la capacité à faire évoluer ce maillage est très limitée. Avant de pouvoir vraiment qualifier cette fonctionnalité de complète, nous devrons franchir une autre étape importante, que nous appelons "maillage dynamique". Cette étape nous permettra de mailler dynamiquement les nœuds de serveur ensemble, puis de faire évoluer le maillage dynamiquement en fonction de la demande. Une grande partie du travail sur cette partie se fait en parallèle. Par exemple, le gestionnaire de flotte qui contrôle la demande dynamique du maillage est déjà en cours de développement, de même que les exigences en matière de matchmaking qui accompagnent la nouvelle inclusion des "shards". Pendant ce temps, de nombreuses équipes de code de jeu doivent également travailler à l'adaptation du code de jeu existant pour qu'il fonctionne pleinement avec un maillage de serveur (et surtout trouver tous les cas limites qui ne feront surface qu'une fois que nous aurons un véritable maillage). Bien que le travail sur l'autorité des entités ait été achevé en 2020, l'autorité des entités n'est actuellement transférée qu'entre le client et un seul serveur, de sorte que certains codes peuvent nécessiter des ajustements supplémentaires. Comment envisagez-vous de gérer un grand vaisseau, par exemple un Javelin ? Aurait-il sa propre ressource dédiée avec les vaisseaux qui l'entourent ? Avec le maillage de serveur dynamique, il est possible que les grands vaisseaux tels que le Javelin aient leur propre serveur dédié pour exécuter la simulation faisant autorité pour ce vaisseau et tout ce qu'il contient. Cependant, nous essayons d'éviter d'avoir des règles inflexibles sur la façon dont les entités sont assignées aux ressources de traitement, donc ce ne sera pas toujours le cas. C'est une question d'efficacité, tant en termes de vitesse de traitement que de coûts de serveur. Si nous avions une règle stricte selon laquelle chaque Javelin et tout ce qu'il contient reçoit son propre serveur, cela ne serait pas très rentable lorsqu'un Javelin ne compte qu'une poignée de joueurs. La même règle ne serait pas non plus efficace en termes de vitesse de traitement des serveurs s'il y avait des centaines de joueurs entassés dans le même Javelin, car la règle nous empêcherait de répartir la charge de traitement sur plusieurs serveurs. Le maillage dynamique des serveurs sera un peu différent dans la mesure où il réévaluera constamment la meilleure façon de distribuer la simulation, afin de trouver le point idéal pour qu'aucun serveur ne soit surchargé ou sous-utilisé. Au fur et à mesure que les joueurs se déplacent dans le 'verse, la distribution idéale des ressources de traitement changera. Pour réagir à ces changements, nous devrons être en mesure de transférer l'autorité sur les entités d'un serveur à un autre, ainsi que de mettre en ligne de nouveaux serveurs et de fermer les anciens. Cela nous permettra de déplacer la charge de traitement d'un serveur qui risque d'être surchargé vers un serveur qui est actuellement sous-utilisé. Si aucun des serveurs existants ne dispose d'une capacité de réserve suffisante pour faire face à une augmentation de la charge, nous pouvons simplement louer d'autres serveurs auprès de notre fournisseur de plateforme de cloud computing. Et lorsque la charge de certains serveurs n'est plus suffisante pour les rendre rentables, certains d'entre eux peuvent transférer leurs parties de la simulation sur les autres et nous pouvons fermer ceux dont nous n'avons plus besoin. Combien de joueurs pourront se voir dans un même espace ? Quel est le maximum que vous prévoyez ? Il est difficile de répondre à cette question, et la meilleure réponse que nous puissions donner pour le moment est que cela dépend. En supposant que la question porte sur la limite du nombre de joueurs qui pourront se voir d'un point de vue client, elle est principalement dictée par le client du jeu. Cela est dû à la simulation côté client, comme la physique et le code de jeu, ainsi qu'au coût du rendu. De plus, cela dépend aussi fortement du scénario ; 100 joueurs en combat FPS sont moins chers à simuler et à rendre sur le client que 100 joueurs se battant dans des vaisseaux spatiaux monoplaces, tirant des missiles et des lasers les uns sur les autres. L'équipe graphique travaille activement sur Vulkan, qui nous permettra d'augmenter les appels de dessin et devrait améliorer le nombre de joueurs/de vaisseaux que nous pouvons rendre en même temps, tandis que l'équipe moteur se concentre sur les optimisations du code de jeu pour augmenter le nombre d'objets de jeu que nous pouvons simuler en même temps. Notre objectif est d'augmenter le nombre de joueurs et nous espérons pouvoir supporter des scénarios où 100 joueurs peuvent se voir à des fréquences d'images raisonnables. Cependant, lorsque nous commencerons à mettre à l'échelle nos shards pour supporter un nombre plus élevé de joueurs, la probabilité que chaque joueur d'un shard puisse se rendre au même endroit physique et se voir sans problème de performance diminuera. C'est là que nous devrons commencer à mettre en place des mécanismes de jeu qui empêcheront ces scénarios de se produire trop fréquemment. La limite absolue est difficile à prévoir tant que les nouvelles technologies ne sont pas en ligne et que nous ne pouvons pas commencer à mesurer les performances. Si je construis une base sur une lune, ma base sera-t-elle reflétée sur les autres shards sur lesquels je ne suis pas ? L'équipe de Planet Tech prévoit d'implémenter la construction de bases en tenant compte des shards du serveur. En revendiquant un terrain pour votre base, vous revendiquerez ce terrain sur tous les serveurs, et nous prévoyons de répliquer votre base sur tous les serveurs. Cependant, un seul serveur disposera d'une version "active" de la base, les autres serveurs générant une version "accès limité/lecture seule" de cette même base. Par exemple, une base donnera un accès complet et la possibilité de s'étendre dans le shard sur lequel le propriétaire joue actuellement, tandis que sur tous les autres shards, cette base peut apparaître avec des portes verrouillées dans un état immuable. Le design complet n'est pas encore établi à 100% et peut changer. Le véritable objectif final est-il un seul et unique shard pour tous les joueurs ? C'est notre ambition, mais il est impossible de donner une réponse définitive à ce stade. Nous commencerons avec de nombreux petits shards par région et réduirons lentement le nombre de shards. Le premier objectif majeur sera de réduire le nombre de shards à un seul par région. Pour y arriver, notre plan est d'augmenter progressivement le nombre de joueurs par shard et d'améliorer constamment le backend et la technologie du client pour supporter de plus en plus de joueurs. Il n'y a pas que les changements technologiques qui sont nécessaires pour atteindre cet objectif - une nouvelle conception du jeu et des mécanismes de jeu sont également nécessaires. Sans mécanismes pour empêcher chaque joueur de se rendre au même endroit, un grand méga-shard sera très difficile à réaliser, surtout sur le client. Par exemple, il pourrait y avoir un mécanisme permettant de fermer temporairement les points de saut vers des endroits bondés, ou de créer de nouvelles couches pour certains endroits. Alors que le backend est conçu pour évoluer horizontalement, le client de jeu fonctionne sur une seule machine et est limité à un nombre défini de cœurs CPU/GPU ainsi qu'à la mémoire. Ce n'est qu'une fois que nous aurons surmonté ces obstacles et réussi à créer un méga-shard par région que nous pourrons nous attaquer au boss final : Fusionner les shards régionaux en un méga-shard global. Cela pose son lot de problèmes, car la localisation joue un rôle important dans l'expérience du joueur. Par exemple, la latence entre les services au sein d'un même centre de données est beaucoup plus faible que la latence entre des services hébergés dans deux centres de données séparés par région. Et bien que nous ayons conçu le backend pour qu'il prenne en charge un seul shard mondial, c'est un défi opérationnel de déployer le backend de manière à ne pas favoriser un groupe de joueurs par rapport à un autre. L'économie de l'univers sera-t-elle indépendante dans chaque shard ou jointe ? L'économie sera globale et reflétée dans chaque shard. Par exemple, prenons le cas des boutiques. Alors que chaque boutique dispose d'un inventaire local (les objets qui sont actuellement exposés), les boutiques sont réapprovisionnées à partir d'un inventaire global partagé par tous les shards. Si de nombreux joueurs commencent à acheter une arme spécifique à la boutique d'armes de Port Olisar, le prix de cette arme augmentera dans cette boutique sur tous les mondes. Le stock de cette arme finira par être épuisé et les magasins de tous les mondes ne seront plus en mesure de la réapprovisionner. Qu'est-ce qui empêchera de grands groupes de "bleus" et de grands groupes de "rouges" de se retrouver dans des shards à chambre d'écho ? La dynamique sociale implique de grandes concentrations de personnes qui auront des amis et seront dans des organisations qui ont les mêmes intérêts. Y aura-t-il une solution pour assurer un bon mélange entre les bons, les mauvais et les intermédiaires ? Les joueurs ne seront pas assignés de façon permanente à un shard, car le système de matchmaking attribue un nouveau shard pour la région sélectionnée à chaque connexion. Au début, cela entraînera une distribution naturelle, car nous commencerons avec de nombreux petits shards en parallèle. Lorsque nous commencerons à faire évoluer nos shards (et donc à réduire le nombre de shards parallèles), cette question deviendra plus pertinente. Nous prévoyons d'y répondre avec notre nouveau système de mise en relation. Le nouveau système de mise en relation, actuellement en cours de développement parallèlement au maillage des serveurs, nous permet d'associer les joueurs aux shards en fonction de plusieurs paramètres d'entrée. Ces paramètres sont utilisés pour associer les joueurs à leurs amis ou à l'endroit où ils ont laissé la plupart de leurs objets dans le monde ouvert. Cependant, il nous permet également d'utiliser des paramètres plus avancés, tels que la réputation et d'autres statistiques cachées des joueurs que nous suivons. Cela nous permettra d'essayer de faire en sorte que chaque shard présente une collection semi-diversifiée d'individus. Par exemple, nous pourrions nous assurer que nous ne chargeons pas par inadvertance un shard avec uniquement des joueurs légaux, ce qui pourrait ne pas être très amusant si une partie de ce qu'ils veulent faire est de chasser les joueurs criminels. Votre personnage et votre vaisseau seront-ils toujours présents dans le jeu après votre départ ? Par exemple, si je me déconnecte du lit de mon vaisseau sur une planète, mon vaisseau sera-t-il toujours là, ce qui signifie que des personnes pourraient essayer de pénétrer dans mon vaisseau ou de le détruire ? Lorsqu'une entité est "déstockée" dans un shard (elle existe physiquement dans le shard), elle existe de manière permanente dans ce shard jusqu'à ce que le joueur "range" l'entité dans un inventaire. Cela peut se faire en ramassant une arme et en la plaçant dans son sac à dos, ou en faisant atterrir un vaisseau sur une aire d'atterrissage, ce qui place le vaisseau dans un inventaire spécifique de l'aire d'atterrissage. Une fois qu'une entité se trouve dans un inventaire, elle est stockée dans la base de données globale et peut être rangée dans n'importe quel shard. Cela permet aux joueurs de déplacer des objets entre les shards. Nous prévoyons également un mécanisme appelé "arrimage/désarrimage des objets de héros". Cela prendra tous les objets de héros appartenant au joueur et les rangera automatiquement dans un inventaire de transition de shard spécifique au joueur. Le rangement automatique se produit généralement lorsqu'aucun autre joueur n'est présent et que l'entité est diffusée. Les objets de cet inventaire de transition suivront automatiquement le joueur. Ainsi, lorsqu'un joueur se connectera à un autre shard, nous prendrons les entités et les rangerons dans le nouveau shard à l'endroit où le joueur les a laissées. Lorsque vous posez votre vaisseau sur une lune et que vous vous déconnectez, le vaisseau disparaît et est automatiquement rangé si aucun autre joueur n'est présent à ce moment-là. Maintenant, lorsque vous vous connectez à un autre shard, votre vaisseau sera désarrimé dans le nouveau shard. Si, pour une raison quelconque, le vaisseau est resté plus longtemps dans l'ancien shard et a été détruit alors que vous étiez déconnecté, vous pouvez vous réveiller dans un lit médicalisé. Dans quelle mesure le nouveau contenu dépend-il maintenant du maillage de serveurs ? Le maillage de serveurs nous permettra de commencer à augmenter le nombre de joueurs pouvant jouer ensemble dans Star Citizen, mais aussi de commencer à ajouter de nouvelles expériences de contenu. Pour l'instant, nous nous concentrons sur l'ajout de nouveaux systèmes stellaires. Le maillage de serveurs est l'une des technologies clés pour faire fonctionner les points de saut dans le jeu, en permettant aux systèmes stellaires d'entrer et de sortir de la mémoire de façon transparente, sans écran de chargement. Les joueurs le verront pour la première fois l'année prochaine, lorsque la première itération du Server Meshing sera mise en service avec l'introduction du système Pyro. Au fur et à mesure que nous affinons la technologie et que nous passons du maillage statique du serveur au maillage dynamique du serveur, les concepteurs peuvent utiliser cette technologie pour créer des zones plus grandes et plus intéressantes (comme de grandes colonies ou de grands intérieurs de vaisseaux) avec un nombre plus dense de personnages IA et de joueurs. Le maillage de serveurs pourrait ouvrir les portes à des expériences de jeu auxquelles nos concepteurs n'ont pas encore pensé ! Quelle est l'ampleur de l'amélioration des performances à laquelle nous pouvons nous attendre ? Le gain le plus important sera la performance du serveur. Actuellement, les performances de notre serveur sont assez limitées en raison du nombre d'entités que nous devons simuler sur un serveur. Il en résulte un framerate très bas et une dégradation du serveur, ce qui entraîne pour le client un effet de lag/élastique et d'autres problèmes de désynchronisation du réseau. Une fois que nous aurons mis en place le maillage statique, le framerate du serveur devrait être considérablement plus élevé, ce qui réduira ces symptômes. En ce qui concerne les FPS du client, le maillage du serveur a en fait très peu d'impact. Le client ne diffuse déjà que les entités qui sont à portée de vue. Il peut y avoir de légères améliorations, car nous pouvons être un peu plus agressifs avec l'élimination de la portée sur le client. En effet, à l'heure actuelle, certains objets ont un rayon de diffusion gonflé pour que des fonctionnalités comme le radar ou les missiles fonctionnent correctement. Avec le Server Meshing, nous pouvons découpler le rayon de diffusion du client et du serveur. Cependant, ces améliorations seront minimes sur le client. Néanmoins, des FPS plus rapides sur le serveur amélioreront l'expérience globale car le décalage du réseau sera considérablement réduit. Je sais qu'il n'y a peut-être pas encore de réponse à cette question mais, lors de la sortie initiale du Server Meshing, combien de shards pensez-vous devoir avoir ? 10, 100, 1000, plus ? Nous savons que l'abandon de DGS signifie plus de joueurs par zone de jeu, mais nous ne savons pas combien vous en prévoyez. La réponse courte est que nous ne pouvons pas avancer un nombre. Le concept de shard est la partie "malléable" de l'architecture de maillage, et nous ne serons en mesure de dire le nombre de shards requis qu'une fois que toutes les pièces constitutives seront en place et que nous prévoyons d'y arriver de manière itérative. Avec la première publication de Persistent Streaming (pas de maillage), nous voulons commencer par imiter le comportement actuel que vous voyez en ligne en ayant un shard par instance de serveur et un réplicant (appelé hybride). La seule différence est que toutes les entités de ces shards seront toujours persistantes. Cela nous permet de faire face au pire des scénarios en ayant un très grand nombre de shards persistants et de réplicants de très grande taille pour tester les mécanismes de création/ensemencement, de simulation avec des joueurs actifs et de démantèlement pour recyclage ou destruction. Nous voulons que la création et la destruction des shards dans cette première phase soient optimales, rapides et sans coût. Cette approche a plusieurs avantages, car nous pouvons tester la persistance des shards plus tôt et, plus important encore, nous pouvons mesurer les métriques actives sur de nombreux shards. Par exemple (non exhaustif !) : Combien d'entités restent dans un shard persistant au fil du temps (taux de croissance du shard). Taille du graphe global (taux de croissance global) Combien de joueurs une base de données d'un seul shard peut-elle gérer (utilisation des joueurs) ? L'effet de plusieurs mécanismes de jeu sur les mises à jour des entités dans la base de données du shard (effets du jeu). Profil de performance des files d'attente d'écriture, temps de requête moyen des clusters de la base de données shard (métriques de la base de données shard) Profil de performance des files d'attente d'écriture, temps moyen d'interrogation du cluster global de la base de données (métriques de la base de données globale) Efficacité du sharding de la base de données (un autre niveau de sharding !) du graphe Bien que nous disposions d'estimations et de mesures internes appropriées pour ces éléments, rien ne remplace des acteurs réels générant une charge représentative sur le système. Au fur et à mesure que nous mettons en place les autres composants du maillage, principalement le maillage statique, nous prévoyons de réduire progressivement le nombre de shards, en regroupant les joueurs dans des shards de plus en plus grands jusqu'à ce que nous soyons à l'aise avec les performances des réplicants, des DGS et du graphe d'entités. Bien sûr, le maillage statique souffrira de problèmes de congestion et nous ne pourrons reprendre le passage à des shards beaucoup plus grands qu'une fois le maillage dynamique en place. En fin de compte, avec le maillage dynamique, nous visons à supporter de très grands shards. Est-ce qu'un asset aussi petit qu'une balle peut voyager à travers les shards du serveur ? La réponse courte est non. Vous pouvez considérer les shards comme une instance complètement isolée de l'univers simulé, très similaire à la façon dont nous avons actuellement différentes instances isolées par serveur dédié. Pour que les objets puissent être transférés d'une instance à l'autre, ils doivent être rangés dans un inventaire avant de pouvoir être détachés dans un autre shard. Par exemple, si un joueur ramasse une arme dans un shard et la place dans son sac à dos. Lorsque le joueur se connecte à un autre espace, il peut sortir l'arme de son sac à dos et la ranger dans le nouvel espace. Au sein d'un shard, une entité telle qu'un missile pourra voyager à travers plusieurs nœuds de serveur si ces nœuds de serveur ont le missile dans la zone de streaming du serveur. Un seul nœud de serveur contrôlera (aura l'autorité) sur ce missile, tandis que les autres nœuds de serveur ne verront qu'une vue client du même missile. Les balles sont en fait créées côté client. Ainsi, une version unique de la balle est créée sur chaque nœud client et serveur, ce qui explique pourquoi j'ai utilisé une entité répliquée en réseau comme un missile dans l'exemple ci-dessus. Lorsque vous gérez différentes régions du monde, envisagez-vous d'héberger quatre fermes de serveurs principales, telles que les États-Unis, l'Union européenne, la Chine et l'Océanie ? Ou envisagez-vous de créer un "One-Global-Universe" ? Si c'est le cas, comment allez-vous gérer l'équilibre des joueurs avec des variations extrêmes de ping ? Nous prévoyons toujours de conserver la distribution régionale des services sensibles au réseau. Dans le déploiement initial du streaming persistant, la base de données mondiale sera véritablement mondiale. Les shards eux-mêmes seront distribués régionalement, de sorte qu'un client de jeu se connectant à la région de l'UE sera de préférence associé à un shard de l'UE. Au fur et à mesure que la taille des shards augmente (tant pour les joueurs que pour les entités), nous prévoyons de revoir ce modèle et d'introduire des services au niveau régional pour servir des données plus proches de la localité. Je vis en Europe de l'Est. Après le lancement du maillage de serveurs, pourrai-je jouer avec des amis des États-Unis ? Nous ne prévoyons pas de limiter le choix du shard et de la région pour un joueur. Un joueur sera libre de choisir n'importe quelle région pour jouer et, dans cette région, nous autoriserons une sélection limitée de shard. Par exemple, le shard avec vos amis ou le shard sur lequel vous avez joué la dernière fois. Comme toutes les données des joueurs sont stockées dans la base de données globale, les joueurs peuvent passer d'un shard à l'autre de la même manière qu'ils peuvent passer d'une instance à l'autre aujourd'hui. Les objets qui sont rangés seront transférés avec le joueur et seront toujours accessibles, quel que soit le shard. Mort d'une couche de réplication : Quelle sera l'expérience des joueurs si une couche de réplication est fermée/"meurt" ? Nous savons que le graphe d'entités collectera les informations ensemencées et les réinjectera dans une nouvelle couche de réplication, mais reviendrons-nous au menu principal si la couche de réplication meurt, comme c'est le cas si un nœud de serveur meurt, ou aurons-nous une sorte d'écran de chargement qui nous fera automatiquement passer à une nouvelle couche ? Pour répondre correctement à cette question, je dois d'abord donner un peu plus de détails sur ce à quoi ressemblera notre architecture finale. En fin de compte, la couche de réplication ne sera pas un nœud de serveur unique. Elle consistera plutôt en de multiples instances d'une suite de microservices portant des noms comme Replicant, Atlas et Scribe. L'un des avantages de ce système est que la couche de réplication elle-même pourra évoluer. Un autre avantage, plus pertinent pour cette question, est que même si un seul nœud/instance de la couche de réplication peut tomber en panne, il est très peu probable que toute la couche de réplication tombe en panne en même temps. Du point de vue du client, les nœuds de réplication sont les plus importants, car ce sont eux qui gèrent le transfert d'entités en réseau et la réplication d'état entre les clients et le jeu. Le réplicant est conçu pour ne pas exécuter de logique de jeu et, en fait, il n'exécutera que très peu de code ; pas d'animation, pas de physique, juste du code réseau. Le fait d'être construit à partir d'une base de code aussi réduite devrait permettre de réduire le nombre de bugs dans l'ensemble. Ainsi, après quelques inévitables problèmes de démarrage, nous pensons que Replicants sera assez stable. Il est également important de savoir qu'à tout moment, un même client peut être servi par plusieurs réplicants (mais ces réplicants serviront également d'autres clients en même temps). La dernière pièce du puzzle est la couche Gateway : Les clients ne se connectent pas directement aux réplicants mais à un nœud de passerelle dans la couche Gateway. Le service de passerelle est juste là pour diriger les paquets entre les clients et les différents réplicants auxquels ils parlent. Le service Gateway utilisera une base de code encore plus petite que celle des réplicants et devrait donc être encore moins susceptible de tomber en panne. Que se passera-t-il donc pour un client si l'un des réplicants qui le dessert tombe soudainement en panne ? Le client restera connecté au shard mais une partie ou la totalité de sa simulation sera temporairement gelée. La couche de réplication créera un nouveau nœud de réplication pour remplacer celui qui s'est effondré et récupérera l'état de l'entité perdue dans la persistance via EntityGraph. Les passerelles clientes et les nœuds DGS qui étaient connectés à l'ancien réplicant vont rétablir la connexion avec le nouveau. Une fois que tout est reconnecté, le jeu se débloque pour les clients concernés. À ce stade, il se peut que le client subisse un certain nombre de fluctuations et de téléportations d'entités. Nous espérons que l'ensemble du processus prendra moins d'une minute. Que se passe-t-il pour un client si la passerelle qui le dessert tombe soudainement en panne ? Le service de passerelle ne contient pas d'état de jeu et aura sa propre forme de récupération en cas de panne. Comme il s'agit d'un service beaucoup plus simple qu'un réplicant, le temps de récupération devrait être beaucoup plus rapide, de l'ordre de quelques secondes. Pendant que la récupération est en cours, le client subira un gel temporaire suivi d'un snapping ou téléportation. Qu'en est-il du service hybride ? Lors de leur présentation à la CitizenCon sur le streaming persistant et le maillage de serveurs, Paul et Benoit ont parlé de la couche de réplication en termes de service hybride. Le service Hybride est, comme son nom l'indique, un hybride des services Replicant, Atlas, Scribe, et Gateway que j'ai mentionné ci-dessus (mais pas EntityGraph), ainsi qu'une poignée d'autres services non encore discutés. Nous avons choisi de développer d'abord ce service avant de le diviser en ses composants, car cela réduit le nombre de pièces mobiles que nous devons traiter en même temps. Cela nous permet également de nous concentrer sur la mise à l'épreuve de tous les grands concepts plutôt que sur le travail de routine consistant à faire communiquer correctement tous ces services individuels. Dans cette implémentation initiale, la couche de réplication sera un seul nœud de serveur hybride. Si ce nœud hybride tombe en panne, la situation sera similaire à celle que connaissent actuellement les clients lorsqu'un serveur de jeu dédié tombe en panne. Tous les clients seront renvoyés au menu principal avec la fameuse erreur 30k. Une fois que l'hybride de remplacement aura démarré, les clients pourront rejoindre le shard et continuer là où ils se sont arrêtés. Avec un peu de chance, nous pourrons implémenter le système de manière à ce que les clients reçoivent une notification à l'écran leur indiquant que le shard est à nouveau disponible et qu'une simple pression sur une touche leur permettra de rejoindre le shard (de la même manière que pour la récupération d'un crash client). Le panel a beaucoup parlé des nœuds qui ont l'autorité d'écriture au sein d'un shard, mais qu'en est-il de l'autorité d'écriture entre des shards séparés ? Des bases de données de persistance distinctes sont-elles maintenues pour des shards séparés ou les états des éléments de l'univers seront-ils finalement synchronisés entre les shards même s'ils ont été laissés dans des états différents (par exemple, une porte est laissée ouverte sur un shard et fermée sur un autre - un shard écrira-t-il finalement son état dans la base de données, mettant à jour l'état de la porte sur l'autre shard ?) D'une manière générale, chaque shard est sa propre copie unique de l'univers, et aucun élément du shard ne partagera son état avec un élément d'un shard différent, car chaque shard possède sa propre base de données. D'un autre côté, nous avons une base de données globale pour les données d'inventaire des joueurs. Cette base de données est utilisée pour stocker tout objet dans l'inventaire d'un joueur, et les objets peuvent être transférés entre les mondes s'ils sont d'abord rangés d'un monde à l'autre dans un inventaire et ensuite rangés dans un autre monde. Certaines fonctionnalités, telles que les avant-postes des joueurs ou les ressources exploitables, mettent en œuvre un code spécial qui réplique un état global sur tous les shards, de sorte qu'un avant-poste peut exister sur plusieurs shards en parallèle et répliquer lentement (par rapport à la vitesse du jeu en temps réel) son état entre les shards. Il ne s'agit pas d'une réplication instantanée (une porte qui s'ouvre/se ferme ne sera pas répliquée), cependant, un état persistant comme une porte verrouillée ou déverrouillée peut être répliqué entre les shards. Il en va de même pour les ressources minables : Ainsi, lorsque les joueurs commencent à exploiter une certaine zone, la carte globale des ressources de cette zone sera modifiée et le nombre de roches exploitables à cet endroit sera affecté sur tous les shards. Lorsque vous avez un groupe qui se déplace (voyage quantique ou autre) d'un objet à un autre, et qu'un autre nœud DGS, un objet ou une instance est plein(e), est-ce que T0 / Maillage statique créera un autre nœud DGS de manière préemptive ? Ou comment cela sera-t-il géré ? Avec le maillage statique des serveurs, tout est fixé à l'avance, y compris le nombre de nœuds de serveur par shard et quel serveur de jeu est responsable de la simulation de quels emplacements. Cela signifie que si tout le monde dans le shard décide de se rendre au même endroit, ils finiront tous par être simulés par le même nœud de serveur. En fait, le pire des cas est que tous les joueurs décident de se répartir entre tous les lieux assignés à un seul nœud de serveur. Dans ce cas, le pauvre serveur devra non seulement s'occuper de tous les joueurs, mais aussi de la diffusion en continu dans tous ses emplacements. La réponse évidente est d'autoriser un plus grand nombre de serveurs par shard, afin que chaque nœud de serveur ait moins d'emplacements dans lesquels il peut avoir besoin de streamer. Cependant, comme il s'agit d'un maillage statique et que tout est fixé à l'avance, le fait d'avoir plus de nœuds de serveurs par shard augmente également les coûts de fonctionnement. Mais il faut bien commencer quelque part, donc le plan pour la première version de Static Server Meshing est de commencer avec aussi peu de nœuds de serveur par shard que possible tout en testant que la technologie fonctionne réellement. Il est clair que cela posera un problème si nous permettons aux shards d'avoir beaucoup plus de joueurs que les 50 que nous avons actuellement dans nos "shards" à serveur unique. Donc, ne vous attendez pas à ce que le nombre de joueurs augmente beaucoup avec la première version. Cela permet d'éviter qu'un nœud de serveur unique ne soit plein avant que les joueurs n'y arrivent, puisque nous limiterons le nombre maximum de joueurs par shard en fonction du pire des cas. Une fois que nous aurons mis en place ce système, nous examinerons les performances et les aspects économiques et verrons jusqu'où nous pouvons aller. Mais pour que la poursuite de l'expansion soit économiquement viable, nous devrons envisager de rendre le maillage des serveurs plus dynamique dès que possible. Compte tenu de l'énorme volume de données circulant entre les clients et les nœuds de serveur, et de la nécessité d'une latence extrêmement faible, pouvez-vous décrire ou préciser comment vous gérez cela ou quelles technologies vous utilisez pour accélérer les choses, ou plutôt les empêcher de ralentir ? Les principaux facteurs qui affectent actuellement la latence sont le taux de tic du serveur, le ping du client, la création d'entités et la latence des services persistants. Le taux de tic du serveur a le plus grand effet et est lié au nombre d'emplacements qu'un serveur de jeu simule. Le maillage des serveurs devrait y contribuer en réduisant le nombre de lieux que chaque serveur de jeu doit simuler. Moins d'emplacements signifie un nombre moyen d'entités par serveur beaucoup plus faible et les économies réalisées peuvent être utilisées pour augmenter le nombre de joueurs par serveur. Le ping du client est dominé par la distance par rapport au serveur. Nous constatons que de nombreux joueurs choisissent de jouer dans des régions situées sur des continents complètement différents. Une partie de notre code de jeu fait encore autorité sur le client, ce qui signifie que les joueurs ayant un ping élevé peuvent nuire à l'expérience de jeu de tous les autres. Il n'y a pas grand-chose que nous puissions faire à ce sujet à court terme, mais c'est un point que nous voulons améliorer une fois que le maillage des serveurs sera opérationnel. La création lente d'entités peut entraîner une latence en retardant l'arrivée des entités sur les clients. Cela peut avoir des effets indésirables, tels que des lieux qui n'apparaissent pas complètement avant plusieurs minutes après que le quantum ait voyagé jusqu'à un lieu, la chute à travers les étages après avoir réapparu dans un lieu, des vaisseaux qui mettent longtemps à apparaître aux terminaux ASOP, la modification de la charge du joueur, etc. Les goulots d'étranglement se situent principalement au niveau du serveur. Premièrement, les entités ne sont pas répliquées sur les clients tant qu'elles n'ont pas été complètement spawnées sur le serveur. Deuxièmement, le serveur a une seule file d'attente de spawn qu'il doit traiter dans l'ordre. Troisièmement, plus un serveur a besoin d'être diffusé dans un grand nombre de lieux, plus il doit faire de spawn. Pour améliorer les choses, nous avons modifié le code de spawn du serveur pour utiliser des files d'attente de spawn parallèles. Le maillage des serveurs sera également utile, non seulement en diminuant la charge sur les files d'attente de spawn en réduisant le nombre d'emplacements dans lesquels un serveur doit se rendre, mais aussi parce que la couche de réplication réplique les entités aux clients et aux serveurs simultanément, leur permettant de spawn en parallèle. Nous utilisons toujours certains de nos anciens services persistants, adéquats tels qu'ils ont été conçus mais connus pour avoir des problèmes de performance et d'évolutivité en fonction de nos exigences. Cela peut entraîner de longues attentes lors de la récupération de données persistantes à partir des services afin de savoir quoi faire apparaître, comme faire apparaître un vaisseau à partir d'un terminal ASOP, examiner un inventaire, modifier la charge du joueur, etc. Étant donné que le streaming persistant et le maillage de serveurs augmenteront considérablement la quantité de données que nous devons faire persister, nous savions que nous devions faire quelque chose à ce sujet. C'est pourquoi Benoît et son équipe chez Turbulent ont complètement réinventé la façon dont nous allons faire persister les données sous la forme d'EntityGraph, qui est un service hautement évolutif construit au-dessus d'une base de données hautement évolutive qui est optimisée pour exactement le type d'opérations de données que nous effectuons. En plus de cela, nous développons également la couche de réplication, qui agit comme un cache en mémoire hautement évolutif de l'état actuel de toutes les entités d'un shard, éliminant ainsi la nécessité de la majorité des requêtes que nous envoyions aux services persistants existants. C'est vrai, il y aura des services hautement évolutifs jusqu'au bout ! Pour aider à réduire/éliminer toute latence supplémentaire que la couche de réplication pourrait introduire, nous la construisons pour qu'elle soit gérée par événement plutôt que par un taux de tic comme un serveur de jeu traditionnel. Cela signifie que lorsque des paquets arrivent, il les traite immédiatement et envoie la réponse et/ou transmet les informations aux clients et serveurs de jeu concernés. Une fois que le travail sur la version initiale de la couche de réplication sera terminé (le service hybride), nous effectuerons un passage d'optimisation pour nous assurer qu'elle est aussi réactive que possible. Et, bien qu'il s'agisse en fin de compte d'une décision à prendre par DevOps, nous les déploierons dans les mêmes centres de données que les serveurs de jeu eux-mêmes, de sorte que la latence du réseau sur le fil due au saut supplémentaire entre la couche de réplication et le serveur de jeu devrait être inférieure à une milliseconde. Oh, et ai-je mentionné que la couche de réplication sera hautement évolutive ? Cela signifie que si nous détectons que la couche de réplication provoque des points de latence dans certaines parties du jeu, nous pourrons la reconfigurer pour remédier au problème. Avertissement Les réponses reflètent fidèlement les intentions du développement au moment de la rédaction, mais la société et l'équipe de développement se réservent le droit d'adapter, d'améliorer ou de modifier les fonctionnalités et les conceptions en réponse aux commentaires, aux tests de jeu, aux révisions de conception ou à d'autres considérations visant à améliorer l'équilibre ou la qualité du jeu dans son ensemble. Traduction : @Maarkreidi Swiss Starships

L'anti-chat facile arrive dans l'Alpha 3.15.1 Bonjour à tous, Avec la sortie de l'Alpha 3.15.1 plus tard ce mois-ci, nous introduirons la première phase de notre déploiement de l'Easy Anti-Cheat (EAC) pour Star Citizen. Easy Anti-Cheat est un service anti-triche utilisé par de nombreux jeux populaires (dont beaucoup auxquels vous avez probablement joué !), qui permet de contrer la triche et l'utilisation de logiciels tiers non autorisés dans les jeux PC multijoueurs. Vous pouvez trouver plus d'informations sur Easy Anti-Cheat ici : https://www.easy.ac. Empêcher l'utilisation de logiciels potentiellement dangereux (y compris les tricheurs) dans nos jeux reste l'un de nos objectifs essentiels pour créer une expérience multijoueur amusante et équitable pour tous. Par conséquent, vous risquez de rencontrer un message d'erreur qui vous exclura du jeu ou empêchera le lancement du jeu en raison de la détection de modifications non autorisées dans vos fichiers de jeu. Nous sommes conscients que certains joueurs utilisent des fichiers moddés pour améliorer leur expérience de jeu, comme des modifications de l'interface utilisateur, la localisation/la prise en charge de langues supplémentaires, etc. Nous tenons à vous prévenir qu'EAC bloquera la plupart de ces mods dans un premier temps, ce qui vous empêchera de lancer le jeu jusqu'à ce que les fichiers moddés soient supprimés de votre téléchargement local. Cependant, la passion et la créativité de la communauté Star Citizen ne connaissent aucune limite, et certains des projets en cours sont vraiment remarquables, notamment en matière de localisation. Bien que vous puissiez constater que ces mods ne fonctionnent pas avec la version 3.15.1, nous étudions déjà la possibilité d'un "programme d'approbation des mods", qui permettrait aux mods d'être mis sur une liste blanche après une vérification approfondie de la compatibilité et de la sécurité de notre part. Nous ne sommes pas encore prêts à nous engager dans cette voie, mais nous avons déjà contacté certains créateurs de mods et explorons les options possibles. Enfin, il est important de noter qu'il s'agit de notre première véritable mise en œuvre de l'anti-triche, ce qui signifie qu'il peut y avoir des cas limites/problèmes, et le service deviendra plus robuste au fil du temps - nous vous encourageons à partager vos commentaires dans notre fil de commentaires dédié, que nous publierons lorsque l'anti-triche sera en ligne. Traduction : @Maarkreidi Swiss Starships

ALPHA 3.15 HÔPITAUX ET SOINS MÉDICAUX Star Citizen Alpha 3.15 apporte avec lui un nouveau système médical, avec des hôpitaux, des blessures à plusieurs niveaux et une pléthore de médicaments et d'outils médicaux. Rejoignez-nous et plongez dans chacune de ces nouvelles fonctionnalités dans l'espoir d'être correctement équipé pour affronter cette mise à jour, qui augmente considérablement les enjeux de la survie dans le verse. LES OUTILS DU MÉTIER Un bon médecin garde une panoplie d'outils à portée de main. Qu'il s'agisse d'objets à usage unique ou d'outils de guérison fiables, il y a beaucoup d'équipement et d'articles pour vous permettre à vous et à votre équipe de tenir debout. Avant d'entrer dans les détails de comment et où guérir, voici un aperçu des trois outils actuellement disponibles pour un professionnel de la santé en herbe, tous pouvant être achetés dans n'importe quel hôpital ou clinique : Stylos médicaux Les stylos médicaux sont un moyen simple et direct de vous soigner ou de soigner une autre personne sur le terrain. De plus, les cinq médicaments peuvent être achetés sous forme de stylos (nous y reviendrons plus tard). Pour utiliser un stylo, maintenez la touche C enfoncée pour ouvrir un menu radial et sélectionnez le stylo que vous souhaitez utiliser. À partir de là, appuyez sur B pour l'utiliser sur vous-même, ou utilisez la souris 2 pour l'appliquer à quelqu'un d'autre. Ces commandes s'appliquent à tous les outils médicaux. Multi-Tool Le Pyro Multi-Tool peut être équipé de l'accessoire médical LifeGuard afin d'être utilisé comme un dispositif de sauvetage. Plus précis et efficace qu'un MedPen, avec l'avantage supplémentaire de guérir à courte distance, cet accessoire est limité à l'administration d'Hemozal. Outil médical Curelife Indispensable à tout professionnel de la santé, cet outil peut administrer n'importe lequel des cinq médicaments en quantité précise ou simplement appliquer de l'hémozal si nécessaire. De plus, il peut également fournir des scans médicaux détaillés d'une autre personne, mettant en évidence des blessures spécifiques et recommandant des traitements. UTILISATION DE L'OUTIL MÉDICAL CURELIFE Le dispositif médical Curelife peut détecter les blessures et l'état de santé de toute personne. Il suffit de pointer l'outil sur la personne pour voir ces informations. Vous pouvez également mettre en évidence des membres spécifiques de cette manière pour voir les blessures infligées. Cet outil dispose de deux modes distincts : Basique et Avancé. Le mode de base permet simplement d'appliquer de l'hémozal, comme avec le Multi-Tool. Le mode avancé vous permet d'appliquer les cinq médicaments dans la quantité précise de votre choix. Pour passer d'un mode à l'autre, et ajuster la quantité de médicament, maintenez l'outil en l'air à l'aide du bouton droit de la souris, puis maintenez la touche F enfoncée pour interagir avec l'écran de l'outil. DROGUES ET BDL Alpha 3.15 élargit l'éventail des drogues disponibles dans l'arsenal d'un médecin. Ces médicaments ont tous des attributs et des effets uniques, mais ils augmentent tous votre niveau de drogue dans le sang (BDL). Votre BDL est suivi à côté de votre état de santé sur le HUD de votre casque. Lorsque ce niveau atteint 50 % du maximum, votre personnage entre dans un état de surdose. Cela affectera votre vitesse de déplacement, brouillera votre vision, ajoutera un effet de balancement des armes et fera que votre personnage pilotera son véhicule de manière erratique. De plus, votre personnage commencera à subir des dégâts lentement, à moins que les effets ne soient contrés. Vous trouverez ci-dessous les types de drogues disponibles, y compris les quatre nouvelles introduites dans la version Alpha 3.15 : Hemozal L'hémozal est le principal médicament utilisé par les médecins. On le trouve à la fois dans un stylo (MedPen) et dans l'arme médicale Curelife et l'accessoire médical LifeGuard pour le multi-outil. Ce médicament peut arrêter les saignements et restaurer la santé jusqu'au maximum actuel, en plus de ramener une personne après une incapacité. Les saignements sont arrêtés quelle que soit la quantité de médicament utilisée. Demexatrine La demexatrine est une forme d'adrénaline synthétique qui peut être utilisée pour soulager la fatigue musculaire et les symptômes liés à une commotion cérébrale. Cela peut aider à lutter contre les effets de balancement des armes et de ralentissement des mouvements causés par les blessures. La demexatrine peut être administrée via un stylo (AdrenaPen) ou le mode avancé du Curelife Medical Tool. Roxaphen Roxaphen est un antidouleur qui peut aider à soulager les symptômes qui limitent considérablement vos mouvements, comme une blessure grave aux jambes ou aux bras vous empêchant de vous tenir debout ou de tenir des objets, respectivement. Roxaphen peut être administré via un stylo (OpioPen) ou le mode avancé du Curelife Medical Tool. Sterogen Le stérogène est un corticostéroïde qui peut aider à soulager les symptômes associés à la faiblesse musculaire ou aux lésions respiratoires, comme les effets d'une blessure à la poitrine qui réduit les dégâts de mêlée ou une blessure à la tête qui rend la vision floue. Sterogen peut être administré via un stylo (CorticoPen) ou le mode avancé du Curelife Medical Tool. Resurgera Resurgera est un désintoxiquant rapide qui, lorsqu'il est pris, commence à réduire lentement un taux de drogue élevé dans le sang et peut également réduire les symptômes causés par une overdose. Resurgera peut être administré par un stylo (DetoxPen) ou par le mode avancé du Curelife Medical Tool. BLESSURES Les blessures sont infligées lorsqu'un joueur reçoit des dommages soutenus et répétés. Les blessures peuvent être reçues sur n'importe quel membre, votre poitrine ou votre tête. Les blessures vous sont montrées soit via le HUD de votre casque dans le coin inférieur gauche, soit via un scan en utilisant l'outil médical Curelife. Vous trouverez ci-dessous les différents types de blessures, la façon dont elles vous affectent, et comment et où elles peuvent être soignées. Niveau 3 BLESSURE MINEURE Les blessures mineures peuvent être soignées par n'importe quel lit médicalisé de niveau 3, comme ceux du Cutlass Red. Ce premier niveau de blessure diminue votre réserve de santé maximale et introduit quelques effets de gameplay, selon l'endroit où vous avez été blessé. Si vos bras sont blessés, vos armes seront plus difficiles à viser et les dégâts infligés par les attaques de mêlée seront réduits. Si ce sont vos jambes, votre vitesse de déplacement est réduite. Si c'est la poitrine, votre endurance est réduite et votre personnage commence à avoir une respiration sifflante. Et enfin, si c'est votre tête, votre vision commencera à se brouiller, le son que vous entendez sera étouffé et il vous faudra plus de temps pour vous remettre d'un étourdissement. Aucune blessure mineure ne nécessite une stabilisation. Niveau 2 BLESSURE MODÉRÉE Une blessure modérée nécessite un lit médical de niveau 2 pour être soignée, comme une clinique ou les baies médicales de plus grands vaisseaux comme le Carrack ou le Jump 890. Les blessures modérées accentuent grandement les effets observés dans les blessures mineures, avec quelques ajouts. Les blessures modérées font que votre personnage commence à boiter et à grogner de manière audible en raison de la douleur. Si la blessure modérée est subie à la tête ou à la poitrine, une stabilisation est nécessaire dans un lit médicalisé de n'importe quel niveau. Niveau 1 BLESSURE GRAVE Une blessure grave nécessite un lit médicalisé de niveau 1 pour guérir, comme ceux que l'on trouve dans un hôpital. Les blessures graves aggravent encore les effets des blessures modérées, avec des inconvénients supplémentaires. Une blessure grave aux jambes contraindra votre personnage à se mettre à plat ventre, sans possibilité de se lever ou de s'accroupir. Si c'est aux bras, votre personnage ne pourra pas tenir d'objets. Les blessures graves à la tête ou au torse nécessiteront également une stabilisation dans un lit médicalisé. INSTALLATIONS MÉDICALES Maintenant que nous sommes familiarisés avec les blessures, nous avons besoin d'endroits pour les soigner. On trouve des installations médicales partout dans le 'verse, des villes massives aux petites stations spatiales. Il y a même quelques vaisseaux qui offrent des soins médicaux en leur sein. S'il s'agit d'une installation publique et non d'un vaisseau, n'hésitez pas à vous faire admettre en utilisant la console d'enregistrement des patients, qui fonctionne de la même manière qu'un terminal ASOP. Vous trouverez ci-dessous les trois types d'installations médicales, ainsi que les services qu'elles proposent. HÔPITAUX Les hôpitaux, ou installations médicales de niveau 1, se trouvent sur toutes les principales zones d'atterrissage. Ils peuvent être utilisés pour stabiliser un patient, traiter toute blessure et ramener une personne de la mort. CLINIQUES Les cliniques, ou installations médicales de niveau 2, se trouvent dans la plupart des stations spatiales du verse, ainsi que dans de petites zones d'atterrissage comme GrimHex. Elles peuvent être utilisées pour stabiliser un patient, traiter des blessures mineures à modérées, et ramener une personne à la vie. AMBULANCES Les ambulances, ou installations médicales de niveau 3, se trouvent dans les vaisseaux médicaux tels que le Cutlass Red. Elles peuvent être utilisées pour stabiliser les patients et traiter les blessures mineures, mais elles ne peuvent pas être utilisées pour ranimer une personne en état de mort. LITS MÉDICAUX ET TRAITEMENT Maintenant que nous sommes familiarisés avec les blessures et les installations qui peuvent les soigner, allons en chercher une et trouver un lit médicalisé. Ces lits peuvent se trouver dans de nombreux endroits, d'un vaisseau à une station spatiale en passant par l'hôpital d'une ville. S'il s'agit d'une installation publique et non d'un vaisseau, n'hésitez pas à vous faire admettre en utilisant la console d'enregistrement des patients, qui fonctionne de la même manière qu'un terminal ASOP. Toutefois, si vous avez subi une blessure grave et qu'il vous est difficile de marcher, une option accélérée est disponible dans n'importe quelle baie de hangar publique, illustrée ci-dessous. Un médecin peut amener un patient à ces lieux de dépôt d'urgence (utilisez un brancard pour accélérer les choses !) et ensuite envoyer cet ascenseur directement à la structure médicale. Dans les deux cas, rendez-vous à un lit médicalisé dès que possible ! Une fois que vous êtes sur le lit médicalisé, un menu vous propose jusqu'à trois options (la troisième apparaissant pour les propriétaires de vaisseaux, leur donnant la possibilité d'éliminer les joueurs qui se sont inscrits à l'ICU de leur vaisseau). La première option vous donnera un aperçu de votre personnage, comme illustré ci-dessous. Vous pouvez y voir les blessures que vous avez subies en détail, ainsi que les options de traitement recommandées. Pour appliquer un traitement, cliquez sur l'onglet "Traitement" et sélectionnez les blessures que vous souhaitez soigner. Après quelques secondes, votre blessure sera supprimée et vous retrouverez votre pleine santé. C'est aussi simple que cela ! N'oubliez pas que ces options ne vous sont présentées que si vous êtes conscient. Si vous êtes inconscient et que vous vous rendez dans un hôpital ou une clinique, l'établissement s'occupera de vos blessures pour vous et vous vous réveillerez complètement guéri. INCAPACITÉ Vous avez subi des dégâts importants, votre santé est à 0 % et vous tombez au sol. Félicitations, vous avez été frappé d'incapacité ! Votre personnage est maintenant immobile, et le chronomètre a commencé. Vous devez recevoir une dose d'hémozal avant la fin du temps imparti, sinon... vous êtes mort ! Gardez à l'esprit que les objets sur votre personne sont laissés sur votre cadavre si vous mourez. La bonne nouvelle est que tout espoir n'est pas perdu, même si vous êtes seul ! S'il n'y a personne pour vous aider dans les environs immédiats, vous pouvez créer une balise en maintenant la touche M enfoncée. Cela crée une mission de balise pour les joueurs à proximité, automatiquement définie pour une récompense de quinze mille aUEC et payée à la livraison à un établissement médical. Les joueurs qui acceptent cette mission peuvent vous amener à la zone de dépôt des urgences médicales, située dans tous les hangars rattachés à une installation médicale. Vous trouverez plus d'informations sur ces lieux dans la section Lits et traitements médicaux ci-dessus. Ce n'est pas un secret, Star Citizen Alpha 3.15 va changer votre façon de jouer pour toujours. Avec des conséquences mortelles vient la folie médicale, alors préparez-vous à prêter main forte à ceux qui en ont besoin. Nous avons hâte que vous vous y plongiez et que vous fassiez l'expérience de la variété des nouvelles fonctionnalités majeures introduites ! Il est important de noter qu'il s'agit de notre première itération du gameplay médical, et nous sommes impatients d'étendre la profondeur de cette nouvelle boucle de gameplay dans les patchs à venir. Rendez-vous sur notre fil de commentaires dédié et faites-nous part de vos réflexions, questions et préoccupations ! Traduction : @Maarkreidi Swiss Starships

Tour d'horizon des feuilles de route Joyeux mercredi à tous ! Toutes les deux semaines, nous accompagnons la mise à jour de la feuille de route d'une brève note explicative afin de vous donner un aperçu de la prise de décision qui a conduit à tout changement. Cela fait partie d'un effort pour rendre nos communications plus transparentes, plus spécifiques et plus perspicaces pour tous ceux qui contribuent à rendre Star Citizen et Squadron 42 possibles. Ceci étant dit, plongeons dans le Roadmap Roundup de cette semaine ! -Équipe communautaire du GCI Changements notables pour le 3 novembre 2021 Salvage Comme annoncé précédemment dans le Roadmap Roundup du 8 septembre, le Core Gameplay Pillar s'est concentré sur la fourniture de fonctionnalités pour Squadron 42, avant de les intégrer dans l'Univers Persistant. L'avantage est double : Squadron 42 bénéficiera grandement de ressources supplémentaires et d'une attention particulière, et l'univers persistant verra les fonctionnalités mises en ligne dans un état plus complet et plus abouti. Les équipes de Core Gameplay ont recalibré leurs plannings après la transition de leur projet et prévoient maintenant de terminer leur travail sur le Salvage pour Squadron 42 au premier trimestre 2022. Afin de disposer de suffisamment de temps pour implémenter cet ensemble de fonctionnalités dans l'univers persistant, la sortie de Salvage est désormais prévue pour le deuxième trimestre 2022. Cependant, vous remarquerez peut-être que nous avons renommé "Salvage T0 - Tech" en "Salvage T0". Ceci afin de mieux représenter le gameplay étendu qui sortira lors du lancement de Salvage. Plus précisément, la version initiale n'est plus seulement l'implémentation de la technologie dorsale, mais introduira le salvage manuel, ainsi que le salvage en vaisseau (décapage et réparation de la coque) en utilisant les systèmes à bord du Drake Vulture. Vue de la version Les cartes suivantes ont été ajoutées à la vue de la version : Vaisseaux spatiaux abandonnés - Points d'intérêt Des points d'intérêt qui seront dispersés sur des planètes. Il s'agira de vaisseaux spatiaux abandonnés avec un certain type d'activité (puzzle, traversée, IA hostile) et un certain type de récompense pour la résolution de ladite activité. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.16. Gadgets miniers Les gadgets miniers permettent de modifier la roche et aident le joueur à exploiter un gisement. Le joueur peut attacher un dispositif physiquement à un gisement exploitable dans FPS pour modifier ses statistiques, rendant l'exploitation plus facile et plus sûre, ou plus rapide et plus risquée. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.16. Ravitaillement de navire à navire Mise en place des systèmes qui permettront aux joueurs pilotant des vaisseaux spécifiques de ravitailler d'autres vaisseaux et d'être payés pour cela. Le joueur peut remplir les réservoirs de carburant de ces vaisseaux spécifiques à partir d'une station en utilisant une interface mise à jour de Réarmement, Réapprovisionnement, Ravitaillement dans les zones d'atterrissage et les stations spatiales. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.16. Mises à jour - Carte Dying Star Mise à jour de la carte Dying Star en augmentant sa taille globale, en ajoutant de nouvelles zones jouables, plus d'options de couverture et de nouvelles ressources spatiales. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.16. Refonte de la physique du Gravlev Une refonte importante du modèle de vol et de conduite des véhicules gravlev en vol stationnaire. L'objectif est d'améliorer la sensation générale et la stabilité, ce qui se traduira par une bien meilleure expérience pour les joueurs utilisant des vélos en vol stationnaire. Cette carte a été ajoutée à la fenêtre de sortie de l'Alpha 3.16. Mise à jour des textures de tête d'ADN Mise en œuvre de mises à jour artistiques pour les têtes de l'archétype ADN qui amélioreront la qualité de toutes les têtes ADN, tant pour les joueurs que pour les PNJ communs. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.16. Vente d'objets aux boutiques Les joueurs auront la possibilité de vendre des objets de leur inventaire local aux magasins en utilisant une nouvelle interface alimentée par les Building Blocks. Cela prend en charge la fonctionnalité de génération de butin récemment ajoutée, permettant à ces objets d'être vendus contre de l'argent. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.17. Mission de taxi pour PNJ T0 Les PNJ demanderont à être transportés entre des aires de repos dans ce type de mission, les récompenses étant déterminées par la vitesse, la sécurité et le confort avec lesquels le joueur conduit le PNJ à sa destination. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.17. Vultur Drake Construire, équilibrer et implémenter le Vautour, le vaisseau de sauvetage léger de Drake Interplanetary, dans le jeu. Cette carte a été ajoutée à la fenêtre de sortie de la version Alpha 3.18. En raison du recalibrage susmentionné du calendrier du Core Gameplay, ainsi que de la priorisation des fonctionnalités ajoutées ci-dessus, ces cartes sont retirées de la Release View jusqu'à ce qu'elles soient correctement reprogrammées : Échange de moteur Origin M50 Alignement dynamique des portes - Véhicules Glissement du joueur Couché Technologie d'acteur - Manipulation d'arme physicalisée Émetteurs de boucliers de navires C'est tout pour cette semaine ! Rejoignez la discussion sur Spectrum. Traduction : @Maarkreidi Swiss Starships

Rapport mensuel de Star Citizen : Octobre 2021 Octobre a été un mois très excitant pour les joueurs et les développeurs grâce à notre première CitizenCon exclusivement numérique. Naturellement, le rapport de ce mois-ci présente le travail effectué pour l'événement, mais il est surtout rempli de détails sur les tâches terminées et en cours pour le contenu à venir. Lisez la suite pour tout savoir, des mises à jour des nouveaux vaisseaux aux dernières nouvelles de Pyro, et plus encore. RAPPORT MENSUEL DE STAR CITIZEN : OCTOBRE 2021 Contenus IA Le mois dernier, AI Content a alloué des ressources à la prochaine version publique de l'Alpha 3.15. Avec la guérison et le statut d'acteur dans le patch à venir, l'équipe a complété le comportement IA et les utilisables de "l'expérience de respawning de l'hôpital", ce qui inclut les médecins et les infirmières qui accueillent les joueurs lorsqu'ils se réveillent dans un lit médicalisé. Un exemple frappant du système de statut de l'acteur peut être vu lorsqu'on achète une boisson dans un bar et qu'on devient ivre. AI Content a donc pris le temps de corriger un grand nombre des problèmes que les joueurs rencontrent depuis longtemps. "Plus tôt dans le mois, pendant la CitizenCon, nous étions heureux que le public puisse voir le comportement des travailleurs, le vendeur d'artefacts et une partie de notre comportement de sécurité à venir." - Équipe chargée du contenu de l'IA Fonctionnalités de l'IA AI Features a passé une partie du mois à travailler sur l'expérience et la réactivité de certains comportements dans le PU. Par exemple, les réactions de perception de combat ont été améliorées, y compris quelques scénarios où les réactions initiales ne jouaient pas correctement. Ils ont également réussi à rendre plus robuste la mise en file d'attente des animations de réaction lorsque les personnages utilisent un utilisable. L'équipe a ajusté les tirs amis pour éviter les dommages indésirables et a corrigé le calcul utilisé par les PNJ pour les empêcher de tirer lorsque des personnages amis se trouvent sur leur chemin. Une analyse approfondie est en cours sur les différentes tactiques de combat afin d'ajouter de meilleures réévaluations des cibles dans plusieurs scénarios. Du côté des commerçants, la réactivité a été améliorée, et l'équipe a corrigé des bugs liés à l'animation du scooching et aux barmen qui servent des clients ayant déjà une boisson devant eux. IA Tech Tout au long du mois d'octobre, IA Tech a poursuivi son travail sur la génération de la navigation planétaire. "Les éléments clés de ce mois-ci concernaient l'implémentation d'une méthode automatique de génération de requêtes sur la zone entourant les joueurs, mais nous avons également travaillé à permettre l'utilisation de l'algorithme d'entonnoir sur les triangles de maillage de la navigation planétaire." - Équipe technique de l'IA L'équipe a étendu le code des liens de navigation pour permettre la création de contrôleurs de personnalisation. Dans ce contexte, un contrôleur est un morceau de code générique qui peut étendre la façon dont les PNJ évaluent s'ils peuvent utiliser un lien de navigation particulier. Par exemple, les portes peuvent avoir des contrôleurs spécifiques pour indiquer aux personnages IA si elles sont verrouillées afin qu'elles puissent être utilisées correctement lors de la recherche de chemin. Pour l'IA des vaisseaux, ils se sont concentrés sur les améliorations du ciblage et de la précision, ont amélioré la façon dont l'IA utilise les missiles en combat, et ont introduit des moyens permettant à la logique de mission de forcer ou de demander la priorisation d'une cible spécifique. Un contrôleur PID a également été implémenté pour la précision qui fournit de meilleurs résultats et permet de l'ajuster plus facilement en fonction des compétences de l'IA. En ce qui concerne l'éditeur de Subsumption, l'équipe a terminé l'implémentation de la fonctionnalité permettant d'ancrer différents éléments dans l'interface utilisateur et de sauvegarder ou de charger des dispositions spécifiques. Animation Le mois dernier, l'équipe d'animation a travaillé sur divers comportements d'IA, notamment l'infirmière, le vendeur, le barman, le client du bar, l'agent de sécurité et le PNJ non-combattant qui se recroqueville et se cache. Des modifications ont également été apportées à plusieurs assets féminins pour Alpha 3.15 afin de donner plus de vie au monde. Des plans ont été élaborés pour améliorer le set de locomotion des ivrognes, ce qui aidera à résoudre les questions techniques pour les sets " lourdement blessés ". Le développement du gadget d'exploitation minière interstellaire Shubin s'est poursuivi, et l'équipe a veillé à corriger les problèmes visuels liés au système de sélection et de désélection. Le travail s'est poursuivi sur les animations faciales pour toutes les animations corporelles existantes, tandis que des progrès ont été réalisés sur les emotes et les lignes pour divers personnages du PU. Art (personnages) Les équipes Art et Technique des personnages ont passé le mois d'octobre à corriger des bogues pour l'Alpha 3.15 et à progresser dans le contenu des différentes versions à venir. Une attention particulière a été accordée à la mise à jour des têtes de l'archétype ADN, ce qui améliorera la qualité de toutes les têtes de personnages dans le PU et Squadron 42. Ils ont également commencé à développer une série de nouvelles tenues de style frontalier pour la population de Pyro. Art (Vaisseaux) Aux États-Unis, l'équipe chargée des vaisseaux a corrigé des bugs et continué à peaufiner diverses parties du Crusader Ares, y compris plusieurs nouvelles peintures. Le Vulture Drake a atteint la phase artistique finale, avec l'accent mis le mois dernier sur l'habitation et la soute. L'un des véhicules non annoncés régulièrement mentionnés a continué à progresser dans le pipeline, obtenant cette fois une disposition d'interface utilisateur finalisée et une passe d'éclairage. Une partie de l'équipe a ensuite commencé le passage sur les dégâts, tandis que d'autres sont passés à la préparation de la sortie. Un autre nouveau vaisseau a reçu ses teintes finales et les bogues ont été corrigés. Au Royaume-Uni, trois vaisseaux sont passés par les étapes finales du pipeline, tandis que le Banu Merchantman a progressé dans la boîte blanche. Les MISC Hulls à venir ont poursuivi leur développement, le A se préparant pour la révision de la boîte blanche et le C approchant de la révision de la boîte grise. Art (Armes) L'équipe chargée des armes a commencé le mois en travaillant sur les bombes Firestorm Kinetics de taille 3 pour le Crusader Hercules et sur les illustrations pour le prochain asset de rayon tracteur de vaisseau. Ils ont terminé le mois sur le gadget de minage, la mine de proximité et la mine à déclenchement laser. Audio L'équipe du code audio s'est préparée à la dernière étape du développement du logiciel audio Claudius, qui a été abordée par Graham, responsable du code audio, et Adi, concepteur sonore, lors de leur panel Sounds of Space CitizenCon. Enfin, l'équipe a travaillé en étroite collaboration avec le compositeur Pedro Camacho sur la partition de Pyro pour établir le ton et la palette sonore. Communauté L'équipe communautaire a passé une partie du mois à préparer le Jour du Vara. Cela a impliqué les coureurs des cavernes et les concours annuels de sculpture de citrouilles de Star Citizen, tandis que les citoyens pouvaient débloquer le casque Hill Horror gratuitement en se rendant à Jump Town pendant toute la durée de la fête. L'équipe a publié le Postmortem de l'Alpha 3.14, dans lequel les développeurs principaux détaillent ce qui a été livré et évaluent comment cela s'est passé. La communauté a également joué un rôle important lors de la Digital CitizenCon 2951, en conservant les nombreuses vidéos communautaires soumises dans le cadre du concours vidéo de l'événement, les gagnants pouvant être visionnés sur le site Web de la CitizenCon. L'équipe a également organisé le concours "Tales of Star Citizen Past" et a aidé les citoyens à partager leurs projets de soirées de surveillance de la CitizenCon. Au cours de l'événement, l'équipe a recueilli les votes pour le concours de cosplay préféré des fans et le vote pour le panel de vaisseaux, a publié le pré-Q&A de l'Origin 400i après son dévoilement, et a compilé le Q&A du vaisseau Anvil basé sur les questions les plus votées par la communauté. Après l'événement, tous les panels ont été mis à disposition pour être visionnés en 4k et un fil de discussion sur le maillage des serveurs a été publié. Enfin, l'équipe communautaire a soutenu l'Alpha 3.15 à venir en publiant des articles sur l'inventaire personnel et la récupération des pannes de serveur, les nouvelles missions et le premier passage des variantes de bouclier, ainsi que le gameplay médical. Moteur Le mois dernier, l'équipe chargée de la physique a pris en charge la prochaine version Alpha 3.15 et a corrigé de nombreux problèmes, et du temps a été consacré à diverses optimisations. Le processus de voxélisation des maillages triangulaires a été accéléré en utilisant une structure d'accélération basée sur les lignes de balayage au lieu d'une structure basée sur les voxels lors du remplissage des cellules. L'équipe a également aidé AI Code à optimiser sa routine de mise à jour de la carte audio en regroupant le traitement des stimuli. De plus, le tri des événements de collision a été optimisé, et la physique des brosses par défaut est maintenant créée automatiquement. Une visualisation de débogage pour l'historique des collisions a également été implémentée. Enfin, en ce qui concerne la physique, une grille arborescente quantum a été implémentée. Elle sera utilisée pendant le boosting du voyage quantum et pendant le voyage quantum régulier pour détecter les collisions et les obstacles le long du chemin. Pour le moteur de rendu, des efforts considérables ont été consacrés à l'amélioration des résultats du profileur de pipeline pour les chemins de rendu Gen12 et anciens. Cela a été fait pour obtenir une évaluation précise de la durée de traitement des passes de rendu et de calcul sur les CPU et GPU sans trop affecter le taux d'images réel (profilage en temps réel). Des progrès significatifs ont également été réalisés dans la transition vers Gen12 : Les objets d'état du pipeline sont désormais compilés à la demande pour améliorer les temps de chargement, l'instanciation massive est désormais prise en charge et la gestion des tampons d'instance a été optimisée. La scène de rendu Scaleform utilisée pour le menu et l'interface utilisateur dans le monde du jeu a été optimisée pour réduire le nombre moyen de scènes de 2000 à un maximum de 60, l'état du pipeline étant également créé à la demande. En outre, le code des particules, l'atlas de lumière et l'analyseur de shaders ont été remaniés. L'intégrité du contenu a été renforcée en ajoutant des alertes de données pour les shaders invalides utilisés dans les matériaux. La prise en charge des mises à jour de la texture des matériaux (animation de la texture) a également été ajoutée. Pour le rendu des atmosphères et des nuages, toutes les améliorations récentes ont été fusionnées dans le flux Alpha 3.15. Des améliorations ont continué à être apportées à l'éclairage indirect des nuages et de l'atmosphère en fonction de la présence de nuages dans l'atmosphère. La partie initiale de ce travail a été achevée (génération de LUT), le travail reprenant une fois que les optimisations de performance prévues seront en place. Pour mettre en place ces dernières, le travail sur la chaîne de reprojection et de filtrage a commencé afin de permettre la réutilisation temporelle et spatiale des résultats de raymarch. À cette fin, la R&D a commencé à travailler sur la reprojection sans vecteurs de mouvement (car ceux-ci ne peuvent pas représenter correctement les médias participants). L'équipe du moteur central a également travaillé sur le code de diffusion des entités, qui prend désormais en charge le triage par sphère nécessaire à SQ42. Une refonte importante a été soumise au planificateur de mise à jour des composants d'entité. Cela inclut une nouvelle API qui utilise les ID de mise à jour au lieu des passes pour permettre plusieurs mises à jour par passe. Le frame profiler du moteur a été mis à jour pour inclure diverses statistiques provenant des événements Heartbeat ainsi qu'un résumé du temps CPU et de l'utilisation de la mémoire par les équipes de développement, des informations sur la construction et une capture d'écran dans la capture. Le gestionnaire de mémoire a été étendu pour prendre en charge des arènes d'allocation et des caches de threads séparés par équipe de développement. En cas d'accès mémoire invalide, le gestionnaire d'exception peut maintenant indiquer à quelle arène une adresse mémoire inaccessible correspond. Cela permet de déboguer les crashs mémoire avec une vérification plus fine de la mémoire, ce qui signifie généralement que la compilation s'exécute beaucoup plus rapidement et utilise moins de mémoire que si le débogage de la mémoire était activé globalement. En outre, le travail s'est poursuivi sur l'amélioration de l'élimination des frustums et une fonctionnalité permettant de capturer et de faire circuler des lambdas C++ sans allocations de la pile a été ajoutée. Enfin, l'équipe examine de plus près les possibilités d'intégrer EASTL. Fonctionnalités (Personnages et armes) Tout au long du mois d'octobre, l'équipe des fonctionnalités a amélioré les nouvelles fonctionnalités d'inventaire des joueurs et de statut des acteurs en fonction des commentaires du PTU, l'ajout le plus notable étant la possibilité de filtrer les objets dans l'inventaire. Cette fonctionnalité a déjà fait l'objet de plusieurs itérations de l'interface utilisateur depuis son introduction au début du mois. Fonctionnalités (Gameplay) L'équipe Gameplay américaine a commencé le mois en finalisant son panel Stream of Thought pour la CitizenCon. Une fois terminé, ils se sont concentrés sur le nouveau kiosque d'objets qui ajoutera la possibilité de revendre des objets aux magasins (il a été converti en Building Blocks dans le processus). Ils ont finalisé les documents de conception technique, ont commencé à travailler sur la refonte majeure du cargo, et ont également travaillé sur le prochain événement IAE. Un correctif a été ajouté afin d'empêcher les joueurs de perdre les objets rangés dans leurs vaisseaux lorsqu'ils subissent une 30k. Désormais, lorsque les joueurs atteignent un 30k, ils pourront réclamer ce vaisseau avec tous les objets stockés depuis n'importe quel terminal ASOP du jeu. "Fini le temps où vous chargiez votre vaisseau d'une tonne d'objets pour vous rendre dans une autre ville et où vous les perdiez à cause d'un crash du serveur. Nous avons déjà vu une réaction extrêmement positive du public sur Spectrum ainsi que sur Reddit à propos de la façon dont cela fonctionne, donc nous espérons que vous l'appréciez tous autant que nous !" - Équipe des fonctionnalités Fonctionnalités (Véhicules) Le mois dernier, l'équipe Véhicules s'est concentrée sur un remaniement important de la manipulation des grav-lev. Une percée dans l'implémentation a permis d'apporter des améliorations significatives à la manipulation, la rendant plus dynamique et flexible. Ils ont également corrigé certains bugs et problèmes liés à l'implémentation existante. Le développement des points de saut s'est poursuivi, l'équipe s'occupant actuellement de régler les derniers détails de la logique de jeu. Par exemple, lorsque plusieurs personnes utilisent un point de saut en même temps. Une partie de la technologie de bas niveau derrière les points de saut dépend du maillage des serveurs, l'équipe a donc continué à travailler avec les équipes concernées. Des améliorations ont été envisagées pour le système de transit. Le système est assez complexe et a été construit avant le maillage des serveurs et le streaming, il y a donc des mises à jour à faire pour s'assurer qu'il s'adapte au nouveau paysage technologique du jeu. L'équipe a également cherché à améliorer certains des outils utilisés par les concepteurs pour créer plus facilement des réseaux de transit dynamiques et complexes. Graphisme et programmation VFX Les améliorations apportées aux volumes d'eau se sont poursuivies, l'accent étant mis en octobre sur la manière de simuler correctement l'éclairage volumétrique sous la surface. Deux approches ont été adoptées : La première utilise le système général de brouillard voxel, bien qu'il présente plusieurs limitations qui le rendent inapplicable aux volumes d'eau très grands ou très petits. La seconde approche consiste à réutiliser le modèle d'éclairage par particules, qui est moins précis mais peut fonctionner à des échelles plus extrêmes. Nous avons également commencé à travailler sur les changements à apporter au système de matériaux pour permettre aux shaders de devenir plus modulaires. Il s'agit d'un tremplin vers la construction d'une nouvelle suite de shaders qui offrent plus de puissance et de flexibilité aux artistes sans nécessiter une réingénierie complexe de la part des programmeurs graphiques. Le travail sur Gen12 a repris après la CitizenCon, avec de nouveaux systèmes convertis. L'équipe cherche également à terminer une vaste refonte des échantillonneurs de textures pour les rendre compatibles avec Gen12/Vulkan. Parmi les autres tâches accomplies, citons les nouvelles fonctions d'animation de la lumière, le travail de conception technique pour l'utilisation des cartes de dommages pour la récupération, les corrections de gamma et le support général de la fonction de feu. Éclairage L'équipe chargée de l'éclairage a commencé le mois en corrigeant des bogues pour les emplacements de l'Alpha 3.15. Elle est ensuite passée à la finalisation de l'éclairage de l'IAE, ce qui impliquait de reprendre l'éclairage existant et de le réaffecter à la nouvelle ambiance de la salle de convention. Certaines zones n'ont nécessité que de petites retouches, tandis que d'autres ont reçu des changements beaucoup plus importants qui, l'équipe l'espère, offriront une expérience nouvelle et intéressante à la communauté. Le début d'un nouveau trimestre a également permis à l'équipe de s'attaquer à l'arriéré des tâches héritées et de peaufiner les emplacements couvrant l'ensemble du PU. Un look-dev pass a commencé sur les stations spatiales abandonnées de Pyro. "Ces lieux nous offrent des tonnes de possibilités d'ambiance et de drame, comme des couloirs sombres et froids contrastant avec des marchés chauds remplis de condensation." - Équipe chargée de l'éclairage Lieux L'équipe Locations, basée à Montréal, a mis la touche finale à l'hôpital d'Area18, dont la sortie est prévue dans l'Alpha 3.16. Il s'agissait de terminer les tâches de polissage, de créer des LOD pour l'ensemble du site et de corriger tous les bugs restants. Parallèlement, d'autres hôpitaux ont bien progressé, notamment l'hôpital Maria Pure of Heart à Lorville et les cliniques des aires de repos, ces dernières approchant les dernières étapes du développement. Les cliniques des aires de repos ont nécessité quelques modules supplémentaires pour permettre à l'équipe de créer des agencements uniques dans chacun des 12 sites. L'équipe a également travaillé sur la boîte blanche de l'hôpital de Levski. Une autre fonctionnalité clé actuellement en cours de développement est Derelict Ships V1. Le mois dernier, l'équipe de conception a éparpillé des parties du Caterpillar de Drake dans des endroits de la planète et a ajouté des énigmes à l'intérieur. Actuellement, il existe deux types de modules : Vanilla et Puzzle. Les modules Vanilla sont de simples pièces de vaisseau spatial où les joueurs peuvent trouver des ressources ou des objets de base. Les modules Puzzle contiennent une énigme avec un conteneur lootable comme récompense. L'équipe a maintenant terminé ces modules et les assemble sur différents sites de crash autour de Stanton. Narration Le mois d'octobre de Narration a débuté par le support final de la poussée d'Alpha 3.15 vers le PTU. Ils ont également soutenu d'autres équipes, corrigé des bugs, ajouté des chaînes de texte et rédigé des noms et des descriptions d'objets. Ils se sont ensuite tournés vers les futures versions et ont commencé à compiler des documents pour certains des futurs hôpitaux. Il s'agissait notamment d'écrire des idées et des textes pour les accessoires environnementaux, tels que des affiches, des panneaux et des scripts d'annonce. L'année touchant à sa fin, l'accent a été mis sur la planification. Narrative a travaillé avec AI, Animation et Design pour définir les objectifs du contenu narratif pour l'année à venir, y compris le prototypage du comportement et les sessions de capture de mouvement. Narration a également continué à travailler sur le contenu de Pyro, notamment en collaborant avec Design sur les missions et en développant les factions et les lieux que l'on trouvera dans le système. Une poignée d'articles nouveaux et réédités ont été publiés. The Advocacy Archive révèle une opération d'infiltration dans une faction potentiellement violente d'un groupe séparatiste terrien, tandis que Dispatches from the Dark raconte l'histoire d'une randonnée conflictuelle d'un passionné de crimes réels sur le site d'un tueur en série tristement célèbre. Le Jump Point d'octobre présentait une rétrospective de la CitizenCon ainsi qu'un regard sur le développement du 400i et un Portfolio sur le Cousin Crow's Custom Craft sur Orison. Enfin, Galactapedia a été mis à jour avec une foule de nouveaux articles. QA L'équipe d'assurance qualité s'est principalement concentrée sur la CitizenCon, l'Alpha 3.15 pour Evocati et les tests PTU de la vague 1. La date de mise en ligne ayant été repoussée à novembre, l'équipe a continué à tester et à publier d'autres vagues tout en mettant à jour le plan de publication. Pour le développement, l'équipe a continué à tester les QATR selon les besoins. Avec le nouveau plan de publication du mardi et du jeudi et la liste de contrôle des fonctionnalités en place, l'équipe a pu effectuer des tests de manière plus fiable. La direction de l'AQ a poursuivi le plan de retour au bureau, a progressé dans le recrutement et a créé une équipe AQ Live dédiée. Services et outils systémiques En octobre, les services et outils systémiques ont terminé leur travail en cours sur l'économie, les outils et la simulation de l'IA. Ils se concentrent maintenant sur l'optimisation pour le reste de l'année. Le développement de la nouvelle fonctionnalité de jeu mentionnée le mois dernier s'est également poursuivi. Le travail sur la création et le suivi des PNJ intelligents a progressé, la dernière moitié du système de création progressant bien. Le système de suivi continue vers sa première étape interne majeure. Enfin, en préparation de l'Alpha 3.15, ils ont abordé de nouveaux cas limites avec le système d'inventaire et les services backend. Tech Animation En octobre, Tech Animation a achevé la mise à niveau du pipeline de création de têtes et d'animation, une tâche de longue haleine. "Nous avons réécrit des parties importantes du système ADN utilisé pour créer nos acteurs dans le jeu. En plus de cela, nous avons ajouté un support pour la création et l'édition de ces assets de tête dans Maya par le biais d'un plugin qui partage la même base de code et une grande quantité d'outils pour l'utiliser efficacement. Cela nous a permis de dépasser les limites actuelles de notre pool de gènes et de nous tourner vers l'avenir." - Animation technique Désormais, tous les types de rigs de visage sont viables (y compris les animaux et les extraterrestres), avec la perspective de mettre à niveau ou de personnaliser les rigs d'animation faciale pour tout ce qui sera nécessaire à l'avenir. Cette technologie est également en cours d'approfondissement pour des formes de déformation plus complexes. Tech Animation est presque prêt à présenter le pipeline de création de têtes qu'il a créé en tandem avec le système ADN. Cela leur donnera la possibilité de créer de nouveaux rigs de visage pour les pools de gènes ADN et de contrôler étroitement la qualité des assets. Des outils supplémentaires ont été créés au cours du trimestre pour inclure l'exportation de cache d'alambic dans le pipeline d'animation. Cette fonction a toujours été prise en charge, mais le fait de l'inclure de cette manière a ouvert de nouvelles possibilités pour les équipes d'animation et de technologie, qui ont pu l'inclure directement dans leurs pipelines d'animation en tant que préférence d'exportation. L'équipe Animation a également poursuivi le développement du pipeline d'outils et a affiné certains anciens codes et outils pour qu'ils continuent à fonctionner comme prévu. Turbulent (Services) L'équipe Live Tools a poursuivi le développement de l'outil Hex présenté le mois dernier, en le mettant cette fois-ci au même niveau que la version précédente. Elle a continué à ajuster le pipeline de gestion des crashs en vue du déploiement le mois prochain, ainsi qu'une nouvelle mise à jour de l'API Panic pour prendre en charge les changements à venir. Les services de jeux ont progressé avec le service de discipline, en réglant les détails lors des pré-tests avant de procéder au QATR complet. L'équipe a également travaillé sur des demandes de fonctionnalités pour le graphique d'entités pour l'équipe Persistent Tech. Interface Utilisateur L'équipe IU a principalement pris en charge l'Alpha 3.15, bien qu'elle ait également progressé sur l'IU de la prochaine fonction de ravitaillement en carburant et des gadgets d'exploitation minière. Elle a passé du temps à convertir les terminaux ASOP pour utiliser les Building Blocks en vue d'une future version et a travaillé avec l'équipe Véhicules pour ajouter des contrôles de porte mis à jour aux derniers vaisseaux. Tech Véhicule L'équipe Vehicle Tech a travaillé sur diverses fonctionnalités pour le patch à venir, notamment la prise en charge des nouvelles versions de véhicules, le train d'atterrissage, le radar et le balayage, la réparation et les interactions des panneaux de commande des portes. "Les panneaux de contrôle sont particulièrement remarquables, car nous souhaitons bientôt étendre ces interactions pour permettre au joueur de contrôler son environnement de manière nouvelle et passionnante, que ce soit dans un véhicule ou une station." - Technologie des véhicules L'équipe est ensuite passée à l'intégration des commentaires sur les améliorations apportées aux radars et aux scanners soumises au trimestre dernier. Des besoins liés à Squadron 42 ont également été découverts qui, une fois mis en œuvre, bénéficieront également au PU. VFX L'équipe VFX a terminé les passes complètes de plusieurs nouveaux vaisseaux, notamment les variantes du Crusader Ares et leurs armes. Le travail s'est poursuivi sur les bombes S10, dont l'aspect est maintenant bien meilleur que la "passe fonctionnelle" montrée dans Inside Star Citizen. Les effets de tempête au sol des planètes ont été rééquilibrés, ce qui était nécessaire en raison du modèle d'éclairage VFX récemment introduit. L'équipe a également organisé plusieurs playtests axés sur les VFX, au cours desquels elle a trouvé et corrigé de nombreux bugs visuels mineurs. Conclusion NOUS VOUS DONNONS RENDEZ-VOUS LE MOIS PROCHAIN... Traduction : @Maarkreidi Swiss Starships

Merci, oui nous avons prévu de le mettre à jours.

Suite... 13: table ronde autour de la question du vaccin ARNm! https://odysee.com/@QuadrillageTraduction:1/trim.7E867785-3381-47C6-8450-ABC0D182A014:0 14: Le passeport vaccinal! https://odysee.com/@QuadrillageTraduction:1/trim.2B2F546F-BCF9-4EF1-AE43-777407D1BCB9:4

La suite.... 12/16: Vaccins à ARNm - Pharmacocinétique et toxicité https://rumble.com/vnb43h-1216-vaccins-arnm-pharmacocintique-et-toxicit.html

La suite.... 7 : La pandémie est un événement économique https://odysee.com/@JeanneTraduction:a/07-JohnTitus:6 8 : Banques centrales et moteurs économiques https://odysee.com/@JeanneTraduction:a/08-Austin-Fitts-Werner:9 9 : Décentraliser le contrôle https://odysee.com/@JeanneTraduction:a/PatrickWoodMarkSkidmore:f 10 : La matrice de la propagande et le rôle des médias https://odysee.com/@JeanneTraduction:a/10-Gerrish-Austin-Fitts:0 11 : L'abus de l'autorisation d'urgence des vaccins https://odysee.com/@JeanneTraduction:a/11-Yeadon:0

CITIZENCON 2951 Il est temps une fois de plus de célébrer tout ce qui concerne Star Citizen, et surtout VOUS, la communauté qui rend tout cet univers possible. Préparez-vous à une journée remplie de contenu passionnant, allant du cosplay aux vidéos de la communauté, en passant par des plongées dans le développement, et plus encore ! Nous diffuserons l'intégralité de l'événement sur Twitch pour le plus grand plaisir de tous, alors attrapez du pop-corn de l'espace, ouvrez une nouvelle boîte de Pips, et nous vous verrons là-bas. N'oubliez pas de revenir souvent sur le site, car nous vous donnerons plus de détails sur les concours, les cadeaux et les surprises qui vous attendent à l'approche de l'événement. 17H00 : OUVERTURE AVEC CHRIS ROBERTS Le président lui-même, Chris Roberts, donne le coup d'envoi de l'événement de cette année. Chris Roberts : Fondateur et président-directeur général 17H05 : LA VIE DANS LE 'VERSE Le forum le plus important de cette année vous propose une visite guidée de l'univers actuel du jeu. Rejoignez les développeurs qui lui donnent vie pour explorer les lieux, les systèmes, le gameplay, et bien plus encore. Ian Leyland : Directeur artistique de Star Citizen Todd Papy : Directeur du live de Star Citizen David Haddock : Directeur narratif Et plus encore ! 19H15 : DISCUSSIONS RELATIVES AUX VAISSEAU Dans le cadre de la présentation du Ship Talk de cette année, John Crewe, Ben Curtis et Paul Jones dévoilent les nouveaux vaisseaux et ceux à venir, décrivent leur parcours dans la production et fournissent des mises à jour très attendues sur les vaisseaux préférés des fans. John Crewe : Directeur des véhicules Ben Curtis : Directeur artistique des véhicules Paul Jones : Directeur artistique 21H00 : GEN 12 & LE MULTICORE DE VULKAN Nous allons nous plonger dans les moindres détails de Gen12, le nouveau moteur de rendu développé pour Star Citizen et Squadron 42, utilisant l'API graphique Vulkan, avec un accent particulier sur le parallélisme multi-CPU ainsi qu'une meilleure flexibilité pour un développement plus rapide des fonctionnalités. Nous verrons pourquoi il était nécessaire, comment son architecture contribue aux performances, et nous vous tiendrons au courant de son évolution. Ali Brown : Directeur de l'ingénierie graphique Christopher Bolte : Architecte du moteur principal Darrell Barnes : Programmeur graphique 21H40 : CRÉATION DES MONDES : OUTILS ET TECHNOLOGIES PLANÉTAIRES Une vue d'ensemble de certaines des nouvelles fonctionnalités technologiques des planètes en cours de développement pour aider à donner vie à Star Citizen. Anis Hireche : Programmeur moteur senior Marc Rivoira : Programmeur outils I Morgan Minardi : Programmeur moteur/outils II Will Hain : Programmeur moteur II Marco Corbetta : Vice-président de la technologie 22H00 : MAILLAGE DES SERVEURS ET STATUT DE LA PERSISTANCE Découvrez les technologies révolutionnaires du maillage de serveurs et du streaming persistant. Une plongée en profondeur dans l'architecture technique de ces initiatives clés qui permettront de créer un monde véritablement massif, évolutif et persistant. Paul Reindell : Directeur de l'ingénierie, Technologie en ligne Benoit Beausejour : Directeur de la technologie chez Turbulent 22H30 : LES SONS DE L'ESPACE Les esprits fous à l'origine des paysages sonores de Star Citizen vous emmènent dans une visite guidée des derniers développements de la nouvelle technologie audio innovante qui donne véritablement vie au verset. Graham Phillipson : Programmeur audio en chef Adi Keltsh : Concepteur sonore 23H15 : GAMEPLAY SYSTÉMIQUE : RÉFLEXION EN CONTINU Tony Zurovec mène une large discussion avec Rob Reininger, Ben Dorsey et Luke Pressley sur les fonctionnalités à venir, comme la vente d'objets usagés, l'inventaire local, la convergence des systèmes de réputation et de mission, les raisons pour lesquelles le fret physique est si important, les prochains événements dynamiques, etc. Tony fera également le point sur l'avancement des efforts visant à intégrer les premiers éléments de la simulation Quantum dans le jeu. Tony Zurovec : Directeur de l'Univers Persistant Rob Reininger : Directeur adjoint, SGS Pillar Ben Dorsey : Concepteur de systèmes senior Luke Pressley : Concepteur principal 01H00 : CLÔTURE AVEC CHRIS ROBERTS Chris Roberts revient pour nous raccompagner à la maison. Chris Roberts : Fondateur et chef de la direction CITIZENCON 2951 ARTICLES DIGITAUX Quelle meilleure façon de célébrer la première CitizenCon entièrement numérique qu'avec des articles numériques ? Ce pack comprend une combinaison spéciale TBF-4 et une arme, ainsi que le trophée commémoratif de la CitizenCon de cette année. La meilleure nouvelle ? C'est gratuit pour tous les backers ! DETAILS UN VOYAGE DANS LE TEMPS RÉCITS DU PASSÉ DE STAR CITIZEN Racontez des moments épiques du passé de Star Citizen pour débloquer des prix intéressants, comme le Tobii Eye Tracker 5, la nouvelle génération de suivi de la tête et des yeux. Rendez-vous le 1er octobre pour plus de détails sur les modalités de participation ! POPCORN ET PIPS REGARDER LA FÊTE ET GAGNER Quittez la CitizenCon 2951 en beauté avec un casque exclusif et personnalisé d'AstroGaming. Préparez-vous à ce concours en organisant la fête la plus épique que vous puissiez ! Nourriture à thème ? Des décorations ? Un code vestimentaire à thème ? Tous ces éléments vous aideront à remporter la victoire ! Rendez-vous le 1er octobre pour plus de détails sur les modalités de participation ! Traduction : @LooPing - Swiss Starships

Le Symposium interdisciplinaire sur le covid-19 s'est tenu le 29 et 30 Juillet 2021. A travers une réunion d'experts en médecine, en économie ou encore en journalisme, ce symposium cherche à rétablir la vérité sur les événements auxquels nous assistons depuis bientôt 2 ans. Il essaye de répondre à des questions telles que : D'où vient le SARS-Cov-2 ? Est-il d'origine naturelle ou fabriqué par l'homme ? S'il est fabriqué par l'homme, par qui et pourquoi a-t-il été fabriqué ? Quelle est la réelle efficacité des vaccins ? Y a-t-il un agenda dissimulé derrière ce vaste théâtre "sanitaire" ? Quelles sont les conséquences économiques et sociales des mesures restrictives ? Ont-elles réellement été prises pour des raisons sanitaires ? Quelles solutions avons-nous pour sortir de cette situation catastrophique ? Des figures comme celles de Reiner Fuellmich, Vera Sharav, Sucharit Bhakdi, Mike Yeadon, Catherine Austin Fitts, Denis Rancourt ou Richard Werner nous fournissent des interventions de grande qualité et nous apportent des éléments clefs. 1 : Introduction du symposium par Sucharit Bhakdi https://odysee.com/@JeanneTraduction:a/01-Intro-Bhakdi:2 2 : Les origines du SARS-CoV-2 par Michael Palmer https://odysee.com/@JeanneTraduction:a/02-Palmer:e 3 : Ulrike Kämmerer sur les tests PCR et les faux positifs https://odysee.com/@JeanneTraduction:a/03-KämmererPCR:2 4 : Dr. Denis Rancourt sur la fausse pandémie https://odysee.com/@JeanneTraduction:a/04-Rancourt:0 5 : Dr. Harald Walach sur le pouvoir des masques https://odysee.com/@JeanneTraduction:a/05-Walach:b 6 : L'impuissance des médecins https://odysee.com/@JeanneTraduction:a/06-White-Binder-Hoffe:6 ... à suivre...

La dépopulation par la stérilisation ! Reiner Fullmich Le Dr Bryan Ardis nous fait part de ses recherches quant au remdesivir ainsi que le protocole sanitaire et de la FDA qui savait pour les effets indésirables. https://infovf.com/video/depopulation-par-sterilisation-reiner-fullmich--10349.html ------------------------------------------------------ Ils construisent une civilisation multi planétaire Catherine Austin Fitts est une banquière d'affaires américaine et une ancienne fonctionnaire qui a été directrice générale de Dillon, Read & Co. et, pendant la présidence de George H.W. Bush, secrétaire adjointe au logement et au développement urbain des États-Unis. Elle a beaucoup écrit et commenté sur le sujet des dépenses publiques et a allégué plusieurs cas de fraude gouvernementale à grande échelle. Catherine Austin Fitts témoigne ici auprès de l'équipe de l'avocat Reiner Fullmich de ses connaissances sur le Going Direct Reset, des banques fédérales. Selon elle, d'innombrables schémas économiques permettraient à l'ensemble de l'humanité de vivre dignement. De plus, elle soupçonne fortement les "élites" souvent invisibles, d'être en capacité depuis l'espace de déployer des forces dont nous n'avons pas connaissance, tels des tremblements de terre ou des tsunamis (exemple de 2004). https://infovf.com/video/ils-construisent-une-civilisation-multi-planetaire--10054.html