Ryzom

Bravo tout le monde ^^

Pour ma part je suis en développement sur la version 2.6 de ma petite horloge qui exploitera ce site. Après quelques difficulté au niveau de la précision, j'ai finalement obtienu un bon résultat. Il me reste un ou deux petits détail à régler encore.

EDIT : il semble que nous ne soyons pas tous d'accord dans les dates j'ai "Tria, Fallenor 21, 2e CA 2545" et sur la version web de ryzom avec le nouveau format "Quarta, Mystia 22, 2e CA 2545".

Bon ben, c'est super cool comme ça, on connait le vrai décallage maintenant Merci

Avec 1 jour de décalage y a forcement quelqu'un qui va pas changer de saison en même temps que les autres

Mais avec 1 jour et 2 mois de décalage ca va être encore plus évident

Désolé VL

J'ai aussi un décalage par rapport à la date donnée par l'API de VL. 1 jour et 2 mois ig, c'est d'ailleurs exactement la durée entre le Tick 0 et l'année 2525. Le tick 0 était le 30 Pluvia, 4e CA 2524, 00h00. Enfin ça c'est tout au moins la valeur qui colle avec les changements de saison ig.

Tu peux comparer avec http://lucjaulmes.free.fr/dates.php Kotaro ? Moi il me semble que ma dernière version collait avec ton horloge v2.5. Je me sers que du tick de l'API de VL et pas de la date, btw.

Le truc c'est que le tick part de 0 a partir du lancement du serveur le lundi de la semaine de la release. il y a eu une petit période de test et le jeudi il y a eu la release officiel ou le jeu a vraiment démarre. Si la date du jeu a bien été positionné lors du lancement de la release officiel du jeudi, le tick lui n'a pas été remis à zero. C'est la raison du décalage que l'on observe. On est obligé d'en tenir compte sinon les saisons colles pas :b

J'ai essayé ta page web mais ce soir j'ai une petite erreur (alors qu'avant ca passait très bien). En tout cas j'avais verifié et on avait des résultats identique sur les dates affichées.

Ceci dit tu va pouvoir verifier toi même car voici l'horloge remise à jour en version 2.6 :
- Horloge Atisyenne v2.6 (basé sur la page web de VL).
Power menu (qui n'est pas de moi :b) permet de maintenir cette fenêtre au premier plan :
- Power menu
A noter que je n'ai absolument pas testé les serveurs Aripotle ni Leanon sur lesquels je n'ai pas de compte. Donc si une bonne âme pouvait me faire un retour .

Pour la petite histoire j'ai maintenu le principe de la base de temps afin d'eviter d'interroger le serveur toutes les 30 secondes.
Cette version peu avoir un décalage de maxi 1 minutes IRL (soit 20 minutes IG) par rapport à l'ancienne version 2.5 car je ne sais pas à la seconde près à quoi correspond le tick affiché sur la page web par rapport à la date réelle.
En contre partie cette version est utilisable même lorsque le jeu est éteint et ca c'est une réelle évolution.
Au lancement une fenetre demandera de séléctionner le numero du serveur. Si vous tapez n'importe quoi cela sera toujours "Aniro" qui sera selectionné.

Cette version peu avoir un décalage de maxi 1 minutes IRL (soit 20 minutes IG) par rapport à l'ancienne version 2.5 car je ne sais pas à la seconde près à quoi correspond le tick affiché sur la page web par rapport à la date réelle.

J'ai considéré moi que le tick affiché est celui de la 1ère seconde de la minute actuelle. (Un peu arbitrairement, je te l'accorde. ) Ça cause visiblement des problèmes, quand moi je change de minute et que le tick change pas ou vice-versa, y a un saut de 20 minutes ig qui se fait. Bref c'est pas encore parfait, mais faudrait déterminer la valeur commune modulo 60 des dates (exprimées en secondes) où se font les mises à jour du tick... Si tant est qu'il y en ait une.

Ce qui est juste un décalage de l'ordre de 3-4 minutes ig doit venir de pertes dans le lag et tout ça. Ça se décale le temps que le serveur qu'est pas une flèche fasse les calculs (6 appels à atysdate() !), te renvoie la page, qu'elle s'affiche... J'ai ce décalage quand je prends la page sur le serveur mais moins quand je la prends en local.

Je devrais peut-être faire un petit javascript pour mettre l'affichage de la page à jour tous les x ms, mais ça c'est secondaire.

Je verrais tout ça quand j'aurais le temps.

houlecorn wrote:J'ai considéré moi que le tick affiché est celui de la 1ère seconde de la minute actuelle. (Un peu arbitrairement, je te l'accorde. ) Ça cause visiblement des problèmes, quand moi je change de minute et que le tick change pas ou vice-versa, y a un saut de 20 minutes ig qui se fait.

