[Actu] Report de la sortie de Tyrannis

Répondre
Partager Rechercher
Citation :
Publié par niahoo
Quelqu'un peut m'expliquer ce qu'est un node en gros ? car je pensais que 1 ou plusieurs systèmes étaient répartis sur un serveur, donc "ajouter un node" correspondrait à ajouter un PC pour gérer un ou plusieurs sytèmes, séparés de leur ancien node, ancien node qui serait donc allégé ?
En gros oui. Un node plus petit (aka qui gère moins de systèmes) réduit les chances d'accumulations de joueurs.

Quand CCP demande au pilotes prévoyant de préciser ou et quand, c'est pour permettre leur donner le temps de transférer cet unique système sur une seule machine dédiée. Qui n'aura donc pas à gérer les systèmes voisins.
C'est pour cette raison que parfois
1- ca lag à 300 en local (CCP non prévenu et système sur le même node qu'un grand nombre d'autre systèmes et/ou avec du monde),
2- parfois à 600 (toujours non transféré mais avec que des systèmes vides sur le même node),
3- ou encore beaucoup plus quand CCP à été prévenu à temps.

Le problème c'est que même une machine DLMQT dédiée à un seul système a ses limites, et là, la limite n'est plus en terme de capacités de calcule mais en terme d'échange avec la data base qui elle et commune à tous les joueurs.
L'étape suivante est peut être de localiser un système avec une copie des sections de la database qui concerne les pilotes impliqués. En admettant que ce soit possible.
Il y aura alors plus de goulet d'étranglement au niveau de l'entrée dans la DB comme c'est le cas actuellement.

Bref, augmenter le nombre de node ne règlera jamais le problème du lag quand deux blobs s'affrontent.

EDIT :
Citation :
Publié par Weirdz
Oui enfin bon au debut de Daoc on ramenez tout le royaume pour les prises de reliques = lagfest, crash et fail.
On a pas persisté comme des débiles a faire ca pour rien . On a donc divisé notre pop de dix et etrangement ... Bha ca marché normalement . Tenir compte des limites techniques pour pas wipe comme des moutons c'est mieux!!

Comprenne qui pourra !
+1
J'adore !
Sérieux jveux bien qu'il faut pas cracher sur le travail de CCP mais répondre par des trolls à coté de la plaque, c'est pas mieux...

Je connais pas les règles de Daoc mais je suis sûr qu'elles ne sont pas applicables à Eve. Dans Eve y aura toujours un unique système où tout le monde mettra toutes ses forces dedans à la fin. Et je pense pas non plus que ça soit comparable niveau échelle de temps pour la durée des guerres.
Citation :
Publié par Rhum
Sérieux jveux bien qu'il faut pas cracher sur le travail de CCP mais répondre par des trolls à coté de la plaque, c'est pas mieux...

Je connais pas les règles de Daoc mais je suis sûr qu'elles ne sont pas applicables à Eve. Dans Eve y aura toujours un unique système où tout le monde mettra toutes ses forces dedans à la fin. Et je pense pas non plus que ça soit comparable niveau échelle de temps pour la durée des guerres.
Effectivement, les guerres n'avaient pas leur comparaison en terme de durée : du premier au dernier jour d'exploitation du jeu, sans aucun arrêt, sans aucune pause, avec entre 500 et 1700 personnes en clipping dans la zone de combat principale. Quand à mettre "toutes ses forces" dans un conflit, il y avait bien plus de gens en PVP sur DAoC qu'il n'y a de gens en guerre 0.0 sur Eve, et ce par serveur, n'en déplaise aux fanboys.

