bon on a la réponse

Ce qui active la transition d'information et donc le transfert du joueur d'un serveur A à un serveur B (alias entre un système A et un B), c'est le jump point. Et à mon avis, le jump point permet de décharger et charger la map côté client.

Le 12 mars 2024 à 18:20:17 :

Le 12 mars 2024 à 09:23:58 :

Le 12 mars 2024 à 09:12:48 :

Le 12 mars 2024 à 08:23:00 :
Alors en fait actuellement le joueur de bouge pas quand il "traverse" le jump point, sa position sur la Megamap ne change pas c est la Map de Pyro qui est chargé a la place de la Map de Stanton, c est facile de s en rendre compte car la position du joueur reste identique sur les deux Map , par exemple le point de saut Stanton - Pyro se trouve proche de Area 18 et vous apparaissez en bas a gauche de la Map de Pyro, inversement si vous allez de Pyro a Stanton le jump point se trouve en haut a droite de la Map et vous vous retrouvez au même endroit en haut a droite sur la Map de Stanton a côté de Microtech

Les vaisseaux bougent nécessairement dans les jump point , sinon il n'y aurait pas de collision a la sortie

Et il y a des joueurs qui ont bien remonté qu'ils ont du avancer manuellement sur certain vaisseaux ou l'auto pilote ne s'enclenchait pas

Oui tu bouges a travers le jump point mais difficile de déterminer la réelle distance que tu parcours, même pas sûr que ça ait vraiment un sens dans le test actuel.

Le fait que l'on apparaisse un peut près au même point dans les 2 systèmes est du au fait que les deux grilles physiques des système soient entremêlés et que les tunnels soient plus ou moins des lignes droites

Un peu près Comme dans mon schéma ci dessous

Si tu pars d'un point en haut à gauche d'un système tu apparaîtra au haut a gauche dans l'autre système
Et ainsi de suite
Donc ta position par rapport aux systèmes ne veut rien dire sur le fait que les vaisseaux se déplacent ou pas .
Par contre voir les 2 étoiles apparaître au bout d'un moment comme on peut le voir dans la vidéo Star Engine ou dans les screens de la vidéo leak que j'ai mise alors qu'au départ il n'y a qu'une seule étoile
Ca montre bien que les positions des 2 étoiles sont bien distinctes et que les vaisseaux se déplacent bien entre eux

Si la Map Pyro se chargeait a la même position que celle de Stanton il n'y aurait toujours qu'une seule étoile visible et exactement a la même position
Ce qui n'est pas le cas

J ai pas tout les détails techniques mais ça a été confirmé par un dev sur le forum Evo et il a dit que ça serait différent lors des futurs implémentation

Laisse Crunky insiste total avec son dessin moisi après avoir pourtant compris il y a quelques pages...
Ceci dit un truc intéressant, on peut connaitre sa distance à l'étoile?
Si oui tu pourrais dire à quelle distance de l'étoile Pyro tu es en arrivant et à quelle distance tu es de l'étoile Stanton avant de partir? (Parce que le système Pyro étant censé être bien plus grand que celui de Stanton, si tu pars du bout de la map Stanton, tu ne devrais pas atterir au bout de la map Pyro qui est censé plus grande)

J'ai compris quoi ? je t'ai juste donner le point pour passer a autre chose hein
mais maintenant qu'il y a la video leak
ben force est de constater que ton dessin n'est pas moins moisie que le mien surtout quand il n'explique pas comment on peut voir les deux étoiles a la fois
Désolé mon cher mais mon schéma est plus proche de la réalité que du tient qui n'a aucun aucun sens dans un monde multijoueur

Le 12 mars 2024 à 20:17:40 :
Ce qui active la transition d'information et donc le transfert du joueur d'un serveur A à un serveur B (alias entre un système A et un B), c'est le jump point. Et à mon avis, le jump point permet de décharger et charger la map côté client.

la transition d'information elle se fait entre les serveurs du shard et la couche de réplication en permanence

Quand une entité est sur un serveur le serveur en question renvoie les données de sa simulation au replication layer , et ce dernier les réplique aux autres serveurs et aux client , c'est a dire que pour une entité a un instant T tu as un serveur qui a l'autorité , qui envoie les données et les autres serveurs lisent ces données de la couche de réplication en tant que client

le jump point pour cette version est effectivement le déclencheur pour transférer l'autorité d'un serveur à l'autre
(ultérieurement notamment avec le server meshing intra système ca sera juste une frontière invisible pour le joueur )

Mais il faut distinguer le transfert d'information et le transfert d'autorité ce n'est pas la même chose

Le 12 mars 2024 à 21:26:18 :

Le 12 mars 2024 à 20:17:40 :
Ce qui active la transition d'information et donc le transfert du joueur d'un serveur A à un serveur B (alias entre un système A et un B), c'est le jump point. Et à mon avis, le jump point permet de décharger et charger la map côté client.

la transition d'information elle se fait entre les serveurs du shard et la couche de réplication en permanence

