e-t172

Members
  • Content Count

    33
  • Joined

  • Last visited

    Never

About e-t172

  • Rank
    Advanced Member
  • Birthday 02/01/1990
  1. A comparer avec la mort de StargateTC: Source. Bon, c'est pas étonnant au final, en relisant le post-mortem de SGTC:S je conclus que j'avais fort bien prédit ce qui allait vous arriver, à savoir que vous engagiez des gens que vous n'auriez pas dû engager et gardiez des gens qu'il ne fallait pas garder. Le problème c'est que dans notre cas (celui de SGTC:S), après le ménage, il ne reste plus grand monde. La déduction que j'en fais c'est que le point d'équilibre n'existe pas. Soit : - Y'a du monde et le travail avance, mais ça se met sur la gueule et le résultat est un compromis sans saveur - Y'a peu de monde et tout le monde est d'accord mais ça n'avance pas Y'a pas de solution. Je commence sérieusement à croire que tout mod Stargate est inéluctablement voué à la médiocrité (SGTC) ou à se casser la gueule avant de sortir une version finale (SGTC:S), SGTC2 étant probablement quelque part au milieu (quoique je ne vous connais pas assez pour jauger). Au final je regrette pas d'avoir quitté le milieu pour vaquer à des occupations plus productives. (Oh, j'oubliais une anecdote croustillante : Anders, le grand méchant de la news, n'avait à l'époque réussi à survivre que quelques jours sur le forum de SGTC:S avant de se faire bannir violemment. Comme quoi, notre flair n'était pas si mauvais.)
  2. Ton raisonnement est faux pour deux raisons : L' "historique" dont tu parles (qui n'est rien d'autre que le lag compensation dont je parle dans mon document) dépend du tickrate et non pas des FPS serveur (ça tombe sous le sens si on connaît la définition d'un tick). Le choke n'est jamais dû à un manque de ressources de calcul côté serveur. Il est toujours dû à un manque de bande passante. Rien d'autre. Fais le test : fais tourner un serveur avec 100 bots, en tickrate 100 et avec des programmes qui bouffent 100% du CPU à côté. Tu lagueras à mort, le tickrate réel du serveur sera complètement pourri, donc ton updaterate réel aussi, mais tu n'auras pas de choke. Qui te dit que lorsque tu augmentes ces FPS, tu ne diminues pas le choke, mais tu empêches le serveur de calculer correctement le choke, et la valeur affichée dans ton net graph serait ainsi erronée et te montrerait un choke plus bas alors qu'il ne l'est pas ? C'est avec ce genre de raisonnement fallacieux qu'on en arrive à sortir des trucs absurdes à propos du netcode. Avant de prétendre avec certitude que ça marche, il faut d'abord se demander pourquoi ça marcherait. J'étudierai ce problème lorsque j'aurai fini mon bac. En attendant, j'aimerais savoir à quel tickrate tournent les serveurs que tu as "améliorés", et leur valeur de fps_max initiale avant tes modifications, puis après.
  3. Je ne suis probablement pas le seul dans cette situation : sans doute à cause des récents problèmes chez Steam, mon serveur dédié Linux fraîchement installé ne veut pas se lancer. Un strace donne ceci : LD_LIBRARY_PATH=.:bin strace ./srcds_i686 -game dod -tickrate 100 +ip 87.98.129.29 +maxplayers 14 +map dod_avalanche connect(8, {sa_family=AF_INET, sin_port=htons(27030), sin_addr=inet_addr("207.173.177.11")}, 16) = -1 ETIMEDOUT (Connection timed out) close(8) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8 connect(8, {sa_family=AF_INET, sin_port=htons(27030), sin_addr=inet_addr("207.173.177.12")}, 16) = -1 ETIMEDOUT (Connection timed out) close(8) = 0 gettimeofday({1166272171, 671650}, NULL) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8 connect(8, {sa_family=AF_INET, sin_port=htons(27030), sin_addr=inet_addr("207.173.177.11")}, 16) = -1 ETIMEDOUT (Connection timed out) close(8) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8 connect(8, {sa_family=AF_INET, sin_port=htons(27030), sin_addr=inet_addr("207.173.177.12")}, 16) = -1 ETIMEDOUT (Connection timed out) close(8) Il semblerait que srcds tente de se connecter à 207.173.177.11 et 207.173.177.12, mais n'y parvient pas, ce qui empêche le démarrage. Après vérification, ces IPs sont situés à Vancouver, et ne répondent pas aux pings. J'imagine qu'il va falloir attendre que Valve remette ces serveurs en place. Si quelqu'un a des informations supplémentaires, qu'il le fasse savoir, merci.
  4. L'ajout d'une CVAR sv_mincmdrate est _TRES_ pertinent. Il permettra d'éviter que certains joueurs jouent sur leur cmdrate pour se rendre plus difficiles à toucher. Pour les détails, voir mon document : http://articles.e-t172.net/srcnetcode/#comp_interp_cmdrate
  5. Je confirme : le corps est bien fichu, mais son visage est franchement horrible. Trop carré.
  6. Va-t-on ENFIN avoir le 64 bits sur les dédiés Linux (srcds_amd64) ?
  7. Je viens de voir la fameuse fiche : http://mods.moddb.com/4211/ Ce que je n'arrive pas a comprendre c'est que la news de leur site mélange gaiement des screens pour Source et pour Renegade. A moins que les screens du début ne soient en fait que des rendus 3dmax (ou un truc du style)
  8. Heuh, j'ai l'impression qu'il y a une grosse couille là : http://mods.moddb.com/631/ Indique que le mod est pour le moteur de Renegade et non pour Source. D'ailleurs les screen shots ingame sur le site le laissent furieusement penser : exactement le meme style et le meme HUD, couleurs, style de texte que C&C Renegade. EDIT : Arcanos > non, la main de Nod dans les screens publies est bien la main de Nod de Soleil de Tiberium et non de C&C premier du nom.
  9. Pour l'anecdote, j'ai contacté personnellement caouecs pour qu'il fasse la news à la minute même où mon document est sorti, mais il a tardé à le faire et du coup elle est arrivée sur Vossey par un autre moyen, à savoir par Half-Life fusion après être passée par Nofrag xD
  10. Notez que je viens de rajouter des informations sur les protocoles HLTV et SourceTV dans le document.