J'ai essayé de faire un poil plus simple que le dernier post, mais ça reste un petit pavé, je préviens !

Rappels sur le serveur Ryzom

Dans Ryzom, tous les calculs de gameplay sont calculés côté serveur ; le client ne fait pas grand chose d'autre que recevoir des informations du serveur et les afficher. Il faut aussi savoir que le temps pour le serveur (comme pour tous les serveurs de jeux vidéos) ne s'écoule pas de manière continue, mais par petits intervalles de temps (un peu comme une montre qui ne peut mesurer que des secondes minimum). On les appelent des "ticks", et la valeur pour Ryzom est de 100 millisecondes - autrement dit, le serveur est incapable de mesurer des évènements plus rapide que 100 millisecondes (soit une action est instantanée, soit elle dure au moins 100 millisecondes), et on a 10 ticks par seconde. Le choix dépend beaucoup du jeu (par exemple, les FPS ont souvent un tick serveur élevé, entre 30 et 60 ticks par seconde, car c'est des jeux très réactifs).

Calcul de la vitesse

Maintenant qu'on sait ça, on peut se pencher sur les armes. Pour attendre entre 2 actions, Ryzom attend en fait un certain nombre (entier) de ticks. Du coup, quand une arme affiche 60 coups par minute, Ryzom va devoir traduire cette information en nombre de ticks entre deux coups. Pour ça, le calcul est très simple : 60 * 10 (60 secondes à 10 ticks chacune) / vitesse de l'arme. Ici, si on reprend l'exemple de notre dague, elle tape tous les (tout pile !) 10 ticks. Parfait !

Le problème, c'est que les divisions tombent rarement juste ! Si maintenant notre dague n'a que 59 coups par minute, on obtient une valeur de 600 / 59 ~= 10,17 ticks (j'ai arrondi à deux décimales pour ne pas trop complexifier mais ça ne change rien). Et vu que Ryzom ne compte que des nombres entiers de ticks, il applique un mécanisme simple : il tronque la valeur. Notre 10,17 devient 10 ticks, et notre arme à 59 coup/minute tape à la même vitesse que notre arme a 60 coup/minutes ... On a donc un problème à cause de ce tronquage, et des objets avec des vitesses différentes affichées ont en fait la même vitesse réelle !! C'est notre problème n°1 : la vitesse affichée n'est pas la bonne.

Évidemment, vu qu'un bug ne vient jamais seul, il y a aussi un autre problème : en réalité, les statistiques d'une arme (dégâts, vitesse, parade, etc) ne sont pas des nombres entiers comme affichés, mais des nombres à virgule (pour notre vitesse, en réalité elle vaut sûrement 59.43, et pas juste 59). Cependant, pour toutes les autres statistiques, on prend la valeur tronquée, et non pas la valeur réelle pour faire le calcul. Sauf pour la vitesse (pour une raison inconnue). Souvent, ça ne change pas grand chose ; entre 59.5 et 59, avec le tronquage on se ramène à la même valeur de ticks (10). Sauf dans des cas un peu particulier, juste autour d'un entier. Par exemple, si vous prenez une dague qui a une vitesse de 54.5 et une qui a une vitesse de 54.6, la première aura un temps d'attente de 11,01 ticks (soit 11 ticks), et la deuxième un temps d'attente de 10,99 ticks (soit 10 ticks). Du coup, vous avez deux dagues avec la même vitesse affichée, et qui ont une vitesse réelle différente. Et la seule manière de le savoir, c'est de passer par l'API (qui vous donne les valeurs précise pour un objet) - très clairement, ce n'est pas évident ... C'est notre problème n°2 : la vitesse de calcul est différente de la vitesse affichée.

Jamais deux sans trois, et cette fois-ci c'est un pur problème de logique au niveau du code qui gère les actions cycliques (celles qui se répètent, comme en particulier les attaques). Imaginez que vous avez un délai d'attente de 18 ticks (une pique full vitesse par exemple), et bien en pratique vous ne frapperez (et ferez des dégâts) que tous les 20 ticks. En effet, le gestionnaire de phrases sabrina (celui qui gère les actions cycliques), est un automate fini avec certains états (action démarrée, action en cours d'exécution, action en attente ...). Le changement d'état d'une action "en attente" (le délai n'est pas encore écoulé) à une action "en exécution" prend 2 ticks, vu la manière dont c'est codé. C'est notre problème n°3 : les attaques (ainsi que le forage) sont toutes ralenties de 2 ticks.

Enfin, un petit bug de précision & de tronquage fait que dans le cas d'une dague à 60 coups par minute, la vitesse calculée est de 9.99999 ticks, qui sera donc tronquée à 9 ticks, au lieu des 10 prévus. C'est notre problème n°4.

Application au craft

Vu que plusieurs vitesses en coup / minute permettent d'avoir la même vitesse réelle calculée, ça veut dire qu'il n'y a aucune différence entre une dague à 54.6 cpm et une à 60 cpm. Par contre, c'est bien plus facile de fabriquer une dague à 54.6 cpm, vu qu'il faut une statistique de vitesse bien plus faible : 81,83 contre 100 (ça veut dire qu'en suprême, vous n'aurez à priori pas besoin de mettre de mp qui donnent de la vitesse tant qu'aucune n'en enlève ... plutôt balèze hein ?). Pour trouver cette valeur c'est simple :

* On calcule l'attente en tick pour la valeur maximale de vitesse. Ici, 600 / 60 = 10 ticks.
* On prend la valeur en ticks juste supérieur (ici, 11), et on trouve la vitesse qui correspond : 600 / 11 = 54.55.
* On rentre cette valeur dans la formule de calcul de craft, qui est minimum + (maximum - minimum) * precraft = postcraft, donc ici pour la dague
30 + (60 - 30) * x = 54.55 <=> x = 0,8183, on multiplie ça par 100 pour avoir le precraft, ça nous fait 81,83
* Si on craft avec une vitesse > 81.9 (en prenant une petite marge de sécurité), on aura donc un délai d'attente en tick < 11 (donc tronqué à 10)

pre = (post - min) / (max-min)

Pour la valeur craft boost, c'est sensiblement similaire, on prend juste la valeur en ticks inférieure (17 pour une pique à 18, par exemple), on obtient le point de bascule [ne pas oublier de diviser par 1.2 pour avoir le precraft, c'est les 20% rubbarn] (par ex 93.15), avec une vitesse > 93.15 on aura donc un délai d'attente en tick < 17, donc tronqué à 16)

Pour trouver les informations pour toutes les armes (vitesse minimale, maximale, et donc temps d'attente en ticks), il suffit de regarder la config de l'EGS. Il faut savoir que les vitesses minimales / maximales ne sont pas des nombres entiers mais des nombres à virgule. Les valeurs precraft minimales à atteindre (craft normal, et craft boost) sont les suivantes : (il faut juste prendre une marge de sécurité de 0.1)

Arme - précraft - precraft boost
Dague - 81.82 - 83.33
Bâton / Épée 1M - 87.52 - 95.26
Massue / Hache 1M - 94.14 - 88.56
Lance - 93.05 - 89.92
Épée 2M - 90.48 - 92.1
Massue / Hache 2M - 91.33 - 91.29

Régler les problèmes ?

Ici, on est clairement dans le cas de problèmes impactant le gameplay : deux armes identiques sur le client peuvent en fait avoir des dégâts par minute différents, toutes les armes sont plus lentes de 2 ticks que prévu (ce qui fait entre 8% et 14% de différence de dégâts par minute, c'est loin d'être négligeable), et enfin deux vitesses affichées différentes qui sont identiques en réalité, ce qui induit en erreur sur la véritable capacité de l'arme. Pour moi, tous ces bugs sont à régler, de la manière suivante :

Problème n°2 : Soit utiliser la valeur entière pour les calculs, soit afficher la valeur à virgule. Pour moi, c'est absurde d'afficher une valeur à virgule (on parle de coup/minutes), et il est mieux d'utiliser la valeur entière pour les calculs (comme dans pratiquement tous les calculs avec des objets, à part le facteur de protection, et ça a un peu de sens car une attaque pouvant monter facilement à 1000, la différence de dégâts entre deux valeurs distantes de 0.1% est au moins 1)
Problème n°3 : C'est un pur bug pour moi, il suffit juste de le régler et de permettre à une action de passer de l'état "en attente" à "en exécution" immédiatement.
Problème n°4 : Idem, un bug, régler l'arrondi.
Problème n°1 : Ici, c'est plus complexe à régler, car soit on modifie les valeurs de vitesse pour que "ça tombe bien" (indice : c'est pas possible si on veut garder la diversité d'armes qu'il y a sur Ryzom), soit on compte des délais d'attente non pas en valeur entière (10 ticks), mais en valeur à virgule (10.2 ticks). Ça veut dire que vos actions d'attaque ressembleraient à ça :
* t=0, attaque n°0
* t=10, attaque n°1
* t=20, attaque n°2
* t=30, attaque n°3
* t=40, attaque n°4
* t=51, attaque n°5
* t=61, attaque n°6
* t=71, attaque n°7
* t=81, attaque n°8
* t=91, attaque n°9
* t=102, attaque n°10
On aurait donc 5 attaques en 51 ticks (notez qu'au début on a une petite différence car la première attaque est instantanée).
En fait, il se trouve que ce n'est pas très difficile à changer, et faisable uniquement pour le sous-système qui s'occupe des actions cycliques (on ne touche pas à l'immense majorité du code des ticks, ce qui évite les bugs partout).

Il se trouve que tout ceci a été réglé dans RyzomCore, de la manière que j'ai indiqué comme préférentielle (c'est normal, c'est moi qui ai fait les fix). Il suffirait donc simplement à Winchgate d'intégrer les bugfix à leur code (et, si ma manière de faire ne convient pas, changer à leur goût, ce qui est relativement facile à faire vu que j'ai identifié toutes les parties du code qui posent problème et expliqué les mécanismes internes du sabrina manager). Ceci ayant été fait il y a 3 mois, j'imagine que ce n'est pas une de leur priorité, ce qui est dommage à mon goût (et si jamais ils le font, pensez aussi à merge le fix pour le bug des monstres buggués qui n'aggro plus, cf l'issue RC, ça serait super cool parce que j'en vois partout maintenant :D). Je sais que c'est pas forcément évident de merge du code, mais là le fonctionnement étant identique entre le serveur officiel et RyzomCore, le code derrière est à priori le même ... donc ça devrait aller :)

Bisous à tous, si quelqu'un a la motivation de traduire ça en anglais et/ou allemand ça serait sympa, je le rajouterai au post (j'avoue que je n'ai pas la motivation de le faire pour l'anglais, et l'incapacité complète de le faire pour l'allemand)

@Lopy merci pour ton travail, mais ca serait bien que tu enleves ses valeurs.
Mais par contre, c'est en effet un veritable soucis comme je te l'avais dis lorsque l'on avait discuter de ce sujet ensemble.

Le point sur lequel je veux principalement te mettre un gros +1 , c'est pourquoi ce n'est pas encore merge et donc corriger sur le serveur officiel ?

- Etait-ce la une volonte de la Ryzom Team de laisser certains groupes de joueurs avantage dans le craft ? (parce que ce bug n'est pas nouveau et des guildes l'utilise pour leurs crafts depuis plusieurs annees) (et oui quand on met en vente nos surplus de craft lors de tentative de boost et que les armes n'affichent pas la vitesse max mais 1 en dessous, elles sont full vitesse)

- Personne ne s'occupe du serveur et est donc capable de merger du code ? (au vu des patchs que Lopy propose ne sont pas d'une complexite qui demanderait plusieurs jours pour l'integration).

Ca serait bien d'avoir une reponse officiel sur ce que la RT pense de ces patchs, si ils sont acceptables ou non sur Atys, et si ils sont rejetes pour le sont-ils ?
Parce que la ca donne clairement l'impression que quelqu'un fait un gros effort pour comprendre et corriger des mecaniques (et ce sur son temps libre et cette dite personne n'a pas remuneration) et en retour la RT ne s'y interesse pas une seule seconde. A ce rythme la, le peu de personne encore motive pour le code ne vont plus faire grand chose.

C'est peut être ce qu'on appelle les secrets du craft et qui donne un peu de magie au jeu et de valeur aux bon crafteurs.
Mais une fois que ces bugs/magies sont connues et diffusés ( comme tu le fait), autant corriger ces bugs.
Merci pour ton travail Lopyrech.

Félicitations Lopyrech non seulement pour tout le travail effectué mais pour en plus partager tout ça à la différence de ceux qui gardaient jalousement le secret :)
Bravo.

Non, le secret de la puissance de nos armes est enfin révélé !

Très bon boulot en effet ! C'est très bien expliqué en plus.

Je reviens sur les questions souvelées.

Parceque le code RyzomCore et officiel n'est pas à 100% le même. Ryzom Core a pour vocation de fournir un moteur de jeu le plus indépendant de Ryzom possible (pour des projets comme Khaganat par exemple) alors que le serveur officiel se concentre sur des ajouts propres à Ryzom. Bien que les différences ne soient pas hallucinantes, il ne suffit pas non plus de patcher les modifications. Il faut donc plusieurs jours pour l'intégration.
Parce qu'aussi avec Atysmas il y a eu peu de temps pour le faire, tout simplement.

Non, le travail de Lopyrech est remarquable, il n'avais jusque là jamais été fait.
Done !


Hummm 99% des gens sur RT sont aussi des bénévoles souvent venus de Ryzom Core ou étant aussi sur Ryzom Core (comme Kervala).

Et justement Kervala a déjà merge ces modifications dans le code de Ryzom Core, ce qui rend possible le merge dans le code du serveur officiel.
Je vois mal en quoi ça donne l'impression qu'on ne s'y intéresse pas.

Bref, tout ça pour dire que le merge sera fait dès que possible (avec le bugfix des mobs bisounours bien évidement :p)

Tout d'abord merci de ta reponse Ulukyn.

On a eue une discussion sur le sujet apres le dernier Ryzom Forge meeting.

Pour mon dernier commentaire, c'etait surtout pour appuyer le fait que peu de personnes font des analyses aussi profondes du code et proposent des patchs sont une denrees rare et ca serait dommage qu'ils ce sentent "exclus" (pas le bon mot mais le principe est la) lorsqu'ils proposent des correctifs sur des bugs qui sont la depuis plus de 10 ans :)

Et quand au fait que ca donne l'impression que personne ne s'y interesse c'est sur ce qu'il ce passe apres le merge dans Ryzom Core.
Est-ce que le code est poussee dans Ryzom etc etc ...
D'apres ce qu'a dit Tamarea ce point pourrait etre resolus avec la nouvelle organisation et les nouveaux outils pour la roadmap, c'est probablement plus ou soucis de communication qu'autre chose en fin de compte.

Et pour revenir a Kervala, p-e que le serveur devrait avoir le meme traitement que le client, aka des changelogs visible de tous :)

En tout cas merci de ta reponse !

Le but est à terme que le code serveur de Ryzom soit une branche de RyzomCore (comme pour le client)

Mais il y a des choses codées en dur (des mots de passe sql, sel de hachage, etc...).

De plus la structure du serveur officiel a completement changé (j'en ai un peu marre d'avoir des binaires dans les sources, des logs n'importe où, alors j'ai tout bien rangé...)

Une fois qu'on aura nettoyé et synchronisé les 2 dépots, on pourra envisager d'avoir un changelog et des modifications open source.

C'est un travail que l'on a commencé à faire depuis un moment en séparant le client, le serveur et les datas privées.

Du coup vous allez libérer le code de toute la partie web ?

Juste pour info, une bonne pratique est de mettre ce genre de données dans des variables d'environnement. Non seulement ça permet de ne pas laisser fuiter d'informations sensibles, mais en plus ça permet de facilement mettre en place des environnement de développement et de test. Bien entendu, c'est très facile à modifier dans le code.

Et vu que tout est bien entendu abstrait par une fonction qui va chercher ces options de configurations, il est aisé de supporter d'autres "backends" que les variables d'environnement. Par exemple, un fichier de configuration.

Allez, en quelques jours c'est fini, on en parle plus.

Nan, on ne parle que des modifications du code serveur. La partie web reste la propriété de Winchgate.


Sauf que même les fichiers de configuration c'est une tannée... il y en a trop.
C'est pourquoi le shard officiel utilise un système avec un fichier unique de configuration qui génère les fichiers de config pour chaque service. Donc pas de soucis de ce point de vue là. 90% du boulot a déjà été fait mais c'est pas fini.

Du coup un shard officiel ressemble à ça :

globals.cfg
cache/
cfgs/
client/
common/
data/
logs/
run/
save/
sbin/
tools/

là ou les shard ryzomcore sont encore avec la structure classique.