Quand une entité est sur un serveur le serveur en question renvoie les données de sa simulation au replication layer , et ce dernier les réplique aux autres serveurs et aux client , c'est a dire que pour une entité a un instant T tu as un serveur qui a l'autorité , qui envoie les données et les autres serveurs lisent ces données de la couche de réplication en tant que client

le jump point pour cette version est effectivement le déclencheur pour transférer l'autorité d'un serveur à l'autre
(ultérieurement notamment avec le server meshing intra système ca sera juste une frontière invisible pour le joueur )

Mais il faut distinguer le transfert d'information et le transfert d'autorité ce n'est pas la même chose

C'est bien, tu me sors la définition d'une base de donnée qui communique avec un ou des serveur(s).

Oui, je parlais de ce qu'on a actuellement. J'espère bien que cela changera car sinon ils auront pris 12 ans pour sortir quelque chose qui existe déjà depuis 10 ans.

Oui, le transfert d'autorité. Tu passes d'une communication avec un serveur A vers un serveur B. Quand je parle de transfert d'information, c'est justement que le serveur B se met à gérer les données de la DB (ce que CIG appelle RL) et non plus le A. Et oui, je résume énormément.

Our goal is to have another Tech-Preview Server Meshing test for select waves of testers (Multiple Waves, not evo only) starting on Friday and running through the weekend. This Server Meshing test will be focused solely on the Stanton system, with multiple servers sharing the load. We will be testing multiple configurations throughout the weekend with more servers per shard than we have ever tested before, increasing the number of players per shard to stress test the system.

ah ouais quand même, très très curieux de voir le résultat
et il y aura pas que les evos qui auront accès

Ce week-end à partir de vendredi : petit test de SM intra Stanton !

Et apparemment ce sera pas seulement pour les Evo donc surveillez vos mails

Edit: Alba plus rapide

Le 20 mars 2024 à 00:07:32 :

Our goal is to have another Tech-Preview Server Meshing test for select waves of testers (Multiple Waves, not evo only) starting on Friday and running through the weekend. This Server Meshing test will be focused solely on the Stanton system, with multiple servers sharing the load. We will be testing multiple configurations throughout the weekend with more servers per shard than we have ever tested before, increasing the number of players per shard to stress test the system.

ah ouais quand même, très très curieux de voir le résultat
et il y aura pas que les evos qui auront accès

oh yeahhhh

S'ils découpent Stanton en un maximum de serveurs c'est sensé réduire considérablement les 30k non ?

Ça + un RL relativement rapide ça peut être vraiment cool en terme de stabilité ! Et si en plus ça améliore les perfs, c'est un autre jeu

more servers per shard than we have ever tested before,

Aya!!! Je ne pensais pas que ca allait arriver si vite!! Très hypé par ces tests.

Je suis curieux de savoir comment se comportera le jeu avec un serveur par planete. On va voir ca

Le 12 mars 2024 à 23:00:47 :

Le 12 mars 2024 à 21:26:18 :

Le 12 mars 2024 à 20:17:40 :
Ce qui active la transition d'information et donc le transfert du joueur d'un serveur A à un serveur B (alias entre un système A et un B), c'est le jump point. Et à mon avis, le jump point permet de décharger et charger la map côté client.

la transition d'information elle se fait entre les serveurs du shard et la couche de réplication en permanence

Quand une entité est sur un serveur le serveur en question renvoie les données de sa simulation au replication layer , et ce dernier les réplique aux autres serveurs et aux client , c'est a dire que pour une entité a un instant T tu as un serveur qui a l'autorité , qui envoie les données et les autres serveurs lisent ces données de la couche de réplication en tant que client

le jump point pour cette version est effectivement le déclencheur pour transférer l'autorité d'un serveur à l'autre
(ultérieurement notamment avec le server meshing intra système ca sera juste une frontière invisible pour le joueur )

Mais il faut distinguer le transfert d'information et le transfert d'autorité ce n'est pas la même chose

C'est bien, tu me sors la définition d'une base de donnée qui communique avec un ou des serveur(s).

Une base de données ne communique pas avec des serveurs déjà pour commencer ....
la communication se fait via des requêtes et des services liés au jeu
et je ne parle pas de base de données mais de réplications ...
la base de données c'est une chose la réplication en est une autre

Oui, je parlais de ce qu'on a actuellement. J'espère bien que cela changera car sinon ils auront pris 12 ans pour sortir quelque chose qui existe déjà depuis 10 ans.

Faux aucun jeu vieux de 10 ans ne permet de répliquer l'intégralité des états de jeu en temps réel sur plusieurs serveurs de façon complètement seamless pour les joueurs

habituellement dans les jeux en ligne quand il y a réplication sur plusieurs serveurs de jeu dans une session , ca ne concerne qu'une partie des données ayant très peu de changement en temp réél , comme ton profil, l'inventaire de ton perso , les quêtes etc

mais tous ce qui est interactions physique et en temps réel comme par exemple répliquer le mouvement d'un objet sur plusieurs serveurs , ou des tirs
On est clairement plus sur le même niveau ni la même complexité de réplication
surtout quand on prend en compte la complexité des entités (ex un joueur qui interagit avec des objets dans un vaisseau en mouvement)