J'ai été confronté excactement aux mêmes problèmes.
Tout d'abord j'avais considéré aussi la 1ère seconde de la minute actuelle comme toi mais j'ai abandonné car cela m'a apporté encore plus d'instabilité au lieu d'en apporter.
Au final j'interroge toutes les minutes (environs) le site web. Dans ce cas on peu avoir un temps de réponse qui dépasse la minutes d'une seconde ou deux à cause du traitement et du coups on peu avoir parfois 1 tick qui passe entre les mailles du filet. Ceci produit un saut de 20 minutes IG.
Visuellement c'est très très désagréable.
C'est également pour détecter cela que je fais intervient le calcule de base de temps (BDT). Si la base de temps est cohérrante (entre 18 et 22) il n'y a pas eu de tick loupé. Si la base de temps saute à 30 par exemple tu peux être sûr qu'il y a un tick de loupé entre les deux interrogations.

houlecorn wrote: ... faudrait déterminer la valeur commune modulo 60 des dates (exprimées en secondes) où se font les mises à jour du tick... Si tant est qu'il y en ait une.

Je n'ai pas trouvé de solution. C'est obligatoirement arbitraire car l'incertitude des 20 minutes IG est chronique dans ce système. La seul solution serai de publier sur la page web l'heure du serveur en plus du tick.

houlecorn wrote: Ce qui est juste un décalage de l'ordre de 3-4 minutes ig doit venir de pertes dans le lag et tout ça. Ça se décale le temps que le serveur qu'est pas une flèche fasse les calculs (6 appels à atysdate() !), te renvoie la page, qu'elle s'affiche... J'ai ce décalage quand je prends la page sur le serveur mais moins quand je la prends en local.

Oui tout a fait ^^ il faut voir que 1 minutes IRL = 20 IG et donc 10 secondes IRL = 3 minutes IG ! Le temps passe vite sur atys ! Pour un site web cela me semble très acceptable quand même

j'admire tout ce travail, vraiment c'est génial
bravo a tous

C'est également pour détecter cela que je fais intervient le calcule de base de temps (BDT). Si la base de temps est cohérrante (entre 18 et 22) il n'y a pas eu de tick loupé. Si la base de temps saute à 30 par exemple tu peux être sûr qu'il y a un tick de loupé entre les deux interrogations.

Mouaip, mais dans un script PHP c'est pas aussi facile à faire... Surtout si on veut une utilisation facile, je veux dire la version 'light' sans base de données.
J'aurais bien aimé savoir (VL, tu nous entends ? =D) comment ça marche un peu dedans l'API... est-ce que le tick se met à jour à chaque affichage de la page si le dernier appel date de plus de 60 secondes, où à la seconde x chaque minute ?

J'ai pas pu récupérer d'informations comme la date de modification du fichier, de toute façon je pense qu'elle doit être générée à chaque appel et pas statique et modifiée régulièrement.

Donc à moins d'un coup de main, je pense que je ne vais pas pouvoir faire avec l'API de VL aussi précis qu'avec les logs... L'idéal étant bien sûr d'avoir une correspondance temps ig/ temps irl, du style "date de mise à jour - tick" comme dans les logs.

Reste à savoir si il est important ou utile d'avoir une horloge ig qui est à moins de 20 minutes près. Pour récapituler, si ce décalage vous gène, continuez avec les fichiers logs (calendrier.php et éventuellement goodtimes.php) et si il ne vous gène pas, la version 2 vous épargne le mal de se soucier des logs ! (calendrier_v2.php)

Oui, mais pour utiliser le ServerTick des logs encore faut-il être IG. Là, je suppose que le but est de faire un outil utilisable n'importe où et quand.