Lorsqu'une infrastructure réseau ne permet pas un rassemblement de joueurs au dela d'une limite connue dans un même node/système/grid ... Soit on met un hardcap en tunant le gameplay pour que les joueurs ne soient pas trop désavantagés par le cap (Et il y a des moyens de check les appartenances d'alliance au loading du système pour équilibrer les présences) ... Soit on espère que les joueurs seront assez angéliques et stupides pour respecter gentiment les limites du système sans se plaindre et en étant patients.

Sur ce coup là, les devs de CCP sont soit extraordinairement naïfs, soit complètement à coté de la plaque : en game design, quand tu mets une règle ou une limite, les joueurs feront tout pour l'approcher le plus possible ou la mettre à l'épreuve, c'est le principe de base de tout jeu compétitif.

btw : Oui, CCP fait de la merde en barres sur les blobs en 0.0 depuis des années.

NB : les chiffres que je donne pour DAoC sont une moyenne 2004/2006. Pendant le temps où je travaillais pour eux.
merci les deux pour les explications et liens.

jack, pourquoi dire que CCP fait de la merde ? ils font quand même des trucs très sympa et proposent un jeu tout à fait respectable. disons simplement qu'ils n'ont pas les moyens|possibilités|compétences pour élargir les capacités des serveurs.
La principale différence est je pense qu'une bataille sur DAoC n'engage que le camp A vs le camp B. avec un choix limité de combinaisons camps A B ou C.

Dans Eve, ce n'est malheureusement pas si simple : il y a des centaines de camps dont les allégeance changent avec le temps.
Alors à moins de former deux ou 3 meta alliances fixe, je ne vois pas trop de solution.
Citation :
Publié par Tessen
La principale différence est je pense qu'une bataille sur DAoC n'engage que le camp A vs le camp B. avec un choix limité de combinaisons camps A B ou C.
C'était plus fréquemment a vs b vs c vs a en fait, même si ça fait moins de combinaisons que dans eve.
J'avais bien aimé une idée disparue dans le flood "risk versus reward" (du risque en belt dans un système enfoui dans un 0.0 protégé mouarf ) du forum " features.... ". A savoir instauré un coup isk/minute pour les supercapitaux actifs, le tout tiré sur le wallet alliance (ou corpo si pas d'alliance). Je ne me souviens plus de la raison derrière, mais j'avais trouvé ça intéressant.
Quant à tous ceux encensant ccp: je vous rappelle que ccp est responsable de ça :
http://go-dl1.eve-files.com/media/corp/GODS/GoonSwarmCCG_Action_boot_ini.gif
Citation :
Publié par niahoo
merci les deux pour les explications et liens.

jack, pourquoi dire que CCP fait de la merde ? ils font quand même des trucs très sympa et proposent un jeu tout à fait respectable. disons simplement qu'ils n'ont pas les moyens|possibilités|compétences pour élargir les capacités des serveurs.
Ah mais je paye dûement mes 3 comptes tous les mois, et même pas en ISK ... CCP a pour l'instant le MMO le plus abouti, complet, intéressant et profond du marché. Mais leur couche de code réseau et de gestion du lag est déplorable. En fouillant un peu les fichiers du jeu, je pense qu'il manque d'une version dégradée des textures des ships et des modèles de turrets pour le lag graphique, accompagné d'un sérieux coup de hache dans la masse des informations transmises par le réseau et/ou un meilleur dispatch des opérations réseau ... Je ne connais pas leur plateforme, donc je ne m'avancerais pas pour dire où ça cloche. Simplement, d'autres le font et le font bien, donc il n'y a pas de raisons

Citation :
Publié par Tessen
La principale différence est je pense qu'une bataille sur DAoC n'engage que le camp A vs le camp B. avec un choix limité de combinaisons camps A B ou C.

Dans Eve, ce n'est malheureusement pas si simple : il y a des centaines de camps dont les allégeance changent avec le temps.
Alors à moins de former deux ou 3 meta alliances fixe, je ne vois pas trop de solution.
Le rapport avec la choucroute ?

Tu sais, pour un développeur, la différence entre : "Magicien A lance une boule de feu sur cible B" et "BS Snipe A lançant une salve sur cible B" elle est proche de 0, tu as un point d'origine, une action mouvante dépendant de compétences chiffrées, qui va toucher un point d'arrivée pour XX dégats dépendant de compétences chiffrées ... Y a strictement 0 aucune nada que dalle de différence.