Oui, le transfert d'autorité. Tu passes d'une communication avec un serveur A vers un serveur B. Quand je parle de transfert d'information, c'est justement que le serveur B se met à gérer les données de la DB (ce que CIG appelle RL) et non plus le A. Et oui, je résume énormément.

Non le RL ce n'est pas la database , la database c'est l'entity graph pour le shard ainsi que la database globale du jeu
le RL lui c'est la couche de réplication , c'est la couche ou se passent toutes les instructions RPC (remote processus call) qui sont des instructions sous forme d'events qui s'exécutent sur des machines distantes

Par exemple si je veux faire avancer un vaisseau ,
dans le cas ou la simulation serveur et la partie replication ne sont pas séparé
Quand je clique sur le bouton avancer , mon pc envoie un event "avancer vaisseau" au serveur qui lui aura des instructions qui exécuteront l'évent de son coté (car initialement le serveur aura une copie de mon vaisseau ainsi que du reste du jeu dans le même état que sur mon pc) et une fois fini et l'exécution de l'event validé le serveur demande a son tour au client donc mon pc d'executer le même process de son coté

C'est ça la principe de réplication dans un jeu en ligne bien sur dans les faits réels c'est un peu plus complexe car déjà il faut que tout le process soit asynchrone sinon bonjour les lags et les gros temps de latences a chaque action

Pour une situation ou la partie simulation et réplications sont séparées c'est le même principe , saut que la partie de réplication va uniquement gérer la prise en compte des events

On ne parle donc pas de réplication d'une base de donnée , mais de réplication d’évènements de jeu (etats de jeu) entre client et serveurs

Le 20 mars 2024 à 00:07:32 :

Our goal is to have another Tech-Preview Server Meshing test for select waves of testers (Multiple Waves, not evo only) starting on Friday and running through the weekend. This Server Meshing test will be focused solely on the Stanton system, with multiple servers sharing the load. We will be testing multiple configurations throughout the weekend with more servers per shard than we have ever tested before, increasing the number of players per shard to stress test the system.

ah ouais quand même, très très curieux de voir le résultat
et il y aura pas que les evos qui auront accès

C'est bon, ça !!

J'espère être dans la vague de test
Je suis wave 1 d'habitude sur le PTU

Si ça permet de libérer de la puissance pour que les serveurs gèrent plus et mieux les pnj / créatures et réduire la desync, ça va être trop bien.

Le 20 mars 2024 à 08:53:57 :
Si ça permet de libérer de la puissance pour que les serveurs gèrent plus et mieux les pnj / créatures et réduire la desync, ça va être trop bien.

Et ça permettra de rajouter des joueurs également.

Le 20 mars 2024 à 08:57:04 :

Le 20 mars 2024 à 08:53:57 :
Si ça permet de libérer de la puissance pour que les serveurs gèrent plus et mieux les pnj / créatures et réduire la desync, ça va être trop bien.

Et ça permettra de rajouter des joueurs également.

Après ça serait dommage d'enfin avoir de la puissance serveur mais de la baisser directement en ajoutant des joueurs.
Mais oui aussi, faudra voir si ça aide les gros dogfight.

Le 20 mars 2024 à 08:15:04 :
J'espère être dans la vague de test
Je suis wave 1 d'habitude sur le PTU

Tu es sub ou Concierge au dessus de 25k euros ?

Parce que le système de vagues a changé depuis l année dernière.

Le 20 mars 2024 à 08:57:04 :

Le 20 mars 2024 à 08:53:57 :
Si ça permet de libérer de la puissance pour que les serveurs gèrent plus et mieux les pnj / créatures et réduire la desync, ça va être trop bien.

Et ça permettra de rajouter des joueurs également.

Pas vraiment ça à moins de gérer le rassemblement de ces derniers au même endroit. On aura ce decuplement de joueur qu'avec une gestion dynamique et toutes les mécaniques adequate pour gérer les situations de stress.

Je me demande si certains essaieront de trouver les zones de transitions, ça m'interesserait de voir les transitions puisque c'est un peu le truc le plus important pour la suite.
Genre un vaisseau de joueur dans un server et un autre dans l'autre serveur.

Donc des tests de Stanton divisé en plusieurs serveurs arrivent?

En espérant que soit convainquant pour passer de 2 serveurs, puis 3 4, etc et même juste pour une planète ou ville.
On pourrait donc déjà voir beaucoup plus de monde avec ça.

Pis Trou de ver et Pyro bordel!

Le 20 mars 2024 à 09:23:25 :

Le 20 mars 2024 à 08:57:04 :

Le 20 mars 2024 à 08:53:57 :
Si ça permet de libérer de la puissance pour que les serveurs gèrent plus et mieux les pnj / créatures et réduire la desync, ça va être trop bien.

Et ça permettra de rajouter des joueurs également.

Pas vraiment ça à moins de gérer le rassemblement de ces derniers au même endroit. On aura ce decuplement de joueur qu'avec une gestion dynamique et toutes les mécaniques adequate pour gérer les situations de stress.

Ca ne sert a rien d'affirmer ce que tu ne sais pas
S'ils vont tester un plus grand nombre de joueurs ce n'est pas pour rien ...