La différence, c'est la façon dont tu dis à ton serveur de calculer les opérations, la façon dont celui-ci renvoie les infos au client et quand, la façon dont ton moteur graphique réagit ... Bref, le codage de ton jeu.

Exemple 1 : Le fait que tout le monde lag quand des gens jetison des Shuttle signifie qu'à l'entrée dans ton système, tu load tous les modèles physiques présents dans le système, ce qui est ridicule quand tu sais qu'il est possible de faire du load à la volée, de faire du load par grid, de faire du load différé ... etc etc etc ...

Exemple 2 : Le fait que les turret effects aient encore des memory leaks après combien d'années d'exploitation ... ? C'est un exemple de codage propre ?
La remarque de Tessen sur les centaines de groupes différents était une réponse à ça :

Citation :
Publié par Jack O'Bannon
(Et il y a des moyens de check les appartenances d'alliance au loading du système pour équilibrer les présences)
Citation :
Publié par Weirdz
Oui enfin bon au debut de Daoc on ramenez tout le royaume pour les prises de reliques = lagfest, crash et fail.
On a pas persisté comme des débiles a faire ca pour rien . On a donc divisé notre pop de dix et etrangement ... Bha ca marché normalement . Tenir compte des limites techniques pour pas wipe comme des moutons c'est mieux!!

Comprenne qui pourra !
Oui oui.... On appelait ça les prises Canadienne et ça râlait autant sinon pire

Citation :
Publié par Eored
BOOT.INI
Ohh putaing, je l'avais oublié cette boulette là Avoir Eve sur un autre DD m'avais épargné.
Huhu, j'me souviens aussi de la panique ce jour là.
C'est depuis ce jour que j'me suis toujours restreint à ne pas me ruer sur les patchs comme un fan boy le plus vite possible.
Patch day no play a pris tout son (bon) sens ce jour là.

BTW, un des premier commentaire est très vrai :
Citation :
Like the way they make fun of it. Great corporation, nobody treats its fans/users as good as ccp does.
Concernant le boot.ini, bon ok, c'est pas la meilleure chose qu'ils aient faites, mais en meme temps un OS où on se connecte plus ou moins en tant que root pour une utilisation quotidienne... (ca change un peu sur Vista....et encore).

C'est marrant comme ce truc n'est pas arrivé sous Linux (et n'arrivera surement pas), faute de CCP.... ou de kro$oft? Sous Linux, essayez de delete un tel fichier....bon courage ! Y'a que Microsoft qui laisse des cavernes pareilles dans ses softs.
Citation :
Publié par Zzabur
...faute de CCP.... ou de kro$oft?
Ah oui ça vas jusque là quand même... Je comprends mieux pourquoi j'en ai pris plein la gueule, CCP est un culte en fait Faut pas critiquer les idoles !

Pour au dessus : Sauf qu'il n'y a jamais eu de client Eve pour téléphone mobile xD
Citation :
Publié par Eyce Karmina
Ca n'arrivera pas sous Linux pour une raison toute simple : il n'y a plus de client Eve pour Linux, et ça c'est de la faute de CCP.
Non la faute que cela n'intéresse pas suffisamment de monde, dommage pour le pingouin
C'est surtout que le client linux fonctionnait franchement moins bien que le client win émulé.
Du coup CCP en a profité pour arrêter le client nux prétextant qu'il n'y avait pas suffisamment de joueurs intéressé. De leurs côté, certains joueurs attendaient un client nux stable pour franchement s'y mettre. Un beau serpent de mer.

Sinon, je suis quand même un peut d'accord, qui pouvait se douter qu'un fichier aussi essentiel que boot.ini ne soit pas protégé ? Franchement ?
Et la je parle pas de CCP fan boy ou d'anti-crosofisme primaire, je parle de la sécurité simple et basique d'un OS utilisé à l'époque par 90% des machines dans le monde.
Perso quand j'ai lu ça, j'ai été abasourdi.
oui d'accord mais bon. 100% des autres jeux arrivent à ne pas supprimer le fichier boot.ini quoi... et surtout, pourquoi toucher à un tel fichier alors que le jeu tourne sur un windows ayant booté de manière tout à fait classique..

alors la faute à microsoft.. mouah.. (clair que c'est mal sécurisé bien sur mais..)

perso j'utilise linux sur un autre pc, mais je joue sur vista, j'aime pas vista, j'aime pas trop microsoft mais j'utilise leurs produits.

et je vois mal les ingénieurs de microsoft se frotter les mains en disant "mouah ha ha, nous allons faire le pire OS de tous les temps "
Citation :
Publié par niahoo
et surtout, pourquoi toucher à un tel fichier
Parce qu'à l'époque, le client Eve utilisait un fichier boot.ini dans le répertoire Eve et que la mise à jour en question devait remplacer ce fichier nécessaire au lancement du jeu. Je crois que maintenant, c'est le fichier start.ini qui a pris sa place.
Le patch, pour remplacer le fichier lançais une commande d'effacement, le seul problème c'est que l'OS effaçait le premier disponible à partir de la partition racine (donc celui de windows) et non celui qu'il devait effacer (dans le répertoire Eve).

Perso, je comprends parfaitement la source de l'erreur : une faute d'inattention (développer le patch hors contexte avec des tests insuffisants selon les dires même de CCP à l'époque : ils n'ont fait que des tests avec une partition dédiée et pas sur C: ) doublé du fait que personne ne pouvait imaginer une telle faille de sécurité dans l'OS.
Depuis CCP à renforcé ses protocoles de tests et c'est tant mieux.
Citation :
Publié par Tessen
Parce qu'à l'époque, le client Eve utilisait un fichier boot.ini dans le répertoire Eve et que la mise à jour en question devait remplacer ce fichier nécessaire au lancement du jeu. Je crois que maintenant, c'est le fichier start.ini qui a pris sa place.
Le patch, pour remplacer le fichier lançais une commande d'effacement, le seul problème c'est que l'OS effaçait le premier disponible à partir de la partition racine (donc celui de windows) et non celui qu'il devait effacer (dans le répertoire Eve).
Petite coquille dans leur programme d'installation. Le chemin complet du fichier n'était pas spécifié, ils pensaient être en chemin relatif (cad par rapport au répertoire où est installé le jeu) alors que le chemin a été interprété comme un chemin absolu, cad C:\boot.ini :x au lieu de C:\Program Files\Eve Online\boot.ini par exemple.
Chemin qui correspond effectivement à un fichier existant et utile de l'OS, c'est vraiment pas de chance ^^
De toute façon c'est pas normal qu'un programme tiers puisse lancer une commande de suppression d'un tel fichier sans que Windows moufte.
Pour moi CCP a merdé sur ce coup là mais le vrai coupable c'est Micro$oft qui nous fait chier avec des trucs inclus complètement nazes mais qui n'assure même pas le minimum en sécurité (qui se souvient que l'UE a du recommander d'arrêter d'utiliser Windows au profit de Linux pour qu'ils se bougent le cul et comble une faille critique en urgence ?)
Linux ne moufte pas quand un sudo make install fait un rm -r /etc au lieu d'un rm -r ./etc
C'est inadmissible, surtout quand on pense que l'UE a recommandé de l'utiliser et dont les mainteneurs de distrib ajoutent des failles d'eux même dans des composants critiques d'un point de vue sécurité parce qu'ils n'ont pas compris comment fonctionne sshd.
Finalement la conclusion évidente de tout çà est de ne laisser le jeu accessible que sous Unix pour régler tous les problèmes de lag d'un seul coup

Sinon plus sérieusement je crains qu'avec ce patch il n'y ait pas que le 0.0 qui se mette à lagger, ça va être de pire en pire dans une bulle de 10 sauts autour de Jita.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés